IPsec VPN failover between two PPPoE WANs takes too long

itr

Hello,

we are using a Netgate 6100 with pfSense Plus and two PPPoE Internet connections:

Fiber = Tier 1
DSL = Tier 2
Gateway Group configured for failover
IKEv2 site-to-site VPN to an external provider

The Internet failover itself works correctly.

The problem is the IPsec VPN. When the Fiber connection fails, the tunnel does not immediately reconnect over DSL. It seems that pfSense/strongSwan continues trying to use the old public IP for some time.

During our tests, the tunnel sometimes takes around 30 minutes before it successfully establishes over the DSL connection.

We already tested different Gateway Monitor IPs and confirmed that the Fiber gateway changes to Offline. The VPN also works over DSL in general, but the automatic switchover is much too slow.

Is there any additional configuration required for IPsec Multi-WAN failover, especially regarding:

list itemexisting IKE/IPsec states
gateway state killing
strongSwan retry timers
Phase 1 interface/local address configuration

Has anyone seen similar behavior?

Thanks!

luckman212

Have you read https://docs.netgate.com/pfsense/en/latest/multiwan/ipsec.html ? Did you enable DPD (dead peer detection) and configure the needed DynDNS entries for your WANs? In general, IPSEC failover is slower to respond than other VPN types, but it should be 30s-3 minutes, definitely not 30 minutes. That sounds more like failover never happened at all and you just hit the rekey interval.

I would look into VTI mode + FRR to get the failover time down to a few seconds. For that to work, the far end of the tunnel also needs 2 WANs, or at least 1 WANs with >1 static IP.

itr

@luckman212

Thanks for your reply.

Some more details about our setup:

Netgate 6100 with pfSense Plus
WAN1: Fiber via PPPoE
WAN2: DSL via PPPoE
Both WANs have their own public IP
IKEv2 site-to-site tunnel to an external hosting provider

Failover itself works and WAN1 is detected as offline, but the IPsec tunnel still seems to use the old WAN1 address. It only comes up on WAN2 after about 30 minutes.

Current IPsec settings:

P1 DPD: 30 seconds
Max DPD failures: 5
P1 lifetime: 28,800 seconds
P2 lifetime: 3,600 seconds

So the ~30 minute delay does not really match the configured lifetimes.

VTI + FRR sounds interesting, but at the moment this is not really an option for us. The remote side is managed by an external hosting provider, so we would first have to clarify whether they support such a setup and whether the required configuration is possible on their side.

Any other ideas or suggestions?

luckman212

@itr well if you don't manage the far end it's going to be a lot tougher... have you tried playing around with the keepalive settings? also, what are your gateway state killing settings set to? talking about System > Advanced > Misc

itr

@luckman212

I know. Unfortunately, though, we’ve only been given guidelines here that we’re supposed to follow. Do you think it’s on the other end?

No, I haven’t tested Keepalive yet. That was going to be my next step. We’ll run another test on Wednesday.

We’ve already tried a few things with the settings under Gateway Monitoring (System > Advanced > Misc), but unfortunately without success. Attached is a screenshot of the current settings.

2026-09-28 16_21_16.png

luckman212

Yes It's quite a lot more difficult when you only control 1 side. if you've been given a set of parameters by the provider, I suggest sticking as close to those as possible. They really need to match for things to work correctly. If all else fails, I would probably resort to some manual scripting with a cronjob that runs every 5 minutes, pings the far end of the tunnel and if it's unreachable, kills the SA's and restarts strongSwan...

luckman212

@itr I was curious so I had a little play around and came up with this simple sentry script. "it works for me" if you want to give it a try.

add it to Cron and schedule every 5 min … don't forget to adjust your remote_ip…

#!/bin/sh

# schedule this to run every 5-10 minutes with Cron

# target on far end, if down tunnel will be restarted
remote_ip=192.168.100.3

# name of ipsec connection, leave as-is to auto-select the first connection
con=$(/usr/local/sbin/swanctl --list-conns 2>/dev/null | /usr/bin/awk -F: '/^  con[0-9]+:/{sub(/^ +/, ""); print $1; exit}')

# or specify manually
# con=con2

if [ -z "$con" ]; then
    echo >&2 "con was not set or not detected, aborting"
    exit 1
fi

if ! /sbin/ping -q -c3 -W3 $remote_ip ; then
    echo >&2 "ping to $remote_ip failed, restarting IPsec $con"
    /usr/local/sbin/swanctl --terminate --force --ike "$con"
    /bin/sleep 3
    /usr/local/sbin/swanctl --initiate --timeout 5 --child "$con"
fi

itr

@luckman212

Thanks for suggesting the script. We will not implement it for now, because further testing shows that tunnel initiation itself is not the root cause.

The gateway and routing failover work correctly, but the connection loaded by strongSwan remains bound to the unavailable address of the primary PPPoE interface.

Manually restarting IPsec using: /usr/local/sbin/pfSsh.php playback restartipsec reloads the connection with the address of the secondary WAN, after which the tunnel establishes immediately.

This appears to be a missing strongSwan configuration reload or local-address rebinding when the active gateway-group member changes, rather than an issue that should be handled by a tunnel monitoring script.

I have opened a support ticket with Netgate to investigate this further, especially since similar IPsec failover and configuration reload bugs have occurred in previous pfSense releases. I will update this thread once I receive feedback from Netgate.

luckman212

Fair enough, please do update back here for everyone's benefit after you work that TAC ticket.