IPSec:IKEv2, new ciphers and hashes problematic?

rcfa

I had the following paragraph buried in a post about the flaky IPSec dashboard widget, where it doesn't really belong, so to separate the issues, here it goes again:

I don't seem to be able to get any connection up and going if I FORCE any of the following:

Phase 1:

IKEv2 (only Auto or IKEv1 seem to work)

AES-XCBC hash (only SHA hashes seem to work, didn't test MD5)

HD key group above 18 (only 18 and below seem to work)

Also: is there no way to force NAT-T to be off? I have it on Auto now, and it enables NAT-T even though I shouldn't need it, because the connection is between two public IP addresses.

Phase 2:

any AES-GCM version (only regular AES works (not testing Blowfish, 3DES, CAST128 or DES))
AES-XCBC hash

Why? Are these bugs, or do these only work with hardware support in the CPU (AES-NI) which I don't have?
Are there any issues with PPTP and IPSec interfering with each other?

cmb

AES-GCM works with or without AES-NI. It's about 15 times faster with AES-NI than without (on the same CPU) but works either way. It definitely works, that's all we're using internally on our production site to site VPNs for employees. The other end must support the options you're using and be configured the same.

There is no way to disable NAT-T in strongswan, it's either auto or forced. It seems well behaved there though, have only seen that kick in where NAT exists. If you're on manual outbound NAT and NATing the host's own traffic, that could cause NAT-T to be enabled between two public IP endpoints. Check Diag>States for the traffic of the VPN.

No issues with PPTP and IPsec interfering.

There is one caveat if you're changing things around like that and the connection has successfully negotiated prior to making the change, you have to go to Status>IPsec and disconnect it before it'll try to use your new settings.

@cmb:

AES-GCM works with or without AES-NI. It's about 15 times faster with AES-NI than without (on the same CPU) but works either way. It definitely works, that's all we're using internally on our production site to site VPNs for employees.

Technically, one of them runs site-to-site OpenVPN, and a couple more haven't moved off AES CBC + HMAC (which AES-NI won't accelerate very well).

But yes, most employees are on site-to-site IPsec via AES-GCM.

rcfa

Well, but there is a problem here…
This works:

![Screen Shot 2014-12-31 at 15.41.39.png](/public/imported_attachments/1/Screen Shot 2014-12-31 at 15.41.39.png)
![Screen Shot 2014-12-31 at 15.41.39.png_thumb](/public/imported_attachments/1/Screen Shot 2014-12-31 at 15.41.39.png_thumb)

rcfa

…and this does not. Even 25 minutes after phase one is up, there's no established phase 2:
(if I make an equivalent change in the Phase 1 setup, the Phase 1 won't be completed, either):

NOTE: both sides are running pfSense, same build, same settings, same single-checkmark change, same hardware

![Screen Shot 2014-12-31 at 15.42.34.png](/public/imported_attachments/1/Screen Shot 2014-12-31 at 15.42.34.png)
![Screen Shot 2014-12-31 at 15.42.34.png_thumb](/public/imported_attachments/1/Screen Shot 2014-12-31 at 15.42.34.png_thumb)

rcfa

So, now, more than 3h later I come back and the link is up ?!?!?!?
Note: I did not only x-out phase 2 and phase 1 entries on the IPSecStatus page, I also stopped and restarted the IPSec service, to make sure after the config change, things start from scratch.
Why would it take that long to establish a connection? I would expect such a link to be up within a minute or two at the very most. Certainly within 15 minutes, but it wasn't up after 25m, and after that, I left, just to see the link up 3h later. I'll continue to play with this, provided I get phase 2 stable with the parameters I want, and then will play with the phase 1 aspect of the link…

Happy new year, to everyone!

rcfa

So, I think there are some negotiation problems.

I got now in phase 2 AES256-GCM/128, no hash and PFS group 18 working.
However, there seem to be issues negotiating terms, because if there are multiple options available, it can seemingly take forever until that comes up. So now, I don't give any wiggling room, and it's faster.

Phase 1 still has issues:
a) when I change Key Exchange version from Auto to V2 => no go
b) when I change DH Key group above 18 => no go

So I got it to work with Key Exchange auto, AES-256, AES-XCBC, DH-8192, NAT-T-Auto, Main-mode, PSK.

Changing things to V2 => no phase 1 completed
Changing things to DH Key group 24 => no phase 1 completed