IPSec dashboard status widget busted in 2.2-RC?

rcfa

My IPSec tunnel is obviously up, otherwise I wouldn't be able to reach my LAN from the outside world, but the web GUI shows me things as shown on the attached screen grab. Is this a known bug? Doing anything wrong?

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

cmb

It works in general if you're on the 26th or newer, but there is some edge case where it doesn't work that I'm trying to track down. What does your Status>IPsec page look like?

rcfa

Like so: (if you need it without the blacked out parts being blacked out, I can send it directly…)

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

cmb

Thanks, that's enough to answer what I was curious about. I saw some things there I hadn't specifically tried in combination which I thought could be responsible. But, I setup a connection matching what you're using (as far as I can tell) and it works fine too.

That a system you could get me access to? If so, PM me and we can work out details.

rcfa

Theoretically I could give you access, however, in the mean time there were some other issues:
I had a rather large number of ciphers and hashes allowed, IKE version to auto, etc. before.

I wanted to nail that down to IKEv2, AES-GCM, no phase 2 DH group, etc.
I did everything the same on both peers, web interfaces side by side. But despite applying changes, the old SA remained active. So I killed the connection and restarted IPsec. Then nothing wanted to connect, even after going back to the old settings. After a reboot and some more fuzzing around, suddenly the link was up again; and low and behold, now the dashboard widget is showing the link as up, too.

So we have two mysteries: why the widget decide to work or not work, and why changing settings and applying them doesn't result in the link being renegotiated and why what should be sound settings sometimes work, and sometimes not.

Now, the connection looks like below. Note that for whatever reason NAT-T is active (set to auto, even though it shouldn't be required), also the entire box for the phase 2 stuff is missing in this status display :o

(And of course, no data flows, that goes without saying, but just before someone thinks this is a UI glitch…)

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

cmb

There is a general oddity in how strongswan works there. If you successfully negotiate, then change the config, it doesn't want to actually apply that config change until the already-established SA has expired. It's something we're going to look at post-2.2, in the mean time just hitting the X in that (rare) circumstance will make it immediately reconnect with the new settings. Where you have 2.2 on both sides, you'll have to disconnect that on both sides on Status>IPsec. Sounds like that was the cause of what you describe after making changes.

Still not sure how that didn't work previously, I spent a significant chunk of my day checking all our IPsec setups, trying other types of configs that weren't already covered, mix of up and down connections, everything I could think of. I can't find any circumstance that's wrong.

rcfa

Beats me, too, also why the phase two doesn't come up…
...I'll try to kill the whole thing once more, and see if it comes up right this time.

rcfa

Now, I have the widget again, and a working connection.

However, 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? I set up the PPTP server after the initial tunnel was up, and I in the mean time turned off the PPTP server so I'm just trying to see if there's potentially some issue there…

rcfa

One of the two peers just gave me this little present:

Crash report begins.  Anonymous machine information:

amd64
10.1-RELEASE-p3
FreeBSD 10.1-RELEASE-p3 #0 8bdb2f8(releng/10.1)-dirty: Mon Dec 29 08:29:40 CST 2014     root@pfsense-22-amd64-builder:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10

Crash report details:

PHP Errors:
[30-Dec-2014 09:02:24 Etc/UTC] PHP Fatal error:  Maximum execution time of 900 seconds exceeded in /etc/inc/ipsec.inc on line 383

Filename: /var/crash/minfree
2048

phil.davis

I expect something has gone wrong reading the status response from the socket there - that code is a tight loop reading the response text and keeps going until it gets "" indicating end.
If something has gone wrong with the socket then it will go into a spin and eventually chew up 900 seconds and PHP will kill itself.
Some code like this should handle a socket read error there:
https://github.com/pfsense/pfsense/pull/1411

I can run with that change and nothing is broken, but I do not know how to create the socket read error to check that the error handling code really does do a reasonable thing.