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

@djohnson
This is a late reply but it may assist someone else in future.
The VOIP audio traffic (RTP) require separate UDP ports to be open. The exact range will vary depending on your VoIP system.

Hence, if the RTP ports are not open, you can experience a "working" system, but with a complete lack of audio.

This looks indeed not possible to do.
Post may be locked.

@jimp Thanks to! Changed to TLS Web Server certificate, error disappeared.

anyone?

@jimp Thanks again!

I'll have a look into a way of automatically deploying the certificates per user, per device then. I have a CA external to pfSense I can leverage for that.

This will let me get the core users we need going in the meantime.

Have a great day
Matt :)