Possible bug - IKEv2 Phase2 entry using crypto that isn't enabled?

ZPrime · Jun 15, 2017, 4:34 AM

I have an IPSec tunnel from my house to my office. The equipment at the office is (an HA pair of) Palo Alto PA3050, currently running PanOS 7.1.9.

Office is static, my side is dynamic.

Tunnel details:
pfSense side
IKEv2
Phase 1:
Crypto - AES-256
Hash - SHA384
DH Group 20

Phase 2 (17 different entries - I need to exclude 2 subnets out of a /24 which is why I have so many)
Crypto - AES (auto) and AES-GCM-256 (auto) <<< this is where the problem manifests, I'll explain below
Hash - SHA384
PFS - DH Group 20

Phase 1 and Phase 2 have lifetimes configured, etc. Tunnels come up fine, everything is working… BUT, I can't get the phase 2 entries to come up using AES-GCM. Please read further for more details.

First, I presume that pfSense's "AES" is actually meant as "AES-CBC". One thing I don't fully understand is what is selected by the drop-down box after the various AES-GCM-xxx options (128/192/256). On the Palo Alto, the GCM options don't quite line up.

Palo Alto offers:

aes-256-gcm
aes-128-gcm
aes-128-ccm
aes-256-cbc
aes-192-cbc
aes-128-cbc
others not relevant to discussion

What do I get from pfsense if I choose "AES256-gcm - 128 bits"?? How does that line up with the options on the Palo Alto?

So per the above, on pfSense I have "AES (auto)" and "AES256-GCM (auto)" enabled. On the Palo Alto, my Phase2 profile (they call it an "IPSec profile") has "aes-256-gcm" and "aes-256-cbc" enabled, with the GCM option listed above the CBC option (meaning it should be tried first / preferred).

Problem #1 is that pfSense doesn't provide any way to order the crypto options in the GUI, so if I have AES [CBC?] (auto) enabled, the CBC cypher apparently wins, even though the Palo Alto is supposedly proposing GCM first.

Problem #2 is that even if I completely disable "AES (auto)" on pfsense, the Phase 2 entry still seems to be connecting with AES-CBC. :o It's very easy for me to disable a given crypto option on pfSense, drop the VPN, then bring it back up, and after doing that, the phase2 entry that should be AES256-GCM only is still negotiating and connecting in CBC mode. I'm guessing this is not intended design? I would expect that ph2 to either come up in GCM mode, or not at all.

Security Associations (1 up, 0 connecting):
     con1000[2]: ESTABLISHED 35 minutes ago, MYIP[fake@myID]...WORKIP[fake@workID]
     con1000[2]: IKEv2 SPIs: 5309b8e50c7c701c_i* 1c9a2c27fbc3ab16_r, pre-shared key reauthentication in 7 hours
     con1000[2]: IKE proposal: AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_384
    con10016{19}:  INSTALLED, TUNNEL, reqid 17, ESP SPIs: c3cebfb1_i ad7d3dea_o
    con10016{19}:  AES_CBC_256/HMAC_SHA2_384_192, 336 bytes_i (4 pkts, 2123s ago), 656 bytes_o (4 pkts, 2123s ago), rekeying in 14 minutes
    con10016{19}:   192.168.42.0/24|/0 === 10.16.0.0/16|/0
    con10012{20}:  INSTALLED, TUNNEL, reqid 13, ESP SPIs: cc057d29_i fc020522_o
    con10012{20}:  AES_CBC_256/HMAC_SHA2_384_192/ECP_384, 0 bytes_i (0 pkts, 2122s ago), 17080 bytes_o (70 pkts, 19s ago), rekeying in 8 minutes
    con10012{20}:   192.168.42.0/24|/0 === 192.168.128.0/17|/0
     con1000{21}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cbb216f1_i 8fd4e8f4_o
     con1000{21}:  AES_CBC_256/HMAC_SHA2_384_192/ECP_384, 193464 bytes_i (282 pkts, 181s ago), 195080 bytes_o (1062 pkts, 1s ago), rekeying in 7 minutes
     con1000{21}:   192.168.42.0/24|/0 === 192.168.0.0/19|/0

con10016{19} above is currently configured in the GUI to ONLY have AES_GCM_256 crypto, and yet it is connecting with AES_CBC_256. The remote side (Palo Alto) will offer both options, but pfSense should be either connecting GCM or not at all.

I'm happy to provide logs from both sides, I just need guidance on what commands to run to collect them. (I'm not CLI-averse, I'm just not very informed on ipsec details/logging on the pfsense side.) If this is better-suited as an actual bug entry on redmine I can create one, but I figured I should post it here first.

I also have full control over the Palo Alto so I can work with development and allow someone to setup their own temporary tunnel to my HQ (I'll just route you to nowhere for testing) if it becomes necessary.

jimp · Jun 15, 2017, 12:39 PM

Look at the config that shows up in /var/etc/ipsec/ipsec.conf, especially "esp =", what does that look like?

If you have multiple P2s on that P1, this bug might be a possibility: https://redmine.pfsense.org/issues/6263

ZPrime · Jun 17, 2017, 6:49 AM

@jimp:

Look at the config that shows up in /var/etc/ipsec/ipsec.conf, especially "esp =", what does that look like?

If you have multiple P2s on that P1, this bug might be a possibility: https://redmine.pfsense.org/issues/6263

I do have multiple P2s on the P1, so that bug is probably why I can't get it to use GCM (since I haven't gone through and disabled all of the other crypto types).

Doesn't fully explain why the selection / ordering isn't working though. The Palo Alto is supposed to be offering GCM first and then CBC last. Only thing I can think of is that the GCM is failing for some reason, and it's falling back to CBC?

Woah, this is kind of ugly. I guess this is due to "auto" for the length, maybe combined with the fact that I have so many P2 entries (the same config line might be repeated for each P2)?

esp = aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384,aes256-sha384-ecp384,aes192-sha384-ecp384,aes128-sha384-ecp384,aes256gcm128-sha384-ecp384,aes256gcm96-sha384-ecp384,aes256gcm64-sha384-ecp384!

I'm seeing each P2 entry in there as individual "con1xxx" and each one has an identical esp= line.

I could pare down to like 3-4 P2 entries if I had a way to "carve out" (exclude) individual /24s from a /16 tunnel… I think this is something strongswan can do but it isn't exposed in pfSense and I'm not about to start mucking around behind the scenes and breaking stuff. ;)

A routed /30 style tunnel would also do the trick (and I'd even prefer it)... I know strongswan can do this too (it's possible with Ubiquiti) but ISTR there are tunnel interface problems in BSD that make this not an option.