Verifying NAT Configuration
Objective:
- 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 68.110.171.98 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 (68.110.171.98). 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 4.2.2.2 anytime I want to test Internet connectivity: NAT_ROUTER#ping 4.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 4.2.2.2, 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 --- 200.1.1.1 172.30.2.50 --- --- tcp 200.1.1.2:21 172.30.2.11:21 --- --- tcp 200.1.1.2:25 172.30.2.10:25 --- --- tcp 200.1.1.2:80 172.30.2.12:80 --- --- tcp 68.110.171.98:49221 172.30.2.177:49221 17.149.160.10:80 17.149.160.10:80 tcp 68.110.171.98:49222 172.30.2.177:49222 17.149.160.10:80 17.149.160.10:80 tcp 68.110.171.98:49223 172.30.2.177:49223 17.149.160.10:80 17.149.160.10:80 tcp 68.110.171.98:49224 172.30.2.177:49224 17.149.160.10:80 17.149.160.10:80 tcp 68.110.171.98:49225 172.30.2.177:49225 17.149.160.10:80 17.149.160.10:80 tcp 68.110.171.98:49226 172.30.2.177:49226 17.149.160.10:80 17.149.160.10:80 tcp 68.110.171.98:49238 172.30.2.177:49238 17.149.160.10:80 17.149.160.10:80 tcp 200.1.1.2:443 172.30.2.12:443 --- --- tcp 68.110.171.98:49236 172.30.2.177:49236 66.151.152.126:80 66.151.152.126:80 tcp 68.110.171.98:49237 172.30.2.177:49237 206.16.21.35:80 206.16.21.35:80 tcp 68.110.171.98:49242 172.30.2.177:49242 69.89.31.87:80 69.89.31.87:80 tcp 68.110.171.98:49244 172.30.2.177:49244 69.89.31.87:80 69.89.31.87:80 tcp 68.110.171.98:49245 172.30.2.177:49245 69.89.31.87:80 69.89.31.87:80 tcp 68.110.171.98:49243 172.30.2.177:49243 209.85.171.167:80 209.85.171.167:80 udp 68.110.171.98:49308 172.30.2.177:49308 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49309 172.30.2.177:49309 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49310 172.30.2.177:49310 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49311 172.30.2.177:49311 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49312 172.30.2.177:49312 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49313 172.30.2.177:49313 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49314 172.30.2.177:49314 4.2.2.2:53 4.2.2.2:53 udp 68.110.171.98:49315 172.30.2.177:49315 4.2.2.2:53 4.2.2.2:53 tcp 68.110.171.98:49227 172.30.2.177:49227 208.46.174.96:80 208.46.174.96:80 tcp 68.110.171.98:49228 172.30.2.177:49228 208.46.174.96:80 208.46.174.96:80 tcp 68.110.171.98:49229 172.30.2.177:49229 208.46.174.96:80 208.46.174.96: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 68.110.171.98 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.
NOTE
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 4.2.2.2 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!
Troubleshooting NAT
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 68.110.171.98 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?