MTU entered above 1280 not persistant after boot for IPv6 tunnel interface and not used for VPN #7451
Comments
|
I have added a request in the forum a while ago and updated it for the second time yesterday after the contact with HE. There have been quite some readers, but no comments from others so far. Search on the internet reveals there have been others reporting the same thing about MTU for OPNsense, but on earlier versions than 24.1.6. https://forum.opnsense.org/index.php?topic=39964.0 I consider the inability to keep the entered MTU active at the desired seeting after boot and the missing impact to the VPN a bug in OPNsense. I suppose the cerise label "support" means that OPNsense don't agree and refers me to the community, right? |
|
Feel free to propose a PR with the desired code changes. Until these changes are clear there is no use relabelling this to anything else. I’m on a vacation today as well so don’t expect qualified input too soon. That being said I’ve rarely heard this is a real world problem and if so only in intermittent problems that have been solved with users before without the need for a generic request to „fix the bug“. |
|
Enjoy holiday and be assured that I don’t expect instant changes. I sometimes do PLC programming and bug finding at work in structured text, is quite good at it, but have no experience of source code for routers. I look around in the public part of the source code for OPNsense GUI, API and systems backend, but really don’t know where to look, maybe these functions are at the frontend anyway… So I’m afraid that I kindly have to ask you look into this when you have the possibility.
I believe there is something, so yes please I suggest a PR!
A recap… I followed the guidance on Configure IPv6 Tunnel Broker — OPNsense documentation<https://docs.opnsense.org/manual/how-tos/ipv6_tunnelbroker.html>. With regards to GIF interface there are limited settings, just added the IP’s and then was none of the options ticked. Route caching removed from GUI and replaced by Disable Ingress filtering in current version, but no asymmetric network here and then not ticked. No option to control MTU or MSS exist on GIF.
Next step was assigning GIF tunnel as a new interface (Opt1) and this interface is where I later set MTU to 1480. Not much guidance given, so nothing was ticked or entered except description. IPv4 Configuration Type and IPv6 Configuration Type are both set to none. I actually tried setting IPv6 once to 6TO4 tunnel, but no IP’s expected and that gives a warning and cannot be configured, so I assume “none” is the correct setting.
Last step was making the new interface a gateway. The only fields that was entered are name, description, interface, IPv6 address family and priority. First I forgot to tick Upstream gateway, but I didn’t really see any difference when that was done. I haven’t seen any attempts for support on the forum, so I guess that will never happen.
I assume the problem can be split in two pieces that may not be related:
1. Why don’t the entered interface setting for MTU reload after boot. Perhaps is the mechanism in the source code for reload of existent previously made settings different from when new settings are being applied? It is very repeatable, MTU increase 200 Byte after a while around 8-10 minutes after being applied, but it always has to be applied again although still present in the GUI and backup XML before and after boot, so I believe there must be something incorrect in the code…
2. The VPN IPsec ESP tunnel does not benefit from the MTU increase and will thus carry too small packets to allow for DNS server RPC traffic.
|
|
From this morning I can ping between Tunnel Broker and native IPv6 sites to up to 1295 Byte and RPC traffic between DC:s is now working! I don’t understand, since I have not done anything, what could have changed? The problem with MTU to be reapplied after boot persist, but the most serious problem seems gone, at least for now... |
|
It seems that this problem now is gone without doing anything to fix it! Didn't understand why it appeared and what solved it. Could be something done by the Internet Service Provider or by the Communication Operator in the P- or the PE-routers oit on the internet, but I guess we will never know. I asked Hurricane Electric, but they haven't done anything recently. |
I have three sites with dual stack. IPv6 on two of the sites are native and on one is through Hurricane Electric. There is a least one Domain Controller on each site, which need to commuincate with the others through IPv4 and IPv6. All sites have OPNsense routers and there are IPsec VPN tunnels between sites for both IPv4 and and IPv6 to reach subnets between the sites. Ping and simple DNS queries work between the subnets, but DNS replication through RPC fails when IPv6 is set on the DC on tunnel broker site. Others servers and network in general is affected with latency, etc. since the DC is not replying on the tunnel broker site. Mail servers typically need contact with all DC during update. Swithcing off IPv6 on that site normally solves the the network problem on the other sites.
I contacted Hurricane Electric and they said these problems typically are related to low MTU.
Ping through HE-tunnel over IPv6 with payload empasize the problem. Ping to Internet (Google) only works until 1230 Byte, whereas ping through IPsec to native site only reach 1095 Byte. Native site to Internet hit 1450 byte and 1310 byte in ping through IPsec between two native sites. The MTU for the HE-tunnel is too low for IPv6 to work, particularly for IPsec that seem to take 135-140 Byte.
MTU default at Hurricane Electric is 1480 Byte, as seen under advanced settings at HE. The GIF interface in OPNsense likely defaults to 1280 Byte and is as i understood suggested part of FreeBSD. Setting MTU to 1480 Byte on the TunnelBrokerHE interface increase the Payload ping from 1230 to 1430 Byte temporarily, but it had no effect on traffic through IPsec, which still fails over 1095 Byte. Packet size reverts to 1230 after boot although the MTU 1480 setting still exists on the interface and can be seen in backup XML! Netwok behaved erratically before router boot after server boot, but stabilize at low MTU after router boot.
Router is Chinese Topton industrial fanless mini PC with 16GB DDR4, 256GB NVMe, Intel N100 and 4x2.5G i226-V ports. Ethernet ports reports Katsujima Co., Ltd., which suggests Topton could be based on Japaneze motherboard.
OPNsense 24.1.6-amd64
FreeBSD 13.2-RELEASE-p11
OpenSSL 3.0.13
Setup is made recently and I never tried ping with payload on older versions, started with 2.1.4 and went through 2.1.5 to 2.1.6. Believe there could be one FreeBSD update in this sequnce too.
There are to my knowledge no setting to increase MTU for VPN IPsec in OPNsense. IPv6 requires 1280 as a minimum. The MTU need up near 1480 for the HE-tunnel to allow for the loss of bytes in headers, ESP, encryption, padding, etc. in the IPsec tunnel. This is needed to enable a packet size able for proper communication.
Try to solve persistant MTU after boot inline with the setting on the tunnel interface and make sure VPN through IPsec can utilize the higher MTU!
The text was updated successfully, but these errors were encountered: