Your Network Address Translation (NAT) takes your public IP address, which is assigned to you by your ISP, and tells your router how to point those connections to your private IP addresses internally. We have a few NAT best practices that can make your life easier.
Typically people employ a one-to-one NAT method, which isn’t the ideal configuration. By doing a one-to-one NAT, no matter what connection you try to make from the public IP — whether it be SSH, HTTP or even DNS — it all gets sent to that one private IP address, making it insecure. Say you have an ecommerce web server with a one-to-one NAT with no port restrictions. I could just RDP into your box and get myself admin access, exploit a vulnerability, and steal data or encrypt all your data and ransom it.
You can partially mitigate this with good firewall rules, but it’s still not the optimal way to configure your NAT. By including both your public IP and port number in assigning to a private IP, you employ some restrictions to prevent unexpected access like the scenario above. This is called PNAT or port NAT-ting.
NAT Naming Conventions
You also have to name your NAT, and we usually see logical names like what application is being accessed. This isn’t a bad practice necessarily, except if that application you named your NAT for becomes unfamiliar (out of service or renamed or a newbie joins your networking team). In light of that, we usually write it out as the “public IP-private IP-TCP/UDP-port number”. You don’t get the name to the application, but the networking team will know everything they need to know at a glance. It also makes it easier for you to sort through your rule sets to see what’s in use in terms of IP addresses and ports.
Which brings me to my next PNAT strategy: if you are adding port numbers to your public IP addresses, that allows you to reuse your public IPs. This is a huge benefit if you have something that needs to access multiple, private servers, like a cloud spam filtering service such as Proofpoint. We have the public IP for Proofpoint going to both port 25, which is our Exchange server, and port 386, which is our LDAP. (Note, some spam filters don’t need LDAP access but Proofpoint does.)
What I Call “Port Magic”
You can also address the need for multiple internal boxes requiring access to the same port. This occurs frequently in Cisco WebEx, Skype for Business, or VDI deployments. These types of programs roll in a variety of different services like video conferencing or phone calls. However, you can’t duplicate the same public IP to the same port and send it different places. That’s like having the same address in two different locations and expecting all the mail to go to the right one.
You can actually assign two different port numbers to the public IP, but they will essentially serve the same function except for sending the traffic to a different destination. Before we get into this, it’s important to understand that in NAT-ting, the first 1024 ports have universally defined uses. It’s best practice to stick to those to prevent confusion. For example, port 80 is usually HTTP. As a funny side note, the video game Doom is assigned to port 666. Learn more about what the well-known ports are (these well-known ports are defined by the Internet Assigned Numbers Authority).
In this case, what you may want to do is assign port 80 to go to one box, and port 10080 to go to the other. I usually use a similar number added onto 10,000 or higher so that I can keep track of what goes with what.
From there, you configure your DNS! It’s a simple step, but important.
First off, add ports into your NAT strategy. This makes it more secure and helps you make your public IPs go farther. Secondly, stick to the IANA-defined port conventions for the ports up to 1024 to keep it universally understood. Thirdly, when naming your NATs, define the IP addresses and ports for ease of identification and rule tracking. Fourthly, when engaging in “port magic” employ some kind of practice to tie your similar port behaviors together, like 80 and 10080.