> 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.
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.
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).
regards Frank
