Understanding NAT address types
By stretch | Thursday, January 7, 2010 at 2:11 a.m. UTC
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
Posted in Design
Comments
January 7, 2010 at 2:24 a.m. UTC
Best Explanation for NAT I have seen. Good show!
January 7, 2010 at 2:34 a.m. UTC
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?
January 7, 2010 at 3:20 a.m. UTC
Dude, you should really get into training :) I'd pay to join your class!
January 7, 2010 at 4:06 a.m. UTC
I was just thinking yesterday about how confusing that terminology was. Now I understand it much better. Thanks Stretch!
January 7, 2010 at 4:08 a.m. UTC
Maybe this should be a cheat sheet?
January 7, 2010 at 4:19 a.m. UTC
I was going over NAT as I do my CCNP studies. thanks for the good clear explanation
January 7, 2010 at 4:27 a.m. UTC
Great Post, thanks!!
January 7, 2010 at 10:05 a.m. UTC
I'd love to see a cheat sheet too.
January 7, 2010 at 1:16 p.m. UTC
I have to agree. By far the best explanation to date.
Thanks Stretch
January 7, 2010 at 1:33 p.m. UTC
I can't see any tab on blog to visit recent posts
January 7, 2010 at 2:34 p.m. UTC
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.
January 7, 2010 at 5:17 p.m. UTC
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.
January 7, 2010 at 5:19 p.m. UTC
Perfect explanation. I love the table ;)
January 8, 2010 at 2:03 a.m. UTC
Excellent post
January 8, 2010 at 12:54 p.m. UTC
The GUI difference shown is really awesome.
January 8, 2010 at 2:31 p.m. UTC
Excellent post
January 9, 2010 at 3:21 a.m. UTC
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.
January 10, 2010 at 12:25 a.m. UTC
Click! And another Cisco concept makes sense thanks to Packet Life!
Not a difficult concept, just Cisco's explanation! Thank you Jeremy!
January 11, 2010 at 7:54 a.m. UTC
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.
January 11, 2010 at 7:51 p.m. UTC
@mspn
Not that I've ever seen the inside end does not know about the outside.
January 14, 2010 at 4:56 p.m. UTC
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,
February 18, 2010 at 1:34 a.m. UTC
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.
August 8, 2010 at 12:09 p.m. UTC
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
August 8, 2010 at 3:18 p.m. UTC
@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.
December 29, 2010 at 7:47 a.m. UTC
Hy That is the best NAT explanation ewer seen ..THX
January 18, 2011 at 7:11 p.m. UTC
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.....
May 7, 2011 at 5:07 a.m. UTC
Awesome explanation !! Thanks a ton :)
June 2, 2011 at 6:06 a.m. UTC
Thanks..u r really doing a good job..... thanks for the clear explanation.
June 28, 2011 at 3:58 p.m. UTC
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
November 8, 2011 at 6:38 p.m. UTC
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
July 1, 2013 at 10:41 a.m. UTC
I went and read the Cisco site on this and it just left me confused, this article was crystal clear when I realised the differences were regarding perspective.
In addition to this the article was only as long as it needed to be where as Cisco's is about 4 times longer.
August 1, 2013 at 9:15 p.m. UTC
Amazing explanation!!!! Thank you very much!!!
September 21, 2013 at 11:29 p.m. UTC
Excellent explanation. Like you, the book definitions weren't cutting it for me. Thanks much!
November 8, 2013 at 12:01 p.m. UTC
very simple and good explanation, congrat for all your posts
November 13, 2013 at 6:08 p.m. UTC
Excelent explanation!!!, it was a confusing topic for me, keep going with this kind of work!
March 11, 2014 at 6:43 p.m. UTC
Thank you!! Though I understand the concept of NAT, I could not grasp these four terms. This is the best breakdown I've found. Many, many thanks!
May 8, 2014 at 6:42 p.m. UTC
Thanks for the clear definition!
July 16, 2014 at 6:59 a.m. UTC
Thanks. this is just the right explanation i have been searching for.
October 2, 2014 at 6:43 a.m. UTC
I understand the stages of address states from original to translated, except for how the (outside local) address is processed.
My theory is that the (outside local) address is seen on the private network to which it is not a member, as the same ip as the (outside global) address.
For the device with an outside global (internet) address, that is connected to its own local network, it would have an outside local address that is different from its outside global address, in its private network.
I envision two private networks facing each other through the internet, and the addresses of each.
But are there internet-only devices with no local network connection, and what of the outside local address then?
November 1, 2014 at 9:37 a.m. UTC
Well done mate. Excellent work! Keep it up.
April 26, 2015 at 6:27 p.m. UTC
Thank you
August 29, 2015 at 9:44 a.m. UTC
Thanks jeremy
January 29, 2016 at 3:02 p.m. UTC
Thanks! After reading this post NAT makes more sense. Great explanation on how to distinguish between all the terminologies.
March 2, 2016 at 7:47 p.m. UTC
Best description for the four terms most often confused.
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