search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.33k stars 745 forks source link

IPSec ESP not decrypted via IPv6 transport #6964

Closed nova-2nd closed 6 months ago

nova-2nd commented 12 months ago

Important notices

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

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

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 commented 12 months ago

Support?

AdSchellevis commented 12 months ago

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 commented 12 months ago

I see

Monviech commented 12 months ago

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 commented 12 months ago

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

Result:

Monviech commented 12 months ago

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 commented 12 months ago 
* 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 commented 12 months ago

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

doktornotor commented 11 months ago

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

Also: https://github.com/strongswan/strongswan/issues/1759

Monviech commented 11 months ago

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 commented 11 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 4 months ago

Added both patches to stable/24.7 as https://github.com/opnsense/src/commit/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 commented 4 months ago

@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 commented 4 months ago

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