Class in Session: Cisco

Many people are confused by Cisco’s NAT/PAT naming conventions, such as “inside local”, etc. Since a picture is worth a kiloword, I thought that perhaps a few diagrams might help.

Let’s say that our host H1 has IP address 10.1.1.1/24, an RFC 1918 private address. We want to cross the Internet to access host H2, which has the public IP address 198.133.219.25, as shown in Figure 1:

Because we can’t advertise RFC 1918 addresses to the public Internet, in order to make this work we’re going to perform PAT (overloading) on R1, our edge router. Let’s assume that our internal LAN, with address space 10.1.1.0/24, is connected to R1’s Ethernet 0 interface. We’ll be overloading on Serial 0, which has the IP address 64.82.100.67, in public space. To accomplish the translation, the commands would be:

• R1(config)#access-list 1 permit 10.1.1.0 0.0.0.255
• R1(config)#ip nat inside source list 1interface serial 0 overload
• R1(config)#int e0
• R1(config-if)#ip nat inside
• R1(config-if)#int s0
• R1(config-if)#ip nat outside

Figure 2 summarizes the situation at this point:

Inside and Outside: These refer to the physical location of the device whose address is being referenced. The physical locations were unambiguously defined by configuring the appropriate router interfaces with these commands:

• ip nat inside
• ip nat outside

In our example, R1 is doing the translation, with the “inside” interface attached to our LAN, and the “outside” interface on the WAN link to our service provider.

Key point: Because of the way we have configured R1’s interfaces, “inside” is defined to mean “located on our side of R1”, and “outside” means “located on the far side of R1”.

Local and Global: These refer to the perspective (viewpoint) from which the address is being observed, not where the device is located.

Key point: In our example, “local” is defined to mean “looking at it from our side of R1”, and “global” means “looking at it from the far side of R1”.

Yeah, yeah…but what about “inside local”? The key to the jargon is to realize that it describes what we’re looking at, and from where in that order. It’s location-perspective. In other words, “inside local” means that we’re looking at the address of an “inside” device (on our side of our router), from our “local” perspective (from our side of our router). Given the two locations (inside and outside), and the two perspectives (local and global), there are four possibilities:

• Inside Local
• Inside Global
• Outside Local
• Outside Global

We’ll discuss each of these in turn. Since humans can’t actually see the packets as they traverse the media, by “looking” we mean what we would “see” if we were to install protocol analyzers “locally” and “globally”, and examine the addresses within the packets’ IP headers. Since I can’t draw a protocol analyzer, in the diagrams I’ll use an “X-ray eyeball” that’s able to see the packet headers.

Inside Local: Viewing an “inside” device from the “local” perspective, as shown in Figure 3. This is how we see the IP address of H1 from our side of R1. In our example, the “inside local” address is 10.1.1.1, which is the actual address of H1.

Inside Global: Viewing an “inside” device from the “global” perspective, as shown in Figure 4. This is how the Internet sees the IP address of H1. In our example, the “inside global” address is 64.82.100.67, the translated address of H1.

Outside Local: Viewing an “outside” device from the “local” perspective, as shown in Figure 5. This is how H1 sees the IP address of H2. In our example, the “outside local” address is 198.133.219.25, which is not being translated.

Outside Global: Viewing an “outside” device from the “global” perspective, as shown in Figure 6. This is how the Internet sees the IP address of H2. In our example, the “outside global” address is 198.133.219.25, which is H2’s actual address.

Since in our example we’re not translating the destination address on the way out (nor the source address on the way back), the “outside local” and “outside global” addresses are identical. Figure 7 shows our current situation, including the four combinations of location and perspective, along with the corresponding addresses.

Key point: It’s possible that NAT/PAT is also being done on H2’s side, but there is no way we can tell that from our side. If so, they would have their own versions of inside/ outside and local/global that have nothing whatsoever to do with ours.

No matter what terms Cisco chose to use, it would boil down to the same location-perspective issue.  So it is what it is, and that’s “what we’re looking at, and from where”.

And, yes, I still often put my fingers on the diagram and talk to myself when figuring this stuff out. “Inside global…so we’re talking about the inside stuff” while my left hand is pointing to the LAN…“from the global perspective” …my right hand is pointing to the Internet, and sliding from right to left to show the direction I’m looking.

By the way, although we used PAT (overloading) in our example, the “location-perspective” terms work the same way for static and dynamic NAT.

Author: Al Friebe

Dynamic NAT, which could allow several hosts to use the same public IP address at different times of the day, still translates on a “one-to-one” address basis. That is, each inside local address (usually private) being actively translated requires one global address (usually public).

