Excellent questions. I will check when it happens again. I appreciate you replying so quickly.

-Andrew G

Removed all config and re did all config on both pfsense and Cisco and it now works.

Dont know why it works as I din't change any settings....

I assume some things here which may be wrong:

one pfSense cluster = HA group Azure connection = your IPSEC goes to your Azure server/cluster

We use a setup something like this one currently, just not connected to Azure but another third party. This has been used for a few years now with no issues. We only have one pfSense though, not an HA group on our side.

For the interface, we use a two-tiered gateway failover group, and on the other side, there are two profiles set, one for each of our VPN IPs. I imagine a load balance group would work the same for IPSEC, just not prefer one over the other?

By the time we replace our aging firewall with an HA failover group, we could use the CARP IPs in the failover group I guess? In reality, we'll likely go for BGP as well by then, but our IPSEC solution currently works fine without BGP.

If I have misunderstood something, then please elaborate.

Yes I tried disabling TCP offloading, and it reduced my throughput by 80%. I re-enabled it.

I am getting the full 150Mbps over SMB on the PFSense tunnel, that is not the issue. I am sorry, it can be difficult to explain these issues using only text and I may not be explaining this correctly.

Throughput is good!
Random filesystem access is bad.

Example:

I search the SMB shared for all jpg files. Using the 50Mbps Cisco tunnel, it takes 5 minutes. Using the 150Mbps PFsense tunnel, it takes 15 minutes.

It is an odd issue to have, and one I have not seen before.

don't know why, but suddenly it's working.
I just deleted phase 2 and recreated it...

Is there a NAT rule to let mobile users to go out?
Or they only use internal resources, thus not needing NAT?

If there is a NAT rule to let this mobile users go out, can you confirm if the NAT is set to static, or dynamic ?

Thank you that resolved it. I didn't realize the IPSec NAT and the firewall NAT were the same. Thanks again.

Thought I'd put a final update into this as the working solution.

After getting a couple of Cisco ASA 5506 units on site and creating exact copies of the IPSEC VPNs that I was having issues with, and running these test VPNs over other IP addresses on our twin internet links back to the firewall, I couldn't get the damn things to fail like the original links. They worked for a good couple of weeks without a dropped packet, even although I'd put the phase 1&2 settings to rekey every hour and half hour respectively in the hopes of generating enough debug traffic on both sides to see where the issue lay.

Went back to the outside agency in question, presented them with my findings, to be told point blank again, that the fault was on our side. After a pretty gritted teeth conversation with their network admin, he let slip that their configuration had a data transfer limit on both VPNs, where it would rekey every 4Gb of traffic. This was the first I'd heard about it, the agreed VPN documentation didn't have this noted, and PfSense IPSEC configs didn't have this in there (I don't think the StrongSWAN version currently in use on PfSense has this as an option anyway). After insisting that this be removed, both VPNs haven't failed since.

Cheers,
Monty

This appears to be an MSS issue. I chnaged the index.html file down to a couple of words and the curl works. Will see if I can resolve by changing the MSS settings.

3 days of troubleshooting, you are a legend!! The issue was source/dest on the interface level (thought it was only on instance level).

Thanks heaps - much appreciated!

https://docs.netgate.com/pfsense/en/latest/book/ipsec/index.html

IPsec provides a standards-based VPN implementation that is compatible with a wide range of clients for mobile connectivity, and other firewalls and routers for site-to-site connectivity.

pfSense is not designed to be used as a IPsec mobile client itself.