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 18.104.22.168 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 (22.214.171.124). 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 126.96.36.199 anytime I want to test Internet connectivity: NAT_ROUTER#ping 188.8.131.52 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, 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) Outside interfaces: Ethernet1/0 Inside interfaces: FastEthernet0/0 Hits: 1211 Misses: 121 Expired translations: 88 Dynamic mappings: -- 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 --- 220.127.116.11 172.30.2.50 --- --- tcp 18.104.22.168:21 172.30.2.11:21 --- --- tcp 22.214.171.124:25 172.30.2.10:25 --- --- tcp 126.96.36.199:80 172.30.2.12:80 --- --- tcp 188.8.131.52:49221 172.30.2.177:49221 184.108.40.206:80 220.127.116.11:80 tcp 18.104.22.168:49222 172.30.2.177:49222 22.214.171.124:80 126.96.36.199:80 tcp 188.8.131.52:49223 172.30.2.177:49223 184.108.40.206:80 220.127.116.11:80 tcp 18.104.22.168:49224 172.30.2.177:49224 22.214.171.124:80 126.96.36.199:80 tcp 188.8.131.52:49225 172.30.2.177:49225 184.108.40.206:80 220.127.116.11:80 tcp 18.104.22.168:49226 172.30.2.177:49226 22.214.171.124:80 126.96.36.199:80 tcp 188.8.131.52:49238 172.30.2.177:49238 184.108.40.206:80 220.127.116.11:80 tcp 18.104.22.168:443 172.30.2.12:443 --- --- tcp 22.214.171.124:49236 172.30.2.177:49236 126.96.36.199:80 188.8.131.52:80 tcp 184.108.40.206:49237 172.30.2.177:49237 220.127.116.11:80 18.104.22.168:80 tcp 22.214.171.124:49242 172.30.2.177:49242 126.96.36.199:80 188.8.131.52:80 tcp 184.108.40.206:49244 172.30.2.177:49244 220.127.116.11:80 18.104.22.168:80 tcp 22.214.171.124:49245 172.30.2.177:49245 126.96.36.199:80 188.8.131.52:80 tcp 184.108.40.206:49243 172.30.2.177:49243 220.127.116.11:80 18.104.22.168:80 udp 22.214.171.124:49308 172.30.2.177:49308 126.96.36.199:53 188.8.131.52:53 udp 184.108.40.206:49309 172.30.2.177:49309 220.127.116.11:53 18.104.22.168:53 udp 22.214.171.124:49310 172.30.2.177:49310 126.96.36.199:53 188.8.131.52:53 udp 184.108.40.206:49311 172.30.2.177:49311 220.127.116.11:53 18.104.22.168:53 udp 22.214.171.124:49312 172.30.2.177:49312 126.96.36.199:53 188.8.131.52:53 udp 184.108.40.206:49313 172.30.2.177:49313 220.127.116.11:53 18.104.22.168:53 udp 22.214.171.124:49314 172.30.2.177:49314 126.96.36.199:53 188.8.131.52:53 udp 184.108.40.206:49315 172.30.2.177:49315 220.127.116.11:53 18.104.22.168:53 tcp 22.214.171.124:49227 172.30.2.177:49227 126.96.36.199:80 188.8.131.52:80 tcp 184.108.40.206:49228 172.30.2.177:49228 220.127.116.11:80 18.104.22.168:80 tcp 22.214.171.124:49229 172.30.2.177:49229 126.96.36.199:80 188.8.131.52: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 184.108.40.206 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 220.127.116.11 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 Building configuration... Current configuration : 111 bytes ! interface FastEthernet0/0 ip address 172.30.2.77 255.255.255.0 ip nat inside NAT_ROUTER#show running-config interface Ethernet 1/0 Building configuration... Current configuration : 100 bytes ! interface Ethernet1/0 ip address 18.104.22.168 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 outside interface.
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?