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.

NAT_classes_chart.png

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

NAT_boundary.png

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.

NAT_packet.png

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

About the Author

Jeremy Stretch is a networking engineer and the maintainer of PacketLife.net. He currently lives in the Raleigh-Durham area of North Carolina. Although employed full-time out of necessity, his true passion lies in improving the field of network engineering around the world. You can contact him by email or follow him on Twitter.

Comments

Best Explanation for NAT I have seen. Good show!

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

Leave a Comment


Register to comment as a member. You'll look cooler.

Optional; will not be displayed publicly or given out.

No commercial links. Only personal (e.g. blog, Twitter, or LinkedIn) and/or on-topic links, please.
For syntax help, see the editing guide.
Layer five of the OSI model is the _____ layer.