Azure Virtual WAN VPN site struggling with making it work with both IPSec instances active

Didier Van Hoye 6 Reputation points MVP
2020-05-18T18:57:49.38+00:00

Hi there,

I am struggling to get the active-active tunnel functional in the lab with a WatchGuard FireBox. I use the downloaded VPN site config from Azure for the parameters. When both instances are up only one seems to receive the correct routing (BGP), the other one has none. The net result of this that while on-prem connectivity to Azure works, Azure to on-prem fails. When I disable one of the virtual VPN interfaces it does work in both directions. But then I use only instance 0 or instance 1, not both. I looked at an example of the manual configuration with a different vendor (which is a Azure Virtual WAN partner) but they use only one instance it seems (Baracuda).

Is WatchGuard supported? What is the normal behavior, what can I expect? I can find very little real-life or end to end lab information/demos on this subject. Any help or pointers you can provide is much appreciated.

Much obliged,
Didier

Azure Virtual WAN
Azure Virtual WAN
An Azure virtual networking service that provides optimized and automated branch-to-branch connectivity.
187 questions
0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. TravisCragg-MSFT 5,676 Reputation points Microsoft Employee
    2020-05-21T00:30:30.5+00:00

    I would look for guidance from WatchGuard to see if they have any listed best practices within Azure. Watchguard Firebox Cloud does have a marketplace offering in Azure.

    If you want to troubleshoot using 2 instances further, your best bet will be to speak with Azure Support. If you do not have a support plan, please let me know.

    0 comments
  2. JoseMoreno-MSFT 16 Reputation points Microsoft Employee
    2020-05-25T07:29:41.387+00:00

    To your last question, whether WatchGuard is supported or not, looking at the standalone VPN docs (https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpn-devices) it looks like WatchGuard is supported for RouteBased configurations starting at OS version 11.12x.

    I am not sure I understand the problem you are having though: if you have two instances on Azure (instance0 and instance1) and one WatchGuard on-prem (let's call it watchguard0), you should have 2 IPsec tunnels up and running: instance0<->watchguard0 and instance1<->watchguard0. I am assuming that both IPsec tunnels are up.

    If the IPsec tunnels are up, the next configuration is about routing: you should have 2 BGP adjacencies up: instance0<->watchguard0, and instance1<->watchguard0. You say that only one instance (instance0? instance1?) receives BGP routes, but not the other. How do you see this? Are both BGP adjacencies up, as seen from the WatchGuard appliance? I would guess from your problem description that you only see one BGP adjacency up.

    The fact that when you shutdown one tunnel, then everything works on the other one is interesting: could it be that the WatchGuard sends a different BGP router ID depending on the tunnel? From a Virtual WAN perspective, we expect the remote device (the WatchGuard in your case) to show the same public IP address and the same BGP IP address on both tunnels. Interestingly enough in the WatchGuard config example (https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/bovpn_vif_dynamic_routing_azure.html) they do not have a line in their config to have a fixed BGP router ID, with other vendors you would have that (you can see an example for the Cisco CSR here (note line #62): https://github.com/erjosito/azure-wan-lab/blob/master/csr_config_2tunnels_tokenized.txt).

    0 comments
  3. Didier Van Hoye 6 Reputation points MVP
    2020-05-25T10:31:45.237+00:00

    Hi there, thanks for your insights.

    Yes on the Azure side all routes (both instances) seem to be there (checking on NIC of the VM used for ping test). On the WatchGuard0 side we have indeed to active tunnels but if we enable both virtual interfaces only one gets the routes and one remains empty. That's when a ping from Azure fails to on-premises.
    I added two images to show you this condition on the WatchGuard side fo things:

    8606-instance0onwatchguard.jpg
    8692-instance1onwatchguard.jpg

    The BGP on WathGuard0 looks like below but indeed without a BGP router ID (interface) like the CISCO example has. WatchGuard mentions this for clustered setups but we have a single box in the lab. https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/dynamicrouting/bgp_configure_c.html I did try below with a router ID - Public IP address of the WatchGuard (PPOE). bgp router-id PUBLIC IP WatchGuard0 but no joy. 

    !  
! The local BGP ASN is 10001  
!  
router bgp 10001  
!  
! to Azure VPC  
!  
! The Azure (remote) BGP ASN is 65515 and the VIF IPs (bgpPeeringAddresses) are !10.250.250.12 and 10.250.250.13  
! These are the two parameters you must get from the Azure side.   
!  
neighbor 10.250.250.12 remote-as 65515  
neighbor 10.250.250.12 ebgp-multihop  
neighbor 10.250.250.12 activate  
!  
neighbor 10.250.250.13 remote-as 65515  
neighbor 10.250.250.13 ebgp-multihop  
neighbor 10.250.250.13 activate  
!  
! To advertise the local networks  
!  
network 192.168.2.0/24  
network 172.16.100.0/24