Most average network users will need to know either little or nothing about NAT (Network Address Translation). The fact is that it’s already being handled for you when your ISP installs your router. It seems that many consumer brand routers make this process seemingly invisible or non-existent as well, but make no mistake: some form of NATing occurs on all internet connected networks with internal private addressing. The old adage says ‘knowledge is power’; well it’s no different for networks. The more you understand about your network communications, the better chance you have to remain safe out in the public eye. Since you’re probably reading this article right now thanks to NATing, let’s first discuss what it is and how it works; then we can look it how it relates to your security.
Any serious Gen X era online gamers will remember that the good old days of ad-hoc online gaming with friends required a sort of invitation into their home network. The words ‘Port Forwarding’ will ring a bell and I’m willing to bet that most will remember their first time setting this up and feeling like a regular network pro. Well, port forwarding is a simple type of NAT that translates an inbound session (form your friend) to your PC based on port designation. Games would sometimes have pre-defined ports to allow, or may provide the freedom to specify your own custom ports. Basically you had to know each other’s public IP address and the required port to remotely play PC games together. In a nutshell Port Forwarding would tell your router “if I receive a session to/from IP address X.X.X.X on port xxx, then allow it and forward traffic to IP Y.Y.Y.Y. One PC would act as a server and the other as a client.
So what if you were never really into online gaming; what does NAT have to do with you? Well, if you use the internet then you’re using NAT. Every connection to the internet requires at least one public IP address. In the old days of internet, a single ‘static’ (never changing) public IP would often be assigned directly to one computer in the home, since it was rare for homes to contain more than one computer. Although this type of setup might still exist for specific reasons, it’s pretty uncommon. These days internal computer networks use an internal LAN with private addressing something like 192.168.0.0/24, 192.168.1.0/24 or 192.168.2.0/24. With a /24 subnet or 255.255.255.0 you could potentially have 253 different devices on this one network. When you want to talk to the internet, whatever address you have in that range, let’s say 192.168.1.100 for example, it still needs to be translated to an address that the internet understands; also known as a public IP. The way this occurs in most networks is called Source NAT.
There are 3 commonly used NAT types: Source, Static and Destination. As mentioned above Source is used to translate all of your internet session requests to an understandable IP address. It’s called source NAT because it’s translating your source address to something different in order to reach your destination (See Figure A).
The great thing about NATing is that it doesn’t always have to be a 1-to-1 translation. You can often translate many to one. Home internet source NAT is a perfect example: You can have 20 active network devices talking to the internet all using the same public IP. You would tell your router: “any traffic from 192.168.1.0/24 destined to any address not in that network, NAT to 220.127.116.11”. It’s the same thing as saying: translate 192.168.1.0/24 destined to internet addresses to my internet/WAN interface. This is referred to as ‘Interface NAT’. This type of source NAT to the internet is not only used in homes or small offices, but also in large corporate networks. Chances are you won’t have to worry about this, unless you venture into using enterprise grade routers or firewalls. I see folks taking the leap and setting up an expensive $1000 router or firewall, but can’t seem to get internet access. When this happens I usually check their NAT rules for this critical source NAT and 9 times out of 10 they had no idea it was required.
Source NAT is fine and dandy but what if you want something that supports bi-directional communication to work? Static NAT can provide you with this one-to-one translation, but instead of just NATing the source address, it NATs both ways. Let’s say I have two servers on two different internal networks. One is a server for files that I only need access to at home and I have assigned it to my main LAN using IP address 192.168.1.250. With the help of my router I have also created a DMZ (demilitarized zone) where I house a server which is reachable via the internet. Using a DMZ for this means that I can keep my main internal network fairly secured from the outside world. Make note that I would not accomplish this safety simply by using NAT (which we will discuss in more detail further down). My DMZ server is using IP address 172.16.1.250. Although they are segregated from one another I have some limited communications that I need to happen between the two. Maybe my DMZ box is a web server, but it needs access to a SQL database on the secure internal LAN server. I may not have the ability (or may not want to) route these two networks to each other. When I say they can’t ‘route’ to each other it means they don’t have the understanding of how to talk to one another. What I can do is set up static NAT to allow this limited communication between the two. The idea is that I need the traffic to the destination subnet so that it knows how to talk to the other server. This may sound confusing for some, so please see Figures B, C & D for clarity. Figure B demonstrates failed communication where there’s no routing or NATing. To use an analogy, it would be like someone asking me to read a Latin transcription of “Plato’s Republic” when I only understand English. For me to understand the text, it must first be translated into English. Figure C demonstrates a solution to this problem without the need of a newer more expensive router or firewall. The internal server sends its request to the DMZ and the router translates this. Figure D accomplishes the same goal, but in the opposite direction to demonstrate the usefulness of Static NAT.
You will notice between Figures C & D that static NATing does not only translate a source or a destination, but will translate either or both when necessary. If you have been following closely and understanding then you can probably guess how Destination NAT will work, but let’s review quickly anyway.
Destination NAT (like source NAT) does exactly as it says: it’s NATs the destination. This one can be more closely compared to common Port Forwarding but can have nothing to do with ports at all. Destination NAT is commonly used for people or companies hosting websites on internal servers using public IPs. Let’s saying you host your company or personal website on your internal LAN with one NIC, which is assigned the IP 10.10.10.20. There’s no way I can put http://10.10.10.20 into my web browser and reach your server, because this private IP is meaningless to anyone not on your internal network. There are potentially millions of servers in the world using that same private IP. What I need to do is connect to your public IP and have your router forward my request to your server. This is where we divide Port Forwarding and Destination NAT. The reason people need to use Port Forwarding is that you don’t want to tell your router to forward ALL incoming sessions to your web server; you only want certain sessions allowed. If it’s your only web server then you might tell your router “hey, if you receive anything on my public IP 18.104.22.168 on destination port 80 or 443, forward this traffic to my web server at 10.10.10.20. Big companies often own large public IP spaces and their public IPs are not dynamic (periodically changing). This means that they can afford to designate one IP to an internal web server and they don’t need to necessarily specify only certain ports (although they may still do this). Figure E demonstrates a home server which is Destination NATing only certain ports, where Figure F will represent a corporate public IP designated to just one web server.
You will notice two session attempts in Figure E. Attempt number 1 is successful because its coming in on port 80, which is the default HTTP port. This is traffic we want and we have the correct procedures in place to accept HTTP traffic safely, so we accept. Session attempt number 2 comes on port 22, which is the default SSH (Secure Shell) port. If you’re not familiar with it, SSH is the most commonly used protocol to manage network device command lines. We absolutely do not want to accept any SSH traffic from the internet on the standard port. I can tell you from personal experience: within minutes of standing up a network device or serve with inbound SSH sessions allowed; you will have a hacker attempting to brute force your password within minutes (probably less than 10). Figure F handles things a bit differently because it’s not making decisions based on port and only NATing based on IPs. This is common in an enterprise environment because the internet router and core firewall are quite often two different devices. Plus in a corporate environment, you want to let many ports through but filter based on trusted source IP addresses. You might also be wondering what the hell the ‘bit bucket’ is. It’s a term used to indicate that packets will be dropped and virtually thrown in to the garbage/bin (or perhaps the toilet). This brings us to the most relevant part of the article: NAT and your security.
Don’t think for a moment that NAT provides any level of security, because that’s not its function and it really doesn’t provide any level of security, despite some suggestions to the contrary. First, allowing inbound Port Forwarding and Destination NAT is always going to be a risk; but this is sometimes necessary and the risk needs to be taken. Don’t provide hackers with an ‘in’ to your network just for fun. If you have a legitimate need to let traffic in filter it on port because your router may not give the freedom to filter by source addresses. If you have a professional firewall, then by all means block out any malicious IPs or IP ranges – I’m sure Security sites have some kind of published hacker blacklists you could use (you can start by blocking any addresses in China).
Next, do not think that your basic internet source NATing provides any kind of privacy or security. If you’re up to no good using your own public IP it doesn’t matter if you’re sharing it with other household members on a so-called ‘private’ LAN – this will still be traced back to your home by your ISP. If you do decide to venture out and buy a professional firewall and router remember that you will most likely have to set up your own source NAT to make your internet work. It’s really quite simple; take your private LAN subnet (192.168.1.0/24) and then find out whatever your public IP is. If you’re lucky you will have bought a device where you don’t configure it based on the specific public IP, but instead you tell it to source NAT 192.168.1.0/24 to WAN interface. If you’re like most people you will have a dynamic (periodically changing) public IP and your WAN interface will be set up to pick up an address via DHCP. This is pretty well universal no matter what professional brand you’re using: Sonicwall, Cisco, Juniper, Checkpoint, etc.
NAT is invisible to most of us, but can be a very useful tool when expanding your ability to send and receive traffic in and out of your private LAN. I will heed a word of warning though: it’s probably best not to use NAT if you don’t have to. NATing actually interrupts the network session and although this is not usually a problem for common internet traffic, I can tell you from experience it can be a headache when dealing with bandwidth and latency sensitive applications like voice and video. More importantly, please remember than Network Address Translation is not a security protocol or feature. It doesn’t actually provide any real security functions, but when invented to solve problems around routing and dwindling IPv4 addresses, among others. As I have mentioned many times, they best way to stay safe on networks is to understand them as much as possible.