In the end I switched over to WireGuard - smashing it in around 6-8 MB/s. Tried everything with IPSec but gave up. I think I might have to investiage Wireguard further and switch the other VPNS over too.. The WireGuard seems to really forgiving of the StarLink latency/dropped packets. Here is a file copy from a remote server to local along with 20x robocopy in the background doing file compares (no actual transfers) [image: 1634368161001-fc.jpg] [image: 1634368165462-wg.jpg]

@bp81 I believe we have found the resolution, and I wanted to post it here for anyone else encountering the issue. In our DNS forwarder, we had a domain override set for our company's domain. This is the same domain in the hostname for the remote gateway listed above. The domain override was pointing at a DNS server that is not accessible without the tunnel up. Clearly this was causing the IPSec service to fail repeatedly to establish its tunnel. So there was a misconfiguration on our part which we have fixed. I still maintain that it's a bug if the ipsec service causes the web gui to crash / become unresponsive even when it's a self induced failure state due to misconfiguration. I understand it's possible this may be a limitation of the ipsec service, but it is worth looking at even if it is an edge case.

Bonjour, je rencontre actuellement le meme probleme entre un pfsense et un fortinet. J'ai appliqué les propositions de gerdesj (hormis le reboot coté fortinet). Pour le moment le probleme persiste. Si quelqu'un a une idée. Merci Hello, I currently encounter the same problem between a pfsense and a fortinet. I applied the proposals of gerdesj (apart from the reboot on the fortinet side). For the moment the problem persists. If someone has an idea. Thank you Oct 11 09:46:30 charon 55488 06[NET] <con100000|1> sending packet: from 10.10.10.254[500] to 84.14.183.243[500] (336 bytes) Oct 11 09:46:30 charon 55488 06[IKE] <con100000|1> retransmit 1 of request with message ID 0 Oct 11 09:46:30 charon 55488 06[CFG] ignoring acquire, connection attempt pending Oct 11 09:46:30 charon 55488 06[KNL] creating acquire job for policy 10.10.10.254/32|/0 === 84.14.183.243/32|/0 with reqid {1} Oct 11 09:46:29 charon 55488 06[CFG] ignoring acquire, connection attempt pending Oct 11 09:46:29 charon 55488 06[KNL] creating acquire job for policy 10.10.10.254/32|/0 === 84.14.183.243/32|/0 with reqid {1} Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 disconnected Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 requests: list-sas Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 registered for: list-sa Oct 11 09:46:28 charon 55488 07[CFG] vici client 2 connected Oct 11 09:46:26 charon 55488 06[NET] <con100000|1> sending packet: from 10.10.10.254[500] to 84.14.183.243[500] (336 bytes) Oct 11 09:46:26 charon 55488 06[ENC] <con100000|1> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] Oct 11 09:46:26 charon 55488 06[CFG] <con100000|1> sending supported signature hash algorithms: sha256 sha384 sha512 identity Oct 11 09:46:26 charon 55488 06[CFG] <con100000|1> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 Oct 11 09:46:26 charon 55488 06[IKE] <con100000|1> IKE_SA con100000[1] state change: CREATED => CONNECTING

This was solved by missing GW on WAN interfaces

Ah, didn't spot this yesterday when I looked https://redmine.pfsense.org/issues/11910 This can be considered solved I think.

Just for the record. Just loaded the cert onto a Yubikey 5 hardware smartcard. Same error/result.

@mmapplebeck Hello. Have you solved the reconnection issue? I have updated Pfsense to version 2.5.2. I have check and confirm all data from site A to site B. I have reduce the time to reconnected and that aliave some trouble but not fix it. Too I have enable and set MSS to 1400. Every day one of my tunnels is blocked. It doesn't seem to renegotiate the connection well. After terminate one of the Phase 1 zombie connections, the communication is reset. Also another tunnel connection fails time to time and I have to disable it for any of the Phase 2 to work again.

@elvisimprsntr The router is a TP-Link load balancer that does the connection to the ISP, I tried The Port Forwarding UDP/TCP 500 (Virtual Servers) to the pfsense IP Address but same issue...

Your pre-shared key does not exactly match the key at the far side. https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec.html#phase-1-pre-shared-key-mismatch If it works sometimes and not others, it may be that it only works when initiating in one direction. It could still be a problem with the key, but perhaps something more subtle like an extra space at the start/end that is ignored when checking on one side but not the other.

@michelz said in High CPU load (100% on one core) when enabling Phase 1: Disable properly means IPSec won't need it and won't have these errors in the log? Correct. When disabled with the patch, references to that daemon and/or its services are not present in the IPsec configuration, so the errors will not happen.

@keyser Updated: It actually works if your IPsec is running in tunnelmode and you make sure to resolve the vpn endpoint name to the public IP on the WAN interface, from the inside as well :-)

@jimp Great, thanks for the hint. I was thinking the right direction, but missed the setting. I look more thoroughly again and found it.