Connect to a Home Network from Anywhere via Azure, Point to Site and Site to Site VPNs

Hi all, this is JJ Streicher-Bremer, Platforms PFE. A long time reader, first time poster.

I was recently onsite with a customer and using their guest wireless network. I wanted to connect into my lab network at home for a demo and like many of you, I have enabled port forwarding on my Internet router for the RDP protocol into my home lab.

Typically, this works great and I have direct connectivity from the Internet at-large into my home lab but on that day, it failed via the guest network. I tried connecting through the Internet-sharing feature of my phone, though, and I was able to connect.

I asked the customer about port restrictions on the guest network and sure enough, their security team was blocking everything except "standard web ports". This explained why I couldn't connect to RDP via their network but my phone tether was fine.

Since I have been digging more and more into Azure IaaS and, in particular, networking in Azure, I thought there might be a way to solve this port blocking issue with "The Cloud."

I had already followed some great blog posts to get my on-premises home lab network connected into a network up in Azure through the use of a Site to Site VPN (S2S).

https://blogs.technet.com/b/askpfeplat/archive/2014/03/03/connect-an-on-premises-network-to-azure-via-site-to-site-vpn-and-extend-your-active-directory-onto-an-iaas-vm-dc-in-azure.aspx

Also, I had a way to connect from my Internet-connected client directly into my Azure network through a Point to Site (P2S) VPN.

https://blogs.msdn.com/b/piyushranjan/archive/2013/06/01/point-to-site-vpn-in-azure-virtual-networks.aspx and https://blogs.technet.com/b/cbernier/archive/2013/08/21/windows-azure-how-to-point-to-site-vpn-walk-through.aspx

With all this hard work done for me by my esteemed colleagues, I had a VPN that could connect my client into Azure and another VPN that could connect from Azure to my lab. It seemed I should take the next logical step. In my mind that step is figuring out how to VPN from my client into Azure and gain access to my "on-premises" home lab network.

Thus, we have the topic of this blog post.

To start with, let's set up prerequisites, define some terms, and document some of the network settings.

The expectation is that you, like me, have already created a S2S (Site to Site) VPN connecting your "Lab Under The Stairs," or LUTS, into Azure and a P2S (Point to Site) VPN connecting a client PC into Azure. If you have not, please follow the above links to complete those steps and then come back here.

The Setup

Here are the networks and addresses I'll be working with in this post - use appropriate network addresses for your specific setup.

I know that the Azure network understands how to send packets to my LUTS network (through the definition of the local networks used in the Azure Gateway configuration) and how to send packets to my P2S VPN clients.

From here, let's start by looking at my P2S client side routing table (below) while I was VPNed into my Azure network (the gray laptop in the above diagram).

I can see from the highlighted routes that my client knows that to send packets to the 172.16.17.0/24 network (in Azure), they need to be sent via the 172.16.18.2 NIC on my client PC.

Indeed, this works because I can ping a server on that Azure network. I also notice that my client knows that to send packets to anything on the entire 172.16.0.0/16 network, the next hop is 172.16.18.0.

So, in theory, my client knows how to send packets all the way to my LUTS network (172.16.16.0/24).

Unfortunately, a ping from my client PC shows that something is amiss here.

The Problem

Based on the above, the client knows how to send packets to a system on the LUTS network but perhaps there isn't a route back from the LUTS network to the client on the P2S VPN.

As you can see in the route print below, from a server in my lab, it does not know of a route to the P2S VPN network.

Interestingly, there is no route to the Azure network either.

Taking a quick step back, I want to note that in Mike Hildebrand's post (referenced above), he took the simple path and used the RRAS server as his default gateway: all network traffic leaving his lab network has to go through the RRAS server.

In my case, I didn't take the simple path, so my default gateway IP (172.16.16.1) does not equal the internal IP address of my RRAS server (172.16.16.164).

The Fix – Part I

I had a couple of options to make this work; edit each host or edit the network.

• Edit the hosts

  • I could add a static route on all my LUTS systems, essentially telling them that traffic bound for my Azure network has to go through my RRAS server.
  • The command would look similar to this: "route add 172.16.17.0 mask 255.255.255.0 172.16.16.164".
  • This does work and if I added the "–p" switch to the command it would even make the route persistent across reboots.

   

• Edit the network

  • The other option is to fix the network, rather than each individual host, so I looked at my network router to see what I could do there.
  • My router allows me to add static routes - your router may/may not have this feature
  • This means that a packet leaving my LUTS server headed for the Azure network would first go to the default gateway (172.16.16.1) where it would be re-directed to my RRAS server (172.16.16.164) for forwarding up to Azure.

Knowing that I can fix my network (rather than configuring each host) I figured I just needed to add another route that points traffic headed for my P2S VPN clients to the RRAS server as well (router UI screenshot below):

I set that up but still no joy, my pings were still timing out…

The next troubleshooting step for me was to get a network trace from my LUTS server to make sure that packets were actually getting to the LUTS server and to see where they headed after they left.

Using one of my favorite commands "netsh trace start capture=yes", I captured some traffic while I was pinging from my P2S VPN client to the LUTS server.

Looking at the ICMP traffic in that trace, it shows that my client does get the "echo request" packet from the P2S VPN client (great news!).

I see that the LUTS server tries to send out a packet back to 172.16.16.8 (P2S VPN client) and is redirected by my default gateway to the RRAS system (172.16.16.164).

WAIT - why is my client being re-directed from my RRAS system back to the default gateway??

Could it be that my RRAS system doesn't know how to route packets back to the Azure P2S VPN network?

The Fix – Part II

A quick check of the routing table on the RRAS server shows that it really has no clue how to route traffic back to the P2S VPN network. It was just handing the traffic back to its default gateway, which redirected it back to the RRAS server.

The good news is that I can rectify that issue with a simple addition to the static routes in the RRAS console:

After that last piece, SUCCESS!!!

With this post, my intent was to discuss connectivity to a home lab through Azure and some of the routing challenges I encountered, as well as some of the troubleshooting and resolution steps.

Thanks for reading and please let me know your thoughts.

JJ "PING -T" Streicher-Bremer