Trouble accessing certain websites

Azuriye · July 9, 2024, 6:38pm

is there a way to set mtu's independently? maybe 1428 for ipv6 and 1492 for ipv4?

brada4 · July 9, 2024, 6:54pm

You will not lose much setting 1360 as cloudflare does.

Ramon · July 9, 2024, 7:10pm

Yes you can independently set them, but indeed just bulk changing it to 1448 or 1360 does not cost that much bandwidth

Azuriye · July 9, 2024, 8:34pm

Any idea how you derived 1448?

Ramon · July 9, 2024, 9:03pm

For the 1448 see above from egc

brada4 · July 9, 2024, 9:26pm

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.

Azuriye · July 10, 2024, 12:56am

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

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:

github.com/openwrt/openwrt

MSS clamping does not play nice with policy-based routing (mwan3, pbr)

opened 06:02AM - 03 Mar 23 UTC

closed 01:42PM - 03 Nov 23 UTC

patrakov

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.

Azuriye · July 10, 2024, 7:10pm

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

system · July 20, 2024, 7:11pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.