Two External interfaces. How to use BOVPN

Hi, I am tyring to link 2 routers (watchguard and Draytek) via IPsec iKEv1.
My watchguard has 2 external interfaces (2 separate internet lines). I would like my BOVPN tunels to work via second interface. I can make it work with first interface but when I am trying to use second connection it always times out. Almost like the second interface was not active. I tried different Multivan modes (Should my interfaces be excluded ? I don't really need any traffic balancing) but no luck. How can I use BOVPN with my second external interface ?


  • There is no restriction on using your 2nd WAN inferface for this.

    What Multi-WAN setting are you using now?
    Exactly what times out? The BOVPN connection attempt? Or the Tunnel?

    A tunnel which has no traffic going over is will end, and come back up again when there is traffic to go over it.

    You can use Ping tools to send a periodic ping down the BOVPN to something at the other end to keep the tunnel up. Usually once per minute is often enough.

    In the past, I have use Servers Alive to keep the tunnel up and to notify me when the tunnel is down.

    If this is not your case, and there is nothing to help understand this in your firewall logs/Traffic Monitor, you can turn on diagnostic logging for IKE which may show something to help:
    In WSM Policy Manager: Setup -> Logging -> Diagnostic Log Level -> VPN -> IKE
    Set the slider to Information or higher

    In the Web UI: System -> Diagnostic Log -> VPN -> SSL.
    Click the down arrow and select Information

    More details of the issue are really needed here.

  • edited November 12
    I have tried all available Multiwan configurations. Then I excluded External interface 2 from multiwan but no avail.
    The BOVPN connection attempt fails. Tunels are fine, it works perfectly fine using external interface 1 (wan port 0). Its the same issue for client ssl connections I can't make it work for my second external interface even if I use correct external IP assigned to External Interface 2 (port 4).

    Second Interface is active on ISP end because I was able to use it in Failover multiwan configuration while I was trying different things. It's only when I have both plugged in at the same time the second Interface is not cooperative.

    Thank you for diagnostics suggestions I will try them Monday as they shut down my remote site for this weekend.
  • Since it works fine for external interface 1, then contact the ISP for interface 2 and see if there is something not configured properly for IPSec.

    Many sites have multiple WANs, and have no issues with a BOVPN on an interface other than the lower numbered WAN connection.

    For the record, what firewall model do you have, and what Fireware version is it running?

    Do you have SD-WAN enabled on any policy which is trying to send packets out the BOVPN? If so, details please.

    Do you have link monitor settings for WAN 2 ? If so, details please.

    If you have a support contract on your firewall, you can open a support case on this to get help from a WG rep. If allowed, they can review your config & look at some of your traffic logs.

  • it's T40, running on 12.7.2. I have tried updating to 12.8.2 but then I couldn't make VPN work at all so I have reversed the firmware.

    not SD-WAN

    no link monitor.

    I don't think so, we are buying from a reseller in UK. Habitech. I will try to get some techsupport from them now.

  • [Related Logs] <158>Nov 14 08:26:40 iked[2914]: (WachguardSecondLineIP<->DraytekIP)Resending phase-1 message to DraytekIP. Gateway-Endpoint:ColeyAvenue p1saId:0x0 <158>Nov 14 08:26:44 iked[2914]: (WachguardSecondLineIP<->DraytekIP)Resending phase-1 message to DraytekIP. Gateway-Endpoint:ColeyAvenue p1saId:0x0 <158>Nov 14 08:26:46 iked[2914]: (WatchguardSecondLineIP<->DraytekIP)alwaysUpTimerCb trigger autoStart for ikePcy(ColeyAvenue) ipsecPcy(ColeyAvenue) <158>Nov 14 08:26:46 iked[2914]: (WachguardSecondLineIP<->DraytekIP)AUTOSTART: RECV ipecPcy(ColeyAvenue), ikePcy(ColeyAvenue), ifIndex(6), tunnel_src=WachguardSecondLineIP, tunnel_dst=DraytekIP <158>Nov 14 08:26:46 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)do the ACQUIRE action for the tunnel route [src: <-> dst:], ike_ver=1, peer_udp_port=0 <158>Nov 14 08:26:46 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)(NATT)IkeFindIsakmpSABySPD: Matched IP and peer_udp_port=0 p1saId=0 : pIsakmpSA p1saID=0 DestPort=0 <158>Nov 14 08:26:46 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)(NATT)IkeFindIsakmpSABySPD: Matched IP and peer_udp_port=0 p1saId=0 : pIsakmpSA p1saID=0 DestPort=0 <158>Nov 14 08:26:46 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)StartNegotiation: P1 negotiation is still going on... Increment Pending P2SA counter 1 (Gateway-Endpoint ColeyAvenue) <158>Nov 14 08:26:46 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)(StartNego) maxPendingP2SARequest 128 current 1 <158>Nov 14 08:26:48 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)Resending phase-1 message to DraytekIP. Gateway-Endpoint:ColeyAvenue p1saId:0x0 <155>Nov 14 08:26:52 iked[2914]: msg_id="0203-0015" (WachguardSecondLineIP8<->DraytekIP)IKE phase-1 negotiation from WachguardSecondLineIP8:500 to DraytekIP failed. Gateway-Endpoint='ColeyAvenue' Reason=Message retry timeout. Check the connection between local and remote gateway endpoints. <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)ike_p1_status_chg: ikePcyName=ColeyAvenue, status=DOWN <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)MWAN-Failover notify ikePcy=0x17dbf68(ColeyAvenue ver#1), mwanFlags:0x00000000 p1said=0x0 DOWN continuous-fails:13 <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)WAN-Failover: start "AlwaysUp" timer(expires in 20s) for ikePcy(ColeyAvenue) <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)IkeDeleteIsakmpSA: try to delete Isakmp SA 0x66c5f8 for Gateway ColeyAvenue. State:3 <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)IkeDeleteIsakmpSA: try to delete QMState SA 0x6985a8 for Gateway ColeyAvenue <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)IkeDeleteQMState: deleting QMState 0x6985a8 (ID 0 state:240) with IsakmpSA(0x66c5f8) Gateway(ColeyAvenue) <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)SA Nego Fail: saHandle 0x0x17ecbf8 InitMode 1, reason 2 <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)SA Nego Fail: free saHandle, ipsecPcy("ColeyAvenue") <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)Totally 1 Pending P2 SA Requests Got Dropped. <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)IkeDeleteIsakmpSA: Stop Phase One Retry and Life Timer <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)IkeDeleteIsakmpSA: Stop Phase One DPD Retry timer <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)ikeSADeleteFromCookieHashTable: IKE SA event: Delete IsakmpSA(0x66c5f8) in IkeIsakmpSATable[21],pPrev((nil)) pNext((nil)) ikePcy(ColeyAvenue) Cookies(i=0c2cbe079457be6e r=0000000000000000) <158>Nov 14 08:26:52 iked[2914]: (WachguardSecondLineIP8<->DraytekIP)IkeDeleteIsakmpSA: reclaim isakmpSA(0x66c5f8)'s memory and mark it as "FREED"

  • I have updated firmware to 12.8.2 just for sanity check. VPN still works via first line but won't work via second line...

  • Anything useful in the Draytek logs ?

    You are changing the Draytek BOVPN setup for the 2nd WAN IP addr when you do this test, correct?

    You have WG support if your Feature Key shows "Support" as not expired.

    Contact the 2nd ISP here to see what they say.

  • _WGSupport_ChrisC_WGSupport_ChrisC WatchGuard Representative
    edited November 18

    It sounds like this could possibly be an ISP issue. Some ISP's, especially mobile carriers, block IPSec and SIP. Packet capture on the secondary WAN using TCPDump would be helpful to see what is happening with the ISAKMP and ESP traffic.

    Arguments, assuming eth3 is your secondary WAN, replace as needed:

    -i eth3 port 500 or port 4500

    This will capture all of the raw IPSec traffic.

    A similar capture from the Draytek would be excellent to have. This would make it possible to prove whether the ISP is interfering with the traffic or not.

  • No it's not ISP. It's the same ISP and we already tried swapping lines. Same result. I am now in contact with Wachguard technical, they think issue is Firewall related and want to check few things via webex. I will update this thread if we manage to fix it.
  • turn out one of our engineers decided to tidy up the cables and.. connected my wan 2 port to one of our switches... I only noticed when we changed from static to dhcp and got internal ip !.... VPN works just fine through secondary connector. Admin can delete this thread.

This discussion has been closed.