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.

In this post we’ll setup the Azure configuration in Region 2 (North Europe) and also setup the BGP Region 1 (West Europe) to Region 2 (North Europe) link.

As in part 1 you’ll need to create in advance, two VNets (vnspoke1 and vnhub0).The VNet vnspoke1 uses address space 10.11.1.0/24. Create a subnet within this VNet and place a VM within that we will use for our ping tests. Your setup should resemble to following:

The peering is setup in the same way as in part 1.

Here’s the PowerShell to create the North Europe Gateway and ready it for connection to our Home VyOS router.

$rg=”atnettest2″
$vn=”vnhub0″
$loc=’northeurope’
$vngwname=’gwnebgp’
$gwlocal=’homenet’
$VNet1ASN=65011
# Private ASN for home network
$LNGASN=65168
# these BGP addresses come from part 3
$BGPPeerIP5=’10.168.0.253′
$locprefix=’10.168.0.253/32′

# get the vnet and gateway subnet
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName $rg -Name $vn
$gwpip= New-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName $rg -Location $loc -AllocationMethod Dynamic
$subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name ‘GatewaySubnet’ -VirtualNetwork $vnet

# get a public ip for the gateway
$gwipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name gwipconfig1 -SubnetId $subnet.Id -PublicIpAddressId $gwpip.Id
#
# make the gateway – will take a while – typically about 30 minutes
#
date
#New-AzureRmVirtualNetworkGateway -Name $vngwname -ResourceGroupName $rg -Location $loc -IpConfigurations $gwipconfig -GatewayType Vpn -VpnType RouteBased -GatewaySku Standard -Asn $VNet1ASN -EnableBgp $true
date
# get the public ip for local gw we’ll need to make a note of this for part 3
Get-AzureRmPublicIpAddress -Name gwpip -ResourceGroupName $rg
$gateway1 = Get-AzureRmVirtualNetworkGateway -Name $vngwname -ResourceGroupName $rg

# get the BGP ip for local gw – we’ll need to make a note of this for part 3
$gateway1.BgpSettingsText

# In the following replace a.b.c.d in the following with your home public IP address
New-AzureRmLocalNetworkGateway -Name $gwlocal -ResourceGroupName $rg -Location $loc -GatewayIpAddress ‘81.108.251.116’ -AddressPrefix $locprefix -Asn $LNGASN -BgpPeeringAddress $BGPPeerIP5
## get local gateway and on-prem local info
$local = Get-AzureRmLocalNetworkGateway -Name $gwlocal -ResourceGroupName $rg
## connect the two
New-AzureRmVirtualNetworkGatewayConnection -Name northeurtohome -ResourceGroupName $rg -Location $loc -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local -ConnectionType IPsec -RoutingWeight 10 -SharedKey ‘abc1234’-enablebgp $true

Now setup the gateway to gateway BGP link:

# set some variables

$rg1=”atnettest”
$rg2=”atnettest2″
$loc1=’westeurope’
$loc2=’northeurope’
$vngwname1=’gwwebgp’
$vngwname2=’gwnebgp’
$Connection12  = “wetone”
$Connection21  = “netowe”
#get the West Europe Gateway
$gateway1 = Get-AzureRmVirtualNetworkGateway -Name $vngwname1 -ResourceGroupName $rg1

# check BGP on on
$gateway1.BgpSettingsText

#get the North Europe Gateway
$gateway2 = Get-AzureRmVirtualNetworkGateway -Name $vngwname2 -ResourceGroupName $rg2

# check BGP ip address
$gateway2.BgpSettingsText

# Create the links (two are needed)
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection12 -ResourceGroupName $rg1 -VirtualNetworkGateway1 $gateway1 -VirtualNetworkGateway2 $gateway2 -Location $loc1 -ConnectionType Vnet2Vnet -SharedKey ‘AzureA1b2C3’ -EnableBgp $True -RoutingWeight 10
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection21 -ResourceGroupName $rg2 -VirtualNetworkGateway1 $gateway2 -VirtualNetworkGateway2 $gateway1 -Location $loc2 -ConnectionType Vnet2Vnet -SharedKey ‘AzureA1b2C3’ -EnableBgp $True -RoutingWeight 10

