Options

Simulate Manual Failover

Is there a way to manually trigger a failover to a secondary ISP / Wan?

M200 with HA and 2 WAN / ISPs

We have had several partial outages on our Primary that do not trigger the failover

This is how things go down for me ... my users start complaining .. i jump into my ping monitoring tool i use to watch a bunch of internal devices and external sites.. it tracks graphically in time-series the latency and packet loss for each site .. it becomes clear there is a problem .. i call my firewall / WG / network expect .. he remotes in .. he looks at things as says we still running on primary ISP because the sites are still below threshold for fail-over .. i say just push all traffic over .. he says only way is if i go into office and pull the plugs ..

So it is just hard for me to believe there is a simple way from the policy UI to manually trigger a fail-over from primary ISP to a secondary.

Any pointers tips or even confirmation that there is no way to do this would be a help.

Answers

  • Options
    james.carsonjames.carson Moderator, WatchGuard Representative

    Hi @lotty

    You can either point the link monitor target for that WAN at something that won't reply, or just simply disconnect the cable for the 1st ISP. Either should cause the firewall to fail over to the other connection provided it's set up properly.

    See here:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/link monitor/link_monitor_configure.html

    -James Carson
    WatchGuard Customer Support

  • Options

    Ok using a non responsive target partly worked. It does trigger a fail-over but does not behave like physically disconnecting the primary wan cable from the FB. To give a specific example, my sip trunk continues to communicate with the primary wan interface after the link monitor induces fail-over to our secondary wan. This causes the SIP trunk to think its still talking to the primary IP when the responses are coming from the secondary wan / IP. Our IP phones do not behave normally with one leg of audio not working. We are confirming with more testing.

  • Options
    edited November 2020

    Sounds like the SIP server is doing its own checking to see if the link is up or not and and is using something other than the check that you set up in XTM - perhaps the external gateway addr.

    I also recall a post on the old boards related to SIP and failover/failback issues.
    Consider opening a support incident to get help from a WG rep with the SIP problem.

  • Options

    Yes we have case opened. A second feature of this has been some sip traffic just does NOT show up in the traffic monitor and logging. Makes it very tough to troubleshoot. But a key point is the link monitor induced failover does not compartmentalize the traffic to the failed link in way that the FB behaves the same as physically unplugging the WAN connection.

  • Options

    On the old boards, someone posted that support said that all packets are not logged.

    You can do TCP Dumps on an interface either though the Web UI or WSM Firebox System Manager.
    You can set advanced options to specify the IP addr to capture, etc.

    FSM:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/fsm/log_message_learn_more_wsm.html
    Web UI:
    https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/system_status/stats_diagnostics_tasks_web.html

Sign In to comment.