Closed nova-2nd closed 6 months ago
Support?
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.
I see
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
https://forum.opnsense.org/index.php?topic=22254.0 Short summary:
Result:
https://forums.freebsd.org/threads/error-when-starting-up-strongswan.90468/ Freebsd-13.2 seems not to support UDP Encapsulation/Decapsulation for IPv6.
* 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
Close for now? I'll screen the FreeBSD source code for changes in that area.
https://forums.freebsd.org/threads/error-when-starting-up-strongswan.90468/ Freebsd-13.2 seems not to support UDP Encapsulation/Decapsulation for IPv6.
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.
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...
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
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.
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).
@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.
Ok let's keep the commit for the RC and see what happens 👍
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