Configuring Static NAT
Static NAT, also more commonly known as one to one NAT is primary used to translate a public IP Address to an internal DMZ private address. There are of course other uses for static nat which will be explains however this lab will discuss and demonstrate the configuration and verification of basic Static NAT.
Real World Application & Core Knowledge
Network Address Translation; referred to as NAT is used in almost every network in the world in some form or fashion rather it be a NAT one to one translation, NAT pool where a pool of IP addresses are given on a first come first serve basis to the inside private address range or the most famous PAT (Port Address Translation), commonly a misconception and referred to as NAT but PAT translates many inside addresses to a single outside address by using random port numbers for ip communication.
NAT Pooling and Port Address Translation (PAT) will be discussed in the next two labs but for this lab lets dive into the abyss of Network Address Translation (NAT) one to one.
NAT was created with the intention to prolong the inevitable which was our ever depleting IPv4 address space. As more and more address blocks were allocated by IANA, more and more people became worried that we would soon one day run out of IPv4 addresses. Granted if IPv4 NAT was not created we would have ran out of IP addresses a long time ago but NAT saved us in more ways then one.
NAT one to one is commonly used when you go from one autonomous system to another autonomous system and you need your source address when communicating to the destination to be a specific IP address but that IP address does not match your IP address layout. In which case you’d need to NAT one to one the source address to a destination address, in this case NAT one to one is commonly performed on both sides.
For example; ABC Inc. and XYZ Inc. need to establish IP connectivity using a point-to-point T1 and you need to ensure ip communication but both companies use the SAME RFC1918 address space. In this case Network Address Translation (NAT) would be need to be implemented on both sides of the point-to-point T1.
In ABC Inc. the source address is 10.17.50.22 and the destination is 10.84.18.7 however the 10.84.18.7 address shows up in ABC Inc.’s networks routing table as a small branch office in Miami, Florida. In XYZ Inc.’s network the source address is 10.84.18.7 and the destination needs to be 10.17.50.22 however that address shows up as being located at the corporate head quarters in Dallas, Texas. In a scenario like this you’re in a tough spot but no need to fear, Network Address Translation is here to save the network and possibly your job…
Both ABC Inc. and XYZ Inc. would need to agree on an IP address allocation used for the connectivity between the two companies. Let’s say ABC Inc. and XYZ Inc. agree on using the 10.240.18.0/29 address space for the point to point T1. In this case there would be six usable host IP Addresses. ABC Inc. would use 10.240.18.1 on their T1 serial interface and 10.240.18.2 as their NAT address for the source address of 10.17.50.22 and XYZ Inc. would use 10.240.18.5 on their T1 interface and 10.240.18.6 as their NAT IP address for source of 10.84.18.7.
Through the magic of Network Address Translation when ABC Inc.’s server attempts to communicate with XYZ Inc.’s server they need to use the destination NAT address. So ABC Inc.’s server would communicate to 10.240.18.6. In this case The traffic would originate from 10.17.50.22, go to the router and get translated from 10.17.50.22 to 10.240.18.2 then go to 10.240.18.6 which in turn would be translated from 10.240.18.8 to 10.84.18.7 therefore full IP communication would be functional without any drastic changes to the companies networks.
Now that you have an general understanding of how NAT works, its time to take a look at how NAT operates.
When dealing with Network Address Translation on a Cisco router you’ll need to familiarize yourself with four different terms. Inside Global, Inside Local, Outside Global, Outside Local.
- Inside Local — Is an IP address assigned to a host on the inside network. This is can be configured statically or obtained via DHCP. This IP Address is most likely to be an RFC1918 private address.
- Inside Global — Is commonly a public IP Address assigned by an Internet Services Provider (ISP) or a Network Operations Center (NOC) that represents one or more inside local IP addresses to the outside world.
- Outside Local — In an IP address of an outside host as it appears to the inside network. Not necessarily a public IP address, it is allocated from an address space routable on the inside.
- Outside Global — Is an IP address that is assigned to a host on the outside network by the host owner. This address is allocated from a globally routable address or network space; not a private address (RFC1918)
When configuring Network Address Translation, you’ll need to specify the INSIDE and OUTSIDE interfaces. This specifies the NAT boundary at a given router. To specify these types of interfaces you’ll use the ip nat inside | outside command in interface configuration mode.
To configure a static one to one NAT translation you’ll need two key components; the inside host address (inside local) and the ip address of which the inside local address is to be translated to, (the inside global). Once you have this information you’ll use the ip nat inside source static inside_local_ip outside_global_ip command in global configuration mode.
When configuring a NAT statement rather it be a static one to one translation or port address translation (PAT – Many to One), you have the ability to specify rather or not the entry is extendable by adding the extendable following the NAT statement.
The Extendable option allows you to configure multiple NAT statements that use the same inside local or inside global address whereas when attempting to create a static translation map where the inside local or outside global matches an IP address that’s already used in a different translation map would give you an ambiguous command error.
In general there are two types of static NAT translations. The first one being a standard translation where the translation entry maps a single inside local address to a single outside global address then there is the extended NAT translation where you can create static translation map(s) that include multiple identical inside local OR outside global maps based on an inside/outside port number.
For example;
ip nat source static tcp 10.11.1.1 8080 172.29.18.5 80 extendable
ip nat source static tcp 10.11.1.14 80 172.29.18.5 443 extendable
In the example given, any traffic destined to 172.29.18.5 on port 80 would be translated to 10.1.11.1 port 8080 internally whereas any traffic destined towards 172.29.18.5 on port 445 SSL would be translated to 10.11.1.14 port 80.
You have the ability to view the routers IP NAT translation table by using the show ip nat translations command in user or privileged mode. This gives you the ability to determine what translation flows are currently installed in the NAT table. You can purge the NAT table’s dynamic translations by using the clear ip nat translation * command in privileged mode.
Now that you have an understanding of NAT one-to-one, this lab will build the same scenario given as an example previously to familiarize you with NAT one-to-one configuration.
Please review the following command(s) listed below;
| Command | Description |
|---|---|
| ip nat inside source static il.il.il.il ig.ig.ig.ig | This command is executed in global configuration mode to configure a static NAT one to one translation where as il.il.il.il is the inside local address and ig.ig.ig.ig is the outside global address which the inside local address will be translated to. |
| ip nat inside source static {tcp | udp} il.il.il.il {TCP/UDP Port #} ig.ig.ig.ig {TCP/UDP Port #} extendable | This command is executed in global configuration mode to configure an extended static NAT translation where you translate a single inside local or outside global address based on port number(s). |
| show ip nat translations | This command is executed in user or privileged mode to view all the current NAT translations in the routers NAT table. |
| clear ip nat translation * | This command is executed in privileged mode to purge all the dynamic NAT translations that exist in the routing table. If this command is executed in a live network take caution as it will drop current dynamic NAT translated TCP sessions. |
In this lab you will be configuring static NAT (One-to-One) between two companies; ABC Inc. and XYZ Inc. both of which have a server with the IP address of 10.111.14.14. Since both companies believe it would be too difficult to RE-IP the network, you’ll need to setup a static NAT translation on R2 and R3 to ensure IP communication between the two servers that have the same IP address among both organizations.
The following logical topology shown below is used in this lab;
Lab Prerequisites
- If you are using GNS3 than load the Free CCNA Workbook GNS3 topology than start devices; R1, R2, R3 and R4
- Establish a console session with devices R1, R2, R3 and R4 than load the initial configurations provided below by copying the config from the textbox and pasting it into the respected routers console.
<
Lab Objectives
- Configure R2 and R3’s respected interfaces as NAT Inside and NAT Outside.
- Create a static NAT translation on R2 to translate the inside local address 10.111.14.14 to the outside global address of 172.20.23.41
- Create a static NAT translation on R3 to translate the inside local address 10.111.14.14 to the outside global address of 172.20.23.14
- Verify that you have IP communication between the two simulated servers by pinging 172.20.23.14 from R1’s Lo0 interface.
Lab Instruction
Objective 1. – Configure R2 and R3’s respected interfaces as NAT Inside and NAT Outside.
R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#interface Serial0/0.221 R2(config-subif)#ip nat inside %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up R2(config-subif)#interface Serial0/0.223 R2(config-subif)#ip nat outside R2(config-subif)#end R2#
R3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R3(config)#interface Serial0/0.322 R3(config-subif)#ip nat outside %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, changed state to up R3(config-subif)#interface Serial0/0.324 R3(config-subif)#ip nat inside R3(config-subif)#end R3#
Objective 2. – Create a static NAT translation on R2 to translate the inside local address 10.111.14.14 to the outside global address of 172.20.23.41
R2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R2(config)#ip nat inside source static 10.111.14.14 172.20.23.41 R2(config)#end R2#
Objective 3. – Create a static NAT translation on R3 to translate the inside local address 10.111.14.14 to the outside global address of 172.20.23.14
R3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R3(config)#ip nat inside source static 10.111.14.14 172.20.23.14 R3(config)#end R3#
Objective 4. – On R1 verify that you have IP communication towards the R4’s Lo0 via the translated address 172.20.23.14 by pinging 172.20.23.14 sourced from R1’s Lo0 interface.
R1#ping 172.20.23.14 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.20.23.14, timeout is 2 seconds:
Packet sent with a source address of 10.111.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/90/93 ms
R1#
As you can see from above you now have full IP connectivity between the two completely seperate networks that have a server using the same IP address via Network Address Translation.
So when ABC Inc.’s Server 10.111.14.14 attempts to communicate to 172.20.23.14 it is actually communicating to the 10.111.14.14 server located in XYZ Inc.’s network.
So for a complete run down of this scenario, when the simulated server 10.111.14.14 sends traffic to 172.20.23.14 it goes towards R2 and from R2 the traffic gets NAT’ed to 172.20.23.41. At which point 172.20.23.41 is on a common subnet to 172.20.23.14 so the traffic gets forwarded out Se0/0.223. When it reaches Serial0/0.322 on R3, R3 looks at its static translation table and immediately forwards traffic destined to 172.20.23.14 towards 10.111.14.14. When the simulated server at 10.111.14.14 receives the traffic it responds in the opposite direction in the same manner.
You can check the ip nat translation table on R2 to verify that the NAT translation was installed into the NAT table as shown below;
R2#show ip nat trans
Pro Inside global Inside local Outside local Outside global
--- 172.20.23.41 10.111.14.14 --- ---
R2#
