IPSec packet loss/routing issue with 21.02-RELEASE

Majik

@jimp Yes, I have done that. TBF it was pretty stable with AES-256-GCP, but I would rather have the option to use AES 256 if I have to.

Thanks.

Keith

jimp

So is it working OK with that setup now?

Majik

The VPN seems to be OK now. I have switched to QAT as a precaution, but AES-256-GCM seemed to work fine without that.

I have not tried AES 256 with QAT.

I have some issue with Unbound randomly dying, but that's something else, and I see there's already a thread or two about that.

Cheers,

Keith

e37921

@jimp I had this issue with one Ipsec vpn on a SG-5100. I am using AES-CBC SHA256. I set the hardware acceleration to none, now the tunnel is staying up. Before, the vpn would show as up but stop sending traffic. Took a few hours to find this topic but glad I did. Thanks

jimp

@e37921 said in IPSec packet loss/routing issue with 21.02-RELEASE:

@jimp I had this issue with one Ipsec vpn on a SG-5100. I am using AES-CBC SHA256. I set the hardware acceleration to none, now the tunnel is staying up. Before, the vpn would show as up but stop sending traffic. Took a few hours to find this topic but glad I did. Thanks

If you find that you need the acceleration you could enable QAT on that SG-5100, or you could switch from SHA256 to another hash

mbr

@jimp I'd like to add that I updated an SG-5100 to 21.02 and am having what appears to be the same problem.

Site-to-site IPsec with Cisco ASA on remote end with AES256 and SHA1 for P2. Tunnel connects but after ~30 seconds my traffic stops and remote side reports ESP failed authentication. Using a different hash works but I'll try switching to QAT instead of AES-NI for now since that seems to work for others.

Issue seems related to this post as well:
https://forum.netgate.com/topic/161268/ipsec-tunnels-using-sha256-may-not-connect/5

Thanks to everyone for the troubleshooting tips!

viniciusmerlim

@majik The number of operations required to brute force a 256-bit cipher is 3.31 x 10^56. This is roughly equal to the number of atoms in the universe. And 1.02 x 10^18 - around one billion billion (one quintillion) - years to crack a 128-bit AES key by force. This is older than the age of the universe (13.75 billion years).

The most powerful supercomputer in the world in 2017 was the Sunway TaihuLight in China. This beast is capable of a peak speed of 93.02 petaflops. This means that the most powerful computer in the world would still take some 885 quadrillion years to brute force a 128-bit AES key.

I think you can use 128bits key with no worries.

adeparker

Just to add in that I had the same issue with an XG-7100. Turned off the Crypto acceleration totally and now all ok. Using AES256, SHA1 and AES128, SHA1.

Tried switching hash methods but no real change at this end (other than mobile clients not being able to connect)

Hoping this get's fixed in the next production release so can turn back on.

sgnoc

I found this topic after having similar issues. I have an IPSec tunnel to a remote endpoint with a file server. I was able to ping the file server from my end with no problems but as soon as a computer (didn't matter which one) tried a TCP CIFS connection to the server, I was only able to usually get the directory structure loaded before the connection became unresponsive. Oddly enough, the P1 and P2 connections were still functioning and keeping the connection open.

I just had no response from the server with CIFS and the ping replies stopped.

I first tried to change the AES-NI hardware encryption to QAT. That got better results, but after transversing through another sub-directory or two, the CIFS became unresponsive again. I then did as @adeparker suggested and turned off hardware encryption completely, did a reboot to unload the modules and now the CIFS is completely responsive and there are no problems with the file server connection anymore.

Also hoping this gets fixed in the next release. I'm running pfsense on the XG-7100 and one of the reasons I selected this one was specifically for the hardware encryption with OpenVPN and IPSec.

viniciusmerlim

@adeparker IST has banned the use of SHA-1 by U.S. federal agencies since 2010. This offers no acceptable security at all. I'm using AES-128GCM with SHA256. I have an SG5100 with QAT enabled and it is working wonderfully. Is it possible that this problem is related to the XG7100?

viniciusmerlim

@sgnoc How was your IPSec configuration before you disabled qat?

sgnoc

@viniciusmerlim I had Cryptographic Hardware set to AES-NI and BSD Crypto Device. I ran that way for the last year and a half with no issues until recently. QAT didn't seem to resolve the problem, but improved it just slightly. Although I did not reboot after changing to QAT, so maybe that would have been a difference?

I then switched to None, rebooted and it is working the way it used to. No other settings were modified.

P1 is set AES / 256 bits / SHA256
P2 is set ESP / AES (256 bits) Transform, SHA256

sgnoc

@viniciusmerlim I just upgraded to the new 21.05 release tonight and it seems to have resolved my issues. I re-enabled the AES-NI with no changes to my IPSec configuration on either end. The hardware crypto has been turned back on and my IPSec tunnel is back to working properly with optimal speeds (no latency or speed issues noticed).

Hopefully that resolves your issue too. I didn't check the changelogs to see if the specifically mentioned this in there, but it definitely fixed the problem for me.