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