Ever since playing with BGP I was looking for a way to make redundant tunnels. As the local internet provider here would only allow me a single IP address, I looked at the other side. What if we have two Azure regions that have a VPN tunnel to my SRX and between each other. Routing would be dealt with by BGP and thus, I should be able to connect to both VNET’s through each of the VPN tunnels.

In order to make it a bit more challenging, I threw in the new VNET Peering option too.

So our new architecture looks like this:

While the technical details are below in this post, lets discuss the architecture in general.

The advantage of this solution is that the VPN reliance is less now, while I only have a single SRX on-premises, enterprise customers will have multiple devices connected to different ISP lines which can then VPN into the Azure VNET’s. The second advantage is that we can now create a highly-available architecture which runs cross region. When another network is added on (or behind) the yellow box on the right, it can be filled with other services/VM’s.

So how to set it up?

We will use the parts we learned in this blogpost.

As you can see, on the top we have our Juniper SRX with ASN65050 and then on the left we have the westUS gateway (GW-201) and the VNET201. With peering in the westUS region I also made a new VNET VNET200.

In order to build this, follow the following setup:

–          Create VNET’s

–          Build Gateways

–          Resize Gateways to standard (or premium)

–          Create Peering connection

–          Create IPSEC tunnels

–          Create VNET2VNET connection

I’m not going to go through the setup of the VNET’s but I have the following configurations:

The gateways can be created from the portal, or directly from PowerShell. If you make the gateways directly from PowerShell, they need to be resized and then the BGP information needs to be updated:

Get-AzureRMVirtualNetworkGateway -Name ‘GW-201’ -ResourceGroup ‘RoutingGroup’ | resize-AzureRmVirtualNetworkGateway -GatewaySKU Standard
Get-AzureRMVirtualNetworkGateway -Name ‘GW-201’ -ResourceGroup ‘RoutingGroup’ | Set-AzureRMVirtualNetworkGateway -asn 65514

I used the ASN number 65514 and 65515 for the Azure gateways and 65050 for my SRX.

Next is the VNET2VNET connection that connects the two gateways together and enable the BGP protocol over this connection. During the command of the actual connection you need to add the gateway objects, so there are 3 commands to be executed:

$gw1=Get-AzureRMVirtualNetworkGateway -Name GW-201 -ResourceGroup ‘RoutingGroup’ $gw2=Get-AzureRMVirtualNetworkGateway -Name GW-224 -ResourceGroup ‘RoutingGroup’ New-AzureRmVirtualNetworkGatewayConnection -Name ‘GW201-to-GW224’ -ResourceGroupName ‘RoutingGroup’ -Location westUS -VirtualNetworkGateway1 $gw1 -VirtualNetworkGateway2 $gw2 -ConnectionType Vnet2Vnet -RoutingWeight20 -EnableBgp $true

This takes care of the Gateway configurations.

Next is the VNET peering. While it is possible to do this via PowerShell, it is a lot easier to do via the portal. Go to the VNET properties of VNET200 and select PEERING. You can add a new peering and select the VNET201 network as the target.

When doing the peering, there are three options that can be selected:

–          Allow forwarded traffic

o   Allows traffic to the VNET outside of the target VNET address space.

In our demo setup, we need to enable this to allow network traffic from on-premises as well as the VNET224 to reach the VNET200

–          Allow gateway transit

o   Only applicable for networks that have a gateway deployed. Allows peered networks to use the local gateway for connections

–          Use remote gateways

o   Tells the VNET to use the remote gateway for connections, effectively extending the network with all the VPN’s configured on that gateway.

Note that the Peering needs to be configured from both VNET’s. In our case, the VNET200 will have Allow Forwarded Traffic and Use Remote Gateways enabled, while VNET201 will have Allow forwarded traffic and Allow gateway transit enabled. The Allow forwarded traffic is not really required on VNET201, but in a later stage I will be using this one.

Note: you must first deploy the gateways completely, then deploy the network peering.

So next is the SRX configuration for the tunnels, in Juniper SRX, I have the following configuration:

Security\ike

policy azure-RoutingGroup {
    mode main;
    proposals azure-proposal;
    pre-shared-key ascii-text "somekeyblabla"; ## SECRET-DATA
}
gateway azure-GW-201 {
    ike-policy azure-RoutingGroup;
    address 40.xxx.226.xxx;
    external-interface pp0.0;
    version v2-only;
}
gateway azure-GW-224 {
    ike-policy azure-RoutingGroup;
    address 13.xx.249.xx;
    external-interface pp0.0;
    version v2-only;
} 

Security\IPsec

 proposal azure-ipsec-proposal {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm aes-256-cbc;
    lifetime-seconds 3600;
}
policy azure-vpn-policy {
    proposals azure-ipsec-proposal;
}
vpn azure-GW-201 {
    bind-interface st0.5;
    ike {
        gateway azure-GW-201;
        ipsec-policy azure-vpn-policy;
    }
}
vpn azure-GW-224 {
    bind-interface st0.4;
    ike {
        gateway azure-GW-224;
        ipsec-policy azure-vpn-policy;
    }
}

Protocols
    group NET201 {
        type external;
        multihop {
            ttl 50;
        }
        peer-as 65514;
        neighbor 172.16.201.134;
    }
    group NET224 {
        type external;
        multihop {
            ttl 50;
        }
        peer-as 65515;
        neighbor 172.16.224.134;
    }
}

If all is well, the BGP information should not be exchange between Azure and the SRX. This means that for the subnets in Azure you should see two entries for the routing table.

On the SRX the active route will be marked with a *. And the other route is the backup route that can be used.

For the tests I actually changed the destination address for a VPN in the configuration. While having a ping open to each of the three subnets shows that after about 30-50 seconds the BGP protocol rediscovers the correct paths and the failed pings (after breaking the VPN) are restored.

So, this tells us, that while it is an active-passive failover configuration with high-availability, it is not reliable enough to be used for hybrid scenario’s where continuous connections are required. For this, perhaps ExpressRoute is a better option.

So in this article we looked at how to build redundant tunnels towards Azure. The templates in this post can also be used to create multiple VPN tunnels to a single gateway or multiple gateways ensuring that BGP will be implemented for a HA architecture.

For your inspiration, the following architecture shows the next level that can be achieved: