IPSec tunnel problems after pfSense 2.2.3 upgrade

frmpf

The issue here is the encryption type set on the Phase2 only. If anyone is seeing something different please say so.
The cause seems to be the AES-NI module that is trying to decrypt traffic that it can't so an alternative solution is to disable the AES-NI module if you must use AES-CBC for example.

Is anybody here NOT using the AES-NI module/AES-NI capable hardware?

Steve

Can confirm, disabled AES-NI on the 2.2.3 device and now the tunnels work in the original configuration. Does that leave room for hope that a fix won't be too tough, since 2.2.2 still works fine with the AES-NI component enabled? It's just the kernel module loaded for the hardware aes?

yuljk

I can confirm that everything is working after switching across to 3DES for phase 2 (algorithm SHA1)

I did not have the AES-NI module enabled on my box at any point.

Thanks guys - Hopefully we'll see a fix for AES fairly soon :)

Chris

heper

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

might be "fixed"in the snapshots dating after renato's comments

pbnet

Still does not work for me, even if not using AES encryption

Here is my setup:

On PFSense 2.2.3:

On cisco RV042:

And the results are

on PFSense:

on RV042:

Now the logs show incomplete ISAKMP SA on the RV042

and conn unrouted on PFSense

Of course, no machine on the remote VPN side can be reached.

I don't really think it's a AES issue here, since I'm not using it…. or am I doing something wrong ???
Everything was fine on PFSense 2.2.2

Thanks for any suggestion

stephenw10

That looks like an identifier mismatch, nothing to do with this bug.
The Linksys is complainiung about the identifier sent by pfSense being an FQDN not an IP.

Steve

pbnet

Thanks a lot Stephen.

You're a life savior.

One quick question, regarding something I don't understand

My identifier: My IP Address (does it take the WAN IP Address here) ?
Peer identifier: Peer IP Address (does it take the IP/host name of remote gateway ?)

Thanks a lot.

vbentley

You can use IP addresses for your identifiers but they are not much use unless the WAN IP addresses at each end are both static. The IP address identifier is just for IP addresses not hostnames.

If you have one or more WAN interfaces with dynamic IP addresses you should use an identifier that doesn't change.

If you have a resolvable hostname for your pfSense host and another for your Linksys host you could use the Distinguished Name type like in this example:-

On pfSense
My Identifier: Distinguished Name: pfsense.mydynamic.dns
Peer Identifier: Distinguished Name: linksys.mydynamic.dns

On Linksys
My Identifier: Distinguished Name: linksys.mydynamic.dns
Peer Identifier: Distinguished Name: pfsense.mydynamic.dns

vbentley

Am I the only one on this thread that was using RSA Certificate authentication on 2.2.2?

RMB

Hi,

I have had some contact with pfSense Support and they have narrowed down the problem.

-quote-
Expect 2.2.4 out soon!
For now, simply disable AES-NI from System > Advanced, Misc, set Crypto Acceleration to None, and then reboot.
-end-of-quote-

I can confirm that this workaround is working for me!

Kind regards,
Rene.

vbentley

@RMB:

I can confirm that this workaround is working for me!

Are you using Pre Shared Keys or RSA Certificates for authentication?

RMB

I am using Preshared Keys.

vbentley

Thanks. Using PSK works for me too, but I would rather use certs instead.

I don't think that the AES patch rollback will make any difference to the issue I am experiencing which is a failure to establish a P1 with RSA Certs and 3DES.

I suspect that I could be the only one using RSA Certs with site-to-site IPsec VPN on pfSense as more people would have spotted this.
I really wish 2.2.3 was just a GUI XSS fix.

doktornotor

@vbentley:

I suspect that I could be the only one using RSA Certs with site-to-site IPsec VPN on pfSense as more people would have spotted this.
I really wish 2.2.3 was just a GUI XSS fix.

Mutual RSA works here with 2.2.3 on pfS -> pfS (2.2.3)

stephenw10

Obviously we haven't tested with whatever hardware crypto cards you are using but the base FreeBSD hasn't changed so I wouldn't have expected them to fail.
Does it work if you choose not to use the hardware encryption?

Steve

vbentley

@doktornotor:

Mutual RSA works here with 2.2.3 on pfS -> pfS (2.2.3)

Excellent!
Can you tell me if you are using IP:value references in your certs or DNS:value references?

I am using DNS:value references because one end of the VPN is on a dynamic IP with dynamic DNS. It works on 2.2.2 perhaps StrongSwan 5.3.2 is looking for something in my certs that 5.3.0 doesn't need. I'm thinking this has something to do with reqid.

vbentley

@stephenw10:

Does it work if you choose not to use the hardware encryption?

I will try building two test boxes without crypto cards next week.
OpenSSL version hasn't changed so I'm fairly confident this isn't the problem.

phil.davis

OpenSSL version hasn't changed so I'm fairly confident this isn't the problem.

That cannot be automatically assumed because of:

FreeBSD patches OpenSSL without changing the version number.

https://forum.pfsense.org/index.php?topic=91461.msg532876#msg532876

doktornotor

Main problem here is that debugging any IPsec is impossible since logging is totally no-op (yet another regression). I really don't have any decent words for this "strongs"wan thing. Has been nothing but one giant pain in the butt ever since it's been introduced.

mauirixxx

I know this thread is over 2+ weeks old but ….

@Work tonight I upgraded pfSense to 2.2.3 with the AES-N1 option enabled.
@Home when 2.2.3 was released, I upgraded right away, and had the AES-N1 option enabled.

After the upgrade at work tonight, I had the same symptoms - endpoints would connect like they should, but 0 traffic passed between them. After I disabled the AES-N1 acceleration @work and rebooted, all is well and acting like it should again.

So I have 1 endpoint with it enabled, and 1 without, and traffic flows. I haven't tried re-enabling it because stuff works now.

Next test would be to disable it @home, and enable it @work, and see if it still works as it should. Or should I just leave well enough alone?

stephenw10

It's fixed in 2.2.4 snapshots. Perhaps the CPU at the home end is not actually supporting AES-NI as it reports?
If the module actually loads at boot (check the boot logs) then I would exepct it to break IPSec if AES is used.

Steve