IKEv2 Site-to-Site and MultiWAN on one side
-
When the tier 1 gateway comes back up the VPN tunnel will not automatically switch back to it as doing so would be needlessly disruptive to traffic when the tier 2 gateway is still passing it.
What I expect to happen in that situation is the tunnel remains on the tier 2 WAN until it is re-established. It will then be re-established on the tier 1 WAN. Is that not what you're seeing?It seems from your description as though the dual WAN end is trying to establish the tunnel again but the other end has not updated the DynDNS entry so it refuses? Have you shown it's still resolving to the tier 2 WAN at that end?
Steve
-
@stephenw10 point in that DDNS record actually updated. But not "reloaded". If I run on pfSense nslookup myddns.com 127.0.0.1 it return correct IP, but IPsec service still try connect to incorrect IP. And this will be going even a full day. No way that 5mins (lowest dns.he.net cache avaible) will cache on pfSense for a day. Problem that IPsec service "remember" IP and not try to re-resolve DNS at all even with N100 failing times.
-
@stephenw10 stop-start of Phase1/2 not help too, only full restart of IPsec service (including another tunnels as well T__T) will resolve issue with DDNS. Now to have working solution I ignore that I have MultiWAN and listen only 1 WAN which not give 100% uptime unfortunately :(
BTW: Thank you for join the topic -
Does it try to connect out to the wrong IP or just disallow incoming connections from the WAN it's not expecting? Or both I guess?
One thing you can do here it to set the remote gateway to 0.0.0.0/0 and use an identifier type other than IP address. That will allow connections from both WANs but the tunnel can then only ever be established from the multi-wan side.
If you do try that you should check 'Disable Auto-added VPN rules' in Sys > Adv > Firewall and add your own rules to allow the IPSec traffic in from only the two remote WAN IPs. Otherwise the auto rule will allow IPSec connections from any IP. Connections will fail as they won't have the right credentials but the logs will be filled with drive-by connection attempts, potentially.Steve
-
@stephenw10 I'm not sure, but I think both: it try connecting to tier2 and at same time it rejecting connection from tier1. Your solution maybe working (looking), but no auto rules will give troubles in future in system with 2+ tunnels and possibility to establish connection in ony one way is not good to. Specialy when I now know that failing of IPsec not trigger smtp notications (which is another issue too). Can this be done by pfSense in more "graceful" way with reload configs at least in future? As guy who closed ticket on redmine says that pfSense work fine with ddns and IPsec and this not issue in pfSense. As far I see it not fine as it must be :(
Could you please describe how this rule looks like? If it simple UDP port 500 then it not so hard.
And big question what if there would be 2 systems with IPsec and multiWAN:(. If reloading of DDNS will work as expected then all be fine, but in your workaround it will not work. Maybe there must not DDNS and must be simple A(AAAA) 2 records for both IPs and it must try communicate to both of them until connection will succeed? -
I believe that I have a similar issue with the IPsec tunnel. My setup is as follow:
main office
Pfsense with Dual WAN. They are configured in a Failover group (Tier1 and 2 ). I have static public IP addresses for both of the WANs.Branch office:
Pfsense with one WAN. It has a static public IP address.I configured one tunnel in the main office that points towards the branch office from the WAN failover group. On the branch office, I set up 2 tunnels one point towards the main WAN in the main office and the other points towards the secondary WAN.
When the main WAN in the main office goes offline, The tunnel will be recreated with the secondary WAN. But when The main WAN comes back online there will be 2 active tunnels from the main and secondary WAN to the branch office. I don't know if this is an issue with my configuration since there is one tunnel in the main firewall and 2 tunnels in the other firewall, or it is only a limited configuration.
-
Is there a solution for this in 2024?
-
Specifically for the VPN remaining on the failover WAN?
There are options to kill states on recovery in 24.03 that weren't there 5 years ago:
https://docs.netgate.com/pfsense/en/latest/config/advanced-misc.html#state-killing-on-gateway-recovery -
@stephenw10 i mean set in ipsec tunnel a backup IP peer for when the remote ip peer is down, that pfsense connect to backup ip (or backup tunnel)
-
You can use an FQDN there and have it be a DynDNS name that fails over. Or setup two tunnels.
If it's inbound you can just allow connections from any remote peer.
-
@stephenw10 said in IKEv2 Site-to-Site and MultiWAN on one side:
Does it try to connect out to the wrong IP or just disallow incoming connections from the WAN it's not expecting? Or both I guess?
One thing you can do here it to set the remote gateway to 0.0.0.0/0 and use an identifier type other than IP address. That will allow connections from both WANs but the tunnel can then only ever be established from the multi-wan side.
If you do try that you should check 'Disable Auto-added VPN rules' in Sys > Adv > Firewall and add your own rules to allow the IPSec traffic in from only the two remote WAN IPs. Otherwise the auto rule will allow IPSec connections from any IP. Connections will fail as they won't have the right credentials but the logs will be filled with drive-by connection attempts, potentially.Steve
Would this configuration help to connect IPsec on the link that is tier2?
I can only connect my tunnels to the link that is tier1.
-
Well if you set one side to allow traffic from any IP address (0.0.0.0/0) then connections can only be established from the other end. That would be the multiwan end. You can set a tunnel to use a backup WAN specifically if you need to.
If you set a tunnel on a failover group it will always try to use the lowest tier WAN. That can be a different group so the VPN uses a different WAN than other traffic.
-
@stephenw10 said in IKEv2 Site-to-Site and MultiWAN on one side:
Well if you set one side to allow traffic from any IP address (0.0.0.0/0) then connections can only be established from the other end. That would be the multiwan end. You can set a tunnel to use a backup WAN specifically if you need to.
If you set a tunnel on a failover group it will always try to use the lowest tier WAN. That can be a different group so the VPN uses a different WAN than other traffic.
Even though I configure the backup WAN in the tunnel, it doesn't connect, I can only connect to the main WAN. I don't know if I'm forgetting some configuration.
I have 3 wans and some ipsec tunnels, I would like to balance these tunnels between the 3 wans, but I get stuck connecting them all to the main one.
-
If you're not using a gateway group on the multiwan end and the other side is connecting to one of the non-default WANs by IP that should connect fine.
How does it fail? What errors are shown?
-
@stephenw10 I use "gateway groups" with these wans, could that be the problem? Can't the wan belong to a gateway group?
-
The existence of a gateway group should not prevent other services being set to use a specific WAN even if it's in a group.
-
-
OK that looks like the other end is not seeing the replies for some reason.
Check the state table at both ends.
Which end are those logs from?
-
@stephenw10 This is the side that has the two wans.
-
Ok so it sees the incoming request on the correct WAN and replies but the other end never sees that reply because it just sends the initial request again.
So either that reply is not actually being sent or it's send incorrectly somehow. Or something in the route is blocking it.
I'd first check the state tables at each end. If that doesn't show something obvious then run a pcap at both ends to confirm replies are being sent and received.
