IPv6 IPsec site to site between native and HE, but DNS in one direction only

[Skreabengt]

It is an IPsec legacy IPv6 site to site VPN between peers on the WAN and the Hurricane Electric Tunnel Interface gateways. The routing is setup between /64 local subnets on each site.

Ping works from one site to the other on any IP-address, but DNS queries only work from the native IPv6 site to the IPv6 HE-tunnelbroker site and will timeout when DNS queries are made from HE to native.

Monitoring of the traffic through Firewall/Log files/Live view seem to pass as expected on WAN, IPsec and the Tunnelbroker Interfaces for port 53, 135 etc., but I don't see so much traffic to LAN.

It behaves like the packets get stuck in the tunnel and don't find their way to the local IP-addess...

I am not using NAT-T and the settings are pretty much standard.

Anyone who have experience or any idea what I do wrong?

Similar settings work fine between two native sites, but obviously not when one site is with a tunnelbroker...

[Skreabengt]

We noticed that DNS traffic to a client computer actually work over the IPv6 tunnel in both directions with NSLOOKUP, but not in one direction to the domain controller, which is a Windows Server 2012 R2 sitting on the IPv6 HE tunnel site.

It works in the other direction to one Windows Server 2019 through one tunnel and to a Windows Server 2022 through another, both in native IPv6 sites.

I suspect the problems are more related to the Windows Server 2012 R2 than to IPv6 VPN site to site, but are not sure. I have tried shortly with windows firewalls deactivated, but that have no effect.

Will replace the server with a new Windows Server 2022, but it is still strange that this happen. The Windows Server 2012 R2 DNS works fine when IPv4 is solely active.

All 3 servers are DC with DNS, AD and DHCP, where one have all the master roles.

[Skreabengt]

I tested a new Windows Server 2022 for a short while to see if it makes any difference, but it missing some hardware and was removed again. The replication and access problem in DNS mainly persisted although Nslookup worked liked described for the client computers.

I contacted Hurricane Electric support and they said these problems typically are related to MTU.

Ping through HE-tunnel over IPv6 with payload empasized the problem. Ping to Internet only worked until 1230 Byte, whereas Ipsec to other site only reach 1095 Byte. Native site to Internet hit 1450 byte and 1310 byte in Ipsec. The MTU for the HE-tunnel is too low for IPv6 to work, particularly for IPsec that seem to take 135-140 Byte. IPv6 requires 1280 as a minimum.

MTU default at Hurricane Electric is 1480 Byte. The GIF interface in OPNsense defaults to 1280 Byte according to other threads and is part of FreeBSD. Setting MTU to 1480 Byte on the TunnelBrokerHE interface increase the Payload ping from 1230 to 1430 Byte, but it had no effect on traffic through IPsec, which still fails over 1095 Byte. The packet size reverts to 1230 after boot although the MTU 1480 setting still exists on the interface!

I have seen other reporting the same thing and suppose this is kind of a bug in OPNsense?

[Skreabengt]

I reported the issues and is currently on community support https://github.com/opnsense/core/issues/7451. OPNsense doubt that this is a real world problem and ask me to reach out to the community.

So please any idea what I possibly could have done wrong?

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. It is very repeatable, MTU increase to 1430 Byte in payload ping 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 what incorrect settting could cause this? I attach the screens in the thread.
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.

[Skreabengt]

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

[Skreabengt]

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 out on the internet, but I guess we will never know. I asked Hurricane Electric, but they haven't done anything recently.

RPC traffic on the DNS-servers now work in all directions when packet size is large enough. MTU 1480 was applied to the Tunnel Broker interface quite early in the process, but didn't increase MTU until after some days. First it only increase payload to internet, but suddenly also through the tunnel after more days. Initially the setting have to reapplied after boot, but now it comes on every time. Strange indeed!