IPSECv2 to Azure no longer working 2.2.4



  • In 2.2.3 we lost the VPN because of the AES-NI bug. We disabled AES-NI and it restored functionality as expected. We upgraded to 2.2.4 last night, and re-enabled AES-NI. Today, we can still not connect to the Azure tunnel that was previously working on 2.2.2 and 2.2.3 with AES-NI off. We are seeing an attempt to get certs from Azure, then we send a cert back for some reason (I am not sure if this is the cause, or just a harmless negotiation). This is a PSK AES-256 standard tunnel. I never looked when it was working if this odd cert exchange occurs or not. Azure does not use certs for S2S tunnels, only PSK.

    P1 -> AES-256 / SHA1 / PSK / DH 2 / DPD on
    P2 -> ESP / AES auto / SHA1 / PFS G1

    Here is the kicker. We have another firewall that was also upgraded to 2.2.4 last night. This one does not use AES-NI. It is configured to connect to the same S2S Azure gateway IP. It IS working fine. The only difference is this firewall does not have AES-NI functionality. The VPN policies are exact.

    We cannot reboot the suspect firewall to re-disable AES-NI yet, but will try tonight. Is there anyone else on 2.2.4 having issues?

    Before you ask, the PSK is correct, we re-verified it with Azure this morning. We also generated a new key (twice) and changed it on pfSense.

    
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received AUTHENTICATION_FAILED notify error
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received AUTHENTICATION_FAILED notify error
    Jul 28 09:55:03	charon: 08[ENC] <con1|47>parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
    Jul 28 09:55:03	charon: 08[NET] <con1|47>received packet: from 191.237.6.27[500] to 216.201.91.1[500] (76 bytes)
    Jul 28 09:55:03	charon: 08[NET] <con1|47>sending packet: from 216.201.91.1[500] to 191.237.6.27[500] (396 bytes)
    Jul 28 09:55:03	charon: 08[ENC] <con1|47>generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ IDr AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(EAP_ONLY) ]
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>establishing CHILD_SA con1{5}
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>establishing CHILD_SA con1{5}
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>authentication of '216.201.91.1' (myself) with pre-shared key
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>authentication of '216.201.91.1' (myself) with pre-shared key
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>sending cert request for "C=US, ST=GA, L=Canton, O=Company, E=xx@xx.com, CN=internal-ca"
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>sending cert request for "C=US, ST=GA, L=Canton, O=Company, E=xx@xx.com, CN=internal-ca"
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received 23 cert requests for an unknown ca
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received 23 cert requests for an unknown ca
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received MS-Negotiation Discovery Capable vendor ID
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received MS-Negotiation Discovery Capable vendor ID
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received MS NT5 ISAKMPOAKLEY v9 vendor ID
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>received MS NT5 ISAKMPOAKLEY v9 vendor ID
    Jul 28 09:55:03	charon: 08[ENC] <con1|47>parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V CERTREQ ]
    Jul 28 09:55:03	charon: 08[NET] <con1|47>received packet: from 191.237.6.27[500] to 216.201.91.1[500] (829 bytes)
    Jul 28 09:55:03	charon: 08[NET] <con1|47>sending packet: from 216.201.91.1[500] to 191.237.6.27[500] (328 bytes)
    Jul 28 09:55:03	charon: 08[ENC] <con1|47>generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>initiating IKE_SA con1[47] to 191.237.6.27
    Jul 28 09:55:03	charon: 08[IKE] <con1|47>initiating IKE_SA con1[47] to 191.237.6.27
    Jul 28 09:55:03	charon: 06[KNL] creating acquire job for policy 216.201.91.1/32|/0 === 191.237.6.27/32|/0 with reqid {5}</con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47></con1|47> 
    


  • The AUTH_FAILED would be a config mismatch of some sort. The presence or not of AES-NI wouldn't come into play at that level. The problem with AES-NI didn't impact negotiation at all, and is fixed in 2.2.4 regardless.

    Double check all your settings, that almost certainly didn't regress from upgrading (if it did, it would have broken your other one), and isn't AES-NI related.



  • Well, it turns out it was not the config or the pfSense upgrade. Both were correct. It was Microsoft Azure as the problem. For reasons unknown, the whole Azure gateway had to be removed and re-built so it would recreate the RRAS hidden servers again. No matter what, or how many times they key was changed on Azure it would fail. Rebuilding the gateway fixed it. Azure still has ALOT of bugs to work out.

    It was purely a coincidence that whatever failure occurred was at the exact same time as the 2.2.4 upgrade.



  • Thanks for the follow up, glad you got it resolved.