lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <388009b205bbb4046cdad4124e7e447d8f16d6dc.camel@interlinx.bc.ca> Date: Sat, 05 Jul 2025 12:20:43 -0400 From: "Brian J. Murrell" <brian@...erlinx.bc.ca> To: netdev@...r.kernel.org Subject: nftables, prerouting and rate limiting Hello. I'm hoping somebody can clarify something for me. I understand that I can create filter rules that can rate limit connections by creating first, an un-rate-limited rule that allows "established" packets and then after that rule, create rules that allow whatever various connections I want to allow and apply the rate limiting on those rules. Effectively the rate limiting is only be applied to the initial packets that are establishing a connection since all other packets in a connection will be processed by the first, "established connections" rule (without a rate-limit on it). Very straightforward. Where it gets fuzzy for me is with "type nat hook postrouting priority srcnat" chains. If I have a chain: chain dstnat { type nat hook prerouting priority dstnat; policy accept; iifname { "eth0.2", "pppoe-wan1" } jump dstnat_wan comment "!fw4: Handle wan IPv4/IPv6 dstnat traffic" } along with: chain dstnat_wan { meta nfproto ipv4 tcp dport 25 limit rate 10/minute burst 5 packets counter packets 301 bytes 17120 dnat ip to 10.75.22.9:25 comment "SMTP" } In that case, is the rate limiting being applied to only connection establishing packets (i.e. SYN, SYN/ACK three-way handshake packets in the case of TCP as similar to the above description for the filter case) or is it applying to every packet in the connection/stream? Ultimately I am trying to figure out if I need to be using a different accounting scale on rate limiting for dnat rules than I use for filter rules because for the former do I need to account for every packet in a connection/stream being counted vs. the latter where I only need to account for the initial connection establishing packets being counted? Cheers, b.
Powered by blists - more mailing lists