WAN failover and IPsec, a never ending story?
-
Hi,
searching the forum I found dozens of posts concerning WAN failover, DynDNS and IPsec, but no current solution.
Since this issue is present for so long time, I can hardly imagine that it is still unsolved.Basic installation which was running several months:
A DrayTek modem (full bridge mode) and an Netgate Appliance running now pfSense 2.4.5-p1.
DynDNS is configured and runs well, IPsec too, access from Windows and Android devices are working without an issue.
In the last weeks I realized very often, sometimes several times a day, in worst-case 2 or 3 times in an hour, an DSL outage.
Hardware was exchanged (a AVM Fritzbox was put in place for some days) but outages still occur. So it seems to be a provider issue. After dozens of phone calls the situation was still the same.
So I decide to add a second DSL line to get a stable connection, which is mandatory at this times during working at home office and having kids with home schooling.
The second line is still not present by now, but I did already prepare the configuration at the pfSense, and now the mistery begins.
I am rather sure, I did all well, but since this point of time I am not able to login via IPsec after an outage of the DSL. DynDNS is well configured, the new IP is sent to DynDNS service, a ping to hostname is answered.What did I do at pfSense?
I created a second WAN interface, created all the firewall rules in the same was as for the existing interface and so on.
Finally I created a gateway group, containing both gateways (WAN#1and WAN#2).
The gateway group was set as interface to DynDNS service and in IPsec general settings as the local endpoint.
But whenever an outage occurs and DynDNS was updated, an access via VPN is not possible any longer.
To resolve this issue, I need to restart the IPsec service. And that is, what seems to be unbelievable to me. Did I still have an misconfiguration?
Remember: currently only one WAN interface is active, the second line is still not present, so it is still the same interface which is affected (by now).
I also noticed, when I change interface in IPsec back to WAN#1 (instead of failover gateway) VPN access is also possible. So I guess there is an issue with the failover gateway setting, but at which point? I do not use load balancing, just failover.
Sorry for the long post. Any ideas how to pinpoint the issue?Regards
-
Hi,
we have been having a similar issue last week. What do you mean with "an access via VPN is not possible any longer?"
We have a firewall with several IPsec tunnels using VTI mode on phase 2.
This firewall has gateway group consisting of one connection for Tier 1, and one for Tier 2.There were some problems with the Tier 1 connection last week - after which the IPSec tunnels just didn't seem to want to connect again, without any message being logged (at least not that I found).
On the weekend, we did a test: after removing the cable for the Tier 1 connection, switch to Tier 2 connection worked perfectly. After plugging Tier 1 back in, the Firewall reported that it had added the first connection to the group again. However, the Ipsec tunnels remained up on the tier 2 connection - but could not be used, I assume because traffic was going out on an interface which was not connected by ipsec. This time, a manual disconnect and reconnect of the ipsec tunnel made them useable again. -
Hi,
it is the same here, after restarting the IPsec service a VPN connection can be established again.
In the meantime I have two WAN links online (no load balancing, only failover). WAN 2 has priority 1, WAN 1 priority 2, so all traffic should use WAN2. This night there was a short outage of WAN 2, I saw this in the syslog messages. Trying to establish a VPN fails! After manual restarting the IPsec service all was fine.
So my workaround is: I created in VPN-IPsec two more phase1 tunnels without a phase 2 entry, one for each WAN interface (in picture one is disabled).
Using this "pseudo" tunnels a VPN was always possible after a WAN link outage because IPsec service was restarted always.
Regards
-
Ah - the idea being that complete IPSec is restarted when something happens to each of the gateways separately, forced by the "pseudo" tunnel?! I would not have come up with that idea, I will try it out!
It's of course still a "hack" - it can't really be the expected behaviour? Any other comments on this from anyone?
-
To be honest: this hack works as long as only one WAN link was online.
When the second WAN link was setup last Friday, I disabled the pseudo tunnels to monitor what happens, if now the favorite WAN link fails, which happened last night.
My expection was that IPsec will be restarted when the WAN link moves, but it seems not working.
So I enabled the tunnels again and will see after next link outage if my workaround ist still working
.
But of course, my expectations are that this should work without such hacks.Regards
-
I tried - but without success. I can't spend a lot of time trying this at the moment, because I am disturbing others who are trying to work :)
One problem is that it is not allowed to have several ipsec tunnels to the same target.
Just a thought, don't know if if actually makes a difference: do you have "Make before Break" on the page VPN -> IPsec -> Advanced settings enabled? (I do) -
Yes, it is enabled.
As far as I remember this is a default setting, cant remember that I did modify here anything...Regards
-
Today I need to bring down the WAN 2 link for an installation of a new wall outlet.
During WAN2 was down I tried the VPN connection - works as expected
, using the WAN1 link.
When WAN2 was up again I checked again the VPN connection, again it worked, now with WAN2.
Without my pseudo tunnels it will not work. I guess, that is a bug in pfSense software.
Looking forward, if 2.5 will fix this issue.
As far as I found this issue is a very old one, people claimed since years about it.Regards