On Tue, May 04, 2021 at 12:54:24PM +0200, Frank Wunderlich wrote:
> > Gesendet: Montag, 03. Mai 2021 um 23:32 Uhr
> > Von: "Pablo Neira Ayuso" <pablo@xxxxxxxxxxxxx>
>
> > On Mon, May 03, 2021 at 08:56:48PM +0200, Frank Wunderlich wrote:
> > I have updated the wiki: you have to mangle the TCP MSS options of the
> > original syn and the reply syn+ack packets.
>
> does old rule not match both directions (syn and syn+ack)? it looks like
> you have only removed the "oifname ppp0"
>
> > > but imho this should affect 5.12 and 5.10 without flowtable too
> > > (because limit is the ppp-tunnel in default Gateway), right?? so it
> > > looks like flowtable in 5.10 breaks the Path Discovery or prevents
> > > fragmentation which should normally happen if packets are too big.
> >
> > Did you try with the rule that mangles both the original syn and the
> > reply syn+ack packets? Do not restrict mangling to oifname pppoe0.
>
> my last tests were completely without any mss fix, so i should have
> always the problem with and without flowtable in all
> Kernel-versions. but i had the problem only in 5.10 with flowtable,
> so i guess flowtable in 5.10 blocks the normal behaviour or adding
> additional headers internally which prevents a normal forward.
You also need TCP clamp MTU in a non-flowtable setup.
> my current rule is this (only on main-router without any extensive tests...):
>
> chain FORWARD {
> type filter hook forward priority 0; policy drop;
> #https://wiki.nftables.org/wiki-nftables/index.php/Mangling_packet_headers
> #MSS fix for pppoe 1500 - 8 (pppoe) - 20 (ipv4) - 20 (TCP)
> oifname $ifwan tcp flags syn tcp option maxseg size set 1452
>
> $ifwan is my ppp8, and "tcp flags syn" imho should match syn and syn+ack.
syn+ack matches iifname $ifwan.
> Dropping the "oifname pppX" makes no sense for me as the
> ppp-interface is the bottleneck. why should i watch for tcp-packets
> on lan-only where every interface has the mtu 1500? imho i need to
> limit only the packets going through the bottleneck on my side. The
> other side should be handled by ISP (but with syn and syn-ack i
> watch both directions and modify if needed).
>
> btw. i read that the flow offload makes a bypass resulting that
> further rules are not processed, right?
>
> i have some limits in formward-chain, that may be skipped.
>
> example:
>
> chain FORWARD {
> type filter hook forward priority 0; policy drop;
> oifname $ifwan tcp flags syn tcp option maxseg size set 1452
> ip protocol { tcp, udp } flow add @f
> oifname $ifexternal ip saddr $iprangesblocked jump REJECTED comment "block internal ip ranges to have only internal access"
> udp dport {41,43,44,58,59,60} jump REJECTED comment "block ipv6 in ipv4 tunnel"
>
> is it true that bottom 2 rules are not processed due to the
> flowtable? i guess (!) flowtable only affects established
> connections where bottom 2 rules prevent this ("connections" do not
> enter established state because dropped on first packet).
Only the two initial syn and syn+ack packets follow the classic
forwarding path. Therefore, the FORWARD chain in your example above is
evaluated only for the two initial packets of the TCP connection.
You should add the 'flow add' rule at the bottom of your ruleset in
your example above.
