Often times people would shy away from simulating a S2S VPN. The real-time setup has configurations of the physical VPN device using the Azure provided settings. An easy option is the use of an Windows Server feature called RRAS (Routing & Remote Access) for a simulation. This feature can help simulate a VPN device and help create an IPSEC VPN tunnel over IKE. If you are interested in trying this setup, use the following video series
The actual process where in a couple of edge routers negotiate and establish IKE phase 1 and 2 tunnels is super interesting. If you are an enthusiast like myself please watch this video. After watching this video you would be intrigued by the details that go into establishing this in the real time. I don’t intend to explain VPN tunnels and the IPSEC and IKE protocols. The picture below should be able to help you visualize stuff that we are going to talk about in the rest of this post.
The following diagram shows a simple setup that I used to test S2S VPN and check the packet encryption portion of the exchange between networks. As seen in the picture I have a couple of VMs created in my local box. One of those if a test server/client machine that is used to perform an ICMP test and the other is the Windows Server 2016 running RRAS. The test machine can be configured to use the RRAS server to route the packets to a specific address space in azure using a couple of methods
- Configure the internal network address of the RRAS server as the default gateway in the NIC’s config that is supposed to exchange data with Azure
- Create a static route in the client machines that will use a secondary NIC for all the traffic to the Azure address space and the RRAS as the Gateway (next hop)
The setup of the route based VPN gateway and the configuration of a S2S VPN connection to a Local Gateway (the public IP that my router provides in my setup) can be performed using the steps illustrated in the aforementioned video series. After the setup is done, before actually testing the VPN tunnel, I installed Microsoft Network Monitoring Tool on the RRAS Server. You can use Wireshark if you prefer that. I started a packet capture after I initiated an infinite loop ICMP from the client machine to the Azure workload VM. ICMP from 192.168.29.55 to 10.0.10.4.
The main part of the capture was where the RRAS server performs the packet encapsulation using the ESP (Encapsulating Security Payload) before letting the ISP’s router NAT and send the packets over the tunnel. You can read more about all the capabilities of ESP but here a few that are quite important in this context.
The following picture shows a filtered capture from the RRAS server at the time that the ICMP test was performed. When the client machine initiates a ping, the RRAS server would try to establish a VPN connection with the target network through a demand-dial interface. During the process after the IKE phase 1 and 2 tunnels are established, the RRAS server encapsulates the packet according to the ESP protocol. One other important detail is that since the RRAS server has to route the packets through my ISP’s router and the packets’ confidentiality is an important aspect of any IPSEC VPN session, a UDP encapsulation using NAT-Traversal is performed. You can read more about NAT-T and UDP encapsulation from this page.
After the packet reaches the target network, Azure VPN gateway is supposed to extract the actual ping packet from the encapsulated packet in the IP layer and pass it on to the target VM. When the target VM responds back to the initiated ping command, a similar cycle is followed except that this time the VPN gateway does ESP of the response and sends it through the VPN tunnel.
In the packet capture picture,
- 192.168.29.55 is the test server’s IP
- 192.168.29.52 is the RRAS server’s IP
- 220.127.116.11 is Azure VPN Gateway’s public IP
- 10.0.10.4 is Azure VM’s private IP
An illustration of how an ESP encapsulated packet would look like on Layer-3 is shown in this picture.
That is all in this story. Happy Learning!