Hybrid Cloud Connectivity: Azure P2S VPN, S2S from Azure to AWS
1. Summary: Hybrid Cloud Connectivity – Azure P2S VPN
This is the fifth blog in the Azure Networking Blog series, and focuses on Azure P2S VPN functionality. Check out other blogs in this series:
- Azure Traffic Manager and Load Balancer Design
- Third Party Network Devices (Part-1) – Citrix VPX in Azure
- Third Party Network Devices (Part-2) – Cisco ASAv in Azure
- BGP Express Route and BGP over IPSec Tunnel
In this blog post we will review various Hybrid Cloud Connectivity Options. The VPN Client allows the remote users to connect to Cloud private network through Internet from anywhere in the world. In Azure, this can be accomplished with a Point-to-Site VPN Gateway (Route-Based) with RADIUS Authentication. Azure P2S is a useful solution instead of a site-to-site when you have a few remote users that need connectivity into Azure. In the first part of this blog post, I will walk you through a use case with Azure P2S VPN using Active Directory Server configured with Radius Server role.
One of our clients recently migrated from AWS to Azure. One way to connect the two clouds together is via an IPSec VPN tunnel. We ran into compatibility issues between Azure and AWS while setting up the VPN tunnel, due the fact that AWS currently only supports ikev1, and Azure’s Route-Based VPN gateway only supports ikev2.
To address overcoming this limitation, in the second half of the blog post we’ll take a look at a use case to connect AWS Cloud to Azure Cloud using StrongSwan (which serves as a Virtual Appliance on the AWS die) with ikev2 support, and using custom routing. This can also be accomplished with Windows Server (RRAS on the AWS side)
Note: This blog post assumes general familiarity with Azure cloud constructs (Resource Groups, VNets and Subnets), AWS networking constructs (VPC, Subnet, Instances and Route tables) and common networking concepts. Microsoft has some great documentation to assist with further understanding this process.
This blog post is focused on end-to-end configuration blueprint, reference architecture and in-depth troubleshooting for the above two use cases. We will use this diagram as a reference architecture.
2. Point-to-Site VPN Configuration
Summary:
The VPN Client allows the remote users to connect to a private network through Internet from anywhere in the world. In Azure, this can be accomplished with a Point-to-Site VPN Gateway (Route-Based) with RADIUS Authentication. Azure P2S VPN is a useful solution instead of a site-to-site when you have a few remote users that need connectivity into Azure.
In the first part of this blog post, I will walk you through a use case with Azure P2S VPN using Active Directory Server configured with Radius Server role.
Microsoft Documentation:
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-vpn-client-configuration-radius
Azure P2S VPN is supported from Windows, MAC OS X and Linux Client devices. This blog post covers Windows Client.
Prerequisites: Azure Resource Group (nn-rg-2), Vnet (nn-vnet) and Subnets Exist in Azure. Active Directory Domain Controller created in Azure Subnet (Windows 2012 R2)
Steps:
- Create Route based Virtual Network Gateway
- Configure Point-to-Site VPN on Azure VNG
- Create VPN Users Group in Active Directory
- Setup RADIUS Server and Network Policy Server Security
- Download VPN Client
- Connect to Azure
- Troubleshooting and Verifications
- Create Route-Based Virtual Network Gateway
- Configure Point-to-Site VPN on Azure Virtual Network Gateway. The address pool should be something unique on your network.
- Create VPN Users Group in Active Directory. Add VPN users to this group.
- Install and Setup RADIUS Server and Network Policy Server (Step by Step)
Register Network Policy Server Security
Configure Radius Client on Network Policy Server. Allow traffic from the Azure Gateway subnet(10.6.0.0/24)
Configure security policy to allow conditional Requests
6. Download and Install VPN Client
Extract the zip file into a folder and install the client6.
Connect to Azure. The above step will install a new connection “nn-vnet-2”
Launch the client and login with your AD domain credentials. Make sure the user is in the VPN Users group.7.
7. Troubleshooting and Verifications
On the Azure side, for the VM in question, check the effective Route in the Azure Portal.
On the client side, veriy the IP and routes.
3. Azure to AWS Connectivity
Summary:
As noted above, while assisting a client in their migration from AWS to Azure, we ran into compatibility challenges between the two platform, when connecting the two clouds together via an IPSec VPN tunnel.
AWS currently only supports ikev1, while the Route-Based VPN gateway in Azure only supports ikev2 – this necessitated connect AWS Cloud to Azure Cloud using StrongSwan (which serves as a Virtual Appliance on the AWS side) with ikev2 support and using custom routing. StrongSWan is an open source tool that requires minimal configuration to get it up and running. This connection can also be accomplished with Windows Server (RRAS on the AWS side)
Prerequisites:
AWS: VPC: nn-VPC, Subnets: nn-subnet-1, nn-subnet-2, instances: vm1 in subnet1 and vm2 in subnet2 exits
Azure: Resource Group: nn-rg-2, vNET: nn-vnet-2, subnet: nn-subnet1, Route-based Virtual Network Gateway: nn-route-based-vng
Documentation Links:
https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/ExerciseOverview.html
https://wiki.strongswan.org/projects/strongswan/wiki/AwsVpc
Steps:
- AWS: Install a Ubuntu instance and configure StrongSWAN.
- AWS: Configure Custom Routes
- Azure: Create new Local Network Gateway
- Azure: Create a new connection
- Verification and troubleshooting
1: AWS: Install a Ubuntu instance and Configure StrongSWAN.
Install StrongSwan: apt-get install strongswan Enable echo 1 > /proc/sys/net/ipv4/ip_forward Verify IP Configuration ubuntu@ip-10-82-1-214:~$ ifconfig eth0 Link encap:Ethernet HWaddr 0a:c2:0d:ce:44:a8 inet addr:10.82.1.214 Bcast:10.82.1.255 Mask:255.255.255.0 inet6 addr: fe80::8c2:dff:fece:44a8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1 RX packets:318569 errors:0 dropped:0 overruns:0 frame:0 TX packets:212384 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:182188399 (182.1 MB) TX bytes:27196737 (27.1 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:192 errors:0 dropped:0 overruns:0 frame:0 TX packets:192 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:14456 (14.4 KB) TX bytes:14456 (14.4 KB) Configure StrongSWAN: root@ip-10-82-1-214:~# more /etc/ipsec.secrets 10.82.1.214 13.77.XX.XX : PSK "AzureXXXX" root@ip-10-82-1-214:~# more /etc/ipsec.conf # ipsec.conf - strongSwan IPsec configuration file conn azure authby=secret type=tunnel leftsendcert=never left=10.82.1.214 leftsubnet=10.82.1.0/24,10.82.2.0/24 right=13.77.XX.XX rightsubnet=10.6.1.0/24 keyexchange=ikev2 ikelifetime=10800s keylife=57m keyingtries=1 rekeymargin=3m compress=no compress=no
root@ip-10-82-1-214:/etc# ipsec status Security Associations (1 up, 0 connecting): azure[1]: ESTABLISHED 4 seconds ago, 10.82.1.214[10.82.1.214]...13.77.XX.XX[13.77.XX.XX] azure{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: caee2e84_i e517cc8e_o azure{1}: 10.82.1.0/24 10.82.2.0/24 === 10.6.1.0/24 root@ip-10-82-1-214:/etc# ipsec restart Stopping strongSwan IPsec... Starting strongSwan 5.3.5 IPsec [starter]... root@ip-10-82-1-214:/etc# ipsec statusall Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-1057-aws, x86_64): uptime: 6 seconds, since May 14 03:39:39 2018 malloc: sbrk 1486848, mmap 0, used 346512, free 1140336 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3 loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pub key pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netl ink resolve socket-default connmark stroke updown Listening IP addresses: 10.82.1.214 Connections: azure: 10.82.1.214...13.77.88.243 IKEv2 azure: local: [10.82.1.214] uses pre-shared key authentication azure: remote: [13.77.88.243] uses pre-shared key authentication azure: child: 10.82.1.0/24 10.82.2.0/24 === 10.6.1.0/24 TUNNEL Security Associations (1 up, 0 connecting): azure[1]: ESTABLISHED 6 seconds ago, 10.82.1.214[10.82.1.214]...13.77.88.243[13.77.88.243] azure[1]: IKEv2 SPIs: 370014ff2c35787c_i* d34deb87dbd7433d_r, pre-shared key reauthentication in 2 ho urs azure[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 azure{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: caee2e84_i e517cc8e_o azure{1}: AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 50 minutes azure{1}: 10.82.1.0/24 10.82.2.0/24 === 10.6.1.0/24 <br>
2: AWS: Configure VPC,Subnets and Custom Routes
AWS: VPC
AWS: Subnet1
AWS: Subnet2
AWS: Intenet Gateway
AWS : NAT Gateway
3. Azure Create Virtual Network Gateway
4. Azure: Create Local Network Gateway and a new connection
5. Verifications and troubleshooting
VM in Subnet2
VM In Subnet1
4. Conclusion
This blog came from a real day-in-the-life experience of Navisite’s Solution Engineering team, an element of Navisite’s Elite 5-Star Managed Services team. At Navisite, we partner with our current and prospective clients to bring creative, business-enabling technology solutions to life.
In conclusion, we reviewed Hybrid Cloud Connectivity options. For remote users, we looked at Azure Native P2S solution with Radius Authentication. Other options for Remote user connectivity are using third-party appliances like Cisco ASAv with AnyConnect VPN. For ASAv in Azure check out my earlier blog post.
We also looked at connecting Azure and AWS Cloud using IPSec VPN. For a short-term migration strategy, we used StrongSWan as an open-source tool, which requires minimal configuration to get it up and running. This can also be accomplished with Windows Server (RRAS on the AWS side), a topic which I will cover in future blog posts.