@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

No

You probably need to add tunnels so sites B and C think the remote access tunnel network is interesting to IPsec so the reply traffic from there makes it back to Site A and, from there, back to the remote client.

List all your networks at the sites and the tunnels (phase 2s) you have established. And the remote access tunnel network, and whether it is split-tunnel or if it sends all traffic over the VPN from the clients.

I recently read a post where someone solved their problem right after posting here for assistance… this has now happened to me.

All I had to do is add a route manually via powershell.

Add-VpnConnectionRoute -ConnectionName "VPN_NAME" -DestinationPrefix "Network/Subnet" -PassThru

taken from here

https://forum.pfsense.org/index.php?topic=127457.0

Patch application fixed the issue! Thanks!

@domf:

Enable "IP Forwarding" on the interface attached to the pfsense host.

Bingo. I've been banging my head on my desk for two days, and this has solved my problem. Thankyou!

pfSense is 2.3.5-RELEASE (i386)

You are not running racoon. You are running strongswan (charon). i386? It's 2018.

I would guess the phase 1 is succeeding then the phase 2 is failing and one side or the other is subsequently deleting the phase 1.

Impossible to tell without looking at the IPsec logs.

Guidance:

https://doc.pfsense.org/index.php/IPsec_Troubleshooting