In this part we’ll setup the VyOS VM and configure the required networking options for IPsec and BGP within VyOS.

Home Network:

Like many folks my home network has a private IP address space (192.168.0.0/24) and my broadband provider supplies a single public IP address a.b.c.d. If you’d like to know you public IP address look on your router or go to a browser on your home machine and navigate to http://whatsmyip.org   or http://whatsmyip.net

My home router NAT’s internal private address space onto the public IP.

I have a small server the private network running HyperV within this I create two VM’s

One for VyOs and one for VM2 running a base install of CentOS

Before starting to configure the VyOS VM download the VyOS .iso from the download section of http://vyos.net. At the time of writing I used this 64bit stable release:
http://packages.vyos.net/iso/release/1.1.7/vyos-1.1.7-amd64.iso

The VyOS VM needs:
1GB RAM, 1cpu, 2GB disk drive and 3 Network Adapters: 1 external and 2 internal

The VM should be set to boot off the VyOS iso image loaded to the virtual CD

Boot the VM off the iso, when presented with the login prompt enter “vyos” for the username and password, then:

$ install image
… installation stuff …
$ reboot

After the reboot  we need to configure the VyOS for both IPsec and BGP setup so it will communicate with our two gateways we setup in part 1 and part 2

This first part is standard stuff much of this may already be setup login to the VyOS VM and enter configure mode

and the enter the commands below

set service ssh port ’22’
set system config-management commit-revisions ’20’
set system console device ttyS0 speed ‘9600’
set system host-name ‘vyos’
set system login user vyos level ‘admin’
set system ntp server ‘0.pool.ntp.org’
set system ntp server ‘1.pool.ntp.org’
set system ntp server ‘2.pool.ntp.org’
set system package auto-sync ‘1’
set system package repository community components ‘main’
set system package repository community distribution ‘helium’
set system package repository community password ”
set system package repository community url ‘http://packages.vyos.net/vyos’
set system package repository community username ”
set system syslog global facility all level ‘notice’
set system syslog global facility protocols level ‘debug’
set system time-zone ‘UTC’

Next we define the 3 interfaces we are going to use

eth0 – connected to our external network (the internet), this is given a static IP address by my home router which always maps the MAC address ’00:15:5d:00:2b:06′ to the IP 192.168.0.197. This same IP address is used in the DMZ in the router

eth1 – Our internal network – set to 10.168.0.1

eth1 -address for BGP – set to 10.168.0.253/32   (a single IP net)

set interfaces ethernet eth0 address ‘dhcp’
set interfaces ethernet eth0 description ‘OUTSIDE’
set interfaces ethernet eth0 duplex ‘auto’
set interfaces ethernet eth0 hw-id ’00:15:5d:00:2b:06′
set interfaces ethernet eth0 smp_affinity ‘auto’
set interfaces ethernet eth0 speed ‘auto’
set interfaces ethernet eth1 address ‘10.168.0.1/24’
set interfaces ethernet eth1 description ‘INSIDE’
set interfaces ethernet eth1 duplex ‘auto’
set interfaces ethernet eth1 hw-id ’00:15:5d:00:2b:08′
set interfaces ethernet eth1 smp_affinity ‘auto’
set interfaces ethernet eth1 speed ‘auto’
set interfaces ethernet eth2 address ‘10.168.0.253/32’
set interfaces ethernet eth2 duplex ‘auto’
set interfaces ethernet eth2 hw-id ’00:15:5d:00:2b:0a’
set interfaces ethernet eth2 smp_affinity ‘auto’
set interfaces ethernet eth2 speed ‘auto’
set interfaces loopback ‘lo’

Set up the IPsec preamble for link West Europe’s gateway

