Shortcut Keys: SecureCRT

Quit terminal via Async = Shift + Ctrl + 6, then 'x'
Break = Ctrl + Break
Stop telnet = Shift + Ctrl + 6, then 'c'

ASA NAT: Order of Operations

1. nat 0 access-list (nat-exempt)
2. match against existing xlates
3. static
   i) static nat with and without access-list (first match)
   ii) static pat with and without access-list (first match)
4. nat
   a) nat access-list (first match)
       Note: nat 0 access-list is not part of this command.
   b) nat (best match)
       Note:When matching nat, oldest nat configured will be matched first.
                When choosing a global address from multiple pools with the same nat id, the following order is tried
   i) if the id is 0, create an identity xlate.
   ii) use the global pool for dynamic NAT
   iii) use the global pool for dynamic PAT
5. Error

NAT: Common Issues

Some of the most common issues when implementing NAT in the field are described next. Most of these are common configuration mistakes, but some of them are due to a lack of understanding of how NAT is supposed to work.

The symptoms of most of these problems are similar, meaning that the devices, whose IP addresses are NATed, are unable to access the public network as they are supposed to. Most of these issues can be diagnosed by understanding what goal NAT is being implemented to achieve and then looking at the configuration to see if one of the following mistakes is the source of the problem:

• Access lists blocking NATed or non-NATed traffic- It is important to keep in mind NAT's operation in relation to the access control lists. Opening an access list for non-NATed traffic, when in reality the traffic hitting it is NATed traffic, causes traffic to be dropped. For instance, ACLs on the interface that has ip nat inside configured on it should use the non-NATed addressing for traffic entering it from the private netwok, and ACLs on the interface that has ip nat outside configured on it should use NATed addressing for traffic entering it from the public side. 
• NAT access list is missing networks to be NATed- The access list that is used to define interesting traffic for the NAT operation must define all the network ranges that need to be NATed. Missing an address or a number of addresses from this access list keeps NAT from occurring for the traffic coming from these addresses. 
• Missing the overload keyword in the NAT statement- If only a limited number of globally routable addresses are available to do NAT, Port Address Translation (PAT) or Overload NAT must be used to allow all the hosts on the RFC 1918 addressed network to reach the public network. To set up PAT, the keyword overload must be used at the end of the NAT configuration command. Omitting this command causes PAT not to be turned on, resulting in only a limited number of hosts being able to access the public network or the Internet. Here is an example of using the overload keyword: ip nat inside source access list 1 interface Ethernet0/0 overload 
• Asymmetric routing causes NAT to fail- NAT occurs when a packet enters an interface configured with the ip nat inside command and leaves via an interface configured with the ip nat outside command. On a router with multiple interfaces, you must make sure that all interfaces on which traffic, that needs to be NATed, enters the router, and all interfaces from which this traffic exits, are configured with the ip nat inside and ip nat outside commands, respectively. Failure to do so causes NAT not to occur for traffic passing through the interface that does not have the appropriate NAT command configured on it. 
• Overlapping addresses in the NAT pool and static NAT entries- It is important to make sure that the IP addresses in the NAT pool are not also being used for a static NAT translation. This can cause NAT to fail intermittently. 
• Using extended access lists to define interesting traffic for NAT- By default, the translations that NAT creates contain only entries for the inside global and inside local address unless PAT is being used. This is done because this is all the information that is needed for simple NAT of inside local addresses to inside global addresses and to de-NAT the return traffic. However, this remains true even when extended access lists are used to define the interesting traffic.

NAT: Show Commands

NAT show Commands

The command most often used to troubleshoot NAT is show ip nat translations. 

Sample Output for the show ip nat translations Command

Router#show ip nat translations



Pro   Inside global         Inside local         Outside local     Outside global

udp  171.69.233.209:1220    192.168.1.95:1220    171.69.2.132:53   171.69.2.132:53

