IPSEC on Alix with PFsense 2.2

[fs]

Hello together,

just registered here to report some potential bug.

I recently updated to pfsense 2.2 and found the IPSEC-Tunnel not running (no it didn't run before, because something wasn't configured correctly and I didn't had time to follow this up.

I digged somehow deeper and found the following log:
"[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel".

While searching through the I-Net I didn't found a clear answer on my problem so I report it here.

I switched back to 2.1.5 and there the IPSEC-Tunnel was coming up fine immediately … with the config done in 2.2 ... congrats on this.

The affected system is an ALIX board with nanobsd install while on the APU with standard install the IPSEC-Tunnel is running fine.

Here I decided to leave this issue up to the professionals ...

Regards

FS

[Clouseau]

I use Alix boards 2D3 and APU with no issues (site-to-site vpn IKEv1 and IKEv2.)  It would help that you would show your Phase1&2 config.

[fs]

I think I got it fixed … it's been the glxsb restriction of aes to 128bit keylength ...

Interestingly the 2.1.5 obviously has chosen at least once the 128bit keylength even though it was set to automatic. I couldn't reproduce it ... but I don't care abaut that.

Now both boxes are running on 2.2 with the tunnel up ...

Thanks anyway, thread can be closed.

FS

[AndrewZ]

Just faced the same issue while configuring IKEv2 remote access between Android (strongSwan VPN Client) and PFsense 2.2 on my Alix 2D13.
Change from AES-256 to AES-128 solved the issue.

BTW, is it really necessary to manually add rules for UDP 500 and 4500 on WAN? Someone mentioned that those rules added automatically.

[cmb]

I added input validation to prevent attempting to use AES > 128 bit where glxsb is enabled, as people don't seem to realize that card will break > 128 bit.
https://redmine.pfsense.org/issues/4361

I also added a note to the upgrade guide, since this misconfiguration apparently wasn't a problem previously, but strongswan (rightly) uses the strongest-available key length, which glxsb breaks.
https://doc.pfsense.org/index.php/Upgrade_Guide#IPsec_Changes

@AndrewZ:

BTW, is it really necessary to manually add rules for UDP 500 and 4500 on WAN? Someone mentioned that those rules added automatically.

No, those are automatically added.

[AndrewZ]

@cmb:

No, those are automatically added.

Thanks, but I don't think it's the case on my box. I had to add the rules manually when I noticed the ports blocked in the firewall log.
What will be the right way to check this behavior? Remove all IPSec configs, reboot and add again?

[doktornotor]

pfctl -sa | egrep "isakmp|nat-t|esp" | grep pass

[cmb]

It'll add them to the interface where it's bound. There are some exceptions where you have to manually add rules, like if you have a routed public IP subnet with VIPs on an interface other than the WAN where those are sourced, there is no way to tell definitively where that traffic will be coming from, so manual rules are required in that circumstance. For all the most common circumstances, where you're binding to WAN or a VIP on WAN, they're there automatically.

[AndrewZ]

OK, removed manual routes I added, disabled IPSec, rebooted, re-enabled IPSec - routes are there:

/root: pfctl -sa | egrep "isakmp|nat-t|esp" | grep pass
pass out proto udp from any to any port = isakmp keep state label "IPsec:  any  - outbound isakmp"
pass in on vr1 proto udp from any to any port = isakmp keep state label "IPsec:  any  - inbound isakmp"
pass out proto udp from any to any port = sae-urn keep state label "IPsec:  any  - outbound nat-t"
pass in on vr1 proto udp from any to any port = sae-urn keep state label "IPsec:  any  - inbound nat-t"
pass out proto esp all keep state label "IPsec:  any  - outbound esp proto"
pass in on vr1 proto esp all keep state label "IPsec:  any  - inbound esp proto"

Thanks!