SSLVPN - Time to fail over to backup IP if primary is unavailable

jmbernejmberne
in Firebox - VPN Mobile User

Hi all
Our M3700 (12.5.12) has two external interfaces with different ISP and IP.
One is primary IP for SSL VPN connections, the other one is backup.
Both are usable but if primary is unavailable, the WG SSL VPN client takes 2 minutes to connect. According to its logs, it tries primary IP for 2 minutes before switching to backup one even if we asked to use the backup IP (or FQDN).
The typed IP seems to be only where the config file will be downloaded from.
As the config file contains both primary and backup IP, the client tries both, in order.
At least, can we reduce the time it tries before fail over ? FW hidden setting ? client registry key ?

Best Answer

  • james.carsonjames.carson Moderator, WatchGuard Representative
    Answer ✓

    Hi @jmberne There isn't a way to change this. Moving to a lower value can cause the connection to flap back and forth.

    If you'd like to have more granular control over the VPN, I'd suggest looking into the IPSec VPN with the IPSec Client provided by NCP. It allows you to set up profiles for the users to use, which can include different endpoints, and allows customization of most settings like retry interval.

    -James Carson
    WatchGuard Customer Support

Answers

  • jmbernejmberne

    Sorry, We have a M370 with 12.10.1. Don't know why I mistyped.
    I should quit drinking alcohol (but I don't want to start in order to be able to quit)

  • james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @jmberne
    The backup IP setting only works for data transport, if the client doesn't already have a copy of the SSLVPN profile, it won't be able to connect at all if the primary is down.

    If you'd like to be able to control what IP the SSLVPN connects to, use a FQDN instead of your IP in your SSLVPN settings under primary address, and change which IP it points to.

    -James Carson
    WatchGuard Customer Support

  • jmbernejmberne

    Thank you @james.carson
    You confirmed what I suspected on the connection's behaviour.
    The users were told to use two FQDN: vpn.domain.tld if it works, vpn2.domain.tld if not.
    It's doing the job, with a 2 minutes delay I wish I could reduce.

  • jmbernejmberne

    Thank you again.
    I'm a service provider. The customer will have to choose if a VPN protocol/client change is worthy (deployment, maintenance, compatibility, user experience).
    I'll forward him your advices.

Sign In to comment.