IPsec tunnels using SHA256 may not connect

LamaZ

Maybe issue is around Phase 2 Authentication Method SHA256? SHA384 fixed it for me, but broke my iOS/OSX native IKEv2 clients. For folks who are seeing broken tunnels, try a hash that isn't SHA256 if the client on the other end supports it.

I promise I'll write up and add logs to show the symptoms and resolution, but in the mean time. Here is a short summary.

Android Strongswan app logs were filled with:

ESP decryption or ICV verification failed

That lead me to this 4 year old Strongswan ticket. https://wiki.strongswan.org/issues/2247#change-7896
that says:
Make sure you're not using sha256. There were and still are implementation bugs with that algorithm and there will always be. Some platforms just implement it with the wrong output size (96 bit and not 128 bit). Choose another authentication method for IKE and ESP but sha256.

So I tried SHA384, and traffic flows.

Symptoms: Clients establish connection, but no traffic.
Solution: Set Phase2 hash to SHA384, traffic flows.
Known issues: Breaks native iOS/OSX IKEv2 clients (without using Apple Configurator 2 profiles).

PS - I took this as the perfect excuse to setup WireGuard as a backup.

-LamaZ

jimp

The changes to SHA256 in FreeBSD for RFC4868 compliance were a long, long time ago (maybe 10 years ago)? I'm not aware of anything recent in that area.

LamaZ

@jimp I'm so happy I didn't spent all the time to carefully document all the steps I went through to pinpoint this issue and workaround with logs and whatnot.

Question, from your last post "With that in hand, check for an existing thread which matches the symptoms exactly. If one exists, post there. If there isn't one, create one.":

Should I create a new thread with my symptoms that were somehow fixed with changing P2 hash from SHA256 (and re-broken when put back to SHA256) or just let it be? I couldn't immediately find a matching issue in list of recent IPsec issues.

jimp

I split your message off into it's own thread so it's OK to keep it here.

Was it working on a previous version of pfSense?

Judging by the strongSwan bug and other notes, the problem is on the client side, not pfSense, so there may not be anything to do on pfSense.

Also, what hardware are you on? And are there any hardware acceleration features enabled on it? Maybe the OS does SHA256 right but the acceleration hardware is using the non-compliant method.

LamaZ

Apologies if this thread gets formatting broken. I keep getting flagged as spam. :) I can't blame the bots. I wonder sometimes myself if I'm spam.
"Post content was flagged as spam by Akismet.com"

@jimp said in IPsec tunnels using SHA256 may not connect:

I split your message off into it's own thread so it's OK to keep it here.

Thanks for your help!

@jimp said in IPsec tunnels using SHA256 may not connect:

Was it working on a previous version of pfSense?

Yes. It has been working rock solid on previous versions (with native OSX/iOS IKEv2 VPN clients)

@jimp said in IPsec tunnels using SHA256 may not connect:

Also, what hardware are you on? And are there any hardware acceleration features enabled on it? Maybe the OS does SHA256 right but the acceleration hardware is using the non-compliant method.

I'm on an SG-5100. I haven't touched the crypto hardware acceleration settings from the factory. System->Advanced->Miscellaneous->Cryptographic Hardware is currently set to "AES-NI and BSD Crypto Device (aes-ni,cryptodev)"

Prior to the upgrade the config was:

<crypto_hardware>aesni_cryptodev</crypto_hardware>

Here is the appropriate phase2 snippet from the config.xml prior to the upgrade.

<hash-algorithm-option>hmac_sha256</hash-algorithm-option>

-LamaZ

jimp

Can you try without AES-NI loaded perhaps?

One thing another developer noted is that in the previous version, the AES-NI driver did not implement SHA acceleration and now it does.

LamaZ

@jimp said in IPsec tunnels using SHA256 may not connect:

Can you try without AES-NI loaded perhaps?

You read my mind. No luck. I just tried all the options (with setting back to SHA256) I could get away with without rebooting. It says I only need to reboot if I want to disable. Network is live, so I can't reboot until late at night or early AM.

Full disclosure, I am on a stock 21.02 install. After the upgrade tried a complete re-image where I saved the config, re-installed from USB device and uploaded the config. I haven't installed all the relevant ipsec patches.

-LamaZ

jimp

Adding the IPsec patches is a good step, though I'm not sure if it would help this, it's best to be sure the other issues are not a factor.

It is best to reboot to ensure that AES-NI is not in use, though it should be enough to stop IPsec, unload the module manually, then restart IPsec.

LamaZ

I'll test completely unloading the hardware crypto module tonight/tomorrow with a reboot and report back.

LamaZ

@jimp said in IPsec tunnels using SHA256 may not connect:

One thing another developer noted is that in the previous version, the AES-NI driver did not implement SHA acceleration and now it does.

Yes, changing the cryptographic hardware setting is a viable workaround for supporting P2 SHA256 on 2.5.0/21.02. A reboot is/was required for the setting to take effect. I changed the setting to Intel QuickAssist (QAT) after verifying my processor supports it.

I love it when a logical explanation is found.

Steps taken:

~~I installed all the relevant ipsec patches~~. Just noticed that I haven't actually applied the patches. Oops! At least that rules them out.
Set P2 hash to SHA256 in IPsec settings.
Set System->Advanced->Miscellaneous->Cryptographic Hardware to "Intel QuickAssist (QAT)". If your processor doesn't support it, then try "None".
Reboot (needed to load the selected crypto module).
Enjoy your IPsec again.

Tested with:

Android Strongswan app.
Native IKEv2 Apple iOS client.
Native IKEv2 Apple OSX client.

Question: Am I losing significant performance or some other major drawback by using the Intel QAT over the AES-NI driver?

Thanks @jimp!

-LamaZ

like they say:
Remember: Upvote with the button for any user/post you find to be helpful, informative, or deserving of recognition!

jimp

We're still running numbers to get full performance data but if the early indicators are accurate then you shouldn't be losing anything by using QAT.

I opened a Redmine issue to have this looked at ASAP.
https://redmine.pfsense.org/issues/11524

LamaZ

Just to close the loop on this, this issue is resolved in 21.05/2.5.2.

I just finished setting the Crypto device back to AES-NI and BSD Crypto Device (aesni,cryptodev) on my SG-5100. Rebooted to load crypto device change, and happy to report that my IPSEC connections using SHA256 hashing are stable.

-LamaZ