If you are reaching for your CCNA Routing and Switching certification, you probably already know that configuring NAT is on the list of stuff to know. In the CCNA world, this is accomplished using dynamic NAT, or NAT pools, as one solution, or Port Address Translation (PAT) for the other solution. Static NAT is mentioned in the official CCNA curriculum for the CCNA classes, but the labs do not require a student to actually configure it. What I want to show today is an alternate method to configure NAT which works just fine, but is NOT the method used in CCNA R&S.
This blog assumes that you already have a basic understanding of NAT configuration. If you want to brush up on your understanding of NAT before diving in, feel free to take a look at my previous blog on the topic Troubleshooting NAT pools on Cisco routers. The main point here is to enable NAT on an interface (or several interfaces) without specifying an inside or outside interface. Let’s take a look at the topology which will be used in this discussion:
The objective is to permit the two clients to access the (fake) Internet hosted on the WWW router, or more precisely, to be able to reach the target address of 18.104.22.168 (borrowed from Google). The two clients are actually Cisco routers in client clothing, so I have disabled ip routing on each of them using the command no ip routing from global configuration mode. I have then configured a default-gateway on each which is 192.168.1.254 for Client1 and 192.168.2.254 for Client2. What remains is to configure NAT on the NAT-RTR.
First, let’s make sure that NAT-RTR can hit the 22.214.171.124 address, because if it can’t get there, our clients are not going to have much success either:
Yay! Success. Now let’s configure the f0/0 interface so that it can speak trunk (802.1q) with SW1. Note that this topology was created using GNS3 1.2.1 and that SW1 is a vanilla ethernet switch which has been preconfigured with port 1 in VLAN 10, port 2 in VLAN 20, and port 8 configured as a trunk link. The steps on NAT-RTR:
Now to repeat the steps for our second subinterface:
Let’s include int f0/1 in the NAT process:
We still need to create an access-list to allow our traffic of choice.
Now to actually fire up the NAT process:
If everything is working as expected, I should be able to hit the 126.96.36.199 address from each of my clients. Let’s check:
All is well on Client1. The last verification step is to try Client2:
So both clients can now hit an external IP address using the NAT-RTR as the initial objective stipulated. We can see that the NAT process is working even though I have not configured NAT inside or NAT outside. You may find it interesting to note that even after a successful ping from one of the clients, the command show ip nat translations will return no results. This is because using the command ip nat enable creates a NAT Virtual Interface (nvi) so if you want to see the NAT activity, you must type show ip nat nvi translation like so:
As mentioned, this is not an expectation if you are studying for your CCNA R&S, but it is way cool to know other ways of accomplishing similar tasks! If you have suggestions or comments, I would love to hear them.
Until next time…