NAT Mapping IP addresses over a VPN tunnel

Sounds complicated, right? Well, that is probably because it IS complicated!

NAT stands for Network Address Translation. When we NAT map an IP address, we are converting – or translating – it from one address to another address as it leaves an interface such as a router or firewall. For example, an address of a server on one side of a firewall might be 192.168.1.1, which is a widely used private network address that is not publically routable. It must be converted to a public address before it can traverse the internet.

This happens all the time for home and business networks. Most homes and businesses have only a a handful of public addresses assigned to them and all the internal IP traffic on their network is non-routable IP addresses. Why? Because the TCP/IP protocol was invented a LONG time ago in the world of mainframes, long before we had personal computers and a LONG time before smart phones and smart refrigerators and smart cars and smart watches – long before “the internet of things”. Hence, there are not nearly enough IP addresses available in the IP Version 4 nomenclature for every device that needs to connect to the internet.

NOTE: There is a new standard called IP Version 6 that has plenty of addresses available, but it is not widely implemented yet. While IPv6 should help alleviate the problem, it is a long ways from being fully implemented and supported by many internet users.

Since there are not nearly enough private addresses for every IP device, the Internet Registry only doles out a few public IP’s to each user/company/ISP. These public addresses are typically assigned to a firewall. Behind the firewall are private addresses. Before traffic can traverse from the private network to the public Internet, it must be converted to a public address in a process we call Network Address Translation – NAT.

NAT Mapping – Private to Public

In most homes and businesses, we use private address spaces like 192.168.1.1 or 10.0.0.1. Packets with these addresses are not allowed on the public internet since they are reserved for private traffic, so those addresses must be converted – or “NAT’ed” to a public address. This typically happens at the firewall. Traffic is converted to the firewall’s public address on the way out, and return traffic is converted back to the private address of the sending device on the way back inbound.

Routing Private IP addresses over a VPN tunnel without NAT

When we build a VPN – or “tunnel” – between two private networks, the private network traffic is encapsulated inside the VPN tunnel. In other words, if we have a device on Site A that has an IP address of 192.168.1.1 and it needs to communicate to another device at Site B that is 192.168.150.1, then it sends the packet to the firewall. The Site A firewall will encrypt the packet and tunnel it across the public internet – never exposing the private address – to the Site B firewall, which will then decrypt the packet and route it to the destination device. There is no need for Address translation, since both networks are private and the traffic between the two, although it is traversing the public internet, it is not exposed to the public internet because it is incapsulated inside the VPN. Think of a VPN as a special tunnel between two secure buildings. The traffic between the buildings is hidden and protected from public access so there is no need for additional security on this traffic. The only thing the outside world sees is the tunnel, not the traffic inside the tunnel.

NAT Mapping over VPN

As long as the networks at each site do not overlap, this all works fine and dandy. But what happens if we have networks at each site that have overlapping IP addresses? For example, what if the server at Site is has an address of 192.168.1.100 and the server at Site B ALSO has an address of 192.168.1.100? PROBLEM, right?

Yes, normally this would be a problem. But by using NAT mapping over the VPN tunnel, a network administrator can solve the problem.

We do this by translating each IP packet to an agreed-upon non-conflicting address as it traverses the firewall. In our example above, we could translate Site A server from 192.168.1.1 to something like 10.0.25.1 as it crosses into the VPN. At the same time, we would translate Side B server from 192.168.1.1 to something like 10.0.50.1 – a non-conflicting address. So if Server A wanted to talk to Server B, it would send packets to 10.0.50.1. And ont he flip side, Server B would replay to Server A on 10.0.25.1.

Complex? Yes it is. But it works and is a great way to allow networks with overlapping IP addresses to communicate.