IPSec ESP not decrypted via IPv6 transport

[nova-2nd]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

A dual stack IPSec road-warrior setup will work via IPv4 transport but not IPv6.
I verified that ESP packets arrive at the ingress interface (WAN in my case) but do not drop out of the IPSec interface.
Everything works fine for IPv4 transport...

To Reproduce

• Set up a road warrior IPSec (non Legacy) config
• Establish tunnel via IPv4 -> OK
• Establish tunnel via IPv6 -> ESP arrives at ingress interface but does not drop out of IPSec interface

Expected behavior

Traffic flows via both protocol stacks

Additional context

Verified on Android (StrongSwan client) and Windows 11 (native client)
Verified for ESP and ESP in UDP
I am happy to share logs/pcap's, if it helps the cause

Environment

OPNSense 23.7.7_3 on KVM
Virtio NIC's
PPPoE dial-up - Deutsche Telekom (Germany) - true dual-stack - fixed IP/Prefix

[nova-2nd]

Support?

[AdSchellevis]

can always be relabeled at a later moment in time if it appears to be a bug on our end. Most logical reason at the moment is a configuration issue, like a missing firewall rule.

[nova-2nd]

I see

[Monviech]

I will test this with my Android StrongSwan Client over IPv6. I have PPPoE with true dual stack, fixed IP and Prefix, and I know the roadwarrior configuration with IPsec Connections in depth.

Whats the testing baseline, did you create the RoadWarrior tunnel with the docs here? https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html

EDIT:
Possibly related, it seems UDP Encapsulation is mandatory for IPv6 Transport to work:

https://wiki.strongswan.org/versions/79
The Android client optionally supports IPv6 transport addresses for IKE and ESP (requires UDP encapsulation
for IPv6 on the server, which Linux only supports since 5.8).

EDIT2:

I have tested it quickly with an IPv6 AAAA only hostname, enabled "Use IPv6 transport addresses" in the StrongSwan Android client. The Tunnel is up and I can see the UDP-encap ESP packets on UDP 4500 on the WAN interface. But they're not decapsulated and don't hit the if_enc(4) interface. I'll look into if it's a firewall issue, but my firewall rules allow IPv6 UDP 500 and 4500, and ESP. Otherwise the tunnel wouldn't even be established.

EDIT3:
https://www.strongswan.org/testing/testresults/ipv6/rw-ikev2/index.html

EDIT4:
Doesn't seem like a new issue, found this:
https://forum.opnsense.org/index.php?topic=22254.0

[Monviech]

https://forum.opnsense.org/index.php?topic=22254.0
Short summary:

• It has never worked before to create an IPv6 Transport tunnel when NAT-T 4500 and UDP Encapsulation is used.
• IPv6 Transport only works directly on UDP 500 to UDP 500 as of now
• The StrongSwan IPsec Client forces the use of UDP Encapsulation, since it doesn't have the privileges to work with raw packets.
• Strongswan doesn't allow NAT-T to be disabled. https://docs.strongswan.org/docs/5.9/features/natTraversal.html

Result:

• Android Strongswan Client + FreeBSD Strongswan implementation + IPv6 Transport with NAT-T and UDP encapsulaton = Currently not working

[Monviech]

https://forums.freebsd.org/threads/error-when-starting-up-strongswan.90468/
Freebsd-13.2 seems not to support UDP Encapsulation/Decapsulation for IPv6.

[nova-2nd]

* Android Strongswan Client + FreeBSD Strongswan implementation + IPv6 Transport with NAT-T and UDP encapsulaton = Currently not working

Thank you very much for the confirmation of this.
Next time I promise to dig even deeper, to not waste the time of others

You have my respect salute

[fichtner]

Close for now? I'll screen the FreeBSD source code for changes in that area.

[doktornotor]

https://forums.freebsd.org/threads/error-when-starting-up-strongswan.90468/ Freebsd-13.2 seems not to support UDP Encapsulation/Decapsulation for IPv6.

Also: strongswan/strongswan#1759

[Monviech]

That's very interesting thanks for sharing. Just today someone in the forum stumbled across this not working too by chance. With many ISPs only implementing CG-NAT and IPv6, it becomes more and more of a requirement: https://forum.opnsense.org/index.php?topic=36742.0

So the alternative seems to be wireguard right now.

[nova-2nd]

Wireguard could be an alternative on greenfield, but out in the wild there is a lot of IPSec and that won't change anytime soon...

[pfoo]

It seems like there are now patches for NAT-T / ESP-in-UDP for IPv6 in Freebsd :
https://cgit.freebsd.org/src/commit/?id=80044c785cb040a2cf73779d23f9e1e81a00c6c3
https://cgit.freebsd.org/src/commit/?id=dc02374f54455e354495870c24f86bb2966a7960

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[fichtner]

Added both patches to stable/24.7 as opnsense/src@18b8a9d5d3dd but it's not going to be part of our beta images for lack of prior coverage and FreeBSD release engineering (not on 14.1 or stable/14).

[Monviech]

@fichtner I just tested it on the testkernel and it works:

09:03:44.904086 IP6 2a02:XXXX:XXXX:3cfb:1410:827d:332a:8.42662 > 2003:a:XXXX:XXXX:5054:ff:fec1:44ca.4500: UDP-encap: ESP(spi=0xc0b7e393,seq=0x970), length 12

VPN client connects, udp encap with ipv6 is working, traffic goes through and gets encapsulated and decapsulated.

Looks good imo.

[fichtner]

Ok let's keep the commit for the RC and see what happens 👍