IPsec Tunnel to Azure Not Working Since 21.02
-
I have two pfSense devices, a SG-3100 which was upgraded to 21.02-p1, and a XG-7100 2.4.5-p1. Both connect via IPsec to Azure. Both have identical configuration. Once the SG-3100 was upgraded, it immediately stopped connecting. In other threads, jimp linked to 6 hotfixes; all of them have been applied, the SG-3100 still cannot connect.
Here’s my configuration on Azure, I’m using PowerShell to ensure the exact same policy is applied to both tunnels:
New-AzIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA384 -DhGroup ECP384 -IpsecEncryption GCMAES256 -IpsecIntegrity GCMAES256 -PfsGroup ECP384 -SALifeTimeSeconds 3600 -SADataSizeKilobytes 500000/var/etc/ipsec/swanctl.conf from the SG-3100
# This file is automatically generated. Do not edit connections { bypass { remote_addrs = 127.0.0.1 children { bypasslan { local_ts = <Internal Network> remote_ts = <Internal Network> mode = pass start_action = trap } } } con1000 { fragmentation = yes unique = replace strictcrlpolicy = yes version = 2 proposals = aes256-sha384-ecp384 dpd_delay = 10s dpd_timeout = 60s rekey_time = 3240s reauth_time = 0s over_time = 360s rand_time = 360s encap = no mobike = no local_addrs = <PF IP> remote_addrs = <Azure VNG IP> pools = local { id = <PF IP> auth = psk } remote { id = <Azure VNG IP> auth = psk } children { con1000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = <Azure Network> local_ts = <Internal Network> esp_proposals = aes256gcm128-ecp384 } } } } secrets { ike-0 { secret = <PSK> id-0 = %any id-1 = <Azure VNG IP> } }/var/etc/ipsec/ipsec.conf from the XG-7100
# This file is automatically generated. Do not edit connections { bypass { remote_addrs = 127.0.0.1 children { bypasslan { local_ts = <Internal Network> remote_ts = <Internal Network> mode = pass start_action = trap } } } con1000 { fragmentation = yes unique = replace strictcrlpolicy = yes version = 2 proposals = aes256-sha384-ecp384 dpd_delay = 10s dpd_timeout = 60s rekey_time = 3240s reauth_time = 0s over_time = 360s rand_time = 360s encap = no mobike = no local_addrs = <PF IP> remote_addrs = <Azure VNG IP> pools = local { id = <PF IP> auth = psk } remote { id = <Azure VNG IP> auth = psk } children { con1000 { dpd_action = trap mode = tunnel policies = yes life_time = 3600s rekey_time = 3240s rand_time = 360s start_action = trap remote_ts = <Azure Network> local_ts = <Internal Network> esp_proposals = aes256gcm128-ecp384 } } } } secrets { ike-0 { secret = <PSK> id-0 = %any id-1 = <Azure VNG IP> } }IPsec log from the SG-3100
Feb 27 10:34:22 charon 24787 14[NET] <2521> received packet: from <Azure VNG IP>[500] to <PF IP>[500] (376 bytes) Feb 27 10:34:22 charon 24787 14[ENC] <2521> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ] Feb 27 10:34:22 charon 24787 14[CFG] <2521> looking for an IKEv2 config for <PF IP>...<Azure VNG IP> Feb 27 10:34:22 charon 24787 14[IKE] <2521> no IKE config found for <PF IP>...<Azure VNG IP>, sending NO_PROPOSAL_CHOSEN Feb 27 10:34:22 charon 24787 14[ENC] <2521> generating IKE_SA_INIT response 0 [ N(NO_PROP) ] Feb 27 10:34:22 charon 24787 14[NET] <2521> sending packet: from <PF IP>[500] to <Azure VNG IP>[500] (36 bytes) Feb 27 10:34:22 charon 24787 14[IKE] <2521> IKE_SA (unnamed)[2521] state change: CREATED => DESTROYING -
Here's the view from the Azure portal, and using PowerShell:
Here's from the pfSense GUI:
Again, the XG-7100 is configured identically, the only difference (besides the model) is the XG-7100 is running 2.4.5-p1.
-
Figured it out. Once I disabled "Strict CRL Checking", the connection started working. Both the SG-3100 running 21.02-p1, and the XG-7100 running 2.4.5-p1 had Strict CRL Checking enabled. Looks like the behavior changed between the two versions.
@jimp I'd consider this a bug, since it'd be impossible to ever verify CRLs on a PSK, so a global CRL setting should have no effect on a PSK-based IPsec tunnels.
-
