IKEv2 mobile doesn't pass traffic inside P2s when P1 is IPv6 or dual-stack

xpxp2002

I've been trying to get a full dual-stack IPSec mobile solution working since version 2.5, with the same issue present in each subsequent version of pfSense up through 2.5.2. I currently have an IKEv2 P1 configured for mobile access using EAP-TLS authentication with mutual certs for each device/user. I have two P2s, one for IPv4 and another for IPv6, both are configured full tunnel so that all traffic is backhauled to the pfSense firewall.

When I set the P1 to dual stack or IPv6 only, my clients (iOS devices) can connect and are assigned virtual IPs in the ranges I've provided, but no traffic will actually pass in either direction. Pings time out, DNS doesn't work, etc. I have confirmed in status that the P1 is being established over IPv6 and the IPSec status in the pfSense GUI shows that the P2 is built.

If I set the P1 to IPv4, changing nothing else, everything works. I can pass traffic between the mobile devices and the allowed networks beyond the pfSense firewall using the same IPv4 and IPv6 addresses assigned out of the virtual pools.

I've searched high and low for a reason, to understand if I've misconfigured the P1, or if there is a known bug. Has anyone else gotten this configuration to work? The IPSec documentation for pfSense suggests that IKEv2 should be able to work in a full dual stack configuration, where the P1 can be reached over IPv4 and v6 networks, and clients can pass traffic using v4 and v6 over that tunnel.

jimp

Do you see anything blocked in the firewall log when this happens?

Is there any obvious difference in the IPsec SAs when clients are connected over IPv4 or IPv6?

I had this working at one point but it has been a while since I tested it specifically. There really shouldn't be anything special about it using IPv4 or IPv6 outside with IKEv2, both are known to work. It's possible it's specific to iOS, though, as that's the one thing I don't have a recent device handy to test.

jimp

I fired up a few clients and it looks like it's working here.

I have a Linux client which is connecting IKE (P1) over IPv6 and it can send IPv4 traffic over the tunnel and get responses.

con-mobile: #4, ESTABLISHED, IKEv2, a7884d9d38b8ba80_i a37baa74bbdded30_r*
  local  'xxxxx.xxx.xxxx.xx' @ 2001:db8::ffff:f236[4500]
  remote 'eapuser5' @ 2001:db8:1:ee10:1911:3982:6c3:94a0[37121] [10.6.240.2 2001:db8:1:ef09::2]
  AES_GCM_16-256/PRF_AES128_XCBC/MODP_4096
  established 415s ago, rekeying in 22680s, reauth in 23825s
  con-mobile: #7, reqid 6, INSTALLED, TUNNEL, ESP:AES_CBC-128/HMAC_SHA2_256_128
    installed 415s ago, rekeying in 2641s, expires in 3185s
    in  cbd2adff,    836 bytes,     9 packets,    19s ago
    out cf08c702,   1648 bytes,     9 packets,    18s ago
    local  10.6.0.0/24|/0 2001:db8:1:ee70::/64|/0
    remote 10.6.240.2/32|/0 2001:db8:1:ef09::2/128|/0

xpxp2002

@jimp No blocks. I enabled logging on the IPsec rules, which allow the subnet of the virtual pool to any destination right now, as well as the IKE and NAT-T rules. The only difference is that my test device is behind a CG-NAT with IPv4 and uses IPSec over UDP when connecting with IPv4. I tried setting the P1 to force NAT-T so that it would be used over IPv6, but that didn't help.

If I try browsing to a website from the device when the P1 is connected with IPv6, for example, I can see the DNS lookup attempts matching the allow firewall rule on the IPsec interface toward the correct DNS servers, but it looks like it's not hearing an answer back because the client appears to retry several times.

I see you're using a limited set of P2 networks. Could the full tunnel config (0.0.0.0/0 and ::/0) be the issue? I don't see why it would, but otherwise what you're doing looks quite similar to what I'm doing. I'll try limiting the tunnel in my P2s and see if that makes a difference.

jimp

It's possible it's related to that but seems unlikely. If it was a general IPv4 over IPv6 problem it would fail for anything.

If it were a NAT or other similar IPv4 config issue I'd expect to fail over both.

Once it hits the IPsec interface the system no longer knows it came over IPv6 at all anyhow.

For reference, here is the bulk of my config:

P1:

P2 for IPv4:

P2 for IPv6:

Mobile Clients tab:

xpxp2002

@jimp Thanks for sharing your config. I've essentially duplicated this, tried different crypto, re-exported certs and putting them into a new config profile for iOS.

When I look at a pcap from pfSense, I can ping the mobile client from a host behind another subnet and even see ICMP requests going out to the mobile client with no response on that IPsec interface.

All I can deduce is that it must be an iOS bug that when the P1 is built over IPv6, some traffic is lost. I'm running 14.6 here, but with 14.7 due to be released imminently and the 15 public beta out, I may load that onto a test device and see if it's something they've fixed or open a feedback ID for it.