IPSec not following config



  • Creating a Phase 1 Tunnel to Azure, Strongswan is ignoring the ike authentication settings.

    The config is configured to use aes256-sha256-modp1024!
    But when setting up the tunnel this is in the logs.

    Jan 26 16:20:35	charon		14[ENC] <1> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
    Jan 26 16:20:35	charon		14[IKE] <1> received proposals unacceptable
    Jan 26 16:20:35	charon		14[CFG] <1> configured proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
    Jan 26 16:20:35	charon		14[CFG] <1> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    

    The ipsec.conf is as follows (I'd nulled the IPs)

    config setup
            uniqueids = yes
    
    conn bypasslan
            leftsubnet = #####
            rightsubnet = #####
            authby = never
            type = passthrough
            auto = route
    
    conn con1000
            fragmentation = yes
            keyexchange = ikev2
            reauth = yes
            forceencaps = no
            mobike = no
    
            rekey = yes
            installpolicy = yes
            type = tunnel
            dpdaction = restart
            dpddelay = 10s
            dpdtimeout = 60s
            auto = route
            left = #####
            right = #####
            leftid = #####
            ikelifetime = 28800s
            lifetime = 27000s
            ike = aes256-sha256-modp1024!
            esp = aes256-sha256!
            leftauth = psk
            rightauth = psk
            rightid = #####
            rightsubnet = #####
            leftsubnet = #######
    

    I have removed the entire /var/etc/ipsec folder, and had the service recreate it, and the problem persists.
    Pfsense Version: 2.4.4-RELEASE-p2 (amd64)



  • @missfox said in IPSec not following config:

    AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024

    Hey
    Show the phase 1 settings of the second side of the tunnel (Azure)

    and show settings of pfsense ipsec phase 1 ( webgui)

    0_1548535677972_0d0b7868-5a25-4ff6-af44-9318df29ef39-image.png



  • Here is the Phase 1 on the pfsense side
    0_1548542106816_87df4109-0755-47f7-b394-54e18268fc03-image.png

    The Phase 1 on the Azure side is detailed here (And also in the Log entry for the received proposals...)
    https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices#ike-phase-1-main-mode-parameters
    This is a RouteBased ipSec tunnel, so follow the second column of the table


  • LAYER 8 Netgate

    It looks to me like the proposal isn't matching the correct configuration, not that it is being ignored.

    Need more logs from earlier in the connection than what you are showing.



  • Here you go. Again i'v hashed out the IPs.
    The azure side is the initiator (I need it to be in that direction) This the full log from the moment Strongswan received the azure side initiator packet to the point Strongswan sends the noprop packet.

    Jan 26 23:23:42	charon		10[NET] <1424> sending packet: from ###.###.###.###[500] to ###.###.###.###[500] (36 bytes)
    Jan 26 23:23:42	charon		10[ENC] <1424> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
    Jan 26 23:23:42	charon		10[IKE] <1424> received proposals unacceptable
    Jan 26 23:23:42	charon		10[CFG] <1424> configured proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
    Jan 26 23:23:42	charon		10[CFG] <1424> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    Jan 26 23:23:42	charon		10[IKE] <1424> ###.###.###.### is initiating an IKE_SA
    Jan 26 23:23:42	charon		10[ENC] <1424> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
    Jan 26 23:23:42	charon		10[IKE] <1424> received Vid-Initial-Contact vendor ID
    Jan 26 23:23:42	charon		10[IKE] <1424> received MS-Negotiation Discovery Capable vendor ID
    Jan 26 23:23:42	charon		10[IKE] <1424> received MS NT5 ISAKMPOAKLEY v9 vendor ID
    Jan 26 23:23:42	charon		10[ENC] <1424> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
    Jan 26 23:23:42	charon		10[NET] <1424> received packet: from ###.###.###.###[500] to ###.###.###.###[500] (620 bytes)
    


  • Fixed it, Layer 8 issue... šŸ¤¦
    somehow mixed up the public IP addresses of the phase 1 on the azure side.

    Thanks for the help though :)