pfSense 2.5.0 broke all IPSec VPNs
-
I can confirm the exact same issue, no single IPsec tunnel came up after an upgrade from 2.4.5 to 2.5.0, they go to pfSense (2.4.5) and Cisco. It all works fine on 2.4.5. I also suspected peer IDs, but this is pretty simple, they are all:
My id: my ip address
Peer id: peer ip addressI tried manually setting the values to IPs; no joy. What do you suggest to configure then? Please note that I use DNS resolution for all peers, as in the remote g/w is specified as hostname, because some are on dynamic IPs. The resulting Strongswan config looks pretty much the same at first glance, minus formatting, between 2.4.5 and 2.5.0.
Not that I'm a Cisco fan (not at all), but given the maturity of their implementation, I would say that if it's worked with Cisco for ten plus years the way it was configured, and now it stopped, then is Cisco also misusing key types?
-
The IP address types are fine, mostly Key ID was the problem. If you aren't using that, then it probably isn't identifiers.
We'll need a lot more information than "it didn't work" to diagnose it, though. Starting with logs.
-
@jimp thank you - yes, obviously, logs. Problem is that all I am seeing is:
no IKE config found for Z.Z.Z.Z...A.A.A.A, sending NO_PROPOSAL_CHOSEN
...which IIRC is not the same as prop not chosen due to transforms/algos not being accepted; it doesn't even get to that point.
This is IKEv2 by the way.
-
Compare the contents of
/var/etc/ipsec/swanctl.conf
and the output ofswanctl --list-conns
and see if the contents line up.That log must mean that somehow it's not matching the P1. Without more details from the logs it's impossible to say why.
-
@jimp ah, now we're getting somewhere...
swanctl --list_conns
gives me zero output (empty), as if the config was not loaded properly. On 2.4.5 it does.There is also a long pause when trying to look up SAs/SPDs under status->IPSec.
-
Do you get any output from
swanctl --load-all --debug
? -
@jimp It doesn't like the debug option alone it seems, but otherwise:
swanctl --load-all --debug 5 created thread 01 [80079e500] started worker thread 01 no events, waiting created thread 03 [80079ef00] started worker thread 03 watching 7 for reading watcher going to poll() 2 fds no files found matching '/usr/local/etc/swanctl/conf.d/*.conf' created thread 04 [80079f400] started worker thread 04 created thread 02 [80079ea00] started worker thread 02 watched FD 7 ready to read watcher going to poll() 1 fds watcher got notification, rebuilding watching 7 for reading watcher going to poll() 2 fds watched FD 7 ready to read watcher going to poll() 1 fds watcher got notification, rebuilding watching 7 for reading watcher going to poll() 2 fds watched FD 7 ready to read watcher going to poll() 1 fds watcher got notification, rebuilding watching 7 for reading watcher going to poll() 2 fds no authorities found, 0 unloaded watched FD 7 ready to read watcher going to poll() 1 fds watcher got notification, rebuilding watching 7 for reading watcher going to poll() 2 fds no pools found, 0 unloaded watched FD 7 ready to read watcher going to poll() 1 fds watcher got notification, rebuilding watching 7 for reading no connections found, 0 unloaded watcher going to poll() 2 fds terminated worker thread 01 terminated worker thread 03
However this is pretty much the same as what I get from the working 2.4.5.
-
OK - in 2.4.5, in /usr/local/etc/strongswan.conf I have:
starter { load_warning = no config_file = /var/etc/ipsec/ipsec.conf }
While on 2.5.0 I have:
starter { load_warning = no }
Would this be it? Or have things been moved around?
-
Yeah I think this isn't getting me anywhere.
swanctl --load-conns
shows "no connections found" on both 2.4.5. and 2.5.0, so this is probably not where I should be looking. -
2.5.0 does not use starter, it uses swanctl/VICI. That isn't relevant.
What is in your
/var/etc/ipsec/swanctl.conf
file? You can obscure private info like iP addresses, identifiers, and keys but leave all the structure and names in place. -
@travisn Sorry to hijack your thread here. But - I think I got something that could also be useful for you. There may be some errors in the config that cause strongswan to fail to load it or parts of it.
Try
swanctl --list-conns
and see if you get a list. If not, tryswanctl --load-all --file /var/etc/ipsec/swanctl.conf --debug 1
and see if you get any errors. -
@612brokeaf Hey no worries! I'm just glad I wasn't the only one. I'm going to run through this thread tonight to see if I can get closer. I'm just setting up another 2.4.5-p1 instance in another lab that doesn't have anything else running to try and cut down on the noise.
-
Well this is interesting. After installing 2.4.5-p1 in a quieter environment so I could have cleaner logs, I added a single IPSec VPN the same way I setup my other ones. I upgraded to 2.5.0 and the VPN came back up and I was able to access the remote site just fine. I'm going to try re-upgrading my original site to see if I can reproduce it again or if it was just some strange fluke.
-
Alright, this must have been a strange fluke. I upgraded the original firewall I upgraded this morning and it completed successfully. No idea what happened
-
@jimp said in pfSense 2.5.0 broke all IPSec VPNs:
On 2.4.x there were some problems with identifiers not using the correct types,
Using IPs instead of distinguished name fixed it for me. Not sure what I'll do when IPs change but I'm up for now.
-
Alright, I hit another one. I upgraded 3 successfully, the 4th (the one where I wasn't monitoring the console, of course), decided to have the same problem.
Tried what @612brokeaf suggested by running
swanctl --load-all --file /var/etc/ipsec/swanctl.conf --debug 1
and didn't get any errors, but my tunnels came right up. Of course it did not survive a reboot but again, no errors. I don't have any pools, so I guess that's a good thing?At this point, I'm not sure what I should be looking for. There's no errors, no warnings, no light at the end of the tunnel. I'm not going to wipe this one so if anyone has any further suggestions, I'm open. Otherwise, it seems to be a shot in the dark whether or not IPSec VPNs survive the upgrade.
-
Hi. Just to review. Distinguished names do not work in 2.5 and when changing it to IP address authentication everything works?
-
i also have problems with my ipsec tunnels after upgrading to 2.5.
i have 5 tunnels which all are not working anymore. an output ofswanctl --load-all --file /var/etc/ipsec/swanctl.conf --debug 1
gave me no clue
the only thing which i see in the log is:
which probably means, the key does not match in P1. but they are definitly correct! i also tried to change the keys on both sites with no success.right now, the only workaround for me was, to recreate the tunnels (P1+P2) with the EXACT SAME settings as before. with that, the first tunnel came up right away. i am also using distinquished name for most of the tunnels.
i wait now for maybe some more hints or instructions to test, before i recreate all the other tunnels.
btw: is the "status --> ipsec" page for you all that slow? it takes around 10sec before it shows me the status.
-
Maybe that helps, but my IPsec tunnel broke after upgrading to pfsense 2.5.0 because the "Peer identifier" was set to Any in both sides. By changing it to "IP address" 0.0.0.0, things got working again.
My IPSec uses dynamic ip in both ends, so i cant use real IPs here
-
@m0nji said in [pfSense 2.5.0 broke all IPSec VPNs]
btw: is the "status --> ipsec" page for you all that slow? it takes around 10sec before it shows me the status.
Yes, same here.