Lesson 54 - Network Address Translation Part 4

It's time to put our theory into practice. We're going to use a single topology and try out different scenarios. They are not related to one another but my intention is to show you the variety of different methods in use. Keep in mind that they are just the few fundamental types of translations but there are more options available and they can become a bit more complex than the ones presented here.

Pic. 1 - Network Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

R2 is playing a role of ISP's router. For the purpose of this presentation I'm not going to use real IP public addresses. I'm going to use 172.x.x.x range and pretend they are public ones.

Addresses used in this lesson are going to be as follows:
Private (LAN) IP = 192.168.1.0/24 and 192.168.2.0/24
Public (Internet) IP = 172.16.1.0/30 (connection to ISP)
Public (Internet) IP = 172.30.1.1 (Internet host used to check NAT)

All these addresses are simulated using Loopback interfaces.

R1 Initial Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
!

ip http server

!

ip route 0.0.0.0 0.0.0.0 172.16.1.2

!

R2 Initial Configuration:

!

interface Loopback0
 ip address 172.30.1.1 255.255.255.0
!

interface FastEthernet1/0
 ip address 172.16.1.2 255.255.255.252

!

ip http server

!

ip route 172.20.1.0 255.255.255.252 172.16.1.1

!

Scenario 1 - Static NAT
In this scenario I'm going to configure a static (one-to-one) NAT. This type of configuration allows me to present my public services to the Internet clients. Let's pretend that our 192.168.1.1 address is a Web server and is connected to R1 (loopback1 simulates this server). Our ISP gave us two public IP addresses (we pretend they are public anyway).

Inside Global Address Pool:

• 172.20.1.1/30
• 172.20.1.2/30

Our web server (192.168.1.1) will be seen on the Internet as 172.20.1.1. Below is the configuration to accomplish that.

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside

!

ip nat inside source static 192.168.1.1 172.20.1.1

!

Note!
When you assign inside or outside role on the interface, the router is going to add 'ip virtual-reassembly' (dependant on the IOS version you use). At the CCNA level you can ignore the meaning of this command.

Verification:

Pic. 2 - NAT Table.

Note!
Static entry is created allowing transmission towards 192.168.1.1 which is seen as 172.20.1.1 on the Internet. Since we have not specified any layer 4 protocols (tcp/udp) and their ports, all ports are open in R1 allowing access to all ports on the web server. If you wanted to open only TCP port 80, you could use this command instead (more likely in real life scenarios):

!

ip nat inside source static tcp 192.168.1.1 80 172.20.1.1 80

!

Pic. 3 - Accessing Web Service.

Connection succeeds!

Scenario 2 - Dynamic NAT using IP Address Pool.
In this scenario we have the same pool of pretend-to-be-public IP addresses from scenario 1. This scenario will dynamically pick the first available IP address and use it for the host that wishes to send packets to the Internet. Since we only have two public IP addresses, only two hosts can send traffic at the time. Adding the 'overload' keyword will include the port translation and more hosts can reuse these two public addresses (172.20.1.1-2/30).

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside
!

!

! The below command defines public IP addresses in the pool.

!

ip nat pool ISP_POOL 172.20.1.1 172.20.1.2 prefix-length 30
!

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed.

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

! The translation of INSIDE Local IP (ACL1) 

! to the INSIDE Global IP (pool ISP_POOL)

!

ip nat inside source list 1 pool ISP_POOL

!

Verification:

Pic. 4 - NAT from 192.168.1.0/24 and 192.168.2.0/24 Subnets.

This type of translation is not used as often as the last one. In case you wanted to use it and have more than two hosts sending traffic towards the Internet, you would use the same configuration including the 'overload' keyword like presented in the scenario 3.

Scenario 3 - Dynamic NAT using IP Address Pool with Overload.
The same method like presented in scenario 2 but used when there is no sufficient public (Inside Global) addresses for the number of hosts used in our LAN (Inside Local addresses).

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside
!

!

! The below command defines public IP addresses in the pool.

!

ip nat pool ISP_POOL 172.20.1.1 172.20.1.2 prefix-length 30
!

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed. 

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

! The translation of INSIDE Local IP (ACL1) 

! to the INSIDE Global IP (pool ISP_POOL)

!

ip nat inside source list 1 pool ISP_POOL overload

!

Scenario 4 - NAT Overload
This is by far the most often used translation. This method is used on all broadband connections. In this method we only need a single public IP address (the one we use on the router's interface facing the ISP).

Our Inside Local addresses are: 192.168.1.0/24 and 192.168.2.0/24, and the single Inside Global address is: 172.16.1.1. Check the configuration below:

R1 NAT Configuration:

!

interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!

interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 ip nat inside

!

interface FastEthernet1/0
 ip address 172.16.1.1 255.255.255.252
 ip nat outside

!

! The ACL1 matches on both subnets, the candidates for translation

! IP addresses that match the ACL1's statements, will be NATed. 

!

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 192.168.2.0 0.0.0.255
!

ip nat inside source list 1 interface FastEthernet1/0 overload

!

Verification:

Pic. 5 - NAT Overload.

In case things do not work, use the following steps to troubleshoot NAT:

1. Check the 'ip nat inside' and 'ip nat inside' statements on the interfaces.
2. Check if your ACL matches on the appropriate Inside Local addresses. If you send traffic from these, 'show access-list' should show you the hits against the ACL entries.
3. You could consider using extremeley dangerous command: 'debug ip nat'. This one however, will inevitably crash your production router. If the traffic is not heavy (no users using the Internet), you can try to use it the way I present below.

I will use the debug ip nat for the presentation purposes only. DO NOT USE THIS on the production equipment!

I will trace a specific Inside Local address (192.168.1.1) translation.

Step 1
Configure the ACL that matches on our single Inside Local address (192.168.1.1)

R1 Configuration: 

!

access-list 99 permit host 192.168.1.1

!

Step 2
Using ACL 99 configured in step 1, I will use debug to see the NAT translation work. The proper output is shown below:

Pic. 6 - NAT Troubleshooting.

Note!
Translation: 192.168.1.1->172.16.1.1 when the packet is sent out F1/0. The translation on the packet returning: 172.16.1.1->192.168.1.1.


Also, the ACL receives the hits. Loot at this below:

Pic. 7 - ACL Hits.

Note!
My ACL 1 which matches on Inside Local addresses has received a hit. It is configured correctly for NAT.