Dave Taht <[email protected]> writes:
> On Tue, Sep 3, 2019 at 7:45 AM Toke Høiland-Jørgensen <[email protected]> wrote:
>>
>> Dave Taht <[email protected]> writes:
>>
>> > On Tue, Sep 3, 2019 at 5:23 AM Mikael Abrahamsson <[email protected]> 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
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
