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:

1. Azure Traffic Manager and Load Balancer Design
2. Third Party Network Devices (Part-1) – Citrix VPX in Azure
3. Third Party Network Devices (Part-2) – Cisco ASAv in Azure
4.  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:

1. Create Route based Virtual Network Gateway
2. Configure Point-to-Site VPN on Azure VNG
3. Create VPN Users Group in Active Directory
4. Setup RADIUS Server and Network Policy Server Security
5. Download VPN Client
6. Connect to Azure
7. Troubleshooting and Verifications

1. Create Route-Based Virtual Network Gateway
   

   

2. Configure Point-to-Site VPN on Azure Virtual Network Gateway. The address pool should be something unique on your network.
   

   

3. Create VPN Users Group in Active Directory. Add VPN users to this group.
   

   

4. 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:

1. AWS: Install a Ubuntu instance and configure StrongSWAN.
2. AWS: Configure Custom Routes
3. Azure: Create new Local Network Gateway
4. Azure: Create a new connection
5. 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.

Note: I’d like to thank my manager John Rudenauer, Navisite Product Management and Marketing team members William Toll, Chris Pierdominici and Carole Bailey for their support.