Part 4 – Testing the Network Triangulation

Having Completed parts 1,2 and 3 you should now have a functioning pair of links to both your chosen regions (West Europe and North Europe in my case.

In the Azure portal you should see 3 connections active on your VPN gateways – two are for the connections from West Europe to North Europe connectivity and one for the IPsec connection back to your VyOS:

On your VyOS VM there are a few commands we can use to confirm all is as it should be

login to your VyOS VM:

then check the IPsec tunnels are up:

$ show vpn ipsec sa

You should see something like the above with your two public ip’s listed for the AZure VPN gateways in your two regions, both should be state “up” and some traffic flowing in/out

If you don’t see the above then you need yo go back and re-check your configuration so far and be sure the steps followed in parts 1-3 have been done correctly for your environment.

Sometimes it’s handy to reset the VPN on the VyOS , if your convinced that everything else is correct give this a try – edit a file (with vi) called for example cyclevpn.sh that has these commands within:

#/bin/vbash
source /opt/vyatta/etc/functions/script-template
run=/opt/vyatta/bin/vyatta-op-cmd-wrapper
$run restart vpn

then just run the command file you created:

$ ./cyclevpn.sh

Hopefully all else being correct your $ show vpn ipsec sa command will now show two functioning links as above.

If you have gotten this far it’s now time to see if BGP is functioning, run the command:

$ show ip bgp

IN the out put above we are interested in a few things – firstly that we are getting route information from our two Azure BGP enabled gateways via BGP:

In the above we can see our two BGP (Azure) Neighbor’s 10.10.0.14 and 10.11.0.14, these IP’s were output by the PowerShell commands we ran in part 1 & 2  ($gateway1.BgpSettingsText and $gateway2.BgpSettingsText)

Notice how for both gateways we have received route prefix information shown by the “7” – if you don’t see numbers for both BGP neighbour IP’s then something is wrong in the configuration of either BGP or the IPsec tunnels may not be working correctly (see above).

Further down in the output we see the routing information and the chosen routes, looking at on example for subnet 10.10.1.0 – which is in the “spoke1” VNet in West Europe:

The two possible routes via  10.10.0.14 (West Europe) and 10.11.0.14 (North Europe) are shown. The route via 10.10.0.14 (West Europe) is preferred at this time as its ASPath (65010) via West Europe is shorter than the alternative path (65011, 65010) via North Europe then West Europe.

If you have gotten this far you should find your local VM can connect and ping to the VM in West Europe spoke successfully.

As a test you can now take down one of the two IPsec tunnels by deleting it:

$ conf
# del vpn ipsec site-to-site peer 1.2.3.4
# commit

(replace 1.2.3.4 with the public ip of the gateway in the region you want to disconnect from

The ping should continue uninterrupted, The output from the

“$ show ip bgp”  command should now show a routing information with some route using a longer path to maintain the connectivity to your region, when I delete the IPsec tunnel to West Europe I see routing information like the following in the output from the command:

   Network         Next Hop           Metric LocPrf Weight Path
*> 10.10.0.0/24     10.10.0.14                             0 65010 65011 i
*> 10.10.1.0/24     10.10.0.14                             0 65010 65011 i
*> 10.10.2.0/24     10.10.0.14                             0 65010 65011 i
*> 10.11.0.0/24     10.10.0.14                             0 65011 I

This shows that my route to the West Europe is now longer – but connectivity is still maintained from my local CentOS VM to the VM in the spoke1 VNET in West Europe even though it’s IPsec tunnel is down.