set vpn ipsec esp-group atazure compression ‘disable’
set vpn ipsec esp-group atazure lifetime ‘3600’
set vpn ipsec esp-group atazure mode ‘tunnel’
set vpn ipsec esp-group atazure pfs ‘disable’
set vpn ipsec esp-group atazure proposal 1 encryption ‘aes256’
set vpn ipsec esp-group atazure proposal 1 hash ‘sha1’
set vpn ipsec ike-group atazure-ike ikev2-reauth ‘no’
set vpn ipsec ike-group atazure-ike key-exchange ‘ikev2’
set vpn ipsec ike-group atazure-ike lifetime ‘10800’
set vpn ipsec ike-group atazure-ike proposal 1 dh-group ‘2’
set vpn ipsec ike-group atazure-ike proposal 1 encryption ‘aes256’
set vpn ipsec ike-group atazure-ike proposal 1 hash ‘sha1’

Set up the IPsec preamble for link North Europe’s gateway

set vpn ipsec esp-group atazurene compression ‘disable’
set vpn ipsec esp-group atazurene lifetime ‘3600’
set vpn ipsec esp-group atazurene mode ‘tunnel’
set vpn ipsec esp-group atazurene pfs ‘disable’
set vpn ipsec esp-group atazurene proposal 1 encryption ‘aes256’
set vpn ipsec esp-group atazurene proposal 1 hash ‘sha1’
set vpn ipsec ike-group atazurene-ike ikev2-reauth ‘no’
set vpn ipsec ike-group atazurene-ike key-exchange ‘ikev2’
set vpn ipsec ike-group atazurene-ike lifetime ‘10800’
set vpn ipsec ike-group atazurene-ike proposal 1 dh-group ‘2’
set vpn ipsec ike-group atazurene-ike proposal 1 encryption ‘aes256’
set vpn ipsec ike-group atazurene-ike proposal 1 hash ‘sha1’

set vpn ipsec ipsec-interfaces interface ‘eth0’
set vpn ipsec nat-traversal ‘enable’

Initiate tunnel to North Europe:

set vpn ipsec site-to-site peer p.q.r.s  authentication mode ‘pre-shared-secret’
set vpn ipsec site-to-site peer p.q.r.s   authentication pre-shared-secret ‘abc1234’
set vpn ipsec site-to-site peer p.q.r.s   connection-type ‘initiate’
set vpn ipsec site-to-site peer p.q.r.s   default-esp-group ‘atazurene’
set vpn ipsec site-to-site peer p.q.r.s   description ‘VNet GW Az Nrth Eur’
set vpn ipsec site-to-site peer p.q.r.s   ike-group ‘atazurene-ike’
set vpn ipsec site-to-site peer p.q.r.s   ikev2-reauth ‘inherit’
set vpn ipsec site-to-site peer p.q.r.s   local-address ‘192.168.0.197’
set vpn ipsec site-to-site peer p.q.r.s  tunnel 1 allow-nat-networks ‘disable’
set vpn ipsec site-to-site peer p.q.r.s  tunnel 1 allow-public-networks ‘disable’
set vpn ipsec site-to-site peer p.q.r.s tunnel 1 local prefix ‘10.168.0.0/24’
set vpn ipsec site-to-site peer p.q.r.s  tunnel 1 remote prefix ‘10.0.0.0/8’

Initiate tunnel to West Europe:

set vpn ipsec site-to-site peer w.x.y.z authentication mode ‘pre-shared-secret’
set vpn ipsec site-to-site peer w.x.y.z authentication pre-shared-secret ‘abc1234’
set vpn ipsec site-to-site peer w.x.y.z connection-type ‘initiate’
set vpn ipsec site-to-site peer w.x.y.z default-esp-group ‘atazurene’
set vpn ipsec site-to-site peer w.x.y.z description ‘VNet GW Az Nrth Eur’
set vpn ipsec site-to-site peer w.x.y.z ike-group ‘atazurene-ike’
set vpn ipsec site-to-site peer w.x.y.z ikev2-reauth ‘inherit’
set vpn ipsec site-to-site peer w.x.y.z local-address ‘192.168.0.197’
set vpn ipsec site-to-site peer w.x.y.z tunnel 1 allow-nat-networks ‘disable’
set vpn ipsec site-to-site peer w.x.y.z tunnel 1 allow-public-networks ‘disable’
set vpn ipsec site-to-site peer w.x.y.z tunnel 1 local prefix ‘10.168.0.0/24’
set vpn ipsec site-to-site peer w.x.y.z tunnel 1 remote prefix ‘10.0.0.0/8’