tcp   171.69.233.209:11012  192.168.1.89:11012   171.69.1.220:23   171.69.1.220:23

Another useful command is show ip nat translations verbose 

Sample Output for the show ip nat translations verbose Command

Router#show ip nat translations verbose



Pro Inside global           Inside local        Outside local    Outside global

udp 171.69.233.209:1220     192.168.1.95:1220   171.69.2.132:53  171.69.2.132:53

              create 00:00:02,       use 00:00:00,  flags:  extended

tcp   171.69.233.209:11012  192.168.1.89:11012  171.69.1.220:23  171.69.1.220:23

              create 00:01:13,       use 00:00:50,  flags:  extended

Here is an explanation of the additional fields in this command:

• create- How long ago the entry was created (in hours:minutes:seconds).
• use- How long ago the entry was last used (in hours:minutes:seconds).
• flags- Indicates the type of translation. Possible flags are

  - extended- Extended translation

  - static- Static translation

  - destination- Rotary translation

  - outside- Outside translation

  - timing out- Translation is no longer used due to a TCP FIN or RST

In general, the following is the terminology used in the show commands to display various addresses:

• Inside local address- The IP address that is assigned to a host on the inside network. The address is probably not a legitimate IP address assigned by the Network Information Center (NIC) or service provider. This is typically an RFC 1918 address.
• Inside global address- A legitimate IP address (assigned by the NIC or service provider) that represents (after translation) one or more inside local IP addresses to the outside world.
• Outside local address- The IP address of an outside host as it appears to the inside network. Not necessarily a legitimate address, it can be allocated from address space routable on the inside.
• Outside global address- The IP address assigned to a host on the outside network by the host's owner. The address was allocated from a globally routable address or network space.

show ip nat statistics is another useful command that gives the administrator information about NAT statistics. 

Sample Output for the show ip nat statistics Command

Router#show ip nat statistics



Total translations: 2 (0 static, 2 dynamic; 0 extended)

Outside interfaces: Serial0

Inside interfaces: Ethernet1

Hits: 135  Misses: 5

Expired translations: 2

Dynamic mappings:

-- Inside Source

access-list 1 pool net-208 refcount 2

 pool net-208: netmask 255.255.255.240

        start 171.69.233.208 end 171.69.233.221

        type generic, total addresses 14, allocated 2 (14%), misses 0

To summarize, the two relevant NAT show commands are

• show ip nat translations or show ip nat translations verbose
• show ip nat statistics
  
  

NAT: Debugs

NAT Debugs

The most useful command that can be used to troubleshoot NAT is

debug ip packet [access-list | detail]

This debug command essentially shows all the packets that hit the access list for which this command is used. With a properly configured access list, it is often very easy to figure out what is happening to packets as they get routed through the router and where they are headed.

Another useful NAT debugging command is

debug ip nat

This command shows the translations being created on the router as well as packets that are being translated using the NAT translations.

So the two most important NAT debugs are

debug ip packet [access-list | detail]

debug ip nat [access-list | detail]

Example.

Configuration

interface Ethernet0

ip address 10.10.3.4 255.255.255.0

ip nat inside

interface Ethernet1

ip address 172.16.4.4 255.255.255.0

ip nat outside

ip nat pool letmeout 200.200.200.1 200.200.200.4 pre 24

ip nat inside source list 7 pool letmeout

ip route 172.16.6.0 255.255.255.0 172.16.4.6

access-list 7 permit 10.10.3.0 0.0.0.255

Debug Commands

# debug ip packet

# debug ip nat

Debug Outputs

The output shown below is from turning on the debug commands listed earlier.

IP: NAT enab = 1 trans = 0 flags = 80

The NAT debug output below shows a translation for 10.10.3.3 to 200.200.200.1

taking place for the traffic headed for the outside local/global address

172.16.6.6. The traffic as can be seen from the IP debugs is ICMPs.

NAT: s=10.10.3.3->200.200.200.1, d=172.16.6.6 [30]

