Pretty quietly Azure has released the option of using redundant VPN connections. In this case, the gateway in Azure actually gets 2 external IP addresses that our on-premises Firewall can connect to. In this chapter, a small update on the Juniper SRX, BGP to Azure post. So that after following this guide, you can actually use redundant connections.
Not only does Azure now support 1:2 redundant connections as shown above, it is actually possible to also create a multiplex architecture where two on-premises firewalls connect to both Azure GW VM’s
Unfortunately I only have 1 external IP address and thus can only try the first option. Perhaps later I can show you the second architecture too.
Let’s start: First of all we need to initiate the dual gateway setup, you can follow the guide here https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-activeactive-rm-powershell
I just deployed this directly 1:1, but obviously it is also possible to use your existing VNET, although your exiting gateway needs to be deleted. And be aware that the required Gateway SKU needs to be HighPerformance.
Once it has been created, you need to configure your SRX, and for this we do the following:
First, I created the new Interfaces in SRX
#interfaces
st0 {
........
unit 6 {
description to-BGP1;
family inet;
}
unit 7 {
description to-BGP2;
family inet;
}
As you can see, I’m at interface st0.6 and st0.7. Next is the Ike Configuration
#Security IKE
proposal azure-proposal {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 28800;
}
policy azure2-policy {
mode main;
proposals azure-proposal;
pre-shared-key ascii-text "blablablamySecretKey"; ## SECRET-DATA
}
gateway azure2-gateway {
ike-policy azure2-policy;
address 23.99.11.zzz;
external-interface pp0.0;
version v2-only;
}
gateway azure3-gateway {
ike-policy azure2-policy;
address 23.99.11.xxx;
external-interface pp0.0;
version v2-only;
}
As you can see we actually have 2 Gateways configured (azure2-gateway and azure3-gateway) each has its own external address. The Azure-Proposal and azure2-policy determine the encryption parameters and presharedkey.
And the next part is the Security IPSec configuration.
#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 azure2-ipsec-vpn {
bind-interface st0.6;
ike {
gateway azure2-gateway;
ipsec-policy azure-vpn-policy;
}
}
vpn azure3-ipsec-vpn {
bind-interface st0.7;
ike {
gateway azure3-gateway;
ipsec-policy azure-vpn-policy;
}
}
As you can see, we define two different VPN’s but each using the same policy configurations. We bind them to the two created interfaces and use the two created gateways.
The next part is the BGP part. When you created the Azure Gateway you will have received the information you require for this part.
#Protocols BGP
local-address 172.16.5.1;
group azure2 {
type external;
multihop {
ttl 50;
}
peer-as 65010;
local-as 65050;
neighbor 10.12.255.4;
neighbor 10.12.255.5;
}
As you can see, we have defined the local address (the IP address of the firewall itself), and created a single BGP group called azure2. Within this group we set the peer-as to match the ASN number retrieved from the Azure Gateway and add two neighbor addresses in the configuration. These also come from the Azure provided information. The local-as ASN number is the one we set on the “local gateway” object in Azure. The ASN used for the Azure gateway and the ASN number used in the local firewall must be different.
Next is the routing-options. We need to tell the system which interface to use to reach the Azure internal IP addresses for the gateways:
#routing-options
static {
route 0.0.0.0/0 {
qualified-next-hop pp0.0 {
metric 1;
}
}
.....
route 10.12.255.4/32 next-hop st0.6;
route 10.12.255.5/32 next-hop st0.7;
}
As you can see, we added two routes in the static routing options (host only by specifying /32) and set the next-hop to match the two interfaces we created.
To finish it off, we need to specify some policies and set the flow parameters
Security
flow {
ipsec-vpn {
mss 1350;
}
}
policies
from-zone Internal to-zone Azure {
policy Internal-to-Azure {
match {
source-address onprem-networks-1;
destination-address [ AzureSubnet1 AzureSubnet2];
application any;
}
then {
permit;
}
}
}
from-zone Azure to-zone Internal {
policy Azure-to-Internal {
match {
source-address [ AzureSubnet1 AzureSubnet2];
destination-address onprem-networks-1;
application any;
}
then {
permit;
}
}
}
zones
security-zone Azure {
address-book {
address AzureSubnet1 10.11.0.0/16;
address AzureSubnet2 10.12.0.0/16;
}
host-inbound-traffic {
system-services {
ping;
}
}
interfaces {
st0.6;
st0.7;
}
}
In the example above, we create 2 policies, from the security zone Azure to Internal and vice versa. We also have created the Azure zone and set the address to include the two subnets created in Azure.
This all should do the trick.. and to validate this, you can exit the configuration mode and go into the cli mode and run show bgp summary:
As you can see, the BGP summary shows that my two peers use the correct addresses, and that packets are going in and out (these are not the VPN packets, but the BGP protocol exchanging information).
If you want to know more details about the bgp neighbors you can type show bgp neighbor
The image above shows all the information on the first neighbor, and the beginning of the information on the second one (I did not capture all the info). What is important is that there are no errors and that you see that there are 2 Active Prefixes and that 4 prefixes where received (I have 4 subnets behind my FW, and the 2 subnets in Azure).
Show route actually shows you all the information that has been exchanged.
The routes show our Azure networks (10.11.0.0/16 and 10.12.0.0/16) and the path towards these subnets. As you can see there are two paths available, via st0.6 (active marked by an asterisk) and st0.7 (not active as there is no asterisk). Also in the table is the two static entries that we created earlier.
And that is it.. redundant VPN connections to a single Azure Gateway using two public IP addresses.