Default route – and blackhole route for BGP and set private ASN number

set protocols static route 0.0.0.0/0 next-hop ‘192.168.0.1’
set protocols static route 10.168.0.0/24 ‘blackhole’
set protocols bgp 65168 network ‘10.168.0.0/24’

BGP for West Europe

set protocols bgp 65168 neighbor 10.10.0.14 ebgp-multihop ‘8’
set protocols bgp 65168 neighbor 10.10.0.14 remote-as ‘65010’
set protocols bgp 65168 neighbor 10.10.0.14 soft-reconfiguration ‘inbound’

BGP for North Europe

set protocols bgp 65168 neighbor 10.11.0.14 ebgp-multihop ‘8’
set protocols bgp 65168 neighbor 10.11.0.14 remote-as ‘65011’
set protocols bgp 65168 neighbor 10.11.0.14 soft-reconfiguration ‘inbound’

Having don’t the above you should be set for some testing of the connectivity which is described in part 4

Setting up Azure Active Directory Sync

The first step is to add a “custom domain” to Azure Active Directory in preparation for directory synchronization.

In this sequence we will add our custom domain (in my case “andyt.work”) to our default directory we were assigned when we created a new Azure account.

Login to the “old” portal https://manage.windowsazure.com

Select Active Directory from the left hand icons and then ensure the Default Directory is selected.

Now ensure one of your cloud user has “Global Admin” rights over the directory, here I have a user called “admin” that has that capability:

Now enter the “Domains” section of the Default Directory and Click the Add button at the bottom of the screen.

Enter the domain name you own and click “add”

The next step involves making a TX record entry with domain registrar. The details of the TX record are shown on screen. There is also a link to a web page describing the process of adding the required TX record for various different domain registrars.

Once you have added the TX record and waited a while for it to propagate click “Verify”

Having completed the verify process you should see the domain as verified , you can now switch the assigned primary domain to your custom domain using the “Change Primary” button at the bottom of the screen.

Specify your domain as the new primary and press the tick button to confirm

We now have registered our domain and made it the primary.

The next step is to synchronize our on premise active directory domain with the Azure hosted Active Directory.

Navigate to the Directory Integration section of the Default Directory and enable Directory Sync, and Save

Next download the AD connect tool to one of your domain controllers or a domain connected machine/VM from:

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Run the Wizard

The AD Connect Wizard has an Express set up option which is sufficient for most cases

Enter the credentials of your Azure user that has Global Admin rights that we set up earlier (“admin” in my case).

Enter credentials of the local domain administrator

Finish by clicking Install

Back in the Azure portal you should now see any local users defined in your Active Directory domain also appearing in the users section of the Default Directory:

Your directory is now “synced” with Azure Active Directory, users can sign on to cloud based application using their username (email address) and the same password as they use on premise to sign onto your local domain.

Enabling secure Access via Azure’s Application Proxy

Now we will make our Intranet web  application securely available over the public internet using Azure’s Application Proxy capability.
On the Windows server where the IIS server in running, start an elevated command prompt

Note the hostname of the machine/VM that is running IIS and the domain.

Run the command setspn to set up a service principal nam.

Next login to the “old” Azure portal
https://manage.windowsazure.com

Select the Azure Active Directory icon on the left , select the Default Directory (or your active directory) and click the Add+ icon at the bottom.

In the dialog box that pops up select the “Publish an application that will be accessible from outside your network” option.

Next enter a name for your application , the internal URL and the pre-authentication method you want. In this case we’re using Azure Active Directory as our local Active Directory is already sync’d with AD Connect to Azure Active Directory. (see Part 4).  (The other Pre Authentication option is Pass Through)

