I'm troubleshooting an extremely strange MTU issue in my LAN. I was able to reach my LAN server in IPv4 with MTU = 1500, but IPv6 is capped to MTU = 1492.
ICMP Mystery
I was able to reach my LAN server in IPv4 with MTU = 1500:
[user@workstation ~]$ ping -c 1 -M do -s 1472 -4 freebsd.lan
PING freebsd.lan (192.168.0.103) 1472(1500) bytes of data.
1480 bytes from freebsd.lan (192.168.0.103): icmp_seq=1 ttl=64 time=0.527 ms
--- freebsd.lan ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.527/0.527/0.527/0.000 ms
By capturing the IPv4 ping via Wireshark, I can confirm Layer-2 (Ethernet) is capable of sending a 1500-byte payload.
127 4.947145000 192.168.0.222 192.168.0.103 ICMP 1514 Echo (ping) request id=0xd887, seq=1/256, ttl=64 (reply in 128)
128 4.947485151 192.168.0.103 192.168.0.222 ICMP 1514 Echo (ping) reply id=0xd887, seq=1/256, ttl=64 (request in 127)
But for some reason, I cannot do the same via IPv6. No ping larger than 1444 bytes can be sent. The system claims the maximum MTU is 1492 bytes.
[user@workstation ~]$ ping -c 1 -M do -s 1444 -6 freebsd.lan
PING freebsd.lan (<REDACTED SERVER IPv6>) 1444 data bytes
1452 bytes from freebsd.lan (<REDACTED SERVER IPv6>): icmp_seq=1 ttl=64 time=0.365 ms
--- freebsd.lan ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.365/0.365/0.365/0.000 ms
[user@workstation ~]$ ping -c 1 -M do -s 1445 -6 freebsd.lan
PING freebsd.lan (<REDACTED SERVER IPv6>) 1445 data bytes
ping: local error: message too long, mtu: 1492
--- freebsd.lan ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
If one attempts to send a ping packet greater than 1444 bytes:
[user@workstation ~]$ ping -M want -s 1445 -6 freebsd.lan
PING freebsd.lan (<REDACTED SERVER IPv6>) 1445 data bytes
1453 bytes from freebsd.lan (<REDACTED SERVER IPv6>): icmp_seq=1 ttl=64 time=0.636 ms
This results in host-side fragmentation:
12983 128.384569597 <REDACTED CLIENT IPv6> <REDACTED SERVER IPv6> IPv6 1502 IPv6 fragment (off=0 more=y ident=0x7886f1ab nxt=58)
12984 128.384572667 <REDACTED CLIENT IPv6> <REDACTED SERVER IPv6> ICMPv6 75 Echo (ping) request id=0x7f1a, seq=7, hop limit=64 (reply in 12986)
12985 128.384936914 <REDACTED SERVER IPv6> <REDACTED CLIENT IPv6> IPv6 1502 IPv6 fragment (off=0 more=y ident=0xd0939359 nxt=58)
12986 128.384937084 <REDACTED SERVER IPv6> <REDACTED CLIENT IPv6> ICMPv6 75 Echo (ping) reply id=0x7f1a, seq=7, hop limit=64 (request in 12984)
WireGuard slowdowns
This issue is bidirectional, affecting both the server and the client in the same LAN.
The original problem was discovered when a IPv6 WireGuard tunnel to the server had extremely low performance, in comparison to the unencrypted LAN. But performance could be restored by reducing the default MTU from 1420 bytes to 1412 bytes. This is consistent with a standard Ethernet MTU with 8 bytes "stolen".
When MTU = 1413 (1 byte over limit) is set within the WireGuard tunnel, server uploading performance is extremely low:
root@freebsd:~ # ifconfig wg1 mtu 1413
Benchmarking with iperf3 shows:
[user@workstation ~]$ iperf3 -c 10.101.0.1 -R
Connecting to host 10.101.0.1, port 5201
Reverse mode, remote host 10.101.0.1 is sending
[ 5] local 10.101.0.101 port 44834 connected to 10.101.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 77.5 MBytes 650 Mbits/sec
[ 5] 1.00-2.00 sec 77.6 MBytes 651 Mbits/sec
[ 5] 2.00-3.00 sec 78.0 MBytes 654 Mbits/sec
[ 5] 3.00-4.00 sec 77.8 MBytes 652 Mbits/sec
[ 5] 4.00-5.00 sec 77.4 MBytes 649 Mbits/sec
[ 5] 5.00-6.00 sec 77.9 MBytes 653 Mbits/sec
[ 5] 6.00-7.00 sec 77.9 MBytes 653 Mbits/sec
[ 5] 7.00-8.00 sec 78.5 MBytes 659 Mbits/sec
[ 5] 8.00-9.00 sec 78.8 MBytes 661 Mbits/sec
[ 5] 9.00-10.00 sec 77.4 MBytes 649 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 779 MBytes 653 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 779 MBytes 653 Mbits/sec receiver
iperf Done.
Wireshark captures showed packet fragmentation:
346923 4.432234927 <REDACTED SERVER IPv6> <REDACTED CLIENT IPv6> IPv6 1502 IPv6 fragment (off=0 more=y ident=0x9e670e98 nxt=17)
346924 4.432234977 <REDACTED SERVER IPv6> <REDACTED CLIENT IPv6> WireGuard 75 Transport Data, receiver=0xBC9E6B8A, counter=159837, datalen=1413
When MTU = 1412 is set within the WireGuard tunnel, server uploading performance is nearly doubled.
root@freebsd:~ # ifconfig wg1 mtu 1412
Benchmarking with iperf3 shows:
[user@workstation ~]$ iperf3 -c 10.101.0.1 -R
Connecting to host 10.101.0.1, port 5201
Reverse mode, remote host 10.101.0.1 is sending
[ 5] local 10.101.0.101 port 37592 connected to 10.101.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 125 MBytes 1.05 Gbits/sec
[ 5] 1.00-2.00 sec 126 MBytes 1.05 Gbits/sec
[ 5] 2.00-3.00 sec 123 MBytes 1.03 Gbits/sec
[ 5] 3.00-4.00 sec 127 MBytes 1.06 Gbits/sec
[ 5] 4.00-5.00 sec 124 MBytes 1.04 Gbits/sec
[ 5] 5.00-6.00 sec 127 MBytes 1.07 Gbits/sec
[ 5] 6.00-7.00 sec 125 MBytes 1.05 Gbits/sec
[ 5] 7.00-8.00 sec 126 MBytes 1.06 Gbits/sec
[ 5] 8.00-9.00 sec 125 MBytes 1.05 Gbits/sec
[ 5] 9.00-10.00 sec 124 MBytes 1.04 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.22 GBytes 1.05 Gbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.22 GBytes 1.05 Gbits/sec receiver
iperf Done.
Packet capture notes
To prevent packet combination via network offloading, all packets are captured after running sudo ethtool -K ens8 gso off gro off lro off tso off.
Question
I cannot find the source of the capped MTU, since all Ethernet interfaces are set to use 1500-byte MTU in the LAN.
On the client:
[root@workstation ~]# ip link show dev ens8
4: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether <REDACTED CLIENT MAC> brd ff:ff:ff:ff:ff:ff
altname enp0s8
On the server:
root@freebsd:~ # ifconfig vtnet0
vtnet0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=ec079b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS>
ether <REDACTED SERVER MAC>
inet 192.168.0.103 netmask 0xffffff00 broadcast 192.168.0.255
inet6 <REDACTED SERVER IPv6>%vtnet0 prefixlen 64 scopeid 0x1
inet6 <REDACTED SERVER IPv6> prefixlen 64 autoconf pltime 2700 vltime 5400
inet6 <REDACTED SERVER IPv6> prefixlen 64 autoconf pltime 2700 vltime 5400
media: Ethernet autoselect (10Gbase-T <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
I assumed the MTU was automatically capped via PMTUD by the Linux kernel, after it discovers that MTU = 1500 doesn't work over the Ethernet (perhaps due to VLAN tagging, or nested Q-in-Q VLAN tagged). However, IPv4 worked over the same Ethernet, so this hypothesis can be ruled out unless my middleboxes are mangling packets in a way that is unexpected (the Ethernet switch, or the Proxmox hypervisor that runs my FreeBSD).
What is capping my IPv6 MTU in the LAN?
Summary:
On Linux, network interfaces may use a IPv6-specific MTU. This is controlled via sysctl net.ipv6.conf.eth0.mtu (where eth0 is the interface name). Ordinary network tools such as ifconfig or ip link do not see this IPv6-specific MTU. Always check net.ipv6.conf.eth0.mtu to troubleshoot IPv6 MTU.
IPv6 routers can override a client's MTU via Router Advertisement (i.e. Linux kernel learns the MTU from an RA, then changes net.ipv6.conf.eth0.mtu automatically).
By default, on OpenWrt, if no MTU is set explicitly on the br-lan interface, the interface inherits the MTU of the WAN. If the upstream WAN uses PPPoE, OpenWrt's br-lan's IPv6 MTU is reduced to 1492 bytes. As a result, the WAN-level MTU is applied to the entire IPv6 LAN as well. This ensures good compatibility without triggering Path MTU Discovery (PMTUD), but the behavior can be surprising.
There's no perfect solution to this problem, there are a few workarounds:
MTU = 1500 can be set explicitly on the router. In this case, clients rely on IPv6's PMTUD for WAN connections. Furthermore, OpenWrt enables the firewall's mtu_fix option by default, which rewrites the MSS during TCP handshakes, there should be no connectivity problems in case of PMTUD black holes. However, other systems may need explicit nftables tcp option maxseg size set rt mtu or ip6tables --clamp-mss-to-pmtu rule on the WAN interface.
The router-advertised MTU can be ignored on Linux by setting sysctl net.ipv6.conf.eth0.accept_ra_mtu = 0. This is not recommended, one should fix the router configuration instead.
Accept a reduced MTU, reduce the MTU of any tunnel over IPv6, even if the said tunnel runs over LAN only. This is the best for compatibility, since PMTUD is never triggered, there's no penalty of latency, and no risk of encountering a PMTUD black hole due to restrictive firewalls. However, this may impact LAN applications that assume MTU = 1500 by default.
On Linux, IPv6's per-interface MTU can be controlled separately via the sysctl option net.ipv6.conf.eth0.mtu (where eth0 is the interface name). One can check the IPv6 MTU via sysctl or /proc/sys
[root@workstation ~]# sysctl net.ipv6.conf.ens8.mtu
net.ipv6.conf.ens8.mtu = 1492
[root@workstation ~]# cat /proc/sys/net/ipv6/conf/ens8/mtu
1492
In IPv6, a router can override the client-side MTU using a Router Advertisement via the ICMPv6 Option MTU (in comparison, this is only supported in IPv4 via DHCP Option 26, not built natively into the protocol).
The existence of a separate IPv6 MTU is primarily meant to support this use case. On Linux, the default MTU is overridden by the router if the sysctl option net.ipv6.conf.eth0.accept_ra_mtu = 1 (where eth0 is the interface name). This is true on the OP's machine.
[root@workstation ~]# sysctl net.ipv6.conf.ens8.accept_ra_mtu
net.ipv6.conf.ens8.accept_ra_mtu = 1
[root@workstation ~]# cat /proc/sys/net/ipv6/conf/ens8/accept_ra_mtu
1
One can audit these Router Advertisement by capturing ICMPv6 traffic while reconnecting to the LAN.
Frame 1088: 230 bytes on wire (1840 bits), 230 bytes captured (1840 bits) on interface ens8, id 0
Section number: 1
Interface id: 0 (ens8)
Encapsulation type: Ethernet (1)
Arrival Time: Jul 22, 2026 07:29:03.371527678 UTC
UTC Arrival Time: Jul 22, 2026 07:29:03.371527678 UTC
Epoch Arrival Time: 1784705343.371527678
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 0.000868205 seconds]
[Time delta from previous displayed frame: 0.000868205 seconds]
[Time since reference or first frame: 77.127397136 seconds]
Frame Number: 1088
Frame Length: 230 bytes (1840 bits)
Capture Length: 230 bytes (1840 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ipv6:icmpv6]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: OpenWrt_<REDACTED> (<REDACTED MAC>), Dst: <REDACTED> (<REDACTED MAC>)
Internet Protocol Version 6, Src: <REDACTED LOCAL IPv6>, Dst: <REDACTED LOCAL IPv6>
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0xc03a [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0xc0, Managed address configuration, Other configuration, Prf (Default Router Preference): Medium
Router lifetime (s): 1800
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : <REDACTED MAC>)
ICMPv6 Option (MTU : 1492)
ICMPv6 Option (Prefix information : <REDACTED PREFIX>)
ICMPv6 Option (Prefix information : <REDACTED PREFIX>)
ICMPv6 Option (Route Information : Medium <REDACTED SUBNET>)
ICMPv6 Option (Route Information : Medium <REDACTED SUBNET>)
ICMPv6 Option (Recursive DNS Server <REDACTED DNS>)
ICMPv6 Option (Advertisement Interval : 600000)
[Community ID: 1:bJ6Xku6RNs+Y5zoN6ERqUZNmVc8=]
There's ICMPv6 Option (MTU : 1492), which causes all IPv6 clients to change their respective IPv6 MTU.
This MTU originated from the PPPoE WAN connection on the OpenWrt router. Tho OpenWrt router redistributes this MTU to all IPv6 clients in the LAN as well.
7: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc noqueue state UNKNOWN qlen 3
link/ppp
inet <REDACTED IPv4> peer <REDACTED IPv4> scope global pppoe-wan
valid_lft forever preferred_lft forever
inet6 <REDACTED IPv6> scope global dynamic noprefixroute
valid_lft 259041sec preferred_lft 172641sec
inet6 <REDACTED IPv6> scope link flags 02
valid_lft forever preferred_lft forever
Fix MTU on OpenWrt
On the surface, the problem is caused by a low MTU advertised by OpenWrt's odhcpd for compatibility, so it appears fixable by changing dhcp.lan.ra_mtu. However, this doesn't work in my case, and ultimately I identified the real problem: br-lan inherited the MTU from pppoe-wan.
Explicit br-lan MTU
I discovered that if no MTU is set explicitly on the br-lan interface, it inherits the MTU of the WAN. As a result, the WAN-level MTU is applied to the entire IPv6 LAN as well. The IPv6 Router Advertisement merely advertised the actual MTU of the router's LAN bridge.
root@OpenWrt:~# sysctl net.ipv6.conf.br-lan.mtu
net.ipv6.conf.br-lan.mtu = 1492
Also, it must be emphasized again that this IPv6-specific MTU is not visible via ip link or the OpenWrt "luci" Web GUI.
root@OpenWrt:~# ip link show dev br-lan
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether <REDACTED MAC> brd ff:ff:ff:ff:ff:ff
This problem can be fixed by setting br-lan MTU to 1500 explicitly. In the GUI, click Network -> Interfaces -> Devices -> br-lan Configure.... Use MTU 1500, IPv6 MTU 1500.
The equivalent CLI operation is to make the following change to /etc/config/network.
--- /etc/cotfig/network 2026-07-22 10:56:48.059435325 +0000
+++ /etc/config/network 2026-07-22 10:57:24.000000000 +0000
@@ -14,6 +14,8 @@ config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
+ option mtu '1500'
+ option mtu6 '1500'
When done, reboot the router and ensure the new net.ipv6.conf.br-lan.mtu has taken effects:
root@OpenWrt:~# sysctl net.ipv6.conf.br-lan.mtu
net.ipv6.conf.br-lan.mtu = 1500
Verify Solution
Restart all servers and clients in the LAN, and the problem should fix itself. There's no need to follow Adjust Router Advertisement MTU in the following section.
Once br-lan's IPv6 MTU is in effect, on the client, check the per-interface IPv6 MTU. It now reads 1500.
[root@workstation ~]# sysctl net.ipv6.conf.ens8.mtu
net.ipv6.conf.ens8.mtu = 1500
For further confirmation, capture the IPv6 RA via Wireshark. The RA packet now reads ICMPv6 Option (MTU : 1500).
Frame 22: 230 bytes on wire (1840 bits), 230 bytes captured (1840 bits) on interface ens8, id 0
Ethernet II, Src: OpenWrt_<REDACTED> (<REDACTED MAC>), Dst: <REDACTED> (<REDACTED MAC>)
Internet Protocol Version 6, Src: <REDACTED>, Dst: <REDACTED>
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0xbb62 [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0xc0, Managed address configuration, Other configuration, Prf (Default Router Preference): Medium
Router lifetime (s): 1800
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : <REDACTED MAC>)
ICMPv6 Option (MTU : 1500)
ICMPv6 Option (Prefix information : <REDACTED PREFIX>)
ICMPv6 Option (Prefix information : <REDACTED PREFIX>)
ICMPv6 Option (Route Information : Medium <REDACTED SUBNET>)
ICMPv6 Option (Route Information : Medium <REDACTED SUBNET>)
ICMPv6 Option (Recursive DNS Server <REDACTED DNS>)
ICMPv6 Option (Advertisement Interval : 600000)
[Community ID: 1:wmc+WttgQx5kxx+dm2vrqIJcDKg=]
Adjust OpenWrt's IPv6 Router Advertisement MTU
On OpenWrt, the default MTU in Router Advertisement as advertised by odhcpd. If br-lan's MTU is fixed to 1500, OpenWrt's Router Advertisement should now advertise the correct value, so this section is not necessary. It's only included here for completeness.
Warning: It's not possible to set a higher MTU than br-lan, fix your br-lan, and don't touch dhcp.lan.ra_mtu.
To change the IPv6 RA MTU, use:
# uci set dhcp.lan.ra_mtu='1500'
# uci commit
In the GUI, it's located under Network -> Interfaces -> LAN (br-lan) -> Edit -> DHCP Server -> IPv6 RA Settings -> RA MTU.
Both methods ultimately modifies the underlying configuration file is /etc/config/dhcp, under config dhcp 'lan', option ra_mtu '1500'.
--- /etc/config/dhcp 2026-07-22 08:06:50.513601181 +0000
+++ /etc/config/dhcp 2026-07-22 08:08:09.000000000 +0000
@@ -25,6 +25,7 @@ config dhcp 'lan'
option ra 'server'
list ra_flags 'managed-config'
list ra_flags 'other-config'
+ option ra_mtu '1500'
config dhcp 'wan'
option interface 'wan'
The Futility of ra_mtu
The reader should be warned that unilaterally adjusting dhcp.lan.ra_mtu won't work without fixing the underlying interface first. If ra_mtu is greater than the interface's IPv6 MTU, the value is clamped back, with a following warning message in logread:
Wed Jul 22 08:44:32 2026 daemon.warn odhcpd[1959]: Clamped invalid ra_mtu value configured for interface 'lan' to 1492
As of 2026, the clamping logic is implemented in odhcpd source code src/config.c, line 1544:
iface->if_mtu = odhcpd_get_interface_config(iface->ifname, "mtu");
if ((c = tb[IFACE_ATTR_RA_MTU])) {
uint32_t original_ra_mtu, ra_mtu;
original_ra_mtu = ra_mtu = blobmsg_get_u32(c);
if (ra_mtu < RA_MTU_MIN)
ra_mtu = RA_MTU_MIN;
else if (ra_mtu > RA_MTU_MAX)
ra_mtu = RA_MTU_MAX;
if (iface->if_mtu && ra_mtu > iface->if_mtu)
ra_mtu = iface->if_mtu;
iface->ra_mtu = ra_mtu;
if (original_ra_mtu != ra_mtu) {
warn("Clamped invalid %s value configured for interface '%s' to %d",
iface_attrs[IFACE_ATTR_RA_MTU].name, iface->name, iface->ra_mtu);
}
}
As expressed in the source code, the user-specific ra MTU is capped by the link MTU via odhcpd_get_interface_config(), which is implemented in src/odhcpd.c, line 195.
/* Read IPv6 MTU for interface */
int odhcpd_get_interface_config(const char *ifname, const char *what)
{
char buf[64];
snprintf(buf, sizeof(buf), "/proc/sys/net/ipv6/conf/%s/%s", ifname, what);
int fd = open(buf, O_RDONLY);
if (fd < 0)
return -1;
ssize_t len = read(fd, buf, sizeof(buf) - 1);
close(fd);
if (len < 0)
return -1;
buf[len] = 0;
return atoi(buf);
}
As shown here, the link-level cap is read from /proc/sys/net/ipv6/conf/br-lan/mtu, showing that it's not possible to set a IPv6 RA MTU higher than the interface that odhpcd runs on.
