IPv6 IPSEC tunnel does not pass data in NAT-T mode

[juere]

I am trying to establish an IPv6 IPSEC Tunnel between two OPNSense boxes that both have a working IPv4 as well as an IPv6 upstream connection.

When using IPv4 the tunnel works flawlessly.
With IPv6 the tunnel goes up, but transports no data if NAT-T (ESP-UDP Transport via port 4500) is used.
IPv6 and ESP Transport (without NAT-T) works fine.

My first idea was to disable NAT-T (it is usually not needed in an IPv6 setup) by setting "NAT Traversal" to "Disable" in IPSEC phase 1 configuration. The problem is, that disabling NAT-T does not work with strongSwan since Realease 5.0.0 as described here https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal.
So the option "Disable" seems to be pointless in OPNSense, I opened a github issue on this today.

strongSwan seems to enable NAT-T everytime when MOBIKE extensions are enabled, I found it hard to impossible to get a reliable IPv6-ESP connection without NAT-T when a mobile VPN is configured on the same WAN interface.

Has anyone experienced this behaviour ?
Is it possible that FreeBSD does not support NAT-T with IPv6 ?

[schnipp]

Today, I was encountering similar problems. The new created mobile IPsec connection with outer IPv6 and inner IPv4 works only if NAT-T is disabled. Although, this works in most situations with my Linux laptop I have problems with my Android smartphone and the Strongswan client.

If I understand correctly, the Android system with Strongswan always uses UDP encapsulation for IPsec. Has anybody an idea, how to debug this iussue? Increasing the log level in the Opnsense does not show up any inconsistencies.

Can you please share the link to the github ticket? Thanks.

[glasi]

For the Strongswan Android app we have to keep in mind that the app runs with reduced privileges. It can't open RAW/PACKET sockets. Hence, it is limited to use UDP-encapsulated ESP, which it sends/receives via the UDP sockets used for IKE. So UDP-encapsulation is always enforced, even if there is no NAT between client and server, by sending a random NAT-D payload.

[juere]

Can you please share the link to the github ticket? Thanks.

https://github.com/opnsense/core/issues/4862

[schnipp]

Thanks, I thought the ticket covers the problem mentioned in the topic. A plain IPv6 IPsec connection from a mobile device works flawlessly, but in case NAT-T is enabled no communication is possible.

I did some further tests with my Linux Laptop establishing an IPv6 IPsec connection with NAT-T enabled:

• IKE seems to be OK, because after the connection is established both endpoints have the same encryption and authentication keys for the SPIs
• Decrypting IPsec traffic passing the WAN interface shows that packets from the Laptop to the Opnsense are OK. But the IPsec traffic does not contain any response messages in direction of the Laptop
• Monitoring the virtual IPsec interface in the Opnsense does not show up any incoming traffic from the Laptop, hence the Opnsense is not sending any responses back

It looks like IPv6 IPsec with NAT-T enabled is broken (tested with Opnsense version 21.1.5). I'll try to investigate a little bit more the next week. Ideas are appreciated  :).

[juere]

I have tested with a Windows10 mobile client, what you describe for Linux client:

The OPNsense box used for testing has only an AAAA DNS entry and a IPSEC mobile client using EAP Radius set up.

Connecting from Windows works fine, when looking at "VPN: IPsec: Security Association Database" ESP transport ist used for the mobile connection. Data flow accross the tunnel is fine for IPv6 and IPv4.

When forcing NAT-T by setting "Nat Traversal" to "Force" on the OPNSense side the Windows Client also connects successfully, but pings accross the tunnel wont work.

So I would agree to

It looks like IPv6 IPsec with NAT-T enabled is broken

testing with 21.1.4 :(

[schnipp]

I did some further experiments but without success. I don't have a clue why the enc0 interface does not receive any data. Does anybody have any ideas?

[rainerle]

Hi,

sorry for my late reply. I encountered this problem already last year.

See here:
https://forum.opnsense.org/index.php?topic=18699.msg85846#msg85846

Best regards
Rainer

[schnipp]

See here:
https://forum.opnsense.org/index.php?topic=18699.msg85846#msg85846

Thanks for your reply. I know the strongswan issues you mentioned in the other thread. The NAT-T issues of IPv6 have already been fixed for Linux and UDP encapsulation of ESP messages work fine on my Linux machine. The problem is that encapsulated ESP messages received by the Opnsense will not be decrypted and passed to enc0 interface. And I don't have a clue, why this happens  :(

[glasi]

I've done a few tests with OPNsense 19.7 to rule out that the problems were introduced with a newer version of OPNsense.

However, the results are the same. While the IPsec tunnel runs smoothly with IPv4, it does not work when using IPv6. Packet dump shows IPsec traffic arriving on the WAN interface. However, somehow packets are not processed and passed on by OPNsense.

Does anyone have any idea what a detailed analysis might look like? Is there some kind of debug mode?