Next we need to enable the Application Proxy

Then click the option to download the connector

Once downloaded run the AADApplicationProxyConnectorInstaller

Follow the install process until the option to Run the connector troubleshooter appears, run the troubleshooter

Conform all is ok – if not you may need to open some outbound ports

Check the Application Proxy Connector local services are running

Back in the Azure portal

Next in the portal navigate to your applications, select the Intranet application and use the configure option, make a note of the new external (Intranet) URL for your application.

Scroll down and set the SPN name we defined earlier using the setspn.exe command

If you’d like users to be able to see this application in their myapps.microsoft.com portal select the self-service option

Next – click the Users and Groups option, notice a default group has been created for this application, you can also use any of the other groups if you want to.

Next navigate back to the Default Directory and select Groups and select the group automatically created for the Intranet application.

Add any members you wish to this group

Now try to access your application using the new external URL. Logging in using one of the users you allowed in the group above.

If this doesn’t work it may be because you have already logged in as a user who was not in the list of users your defined in the applications group

If required start a new in-private browser and login as one of the users defined in the group

This should then log you in to your internal application from the external URL.

If you defined the self-service application then the application can also be listed on myapps.microsoft.com  (if it isn’t listed select Get more applications and select it form the list)

And that’s it – we’re accessing an internal Intranet application using a public endpoint provided by Azure Application Proxy, our connection is authenticated using sync’d credentials and communication is securely setup between the on-premise application proxy connector and the Azure Cloud.

Setting up the Application in IIS

Assuming you have just installed IIS. Stop the default web application.

Add a new website for our application.

Specify a web site name – and select the path C:\www\intranet-app1 (the path we shared earlier in part 2).

After clicking “OK” you will get a warning about port 80’s binding. This can be ignored as we have stopped the default web site that was using it.

At this point if you try to access the application it will show an authentication error:

We need to do some further setup to allow our chosen Authentication method. Enable kernel mode authentication on the Intranet-App1:

Enable Windows Authentication

Next Browse to the website – and you should be prompted to perform a domain login: (If you log straight in without being prompted, it may be because you are already logged into the domain, in that case start a private browsing session and retry.)

You should now see the website page you created in Visual Studio

Up to this point you have an application running on your Intranet, authenticating using your own Active Directory credentials.

In Part 4 we’ll enable Azure Application Proxy  to make this application securely available to external (Internet) users.

To perform these steps, you’re going to need a domain joined Windows Server with IIS installed.

There are a few different ways to deploy a web application, perhaps the simplest is to deploy it using a file share.

Create a root folder for your IIS web site (C:\www) and within this root folder create and share a sub-folder for the intranet-app1 application we have just built:

Map the share to ta network drive on the machine you’ve used for Visual Studio

In the main Visual Studio window – select the Intranet-app1, right click and select Publish …

In the Publish dialog box select the Custom option, enter a new custom profile name, click OK and then click Next

Now select File System as the publish method and set the target location to the file share network drive location we set up previously. Click Publish

If you now resize the Output window in Visual Studio you should see the web application deploying successfully.

In Part 3 we’ll configure the IIS server to support our authentication choice.

Part 1. Creating a simple application in Visual Studio

If you don’t already have Visual Studio you can download and install the community edition for free from here.

Start Visual Studio and create a simple web application:

When Visual Studio has started select  File -> New -> Project 

Then select a ASP.NET Web Application, ensure Application Insights is not selected, enter a name for your project (“intranet-app1” in my case) and click OK.

On the next screen select Web Forms unselect the Host in the Cloud button if it is selected and then click the Change Authentication button.

In the Change Authentication dialog – select the Windows Authentication option and click OK

Back on the select a template box click OK

Next on the main Visual Studio workspace select Default.aspx from the Solution Explorer window on the right hand side. Right click and select View Designer

In the main window for Default.aspx – click around ASP.NET and change the default text to something you will recognize.

Finally Build (or Rebuild) the solution

Now we’re ready to Publish this application which is covered in Part 2