Forcing MTU setting for LAN devices

Installing and Using OpenWrt
1

I've migrated to OpenWRT from DD-WRT and have been able to get most things working, but some issues I've been unable to resolve. I'm running OpenWrt 23.05.0 r23497-6637af95aa.

The biggest issue is getting MTU settings to take for LAN Devices. With the default MTU of 1500 many sites do not work though a Wireguard tunnel. When an MTU of 1380 is manually set on a PC those same sites works fine. The MTU for the WG tunnel is set for 1380.

Looking at what has been recommended in the forum, I've set "option MTU '1380' for the lan interface in the network config file, and the dhcp file for the lan interface, but the MTU for LAN devices remains unchanged and is always set for 1500.

Have any of you experts been able to get an MTU size of other than 1500 to take for DHCP clients?

Thanks.

2

Apply this patch:

i,e download 2 raw files post-patch to the device to get sneak-peek into current master branch.

1 Like
3

Did you create thewireguard interface?

4

Yes, the MTU is the issue.

5

Thanks much. Will give this a try tomorrow.

6

sysupgrade friendly shortcut, will yield duplicate rule once patch is propagated.

Save in /etc/nftables.d/mssfix.nft (any name with .nft extension)

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 run

fw4 check

if no errors shown

service firewall restart
1 Like
7

Lowering the MTU is a workaround. Maybe the issue is IPv6 only and caused by blocking specific ICMPv6 packets either on the PC or somewhere enroute, maybe your own router, maybe an isp router. So instead of lowering you could also check ik you are blocking. If ISP is doing it then there is no solution other than lowering MTU.

Hope this helps

8

The problem is that TCP SYN is very small, no icmp packets generated on path, they get there later when actual data comes in.

9

Only IPV4 is in use and my understanding is Wireguard requires an MTU of 1420 or less to allow for packet overhead. The ISP uses PPPoE so there's a packet size limitation of 1492 even before WG requirements are accounted for.

These tunnels worked fine with DD-WRT on the same hardware with the reduced MTU setting (DD-WRT had many other severe issues), and the tunnels work fine if the MTU is to 1380 in the PC OS.

Even if it's a workaround, is there anything an end user can do in this situation except lower the MTU?

Edit: Thinking back (years) the MTU setting on my old DD-WRT firmware wasn't for the LAN, it was for the WG tunnel itself, so the router was dealing with the packet size.

10

No, if network frame fits X bytes end to end it can not carry more data. Buy optical fibre end to end and run whatever fc jumbo mpls converge:ce you like

11

Generally speaking, you don't need to limit your lan MTU, nor would you want to (you want your lan traffic to be as efficient as possible).

The router should handle the MTU 'translation' as a function of setting the MTU on the upstream interface (that is to say, set the MTU on the WG interface), and be sure to enable MSS fix on the firewall zone that includes the WG network.

3 Likes
12

Good spotting - check "fw print | less" and apply mss fix to wg interface not necessarily adding it to wans

13

I had MSS Clamping enabled early on but it seemed to be causing problems. Will give it another try.

14

At present 23.05.4 it applies MSS fix in wrong place where target MTU is not yet known.
It would work if you connected MTU9000 devices on LAN side and MSS would be fixed to nominal 1500

15

Enabling MSS clamping in my Wireguard firewall zone does solve the problem. Maybe the MSS fix is in the right place if enabled in a dedicated firewall zone? I believe the last time I had it enabled it was in the WAN zone. Hopefully that's all that's needed.

Thank everyone for the assistance.

16

You can leave workaround forever, mss clamp checkbox will add duplicate rule next to it with some firewall4 upgrade in future.
a fork rooter has similar fixups since ages.

17

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