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