IPSec not following config

[missfox]

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)

[Konstanti]

@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)

[missfox]

Here is the Phase 1 on the pfsense side

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

[Derelict]

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.

[missfox]

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)

[missfox]

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 :)