Dave Taht <dave.t...@gmail.com> writes: > On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >> Dave Taht <dave.t...@gmail.com> writes: >> >> > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson <swm...@swm.pp.se> wrote: >> >> >> >> On Mon, 2 Sep 2019, Dave Taht wrote: >> >> >> >> > with copy-pasted parameters set in the 90s - openwrt's default, last I >> >> > looked, was 25/sec. >> >> >> >> -A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit >> >> --limit 25/sec --limit-burst 50 -m comment --comment "!fw3" -j RETURN >> >> -A syn_flood -m comment --comment "!fw3" -j DROP >> >> >> >> Well, it's got a burst-size of 50. I agree that this is quite >> >> conservative. >> >> >> >> However, at least in my home we're not seeing drops: >> >> >> >> # iptables -nvL | grep -A 4 "Chain syn_flood" >> >> Chain syn_flood (1 references) >> >> pkts bytes target prot opt in out source >> >> destination >> >> 2296 113K RETURN tcp -- * * 0.0.0.0/0 >> >> 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* >> >> !fw3 */ >> >> 0 0 DROP all -- * * 0.0.0.0/0 >> >> 0.0.0.0/0 /* !fw3 */ >> >> >> >> But you might be right that in places with a lot more clients then this >> >> might indeed cause problems. >> > >> > Well, *I* long ago had upped those params by 10x and don't see syn >> > drops either on my backbone. But I rather suspect the rest of the >> > world just copy-pasted it. It should scale as a function of bandwidth, >> > I suppose, or get updated as a side effect of setting QoS - or just >> > get bumped up. Start a bug over with openwrt? Take a hard look at >> > other firewall designs? >> >> FWIW: >> >> # iptables -nvL syn_flood >> Chain syn_flood (1 references) >> pkts bytes target prot opt in out source >> destination >> 195K 12M RETURN tcp -- * * 0.0.0.0/0 >> 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 >> */ >> 0 0 DROP all -- * * 0.0.0.0/0 >> 0.0.0.0/0 /* !fw3 */ >> >> # ip6tables -nvL syn_flood >> Chain syn_flood (1 references) >> pkts bytes target prot opt in out source >> destination >> 396 41508 RETURN tcp * * ::/0 ::/0 >> tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ >> 0 0 DROP all * * ::/0 ::/0 >> /* !fw3 */ >> >> rebooted this box today; don't seem to have hit the limit thus far, >> though... This is on a gigabit link. > > Hmm. Try to trigger it with --te=upload_streams=200 ?
Sure, that triggers it: # iptables -nvL syn_flood Chain syn_flood (1 references) pkts bytes target prot opt in out source destination 197K 12M RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 25/sec burst 50 /* !fw3 */ 275 16480 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ And I get tons of errors from netperf failing to start up. However, the protection is only actually enabled for the INPUT chain; i.e., I had to use the router itself as the netperf target to trigger the rule. So not sure a rule such as this would be the cause of your coffee shop failures? This is with the default openwrt config, BTW: config defaults option syn_flood '1' -Toke _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat