Public IP Over VPN in Azure

The fun part about doing tech are the strange little puzzles you need to work out. Or from another point of view, the worst part about doing tech are the strange little puzzles you need to work out.

One of those puzzles I had to work out is how to use a public IP address as an endpoint behind a VPN, like this:

Let me show you a couple of ways to do this in Azure!

Why Would I Do This?

Yeah, good question. It seems stupid, right? I've only come across this while working in the pharmacy technology space, but there is a good reason for this network design.

First, an extremely short detour into how pharmacies process prescriptions. When you pay for your prescription through your insurance, the pharmacy sends that prescription claim to a middleman (there always a middleman in this industry) known as a clearinghouse. Each insurance company is also connected to that clearinghouse. The whole thing is a hub-and-spoke situation like this:

A common way to connect to the clearinghouse is through a site-to-site IPSec VPN connection. Normally when you make
a site-to-site VPN connection, it's all within the same organization and you have control over how you allocate your private IP addresses. So you say "site A will have 10.0.0./16 and site B will have 10.32.0.0/16."

However, since there are going to be multiple connections from multiple organizations, the clearinghouse can't be sure that the private IP address space will be available on both networks. If the clearinghouse has 10.105.0.0/24 available on their network but the insurance company is already using 10.105.0.0/24, then you have a conflict.

To get around this, the clearinghouses decided that the address spaces used will be public IPs. So in our example the clearinghouse will say, "traffic from our side of the VPN connection will come from 198.51.100.0/25." Their customer (you, in this case) will pick their own public IP address on their side of the VPN that will be used for their application's endpoint. Let's say you pick 203.0.113.83/32.

Now this all seems like it should be easy to do but it is surprisingly annoying to use public IP addresses in your private cloud network. The main issue is NAT. You can't just add a NAT rule willy-nilly like you can with a network appliance.

Solution: Public IP Range in Virtual Network

Holy 💩, there's a super easy way to do this! You can specify a public IP range in your Azure virtual network address space. These public IPs will not be available from the public internet by default and can be used to create a private subnet.

• Create an Azure VPN Gateway connection to your clearinghouse (easier said than done, I know).
• Create your own public IP prefix or bring your own. Either way, the prefix must be a /29 or larger.
• Create an address space on your virtual network using the public IP prefix from above and then create a new subnet using the same prefix.
• Assign the subnet to the NIC for your application's VM or load balancer and optionally assign a static IP to the NIC.
• Create a route table with a route to the clearinghouse public subnet specifying the Virtual network gateway as the next hop and assign it to the subnet.

The route for your route table associated with the application subnet has these properties.

• Destination type: IP Addresses
• Destination IP addresses: clearinghouse network
• Next hop type: Virtual network gateway
• Next hop address: n/a

Thanks to David Frazee for enlightening me about public IPs on a VNet.

Solution: Network Virtual Appliance

If you're a control freak, you can spin up your own network virtual appliance (NVA). This is basically plopping a traditional router/firewall in Azure. You can bring your existing knowledge of your preferred networking vendor and apply it to Azure.

The main difference between this and the previous solution is that you'll create some kind of virtual IP in your NVA for your public IP and NAT it to the private IP of your load balancer, VM, or AKS cluster.

How you do this will depend on your networking device, but in general you'll need to do this.

• Establish a VPN connection between your NVA's and the clearinghouse's IPSec peer IPs. Your NVA's peer IP will probably be the same as the default public IP of your NVA.
• Create a NAT rule to translate the public IP address of your application to its private IP endpoint.
• If necessary, create a NAT rule to translate your application's private IP address to its public address. For some routers, this may have been done as part of the previous step.
• If necessary, create a route to the clearinghouse's public IP over the VPN. For some routers, this route is inferred from the VPN.
• Create a route table with a route to the clearinghouse public subnet specifying your NVA as the next hop and assign it to the application's subnet.

The route for your route table associated with the application subnet has these properties.

• Destination type: IP Addresses
• Destination IP addresses: clearinghouse network
• Next hop type: Virtual appliance
• Next hop address: NVA IP address

Further Details

For more detail and other nuances, check out my post at secondsleep.io.

---

VPN tile letters by Richard Patterson, licensed under CC2

house by barretr (Open Clip Art Library), licensed under CC0

physical router by George Shuklin, licensed under Creative Commons Attribution-Share Alike 3.0 Unported