is there a way to set mtu's independently? maybe 1428 for ipv6 and 1492 for ipv4?
brada4
July 9, 2024, 6:54pm
62
You will not lose much setting 1360 as cloudflare does.
2 Likes
Ramon
July 9, 2024, 7:10pm
63
Yes you can independently set them, but indeed just bulk changing it to 1448 or 1360 does not cost that much bandwidth
Any idea how you derived 1448?
Ramon
July 9, 2024, 9:03pm
65
For the 1448 see above from egc
1 Like
brada4
July 9, 2024, 9:26pm
66
cat /etc/nftables.d/mssfix.nft
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
oif $wan_devices tcp flags syn / syn,fin,rst tcp option maxseg size set rt mtu
}
eq.
committed 01:33PM - 03 Nov 23 UTC
Reduce scope of MSS fixup to TCP SYN packets only and relocate the fixing
of egr… ess MSS to the mangle/postrouting chain in order to properly apply
final known MTU size.
Fixes: openwrt/openwrt#12112
Signed-off-by: Andris PE <neandris@gmail.com>
[fix S-o-b tag, fix commit author, reword commit message]
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
I'm sorry, should I apply this fix? I tried this fix earlier but it didn't seem to change the situation
brada4
July 10, 2024, 4:01am
68
It wi;ll be there in next release, just save a file /etc/nftables.d/something.nft with cotent:
chain mangle_postrouting {
type filter hook postrouting priority mangle; policy accept;
oif $wan_devices tcp flags syn / syn,fin,rst tcp option maxseg size set rt mtu
}
Then tune interface MTU to whatever UDP and ICMP indicates.
It is discussed here:
opened 06:02AM - 03 Mar 23 UTC
closed 01:42PM - 03 Nov 23 UTC
bug
### Describe the bug
OpenWrt applies MSS clamping in the `firewall` and `firewa… ll4` packages, by hooking into the `FORWARD `chain of the `mangle` table, or its `nftables` equivalent. This is done on the assumption that locally generated SYN packets will never need their MSS fixed up - but I found a situation where this assumption is wrong, and packets with MSS=1460 are wrongly sent through the VPN.
### OpenWrt version
21.02.1 and 22.03.3
### OpenWrt target/subtarget
ath79/generic and mediatek/mt7622
### Device
TP-Link Archer C7 V2 and Linksys E8450
### Image kind
Official downloaded image
### Steps to reproduce
Create a usual DHCP WAN connection, and a PPTP VPN. Set the metrics, as required by mwan3 which we will install at the next step: 80 on WAN, 90 on PPTP VPN. Assign both to the WAN firewall zone. At this point we have a default routing table with two default routes with different metrics, with the traffic going over WAN, because its default route has a lower metric. In the firewall settings, enable MSS clamping for the WAN zone.
Install mwan3 and curl. Install luci-app-mwan3 if you want.
Configure mwan3. The default policies that prefer wan over wanb, and wanb over wan, should be sufficient, when "wanb" is globally replaced with "vpn" in the config where it refers to the interface name. The default policy should be wan_wanb, thus preferring the WAN. Then create a rule in mwan3: if the destination IP is 139.59.209.225 (or whatever the current IPv4 address of openwrt.org is), then use the wanb_wan policy, thus preferring the VPN. Push the rule to the top, so that it is evaluated first. Delete the load-balancing rule. Save and apply.
The result at this point should be that everything goes through the WAN, except 139.59.209.225, which goes through the VPN. The real use case is to have an ipset instead of the single IP, but for testing, a single IP will suffice.
Then, on the router itself, while observing the resulting packets, run:
```
curl -4 https://openwrt.org/
```
### Actual behaviour
The initial SYN packet indicates MSS=1460, despite the rule that fixes the MTU. If the VPN blackholes "Fragmentation Needed" packets, then the page won't load.
### Expected behaviour
The initial SYN packet should have MSS clamped to 1360.
### Additional info
Applying the MSS clamp in the POSTROUTING chain, in addition to FORWARD (or maybe instead of FORWARD?), would fix the issue. OUTPUT is not sufficient.
Let's see why the wrong MSS exists in the first place, though.
When determining the MSS for locally-created SYN packets, apparently, the kernel only looks into the default routing table. Indeed, this decision is made before running through iptables/netfilter, and therefore, the kernel cannot know that it will select a non-default routing table based on the not-yet-existing firewall mark. Therefore, as the default routing table clearly says "go through WAN, MTU=1500", it selects MSS=1460.
The stock MSS-clamping rule is applied only on forward, but the packet is locally-originated, not forwarded, so it doesn't apply.
End result: packet with MSS=1460 (which is wrong) goes out.
The POSTROUTING chain of the mangle table would still catch it.
### Diffconfig
_No response_
### Terms
- [X] I am reporting an issue for OpenWrt, not an unsupported fork.
Current code sets MSS to match incoming interface MTU i.e no-op.
1 Like
Thanks for all the help, I will monitor the situation regarding IPv6 with my ISP and update in a new thread. So far the fix was mssfix.nft and setting the MTU for pppoe-wan to 1452 (pinging from router allowed upto 1404 bytes to be sent for ipv6).
1 Like
system
Closed
July 20, 2024, 7:11pm
70
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.