@jimp -Thanks for solution this seems to have resolved the connectivity issue. I have another issue which is causing IPSec to disconnect. Also ipsec service is not rebooting unless entire pfsense instance is rebooted. but it looks like different issue i'll troubleshoot and raise different thread if required.

Thank you so much for the help.

Thank you for your reply. I upgraded our current pfsense 2.4.5 p1 to 2.5.0, but then ipsec connections don't work and there is nothing in Description tab of Phase 1 any more.

The PSK could be used to decrypt traffic if someone can capture packets between the endpoints. A weak key, in theory, could be brute forced. There is a lot of info around about this on the web by people much more familiar with the crypto than I.

The PSK could also be used by someone in the right position to MITM or intrude over the VPN, but depending on your settings they would likely have to be able to intercept and spoof addresses in between for that to happen. If you have loose/weak P1 settings (e.g. your remote is "any"/0.0.0.0.0 for example) then the danger is increased. As above, weak keys could be brute forced.

Using certificates is much more secure, as is using strict P1 settings to ensure only specific remotes can connect.

I figured that might be the case. The cloud provider doesn’t natively offer that.

Would you have any recommendations on being able to run it on the pfSense box itself on the on-prem side?

I worked around the problem in this particular setup by using Routed (VTI) in the child SA. This was possible because there are pfSense on both sides.

When using other VPN gateways, sometimes I can't use routed IPsec SA and then it would be nice when GRE over IPsec would just work.

Kind regards,
Mathias

@killmasta93
ping between FW doesn't work without extra actions.
see: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-s2s-psk.html#pfsense-initiated-traffic-and-ipsec

i updated an test pfsense to 2.6 dev version and the problem is solved.

I can confirm that saving the WAN interface (without changes) indeed worked as a workaround.

All is working now. Thank you!

I have found the problem;

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

It is related to the combination of AES-NI and P2 SHA256.

Temporary workaround: disable AES-NI

I hope this will be fixed soon!

I was just searching this topic, not for the same use case but to centrally manage a lot of pfSense appliances, I think being able to set them up as IPsec clients with a virtual IP would be useful.
At this time I have to create a separate tunnel for each managed pfSense, instead of dynamically provisioning virtual IPs via Radius.

I'm pretty sure the answer is no, and the strongswan virtual IP option cannot be used with pfSense as a client.

The difference between those screenshots is the IKE version (IKEv1 vs Auto), the missing field is only valid for IKEv2 (and Auto can use IKEv2). It's not likely to be related to any problem you are seeing.

@eric-scace Last point: Everything works fine if there is only one Phase 2 definition for the full subnet at each site — except, of course, all traffic gets encrypted.

Another way of looking at this problem: How does one take a tunnel between two sites that encrypts traffic (10.32.0.0/12 ↔︎ 10.160.0.0/12)... and divert traffic between a specific subset pair of address ranges (source & destination... in this example 10.40.0.0/13 ↔︎ 10.168.0.0/13) to be sent (potentially through a different tunnel) in the clear?

@msswift Thank you that fixed it for me too!