In PAT (Port Address Translation, also known as “overloading”), many inside local addresses are simultaneously mapped to one inside global address (that is, the global address is “overloaded”). Thus, PAT is a “many-to-one” translation scheme. To configure PAT, the syntax is:

• Router(config)#ip nat inside source list 1 interface serial 0/0 overload

The translation tells the router that if a packet with source address matching a permit in ACL 1 hits the inside interface, and it is bound for the outside interface, translate the source address to the address of the Serial0/0 interface. Thus, all translated traffic has the same source address (note the keyword “overload”), and no pool is required.

Continue reading ‘NAT and PAT, Part 3′

In Part 1 of this series, we discussed static NAT. While static NAT works, since it uses manually constructed “one-to-one” translations, it’s not scalable. For example, translating all of the legal host addresses on the 10.1.2.0/24 subnet would require 254 lines. And if we were dealing with the entire 10.0.0.0/8 network, covering all possible addresses would require over sixteen million lines! The solution is “dynamic NAT”.

In dynamic NAT, instead of specifying the translations one-by-one, you give the NAT device some rules that specify which addresses are translated to what. In the case of a Cisco router, the addresses to be translated are specified by an access control list (ACL), and the addresses to which they are translated are specified by a “pool”.

For example, to translate any address on the 10.1.2.0/24 subnet (those permitted by ACL 1) to an address on the 200.1.2.0/24 network (as specified by the pool named “Test”), you could do this:

• Router(config)#ip nat inside source list 1 pool Test

Continue reading ‘NAT and PAT, Part 2′

In my next few posts, we’re going to discuss NAT and PAT. No, they’re not brother and sister, they’re not even cousins. They are Network Address Translation (NAT) and Port Address Translation (PAT).

It’s common today to use private addressing within an Autonomous System (an “AS” is a collection of routers and subnets under a common administrative domain). Per RFC 1918 (Address Allocation for Private Internets), the private networks are:

• 10.0.0.0/8 – One class “A” network
• 172.16.0.0/12 – A block of sixteen class “B” networks
• 192.168.0.0/16 – A block of 256 class “C” networks

One problem is that per RFC 1918, advertising the address spaces listed above to the public Internet is not allowed. What this means is, that if you send a packet with a “private” source address to the Internet, the destination will not be able to reply to you (because the routers on the Internet backbone won’t know where you are). The solution to this problem is NAT, specified by RFC 1631 (The Network Address Translator).

The first type of NAT we’ll discuss is referred to as “static NAT”. In this method, you build the translation table by hand. For example, let’s say that we want to translate addresses on the 10.1.2.0/24 subnet (private address space) to addresses on the 200.1.2.0/24 network (public). We could translate the first address like this:

• Router(config)#ip nat inside source static 10.1.2.1 200.1.2.1

The translation tells the router that if a packet with the specified source address (10.1.2.1) hits the inside interface and is bound for the outside interface, translate the source address statically to the second address (200.1.2.1). You can have multiple translation lines, as many as you need, so let’s add some more:

• Router(config)#ip nat inside source static 10.1.2.2 200.1.2.2
• Router(config)#ip nat inside source static 10.1.2.3 200.1.2.3
• Router(config)#ip nat inside source static 10.1.2.4 200.1.2.4
• Etcetera

The next thing to do is to tell the router which interface (or subinterface) is the “inside” and which is the “outside”. For our example, let’s assume that the FastEthernet0/0 interface connects to our LAN, and the Serial0/0 interface leads to our Internet Service Provider (ISP):

• Router(config)#interface fa0/0
• Router(config-if)#ip nat inside
• Router(config-if)#int s0/0
• Router(config-if)#ip nat outside

Notice that although we only specified the translation of the source address as the packet transited from the inside to outside interface, the router will automatically translate the destination addresses of packets traversing the router from the outside to inside interface. You can have multiple “inside” and/or “outside” interfaces (or subinterfaces). The beauty of it is that the translation is invisible to all devices, other than the one device performing the translation.

You can view the translation table with the command show ip nat translations, and which interfaces are the “inside” and “outside” (along with other info) with show ip nat statistics.

When you display the translation table (sh ip nat trans), you’ll notice that it specifies “inside local” and “inside global” addresses. The “inside” refers to where the addressed device physically resides (inboard of the “inside” interface, that is, on our side of the router). The “local” or “global” refers to the vantage point from where the address is being viewed. That is, “local” means “as seen from the inside”, and “global” means “as seen from the outside”. In other words, the “inside local” address is our host’s untranslated (actual) address, and the “inside global” address is the translated address (as seen by those outboard of the “outside” interface).

Next time, we’ll examine a variation referred to as “dynamic NAT”.

Author: Al Friebe