Verifying NAT Configuration
- Troubleshoot NAT issues
To verify that everything is working, we need to return to our command-line interface. (The SDM can verify that packets are passing through interfaces but is unable to show us the detailed NAT information we need.) The first thing I want to do when I get to the command line is issue the show ip interface brief command (by far, my favorite command in all of Cisco) to get my bearings:
NAT_ROUTER#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 172.30.2.77 YES NVRAM up up
Ethernet1/0 184.108.40.206 YES NVRAM up up
Serial1/0 unassigned YES NVRAM administratively down down
Serial2/0 unassigned YES NVRAM administratively down down
We can see our internal IP address (172.30.2.77) and our external IP address (220.127.116.11).
Let’s start by ensuring that we can reach the Internet without involving NAT by issuing a ping
command directly from the router. I typically ping the world’s best-known public DNS server at 18.104.22.168 anytime I want to test Internet connectivity:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.214.171.124, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/28 ms Beautiful. Now I’ll configure an internal client to use this router as its default gateway and do some Internet surfing. I’ll spare you the screen captures of me surfing the Internet—you’ll just have to trust that I’m really surfing. Yep, there’s my Apple homepage (I’ve recently become quite the Apple enthusiast). I’ll also surf over to www.CiscoBlog.com to see if there’s anything new. Okay, I’m done surfing. Now let’s verify that NAT is occurring from the Cisco router’s perspective. You can use two major commands to do so. Here’s the first:
NAT_ROUTER#show ip nat statistics
Total active translations: 38 (5 static, 33 dynamic; 37 extended)
Hits: 1211 Misses: 121
Expired translations: 88
-- Inside Source
[Id: 1] access-list 1 interface Ethernet1/0 refcount 33
The show ip nat statistics command verifies NAT from a more global perspective. The primary information you can gather is the outside and inside interface configuration and the number of hits and misses. The number of hits defines how many packets match an existing NAT mapping. For example, I went to www.CiscoBlog.com while I was surfing the Internet. The very first packet that went through the Cisco router was considered a “miss” because no existing NAT translation was created.
So, the Cisco router created the NAT translation, passing the traffic from my internal client (172.30.2.177) to the www.CiscoBlog.com website. The website then received my connection, created a TCP socket, and streamed many packets back to my web browsing application. All those packets were considered “hits” by NAT because they matched an existing NAT translation. The second command you can use to verify that NAT is working is the more popular of the two:
NAT_ROUTER#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 126.96.36.199 172.30.2.50 --- ---
tcp 188.8.131.52:21 172.30.2.11:21 --- ---
tcp 184.108.40.206:25 172.30.2.10:25 --- ---
tcp 220.127.116.11:80 172.30.2.12:80 --- ---
tcp 18.104.22.168:49221 172.30.2.177:49221 22.214.171.124:80 126.96.36.199:80
tcp 188.8.131.52:49222 172.30.2.177:49222 184.108.40.206:80 220.127.116.11:80
tcp 18.104.22.168:49223 172.30.2.177:49223 22.214.171.124:80 126.96.36.199:80
tcp 188.8.131.52:49224 172.30.2.177:49224 184.108.40.206:80 220.127.116.11:80
tcp 18.104.22.168:49225 172.30.2.177:49225 22.214.171.124:80 126.96.36.199:80
tcp 188.8.131.52:49226 172.30.2.177:49226 184.108.40.206:80 220.127.116.11:80
tcp 18.104.22.168:49238 172.30.2.177:49238 22.214.171.124:80 126.96.36.199:80
tcp 188.8.131.52:443 172.30.2.12:443 --- ---
tcp 184.108.40.206:49236 172.30.2.177:49236 220.127.116.11:80 18.104.22.168:80
tcp 22.214.171.124:49237 172.30.2.177:49237 126.96.36.199:80 188.8.131.52:80
tcp 184.108.40.206:49242 172.30.2.177:49242 220.127.116.11:80 18.104.22.168:80
tcp 22.214.171.124:49244 172.30.2.177:49244 126.96.36.199:80 188.8.131.52:80
tcp 184.108.40.206:49245 172.30.2.177:49245 220.127.116.11:80 18.104.22.168:80
tcp 22.214.171.124:49243 172.30.2.177:49243 126.96.36.199:80 188.8.131.52:80
udp 184.108.40.206:49308 172.30.2.177:49308 220.127.116.11:53 18.104.22.168:53
udp 22.214.171.124:49309 172.30.2.177:49309 126.96.36.199:53 188.8.131.52:53
udp 184.108.40.206:49310 172.30.2.177:49310 220.127.116.11:53 18.104.22.168:53
udp 22.214.171.124:49311 172.30.2.177:49311 126.96.36.199:53 188.8.131.52:53
udp 184.108.40.206:49312 172.30.2.177:49312 220.127.116.11:53 18.104.22.168:53
udp 22.214.171.124:49313 172.30.2.177:49313 126.96.36.199:53 188.8.131.52:53
udp 184.108.40.206:49314 172.30.2.177:49314 220.127.116.11:53 18.104.22.168:53
udp 22.214.171.124:49315 172.30.2.177:49315 126.96.36.199:53 188.8.131.52:53
tcp 184.108.40.206:49227 172.30.2.177:49227 220.127.116.11:80 18.104.22.168:80
tcp 22.214.171.124:49228 172.30.2.177:49228 126.96.36.199:80 188.8.131.52:80
tcp 184.108.40.206:49229 172.30.2.177:49229 220.127.116.11:80 18.104.22.168:80
Wow—look at that! These are all the NAT translations my router is currently maintaining. This is how you can really tell if NAT is working. If you look at the first few translations, you’ll be able to verify the static NAT mappings that we entered through the SDM just a few moments ago. The IP address in the Inside global column represents the address on the interface connecting to the Internet. The IP address in the Inside local column represents the internal IP address on your LAN. Do you see now why it’s so important to know that terminology mentioned at the beginning of the chapter? If it’s a little fuzzy, now would be a good time to flip back a few pages and review.
The static mappings have no data in the Outside local and Outside global columns because they are not currently in use (no one is accessing those IP addresses from the Internet at this time). If they were being accessed, we would see the IP address of the device accessing them in those two columns. Now take a look farther down; you see a bunch of mappings on the inside global IP address 22.214.171.124 and the inside local IP address 172.30.2.177. The global IP address represents my ISP-assigned Internet address that I am using for NAT overload (all the internal clients share this one). The local IP address represents the internal client I was surfing the Internet with. Next to each of those IP addresses is a colon, followed by a port number. These are the source UDP and TCP port numbers that my web surfing client uses to keep all its applications separate.
We’ll talk more about the specifics of the show ip nat translations command in Chapter 21. In the two rightmost columns (Outside local and Outside global) you see the public IP addresses that my web surfing client was accessing. I know what you might be thinking: ”Why do you have so many entries in the NAT table? I thought you accessed just two websites!” You’re right! I did access only two websites. However, my laptop had to do DNS lookups to access both the websites, and those websites were supported by many other servers.
For example, the Apple website might have one server that supplies the raw HTML pages, another server that supplies all the graphics, another for flash content, and so on. For each of those servers, the client may have to do another DNS lookup (which is why you see so many requests to the 126.96.36.199 DNS server IP address), and the Cisco router has to maintain another NAT mapping to allow data through. On top of it all, this is just one laptop surfing the Internet! Imagine what this table would look like in a large corporate network. Good thing the show ip nat translation command supports plenty of filtering options!
When you use the SDM to configure NAT, not too much can go wrong, but you can follow some general troubleshooting steps if things don’t seem to be working correctly. To start, enter the following modified show running-config commands:
NAT_ROUTER#show running-config interface fastEthernet 0/0
Current configuration : 111 bytes
ip address 172.30.2.77 255.255.255.0
ip nat inside
NAT_ROUTER#show running-config interface Ethernet 1/0
Current configuration : 100 bytes
ip address 188.8.131.52 255.255.255.224
ip nat outside
This filters the large running configuration to just the interfaces you’d like to see. What you want to verify is that the interface connecting to your internal network is configured as the ip nat inside interface and that the interface connecting to the ISP is configured as the ip nat
If things look good there, do a ping from the router itself. This will test your Internet connectivity without the NAT process getting in the way. The problem could be a simple routing issue (such as missing a default route to your ISP). If things check out in the router-originated ping, try the ping from an internal client. Be sure you’re pinging an IP address rather than a hostname (such as www.examcram.com). You don’t want a DNS problem getting in the way. If the client can ping successfully, NAT is operational.
Last, but not least, is a command that has saved me plenty of troubleshooting time: clear ip nat translations *. This command wipes out the NAT table maintained on the router. Sometimes, when we are setting up a network, we end up with NAT entries in the table that don’t belong there. It could just be from changing a client’s IP address before NAT timeouts are reached, it could be that your public or private IP address changes, or it could just be that the router doesn’t feel like NATing today.
It’s always worthwhile to try entering clear ip nat translations * from the privileged prompt before you get too deep in troubleshooting other issues. Don’t worry; it shouldn’t cause any connectivity problems for existing clients using the Internet. The router will just create a new NAT mapping the next packet that comes through. I have seen this command cause Instant Messenger clients to log out and log back in again, but people don’t really use Instant Messenger clients for anything productive anyway, right?