Sweet thanks Jimp I am sure I speak for a few people that we look forward to this support and appreciate the efforts of yourself and your team.

Support for routed IPsec/VTI is in 2.4.4 snapshots. It's still being tested but it's fairly solid at the moment with no major caveats that I'm aware of.

https://redmine.pfsense.org/issues/8544

@jimp Thank you very much for the response! Looking forward to v2.4.4 being released :)

Short of moving out of Egypt, probably not.

Thank you! deleting P1/P2 and recreating them works now.

Thx - I just registered with redmine and posted a new bug report ticket:

https://redmine.pfsense.org/issues/8549

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

0_1528272343163_Screen Shot 2018-06-06 at 1.04.44 AM.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.