VPN issue during WAN failover on Quantum Spark (R81.10.17)

[jennyado]

Hi community,

I’d like to ask if anyone has experienced this behavior or if there’s any documentation or workaround available for this scenario.

We currently have a Quantum Spark appliance (R81.10.17) with two Internet links configured in redundant mode. The issue occurs when a failover happens:

• When one of the links is disconnected, the other correctly takes over general traffic, but the site-to-site VPN tunnel drops and does not automatically reconnect.

• We confirmed this using the vpn tu command, where the tunnel goes down exactly when the link switches, and it won’t reconnect unless we manually reboot the appliance.

• Additionally, even when restoring the second link, the VPN tunnel does not come back up automatically — it remains down until a manual reboot is performed.

Actions we’ve tried so far:

• Updated the appliance to R81.10.17.

• Adjusted Load Balancing percentages (tested with 50/50 and 60/40) — same behavior.

• Renewed the VPN certificate (valid for 1 year) — no improvement.

• Verified both public IP addresses for the Internet links, since the gateway object was created with Dynamic IP (DAIP) in SmartConsole.

Questions:

• Is there any additional configuration required to force the VPN to automatically reconnect after a WAN failover or when both links are restored?

• Is there a script, workaround, or recommended procedure to restart the VPN tunnels (or VPN services) automatically upon detecting the link change, avoiding a full appliance reboot?

Any experience, advice, or documentation you could share would be greatly appreciated.

Thanks in advance!

[TJ_Aus]

Do you have monitoring setup on the interface? We had a similar issue and setup monitoring (ping the upstream DNS servers) and that sorted our issue

[jennyado]

Yes, we do have monitoring configured on both WAN interfaces.  The issue is that when one link goes down, although general traffic switches correctly to the remaining link, the VPN tunnel drops and doesn't re-establish automatically on the surviving link — unless we  reboot the appliance.

Same when both links are back — the tunnel won’t restore on its own.

[the_rock]

Make sure these are ebanled.

VPN community has "Keep VPN tunnel open" enabled

DPD is enabled under Advanced Settings > Tunnel Management.

Andy

[jennyado]

I guess you mean that enabling "Keep VPN tunnel open" is the same as setting Set Permanent Tunnels?

I looked for the DPD setting under Advanced Settings > Tunnel Management in SmartConsole R81.20, but it’s not there.

 

[the_rock]

If its set to permanent tunnel option, which it is, thats fine then.

Andy

[the_rock]

Question...so when this happens, are there any logs/indication as to why tunnel is down? Does it even show phase 1 or even that does not come up?

Andy

[jennyado]

I looked for logs during the test schedule, but only VPN Routing logs appeared.
It was noticed that sometimes the tunnel would appear like this:

 

[the_rock]

What about any of below commands? Just replace ip-addr with the right IP address.

Andy

vpn tu list
Usage:
vpn tu list ike
vpn tu list ipsec
vpn tu list peer_ike ip-addr
vpn tu list peer_ipsec ip-addr
vpn tu list tunnels
vpn tu tlist
vpn tu mstats
vpn tu del ipsec all
vpn tu del ipsec ip-addr
vpn tu del ipsec ip-addr username
vpn tu del ipsec ip-addr from ip-addr to ip-addr
vpn tu del all
vpn tu del ip-addr
vpn tu del ip-addr username
vpn tu del ip-addr from ip-addr to ip-addr
vpn tu conn

[jennyado]

Currently, the VPN tunnel is up and working fine. When I run the commands you shared, everything looks normal.

The issue happens when there’s a failure on one of the WAN links. Specifically, when the primary link —which has the active VPN tunnel— goes down and all traffic switches to the secondary link. At that point, the VPN tunnel does not reconnect automatically.

As far as I understand, with our current configuration, it should automatically re-establish the tunnel, right? At the moment, we’re not experiencing the issue because the primary link is stable, but I’m checking to see if there’s any missing configuration or if it’s something we should escalate to TAC.

[the_rock]

Thats very logical approach to me. Hey, if you are allowed to do remote, I would be happy to check as well.

Let me know.

Best,

Andy