Case Study
Figure 1 shows that hosts from the 192.168.0.0/16 LANs, PC1, and PC2 cannot ping servers on the outside network, Svr1, and Svr2.
To begin troubleshooting the problem, use the show ip nat translations command to see if any translations are currently in the NAT table. The output in Figure 1 shows that no translations are in the table.
The show ip nat statistics command is used to determine whether any translations have taken place. It also identifies the interfaces that translation should be occurring between. As shown in the output of Figure 2, the NAT counters are at 0, verifying that no translation has occurred. By comparing the output with the topology shown in Figure 1, notice that the router interfaces are incorrectly defined as NAT inside or NAT outside. The incorrect configuration can also be verified using the show running-config command.
The current NAT interface configuration must be deleted from the interfaces before applying the correct configuration.
After correctly defining the NAT inside and outside interfaces, another ping from PC1 to Svr1 fails. Using the show ip nat translations and show ip nat statistics commands again verifies that translations are still not occurring.
As shown in Figure 3, the show access-lists command is used to determine whether the ACL that the NAT command references is permitting all of the necessary networks. Examining the output indicates that an incorrect wildcard bit mask has been used in the ACL that defines the addresses which need to be translated. The wildcard mask is only permitting the 192.168.0.0/24 subnet. The access list is first removed and then reconfigured using the correct wildcard mask.
After configurations are corrected, another ping is generated from PC1 to Svr1, and this time the ping succeeds. As shown in Figure 4, the show ip nat translations and show ip nat statistics commands are used to verify that the NAT translation is occurring.