IPSEC not working after upgrade from 2.1 to 2.2
-
Recreating the tunnels from scratch did not resolve the issue here. It was working for several days, but eventually same issue. I've read that the IPSEC software was changed in pfsense version 2.2. Since that change the VPN tunnels are unstable here.
-
I don't have 100 VPN tunnels. Only 4 here, but mine seemed to work fine on 2.2 and 2.2.1 (Better on 2.2.1 since they fixed the CARP IPs firewall rule for port 500).
My experience has been if the tunnel comes up and doesn't pass traffic either it is firewall rules (You've already covered this) or the Phase 2 is messed up. Hope you figure it out.
-
The 100 tunnels you ref. to are not manually set-up, but the error I get is generating them. So the IPSEC more and more tunnels are added every fews seconds automatically…
-
I didn't follow the link or look at the picture. I am actually seeing some duplicates as well –- It only occurs on the VPN links to our main office to/from the branch offices (They hook to each other as well, but send/receive far less traffic from them).
I only have 3-4 keys per office.
-
Hi,
I have this issue still with 2.2.1. Status of the tunnel is green, but no packets went through. Its seems that this issue occur after reconnection. After disconnect/connect the packets went through.
Has anyone a hint?
-
I have read this topic..
https://forum.pfsense.org/index.php?topic=91627.0I hope this work for me…. ::)
-
It seems that this work around does not fix this issue…
It is senseless to take care to the logs -> https://forum.pfsense.org/index.php?topic=91587.0At this point we discuss to pull the emergency brake and roll back...
What a disaster!! -
Well, the fix did resolve the rekeying issue for me. I have 16 tunnels that would not pass traffic after the re-keying (or other service interruption) Since applying the fix everything has been solid.
-
Have you reboot the machine, or restarted the service?
-
Yes, I restarted the service after I applied the fix. I have 50 or so devices on the other side of the 16 tunnels that I monitor with Zabbix and when the tunnels stop passing traffic I get flooded with email notifications. So, I did not wait to see if the fix would restore the tunnels, I applied it, and then immediately restarted the service. Because of issues with my connection, I was seeing the problem every hour or two. Since applying the fix the tunnels have continued to pass traffic without an issue.
-
For what it is worth, since this thread was at least originally about an upgrade from 2.1 to 2.2, I did have similar problems moving the tunnels from 2.15 to 2.2 originally, (The other end of the tunnels were and still remain 2.1x boxes) Once I changed the negotiation mode from aggressive to Main, at both ends of the tunnel those problems went away. My issue with rekeying only occurred after the upgrade to 2.2.1 and the fix yesterday resolved that issue.
-
Yes, I restarted the service after I applied the fix.
I do not think the restart works or has ever worked with strongswan.. You need to stop and start (no, that sadly is NOT the same thing like restart in this case) or reboot. To clarify, the "restart" actually does some attempt to reload configuration without disrupting the tunnels. Too bad that it only works with some "random" parts of configuration (for the rest, no such thing implemented), so it does more harm than good really. I think users has better things to do than trying to decipher upstream documentation about what changes can be just "reloaded" and which require complete restart (plus add the hassle of translating that to the pfS webGUI options). ::)
-
You are absolutely right - I should have been clearer - When I say restart, I mean that I stopped the service waited a minute (probably unnecessary) and then started the IPSEC service.
-
Ohh…. thanks for your hint....
In this case for troubleshooting remotely (via VPN to a site) , I'm not able any more to "restart" the VPN. Then its only possible to do that with a reboot... Ohhh dear..:-X
-
I set up a OpenVPN connection to each of the remote sites. Then if there issues with the IPSEC tunnel, I still have access to the other end and can start and stop the service there if required.
