@livestrong2109 said in Having issues with Azure IPSec Connection: Jun 1 05:08:08 charon 14[CFG] <7> received proposals: The other side 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 Jun 1 05:08:08 charon 14[CFG] <7> configured proposals: Your side IKE:AES_GCM_16_256/PRF_HMAC_SHA1/MODP_1024 Jun 1 05:08:08 charon 14[IKE] <7> received proposals inacceptable You are forcing AES GCM in the Phase 1 and the other side wants AES CBC (or 3DES). Based on what the other side is presenting I would probably select AES 256 and SHA256. [image: 1528272338840-screen-shot-2018-06-06-at-1.04.44-am-resized.png] Jun 1 05:08:08 charon 14[CFG] <7> no acceptable ENCRYPTION_ALGORITHM found Jun 1 05:08:08 charon 14[CFG] <7> selecting proposal: Jun 1 05:08:08 charon 14[CFG] <7> no acceptable ENCRYPTION_ALGORITHM found Jun 1 05:08:08 charon 14[CFG] <7> selecting proposal: Jun 1 05:08:08 charon 14[CFG] <7> no acceptable ENCRYPTION_ALGORITHM found Jun 1 05:08:08 charon 14[CFG] <7> selecting proposal: Jun 1 05:08:08 charon 14[CFG] <7> no acceptable ENCRYPTION_ALGORITHM found Jun 1 05:08:08 charon 14[CFG] <7> selecting proposal: Jun 1 05:08:08 charon 14[CFG] <7> no acceptable ENCRYPTION_ALGORITHM found Jun 1 05:08:08 charon 14[CFG] <7> selecting proposal: Jun 1 05:08:08 charon 14[CFG] <7> no acceptable ENCRYPTION_ALGORITHM found All of that is probably Azure attempting PFS groups you don't have defined. Probably more secure than PFS group 2.

You can't disable it if NAT is anywhere in what would be the ESP path. There are automatic rules for IPsec tunnels as most people who define an IPsec tunnel want IKE, ESP, and NAT-T to pass between the endpoints. You can disable these rules in System > Advanced, Firewall & NAT, Disable Auto-added VPN rules

An update: Changing the Shrewsoft setting on the Authentication tab for "Local Identity" from "Key Identifier" (which worked for the last several years) to UFQDN (using the same string) fixed the issue for me. I consider myself lucky to have found this, but maybe it makes sense to others. Thanks to anybody who gave this some thought. :-) SJ

@awebster thanks. As noted, it’s coming to 2.4.4.

FYI- We are making progress on IPsec VTI which will let this work. It should be in snapshots in the next week or so.

@TMA-3: I'm curious - is this a Microsoft problem or a pfSense problem?  Both? I'm a little concerned that I've created an installation that will break at the next upgrade, but I hope ECDSA support will be added soon so I don't have to worry. Thanks again for sharing all this information - it is invaluable! Sorry I haven't replied soon, I had some issues in the last months and I had very little time to connect to anything. I'm pretty sure it's a microsoft issue and specific with IKEv2. IKEv1 works perfectly with fragments. Probably (and hopefully) next versions will fix it. FYI, it's very possible to fix the ECDSA even on latest version. I tested it this week. I'll update this post soon using public certificates from letsencrypt.

So I found when it occur, after you first time create a gre over ipsec everything works great, but after reboot it created GRE, and then IPsec, so GRE is not being encrypted. Is it a bug?

Looks like NAT and reauthentication is giving this issue in a certain case. The clients will start to get double virtual ip's if the NAT device expires/reboots/crashes. If I disable reauthentication on both sides it solves the issue. I still can't explain why this works but for me it looks like it could be a bug in strongswan. It's 100 percent reproduceable with the follow setup RW(client) -> Pfsense(nat) -> Pfsense(endpoint) Rebooting the NAT will give double virtual ip's to the RW where one of the ip given doesn't work