PDF(668.1 KB) View with Adobe Reader on a variety of devices
ePub(607.0 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(608.4 KB) View on Kindle device or Kindle app on multiple devices
Updated:July 16, 2021
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes NAT (Network Address Translation) behavior in routers working as CUBE (Cisco Unified Border Element), CME or CUCME (Cisco Unified Cummunication Manager Express), Gateways and CUSP (Cisco Unified SIP Proxy).
Cisco recommends that you have knowledge of these topics:
SIP (Session Initiation Protocol)
Voice over IP (Internet Protocol)
The information in this document is based on
Any IOS version 12.4T and above.
Any CME version
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Network Address Translation is a commonly used technique to translate IP addresses on packets that flow between networks using different address spaces. The purpose of this document is not to review NAT. Rather, this document aims to provide a comprehensive review of NAT as it is used in Cisco’s VoIP networks. Furthermore, the scope is limited to components that make up the MS-Voice technology.
NAT basically replaces the IP address within packets with a different IP address
Enables multiple hosts in a private subnet to share (i.e. appear like) a single public IP address, to access the Internet.
Typically, NAT configurations change only the IP address of inside hosts
NAT is bidirectional- If A gets translated to B on the inside interface, B arriving at outside interface will get translated to A!
Note: It may help to think of NAT as an aid to route IP packets into and out of networks using private address space. In other words, NAT makes non-routable addresses routable
Figure 2 Shows the topology referenced in the illustrations that follow.
This glossary is fundamental to understand and describe NAT
Inside local address—The IP address assigned to a host on the inside network. Typically, the address is from a private address space.
Inside global address—A routable IP address assigned by the NIC or service provider that represents 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 is allocated from an address space routable on the inside.
Outside global address—The IP address assigned to a host on the outside network by the host owner. The address is allocated from a globally routable address or network space.
Note: Get comfortable with these terms. Any note or doc on NAT is sure to refer to them
This is the simplest form of NAT, where in each inside address is statically translated to an outside address (and vice versa).
The CLI to configuration for the above translation is as follows
In dynamic NAT, each inside host is mapped to an address from a pool of addresses.
Allocates an IP address from a pool of inside global addresses.
If a new packet arrives from yet another inside host, and it needs a NAT entry, but all the pooled IP addresses are in use, the router simply discards the packet.
Essentially, the pool of inside global addresses needs to be as large as the maximum number of concurrent hosts that need to use the Internet at the same time
The following CLI illustrates configuring dynamic NAT
NAT overload (PAT)
When the pool (of IP addresses) is smaller than the set of addresses that need to be translated, this feature comes in handy.
Several internal addresses NATed to only one or a few external addresses
PAT (Port Address Translation) uses unique source port numbers on the Inside Global IP address to distinguish between translations. Because the port number is encoded in 16 bits, the total number could theoretically be as high as 65,536 per IP address. PAT will attempt to preserve the original source port, if this source port is already allocated PAT will attempt to find the first available port number
NAT overload can use more than 65,000 ports, allowing it to scale well without needing many registered IP addresses—in many cases, needing only one outside global IP address.
Static translations with ports – Incoming packets addressed to a specific port (e.g. port 25, for SMTP server) sent to a specific server.
Support for route maps - Flexibility in configuring filters/ACLs
More flexible pool configurations- to allow discontinuous ranges of addresses.
Host number preservation - Translate the “network” part, retain the “host” part.
A pinhole in NAT parlance refers to the mapping between the <host IP, port> and <global address, global port> tuples. It allows the NAT device to use the destination port number (which would be the global port) of incoming messages to map the destination back to the host IP and port that originated the session. It is important to note that pinholes time out after a period of non-use and the public address is returned to the NAT pool.
NAT in VoIP
So, what are the issues and concerns with NAT in VoIP networks? Well, recall that NAT that we have discussed so far (losely referredto as basic NAT) only translates the IP address in the IP packet header and re-calculates the checksum, of course, but VoIP signaling carry addresses embedded in the body of the signaling messages. In other words, at Layer 5
Figure 5 illustrates the effect of leaving the embedded IP addresses un-translated. The call signaling completes successful, but the SIP proxy at the service provider fails trying to route media (RTP) packets to media address sent by the call agent!
Another example would be SIP endpoint’s use of Contact: field in SDP to communicate the address at which the endpoint would like to receive signaling messages for new requests.
These issues are addressed by a feature called Application Layer Gateway (ALG).
An ALG understands the protocol used by the specific applications that it supports (e.g. SIP) and does protocol packet-inspection and “fixup” of traffic through it. For a good description of how the various fields are fixed-up for SIP call signaling, refer to http://www.voip-info.org/wiki/view/Routers+SIP+ALG.
Caution: Beware! There is no RFC or other standard that spells out which embedded fields should be translated for the various VoIP protocols. As a result, implementations vary, among equipment vendors, resulting in interop issues (and TAC cases).
Since gateways, by definition, are not ip-to-ip devices, NAT is not applicable.
This section of the document review call scenarios with CME to understand why NAT must be used.
Scenario 1. Local phones
Scenario 2. Remote phones (with public IP addresses)
Scenario 3. Remote teleworker
Note: In all cases, for audio to flow, the CME IP address needs to be routable
In this scenario (Figure 6), the two phones involved in the call are skinny phones with private IP addresses.
Note: Remember that skinny phone that is connected in a call with another skinny phone in the same CME system sends its media packets directly to the other phone; i.e. RTP for local-phone to local-phone does NOT flow through CME.
Therefore, NAT is not applicable or required in this case.
Note: CME determines if media (RTP) should directly or not based on whether the two phones involved in a call are both skinny and in the same network segment. Otherwise, CME inserts itself in the RTP path.
Local to remote
In this scenario (Figure 7), CME inserts itself into the RTP stream such that RTP from the phones will be terminated on the CME. CME will re-originate the streams towards the other phone. Since CME sits on both the inside (private) network and the outside network and sends its inside address to the inside phone and outside (public) address to the outside phone, NAT is not required here either.
Note however, that the UDP/TCP ports (signaling as well as RTP) must be open between remote IP phone and CME source IP address. This means that the firewalls or other filtering devices are configured to allow the ports in question.
Note: Note that signaling [messages] are always terminated on CM
This refers to IP phones connecting to CME over a WAN to support teleworkers who have offices that are remote from the CME router. The most common designs are those involving phones with routable IP addresses and phones with private IP addresses.
Remote phones with public (read: routable) IP addresses
If both the phones involved in the call are configured with public, routable IP addresses, media can flow between the phones directly Figure 8). Therefore, once again, no need for NAT!
Remote phones with private IP address
In this scenario, the call is signaled between skinny phones configured with private IP addresses. The home office (SOHO) routers, in general, tend to not be“SCCP aware”. i.e. incapable of translating the IP addresses embedded in the SCCP messages. This means that, upon call set up completion, the phones end up with each other’s private IP address. Since both the phones are private, CME will signal the call between them such that the audio flows directly between the phones. This however, will result in one-way or no-way audio (since private IP addresses, by definition, cannot be routed to on the Internet!), unless one of the following workarounds is implemented-
· Configure static routes on the SOHO routers
· establish an IPsec VPN connection to the phones
A better way to resolve this would be to configure “mtp”. The mtp command ensures that media (RTP) packets from remote phones transit through the CME router (Figure 9).
The “mtp” solution is better because of complications with opening up firewall ports. The media packets flowing over a WAN may be obstructed by a firewall. This means that you need to open ports on the firewall, but which ones? With CME relaying the audio, firewalls can be easily configured to pass the RTP packets. CME router uses a specific UDP port(2000!) for media packets. So, by just allowing packets to and from port 2000, ALL RTP traffic can be passed.
Figure 10 illustrates how to configure mtp.
All is not wonderful with mtp. There are situations where mtp may not be desirable
MTP is not gentle on CPU utilization
Multicast MOH generally cannot be forwarded over a WAN- The Multicast MOH feature checks to see if MTP is enabled for a phone and if it is, does not send MOH to that phoneL.
Thus, if you have a WAN configuration that can forward multicast packets and you can allow RTP packets through your firewall, you can decide not to use MTP.
Remote SIP phones
Note that SIP phones were not mentioned in the above scenarios. This is because of the fact that if one of the phones is a SIP phone, CME inserts itself into the audio path. This then becomes the local-to-remote scenario described earlier, wherein NAT is not required.
The CUBE inherently performs NAT and PAT functions as it terminates and re-originates all sessions. The CUBE substitutes its own address for the address of any endpoint it communicates with, thus effectively hiding (translating) the address of that endpoint.
Thus, NAT is not required with the CUBE function. There is a VoIP service scenario in which NAT is required on the CUBE, as described in the next section.
Hosted NAT Traversal
A brief background on Hosted telephony service will help understand the rationale for this feature.
Hosted telephony service is a new form of VoIP service in which most of the gear reside at the service provider’s location. They work with the home gateways (HGW), which implement only basic NAT (i.e. NAT at L3/L4). E.g. Verizon installs the Optical Network Terminal (ONT), which provides FiOS services in the home; voice call is signaled using a SIP process built into the ONT. The SIP signaling is made over Verizon's private IP-network to new soft switches, which provide the service and control to establish voice communications to other FiOS Digital Voice customers, or to traditional phone customers.
Among the key provider requirements for the hosted telephony service include,
Remote NAT traversal: the ability to deliver Class 5 services to endpoints utilizing NAT (which can only do NAT layer 3!) and firewall devices (by doing "ALG" remotely!)
Co-media support: the ability to send media between co-located devices where it does not make sense to route the media back to the IP network
No added equipment, eliminating the need to add any CPE.
Given the above, what options exist to implement such a service ?
Replace the HGW with an expensive ALG,
Use a session border controller (SBC) to modify the embedded SIP headers for packets. This involves a network-hosted, carrier-grade product supporting SIP in a very secure, fault-tolerant configuration. This solution is referred to NAT SBC.
The NAT SBC option satisfies the provider requirements listed above.
The NAT SBC works as follows (Figure 11)
Access Router translates only the L3/L4 IP Address
IP Address in the SIP message not translated
SBC NAT intercepts and translates the embedded IP Address. The moment the SBC sees SIP packets destined to 220.127.116.11, it kicks in the nat-sbc code.
Media is not translated and goes directly between the phones
The IP address 18.104.22.168 (Figure 12) is not assigned to any interface on the NAT SBC. It is configured as the address of the “proxy” to which SIP Phone A and SIP Phone B send signaling messages.
Home devices do not translate certain SIP/SDP address-only fields (e.g. Call-Id: ,O= , Warning: headers & branch= parameter. maddr= and received= parameters were handled in certain scenarios only.). These fields are handled by the NAT SBC, except for the proxy-authorization and authorization translation, because these will break the authentication.
If the home devices are configured to do PAT, the user agents (phones and proxy) must support symmetric signaling and symmetric and early media. You must configure the override port on the NAT SBC router.
In the absence of support for symmetric signaling and symmetric and early media, the intermediate routers must be configured without PAT and the override address should be configured in the NAT SBC.
Sample configuration for a typical NAT SBC follows.
ip nat pool sbc1 22.214.171.124 126.96.36.199 netmask 255.255.0.0
ip nat pool sbc2 188.8.131.52 184.108.40.206 netmask 255.255.0.0
ip nat pool call-id-pool 220.127.116.11 18.104.22.168 netmask 255.255.0.0
ip nat pool outside-pool 22.214.171.124 126.96.36.199 netmask 255.255.255.0
ip nat inside source list 1 pool sbc1 overload
ip nat inside source list 2 pool sbc2
ip nat outside source list 3 pool outside-pool add-route
ip nat inside source list 4 pool call-id-pool
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 1 permit 188.8.131.52 0.0.0.255
access-list 2 permit 184.108.40.206 0.0.0.255
access-list 2 permit 220.127.116.11 0.0.0.255
access-list 3 permit 18.104.22.168 0.0.255.255
access-list 3 permit 22.214.171.124 0.0.255.255
access-list 4 permit 10.1.0.0 0.0.255.255
access-list 4 permit 126.96.36.199 0.0.255.255
Call Flow with SBC NAT
Figure 13 and Figure 14 illustrate the call flow in terms of the translations. The following points should be noted-
Upon registration, the soft switch notes down the two phones as
-- SIP Phone A – 188.8.131.52 2001
-- SIP Phone B – 184.108.40.206 2002
In this call flow, SBC NAT effectively leaves the media IP address un-translated.
In earlier versions (of SBC NAT), SIP endpoints had to send keep-alive packets to keep the SIP Registration pinhole open (to allow out->in traffic to flow, e.g. inbound calls). keep-alive packets could be any SIP packet sent by the endpoint or the registrar (soft switch). Recent versions obviate the need for this, with the NAT-SBC itself (as opposed to soft switches) forcing the endpoints to re-Register frequently to keep the pinholes open.
Note: Symptoms of an expired registration pinhole can be obscure, with random call signaling failures.
CUSP has the notion of a logical network, which refers to a collection of local interfaces that are treated similarly for (e.g. interface, port, transport for listening) routing purposes. When configuring a logical network on CUSP, you can configure it to use NAT. Once configured, SIP ALG is automatically enabled. This is useful when certain logical networks.
An obvious symptom might be that a call fails in one or both directions. Less obvious symptoms might include,
One-way audio on transfer
Losing SIP registration
Show and debug commands
deb ip nat [sip | skinny]
show ip nat statistics
show ip nat translations
Things to check
Ensure that the configuration includes the ip nat inside or ip nat outside interface subcommand. These commands enable NAT on the interfaces, and the inside/outside designation is important.
For static NAT, ensure that the ip nat source static command lists the inside local address first and the inside global IP address second.
For dynamic NAT, ensure that the ACL configured to match packets sent by the inside host match that host’s packets, before any NAT translation has occurred. For example, if an inside local address of 10.1.1.1 should be translated to 220.127.116.11, ensure that the ACL matches source address 10.1.1.1, not 18.104.22.168.
For dynamic NAT without PAT, ensure that the pool has enough IP addresses. Symptoms of not having enough addresses include a growing value in the second misses counter in the show ip nat statistics command output, as well as seeing all the addresses in the range defined in the NAT pool in the list of dynamic translations.
For PAT, it is easy to forget to add the overload option on the ip nat inside source list command. Without it, NAT works, but PAT does not, often resulting in users’ packets not being translated and hosts not being able to get to the Internet.
Perhaps NAT has been configured correctly, but an ACL exists on one of the interfaces, discarding the packets. Note that IOS processes ACLs before NAT for packets entering an interface, and after translating the addresses for packets exiting an interface.
Don’t forget to configure “ip nat outside” on the interfacing facing the WAN (even if not translating outside address)!
As soon as NAT is configured, show ip nat translations doesn’t show anything. Ping once and then check again.
Grab wireshark Traces on inside and outside interfaces of the NAT-SBC
Debug output for a couple of scenarios are shown below. They are mostly self-explanatory!
Configuration and debug lines for basic NAT are shown below.
Output lines from debug ip nat sip are shown. In this case, embedded IP address on an outgoing packet is translated.