Understanding NAT address types
My first networking job was as an airman in the US Air Force. Having been deepy involved with early Internet development, the US military owns significant chunks of the IPv4 address space. As such, network address translation (NAT) is often unnecessary on DoD-owned networks. While this made for convenient design, it prevented me from gaining vital real-world experience with NAT until later on in my career.
When first studying NAT, I remember being most confused by the
addressing terminology. An IP address as related to NAT falls into one
of four categories, as seen in the output of show ip nat translations
on IOS:
- Inside global
- Inside local
- Outside local
- Outside global
None of the explanations I read in books at the time settled well in my mind, until I was able to grasp a key concept: there are two attributes of each address in play here: location and perspective.
Location is described by the first word in the tuple, either inside or outside. It refers to the "side" of the NAT boundary router in which the address logically exists. In a typical NAT deployment, inside addresses will usually (but not necessarily) be private RFC 1918 addresses, and outside addresses will usually be globally routable (registered) IP addresses.
Perspective refers to the side of the NAT boundary from which the address is observed, either local or global. If an address is seen by an inside host, it is being observed locally. If an address is seen by an outside host, it is observed globally.
A practical example should help clarify this distinction. To begin with, consider a simple one-to-one static NAT mapping configured on R2 (no layer four port translation is involved in this example).
interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.252 ip nat outside ! interface FastEthernet0/1 ip address 192.168.0.1 255.255.255.0 ip nat inside ! ip nat inside source static 192.168.0.10 192.0.2.10
This static mapping creates a simple NAT translation rule:
R2# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 192.0.2.10 192.168.0.10 --- ---
Note that only the first two address classes have entries. This is because no stateful session is being tracked, and thus there is only one address, the inside address. The entry describes both the global and local perspectives of a single inside address.
To summarize:
- Inside global: The address of the inside host as seen from the outside
- Inside local: The address of the inside host as seen from the inside
If we initiate a TCP session from R1 to R3, we can see that a second, temporary NAT translation is created, this time with all four classes populated with an address:
R2# show ip nat translations Pro Inside global Inside local Outside local Outside global tcp 192.0.2.10:23 192.168.0.10:23 10.0.0.2:32978 10.0.0.2:32978 --- 192.0.2.10 192.168.0.10 --- ---
The meanings of the first two columns are the same as with our static entry; they describe the globally- and locally-significant addresses of the inside host. The second two columns note the locally- and globally-significant addresses of the outside host. The two addresses of the outside address are identical, as global addresses are not being translated between sides of the NAT boundary.
To review:
- Inside global: The address of the inside host as seen from the outside
- Inside local: The address of the inside host as seen from the inside
- Outside local: The address of the outside host as seen from the inside
- Outside global: The address of the outside host as seen from the outside
Comments
One of the more confusing aspects covered by CCNA. Setting up pools of dynamic mappings is a very good way to conserve the ever-dwindling amount of IPv4 addresses. When I was in college they had an entire B block reserved, and gave out publicly routed IP addresses to every client. Maybe Stretch can give me some insight as to why this was preferred, other than lazy network admins?
Dude, you should really get into training :) I'd pay to join your class!
I was just thinking yesterday about how confusing that terminology was. Now I understand it much better. Thanks Stretch!
Maybe this should be a cheat sheet?
I was going over NAT as I do my CCNP studies. thanks for the good clear explanation
Great Post, thanks!!
I'd love to see a cheat sheet too.
I have to agree. By far the best explanation to date.
Thanks Stretch
I can't see any tab on blog to visit recent posts
That some good eatin', Stretch. I've always had to brute force my thought process though all those NAT details. Thanks for being thoughtful enough to show us the logic.
I've always felt that this whole concept of 'inside' and 'outside' was absurd. Just NAT on the involved interface as traffic enters or exits...sheesh. :)
Anyhow now that NVI is available we can at least drop those useless words from the NAT config, and therefore the concept. The whole inside/outside thing made me want to gag myself with an NM.
Perfect explanation. I love the table ;)
Excellent post
The GUI difference shown is really awesome.
Excellent post
This sort of perspective is crucial for non-Cisco gear as well. Any time a NAT is used, it's a routing boundary that presents confusion to end users and application owners. I always map these sorts of things, though I'm not a fan of Cisco's terminology to describe it. In fact, terminiology for NAT is about as fragmented in this industry as any other area, between source nat, hide nat, overload, global inside. Ugh.
Click! And another Cisco concept makes sense thanks to Packet Life!
Not a difficult concept, just Cisco's explanation! Thank you Jeremy!
Can there be a difference between outside global and outside local at any time? This could only happen, if my router knows about a nat config on the far end side, correct? Thanks for your great explanations.
@mspn
Not that I've ever seen the inside end does not know about the outside.
very good explanation
"location and perspective."
this approach makes it easy to logically think out what the "show ip nat translations" is telling us.
thanks,
This has always been a confusing issue for students and its partly Cisco's fault for making these bad early definitions and sticking to them. It would have been more advantageous to use a 'Actual' SRC/DEST and 'Translated' SRC/DEST type of table.
Oh well.
Jeremy,
ip nat inside source static 192.168.0.10 192.0.2.10
Where does the 192.0.2.10 come from? In your figure I don't see any interface with that ip address??
Cheers,
Robert
@Robert: It's simply a static translation rule, similar to if I had created a NAT address pool, but with only a single IP address mapping.
Hy That is the best NAT explanation ewer seen ..THX
Just a thought..
Router B's public address has to be on that subnet that you are SNAT-ing to. In order for this to work it should be like this:
interface FastEthernet0/0 ip address 192.0.2.10 255.255.255.0 ip nat outside
Or is there some cisco NAT black magic I am not understanding? SNAT creates a 1 to 1 mapping but the "Inside Global" or "Outside NAT Address" as the rest of the world calls it still has to be routable on that interface. I can't just SNAT something I don't have and expect it to be routable. Or maybe I am just stupid.....
Awesome explanation !! Thanks a ton :)
Thanks..u r really doing a good job..... thanks for the clear explanation.
Frank,
Thanks for the comment, it forced me to model the whole thing in GNS3 and really get a good understanding. R2's Fa0/0 does not need to change. The entire model works with a default route from r3 to r2 192.168.0.1 and a static 'ip route 192.0.2.0 255.255.255.0 10.0.0.1' in r1. Add a firewall and this would be a valid B2B environment. i.e a business partner that was using the 192.168.0.0/24 space but not the 192.0.2.0/24 space.
Excellent work Stretch!!!
Steve
The trick question is (for 100 points):
can you use NAT to acces a host that does not have a gateway set ?? :D
ex :
HostB ip 10.10.10.2 /24 ( NO gateway set )
R1 fa0 ip 10.10.10.1 /24
R1 fa1 ip 10.20.20.1 /24
HostB ip 10.20.20.2 /24 gateway to 10.20.20.1
How can you use NAT to ping from B to A.
The ideea is to modify the packets source adress while passing R1. as if the ping was initiated from R1 fa0's interface
Ofcourse a ping from B to anything else except local lan would not work cause no route :D
Best Explanation for NAT I have seen. Good show!