FYI this appears to have been resolved as per below and does not appear to have been load related; The Sonicwall Syslog was more revealing - "IKEv2 IPsec proposal does not match: DH Group mismatch" & "VPN Policy: GHtoBH; ESP TFC Padding not Supported". I'm not sure why but checking "Enable Perfect Forward Secrecy" appears to have fixed it, although "ESP TFC Padding not Supported" still appears in the logs. Article here https://www.sonicwall.com/en-us/support/knowledge-base/170505666326684. If anyone can offer an explanation that would be appreciated. I'm not 100% convinced is resolved as I feel it may just have renegotiated and worked - However this is a finger in the air feeling and does not come from any solid fact!

@Bengatzu: Had same Problem: PfSense 2.3.4 and lot of Clients which running Win10 (1607). Connect via Open VPN or via TheGreenBow IPsec works without problems. Then Client Updates Win10 (1703) killed all. No possible VPN Connection. Changed HDD and Restored Veeam Backup on Test Client to Win10 (1607) - VPN works successful After HDD replace to old one with Win10 (1703) - no possible VPN Connection. Workaround that solved my Problem: Deaktivate on Win10 (1703) Clients the following Services: IKE- and AuthIP Ipsec Keymodule, IP-Helpservice, IP-sec Rule Agent after reboot all VPN Connections working successful This worked…although all I did was disable the "IP Helper" service by setting to "Manual" Startup Type.  My VPN would not connect unless the "IKE and AuthIP IPSec Keying Modules" were set to Automatic and I did not have an "IP-sec Rule Agent" Service. Thanks so much for the help!

No one? :( I (maybe wrongly) figured I'd try 1. Interfaces> (Assign) 2. PPPs > New (pptp) 3. Link (tried both wan and lan), input one of the IP's I usually get from my server as local with /24 network mask. Gateway typed in the public IP of the pptp server 4. Interface assignments > Assigned the pptp to OPT1 5. Interfaces > OPT1. Enabled it 6. Status > Interfaces. Hit connect.. nothing happens Am I on the right track here?

Firewall reboot took care of the issue

i found this but it doesn't work. can anyone else chime in. he's describing the same situation im facing. but i find that it dosnt work when i try to replicate it. https://forum.pfsense.org/index.php?topic=109524.0

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

Contacted AT&T support and managed to get to Tier 3, but they could still not help me.  I asked if I could get an older modem that supports bridge mode and they told me my service level doesn't support the older modems.  There is a higher level of support, but requires you to pay! I have no reason to believe that the pay support can make any changes to the modem that will allow the IPSec VPN to work.  I asked if they could do a packet capture on their router so we could see what is happening to the ESP packets that get returned from the remote pfSense firewall.  I'm not sure the tech understood how a packet capture works.

Haha. Just got it working.  I was using manual outbound NAT rules.  Switched back to automatic and then back to manual to pfSense would regenerate NAT rules including those for IPSEC. All traffic flows now!

You haven't provided any details about the hardware or the VPN configuration so it's impossible to speculate what the bottleneck might be. It could be CPU, it could be the encryption settings, it could be hardware acceleration in the ER-X helping it out, etc.