IP: s=200.200.200.1 (Ethernet0), d=172.16.6.6 (Ethernet1), g=172.16.4.6, len 100, 

  forward ICMP type=8, code=0

IOS NAT: Order of Operations

Understand NAT Order of Operations in IOS
Inside to Outside

1. If IPsec, check input access list
2. Decryption for CET (Cisco Encryption Technology) or IPsec
3. Check input access list
4. Check input rate limits
5. Input accounting
6. Inspect
7. Policy routing
8. Routing
9. Redirect to web cache
10. NAT inside to outside (local-to-global translation)
11. Crypto (check map and mark for encryption)
12. Check output access list
13. Inspect
14. TCP intercept
15. Encryption

Outside to Inside

1. If IPsec, check input access list
2. Decryption for CET or IPsec
3. Check input access list
4. Check input rate limits
5. Input accounting
6. Inspect
7. NAT outside to inside (global-to-local translation)
8. Policy routing
9. Routing
10. Redirect to web cache
11. Crypto (check map and mark for encryption)
12. Check output access list
13. Inspect
14. TCP intercept
15. Encryption

Notice the reverse of routing and natting depending on the flow of the traffic

PIM and IGMP

Multicast data, say for audio or video streams, has unicast source IP's and destination IP's in the range 224.0.0.0/4. The data payload is currently always UDP. Local multicast routing decisions are based on IGMP (protocol 2) and PIM (protocol 103).

Clients send IGMP join messages to an upstream device with TTL 1, which processes them, adds the multicast destination IP to its list of subscribed groups, and emits in turn a new IGMP message toward it's own upstream device. On a LAN, ethernet packets will use special multicast destination addresses which repeat a chunk of the multicast group IP.

Within an autonomous system, PIM (protocol independent routing, sparse mode) has a centralized RP (rendezvous point) which keeps track of where multicast senders are for joined group clients. Between autonomous systems, multicast routes are advertised using some other protocol, typically extensions to BGP. Eventually the chain of join messages reaches the multicast source, which starts sending traffic back down the chain toward the client.

IGMP messages stop as soon as you run into a PIM enabled router. From there the PIM router sends join messages towards the RP or source and a distribution tree gets built. IGMP only goes beyond one hop when IGMP forwarding/proxying is enabled (which is described later). Some consumer level Linksys routers also employ an IGMP proxy to allow multicast traffic to penetrate within a local NAT, when configured to do so.

Each intermediate router, firewall, or other device has to keep track of which interfaces have multicast clients on them and send subscribed group traffic to only those interfaces. When a client is done, it sends an IGMP leave message upstream, and the traffic stops. If a client simply vanishes, the upstream device is periodically doing IGMP queries to see what groups are active on a particular interface/LAN. Each active client has to respond with an IGMP group membership report packet. Any groups which don't get responses get pruned by the querying device, and the traffic eventually stops.

The RFC's for multicast and the group assignments by IANA are a bit of a mess; they have mutated a lot over the years, and continue to do so. For example, so far IGMP version 3 exists only in draft form; it hasn't been converted to standards track yet, much less ratified by the IETF. Multicast address assignments are also a bit of a mess. Some particularly important group ranges are:

• 224.0.0.0/8 is globally routable and directly assigned by IANA. 
• 224.0.0.0/24 is reserved for local LAN stuff. 
• 233.0.0.0/8 is the "GLOP" range, where autonomous systems with 16- bit AS's can emit 233.X.Y.0/24 and be globally accessible (clients send joins toward the AS, inside the AS the actual sources register with their PIM RP). Most remote sources you run across will be in this range, because all other globally routable multicast groups have to go to the formality of a specific assignment by IANA. Each 16-bit AS gets its own /24.
• 239.0.0.0/24 is for administratively scoped multicast within an autonomous system (routing domain). Most local sources you run across will be in this range, e.g. our DATN channels.