You are on page 1of 17

Cisco VoIP Traversal of NAT and Firewall

Cisco VoIP Traversal of NAT and Firewall

Table of Contents
VoIP Traversal of NAT and Firewall................................................................................................................1
Introduction..............................................................................................................................................1
NAT and PAT..........................................................................................................................................1
NAT Limitations.........................................................................................................................3
Basic Firewall Information......................................................................................................................3
VoIP Protocols Protocol Stack and Signal Flow.....................................................................................4
Challenges for VoIP Traversal of NAT.................................................................................................10
Challenges for VoIP Traversal of Firewall............................................................................................11
Challenges for Encrypted VoIP Traversal of NAT/Firewall with ALG................................................12
Cisco Solutions......................................................................................................................................13
UDP/TCP Ports Used for VoIP.............................................................................................................14
Related Information...............................................................................................................................15

i
VoIP Traversal of NAT and Firewall

Introduction
NAT and PAT

NAT Limitations
Basic Firewall Information
VoIP Protocols Protocol Stack and Signal Flow
Challenges for VoIP Traversal of NAT
Challenges for VoIP Traversal of Firewall
Challenges for Encrypted VoIP Traversal of NAT/Firewall with ALG
Cisco Solutions UDP/TCP Ports Used for VoIP
Related Information

Introduction
This document provides a basic understanding of the challenges that VoIP has with firewall and/or Network
Address Translations (NATs) across all the protocols (H.323, Media Gateway Control Protocol (MGCP),
Session Initiation Protocol (SIP), Skinny Client Control Protocol (SCCP), RealTime Transport Protocol
(RTP) and RTP Control Protocol (RTCP)). It also provides different proposals for allowing VoIP to
transverse the NATs and/or firewalls. VoIP traffic can be classified into call signalling, call control, and
media communications. Depending on the VoIP protocols used, the communications between the two devices
may use either one channel or many different channels. The channels are Transmission Control Protocol
(TCP)/User Datagram Protocol (UDP) ports used for the connections between two network devices. Thus,
since all VoIP protocols are made up of dynamic signalling and IP address/port combinations and users are
expected to be able to make both inbound and outbound calls, this makes them all inherently nonNAT
friendly.

NAT and PAT


NAT (RFC1631) is a process used to turn one IP address into another IP address. It is commonly used by
organizations to translate unofficial or internal private IP addresses (RFC1918) to public (Internet) IP address.
Most organizations use private on their own internal network, but these are not routable in the public domain
(Internet) and they may also be in conflict with other private networks using the same range of IP addresses.

Devices with NAT enabled provide the ability to rewrite the IP addresses and port in the datagrams as they
pass in and out of the network. Depending on the configuration of the NAT feature, many internal devices can
effectively share a smaller set of public or registered Internet IP addresses. Both static and dynamic address
translations are supported by Cisco IOS NAT alone, or in conjunction with one another. Static address
translations are those in which an administrator explicitly maps an external address to an internal address.
This is a onetoone mapping of an unregistered IP address to a registered IP address. This is particularly
useful when a device needs to be accessible from outside the network such as a mail server, web server, DNS
server, and so on. Dynamic translations are those in which a pool is allocated and each new IP address to be
translated is dynamically mapped to another IP address from the pool in a roundrobin fashion. Static
translations are generally used to allow access to a particular device through the NAT. Please note that
addresses used in static translations must explicitly be omitted from the dynamic translation pool. An IP
packet traversing a NAT can have both its source and destination addresses translated.

Cisco VoIP Traversal of NAT and Firewall


Port Address Translation (PAT) is an extension of NAT. Another term commonly used to refer to PAT is
overload. It translates the IP address and TCP/UDP port associated with it to another IP address and ports.
This allows one or few external addresses to be used in the NAT process. It is a subset of the NAT
functionality used to map internal addresses to one or more external addresses using unique port numbers on
the outside IP address to distinguish between various translations. This allows up to 65,536 translations per
one external IP address due to the TCP/UDP port number being encoded with a 16bit field.

There are several different types of NAT functionality.

Full ConeIf a host behind a NAT sends a packet from address:port {A:B}, the NAT process will
translate the address:port {A:B} to {X:Y} and cause a binding of {A:B} to {X:Y}. Any incoming
packets (from any address) destined for {X:Y} will be translated to {A:B}.

Partial/Restricted ConeIf a host behind a NAT sends a packet from address:port {A:B}, the NAT
process will translate the address:port {A:B} to {X:Y} and cause a binding of {A:B} to {X:Y}. Any
incoming packets (from any address) destined for {X:Y} will be translated to {A:B}. However, once
that first packet comes inward, the bindings are turned into complete fourcomponents bindings. This
enforces only packets from that source to be accepted and NATed from now onward.

Symmetric ConeIf a host behind a NAT sends a packet from address:port {A:B} to {C:D}, the
NAT process will translate the source address:port {A:B} to {X:Y} and cause a binding of {A:B} to
{C:D} to {X:Y}. Only packets from {C:D} to {X:Y} are accepted in the reverse direction and these
will be NATed to {A:B}.

Please note A, C, and X are the IP address and B, D, and Y are the TCP/UDP port used. Also, the Cisco
NAT/PAT feature supports all these configuration and traffic types as illustratred in the diagram below.

For more information on NAT and PAT, please refer to the following documents.

How NAT Works


Product Bulletin Cisco IOS NAT
NAT Technical Assistance Center (TAC) Pages

Cisco VoIP Traversal of NAT and Firewall


NAT Limitations
VoIP presents a problem for NAT. The problem is that when IP phones or routers establish the VoIP call
signalling, call control, and media communications, the IP address and port number are embedded within the
data payload of the IP packets. This causes endtoend routing problems between the endpoints if the
embedded IP addresses are private IP addresses.

The following is a list of NAT limitations.

NATs work at Layer 3 (IP layer).

NATs modify the source/destination IP address.

NATs do not modify Layer 4, Layer 5, Layer 6, and Layer 7 addresses embedded within the IP
payload.

Many applications embed IP addresses at Layer 4 through Layer 7.

NAT breaks the endtoend model of IP for routability, encryption, and so on, due to the embedded
Layer 4 Layer 7 IP addresses.

This limitation of the NAT feature can be overcome with added intelligence to the software. Cisco IOS NAT
and PIX support a feature called Native Support or Fixup Protocol for various applications such as FTP,
HTTP, H.323, and Simple Mail Transfer Protocol (SMTP).

Basic Firewall Information


With the repaid growth of interest in the Internet, network security has become a major concern to companies
throughout the world. When you connect your private network to the Internet, you are physically connecting
your network to a huge amount of unknown networks and all of their users. While such connections open the
door to many useful applications and provide great opportunities for information sharing, most private
networks contain some information that should not be shared with outside users on the Internet.

A firewall provides a point of defense between two networks. It protects one network from the other. Usually,
a firewall protects the company's private network from the public or shared networks to which it is connected.
A firewall can be as simple as a router that filters packets or as complex as a multicomputer, multirouter
solution that combines packet filtering and applicationlevel proxy services. It basically enforces security
rules on the conversion of peertopeer communications. It evaluates each network packet against a network
security policy, which is a collection of security rules, conventions, and procedures governing
communications into and out of a network.

The list below outlines the basic concepts of a PIX firewall.

A firewall identifies networks as inside or outside.

By default, packets can get from the inside to the outside.

By default, packets from the outside that are associated with an inside originated connection are
allowed back in.

By default, packets originated from the outside are not allowed to the inside.

Cisco VoIP Traversal of NAT and Firewall


Many firewalls only work if all outside traffic originates from well known sockets.

The last two points are important considerations when working with VoIP. A VoIP caller must be able to
place inbound and outbound calls. Also, the voice RTP/UDP media traffic is asymmetric and used randomly
as UDP ports numbers (1638432767). All of these can usually be overridden on the firewall, assuming the
system administrator understands the security implications.

The diagram below illustrates the VoIP and firewall blocking RTP audio media stream.

In summary, listed below are some major points regarding VoIP and NAT/firewall.

Firewall and NAT natively work at Layer 3.

VoIP and other applications work at Layer 5 and above.

Cisco IOS firewall feature set and NAT and PIX have application functionality called Application
Layer GW (ALG) or Fixup Protocol which helps in resolving these issues.

The VoIP application is composed of a dynamic set of protocols.

SIP, MGCP, H.323, and SCCP for signaling.


SDP, H.225, and H.245 for capability exchange.
RTP/RTCP for control and audio media.

RTP/RTCP both use a dynamic port for the audio media ranging from 16384 to 32767 for all Cisco
products.

VoIP Protocols Protocol Stack and Signal Flow


The following diagram illustrates the H.323 protocol stack.

Cisco VoIP Traversal of NAT and Firewall


The diagram below illustrates H.323 Call Signaling Flows.

The following diagram illustrates the H.323 message type with an embedded IP addresss and port number.

Cisco VoIP Traversal of NAT and Firewall


The diagram below illustrates the SIP Protocol Stack.

The following diagram illustrates SIP signalling flow.

Cisco VoIP Traversal of NAT and Firewall


The diagram below illustrates a SIP message type with an embedded IP address and port number.

The following diagram illustrates an MGCP protocol stack.

Cisco VoIP Traversal of NAT and Firewall


The diagram below illustrates the MGCP and SS7 signal flow.

The following diagram illustrates MGCP Message Type with the embedded IP address and port number used.

Cisco VoIP Traversal of NAT and Firewall


The diagram below illustrates an SCCP call.

The following diagram illustrates SCCP call flow.

Cisco VoIP Traversal of NAT and Firewall


Below are some sample debugs for SCCP.

! Registration message from SCCP to Cisco CallManager.


{StationMessageID 0x0001;
StationIdentifier sid;
UINT32 stationIpAddr;
DeviceType deviceType; };

! Inform Cisco CallManager with the UDP to be used for RTP audio media.
{ StationMessageID 0x0002;
UINT32 rtpMediaPort; };

! This message is from the SCCP to Cisco CallManager.


{ StationMessageID messageID;
OpenReceiveChanStatus orcStatus;
UINT32 ipAddr;
UINT32 portNumber; };

Challenges for VoIP Traversal of NAT


Consider the following when looking at the diagram below:

NATs only look at Layer 3 addressing.


VoIP signaling protocols embed IP addresses at Layer 5.
RTP/RTCP works at Layer 5.

Cisco VoIP Traversal of NAT and Firewall


Problem: Traditional NATs do not NAT Layer 5 addresses. Therefore, the VoIP signaling and RTP/RTCP
become unreachable after NAT translation (oneway signaling and audio) due to the embedded IP address
and the port specified within the IP payload.

For example, lets take SIP at the VoIP signaling protocol below.

Note: All other VoIP protocols will have similar problems.

1. User A sends an invite to User B.

2. The NAT translates the Layer 3 address, but not the Layer 5 (SIP/Session Definition Protocol (SDP)
addresses.

3. User B receives the invite and responds back to the NAT address. The signaling gets completed (for
example, 200 OK).

4. User A sends RTP to User Bs SDP c= / m= address:port.

5. Problem: User B tries to send RTP to User As c= / m= address:port, but this fails since it cant route
to User A (the SDP address and port did not receive the NAT) to ONE WAY AUDIO.

6. If User A hangs up (because of OneWay Audio), the BYE will be sent to User B correctly.

7. Problem: If User B hangs up, the BYE wont get to User A because the header address did not
receive the NAT. This will leave the state of User A for that session to be up (hung) until User A
hangs up.

Notes:

VoIP devices on the Internet cannot make calls to private addresses (where to send them?)

VoIP devices on the Internet do not know the type of NAT being used (cone, symmetric, and
so on), so they dont know about any bindings to use.

VoIP devices on the Internet do not know if the bindings are still open.

Challenges for VoIP Traversal of Firewall


Consider the following when referring to the diagram below.

The firewall only looks at Layer 3 addresssing.


VoIP signaling protocols embed IP addresses at Layer 5.
RTP/RTCP works at Layer 5.
By default, firewalls do not allow outside to inside traffic.

Cisco VoIP Traversal of NAT and Firewall


Problem: Because of the default nature of the firewall not allowing outside traffic to transverse to the inside,
VoIP calls will fail. Furthermore, dynamic RTP/RTCP ports used by the endpoints are not automatically
opened and allowed without modification of the security policy.

For example:

1. User A is able to call User B, since the firewall allows inside to outside sessions (by default).

2. User B is able to respond back to User A at the VoIP signaling layer.

3. Problem: When User B tries to send from the outside to inside for RTP/RTCP traffic, it fails because
it is using a different socket (SA:Port, DA:Port, Protocol) than the VoIP signaling.

4. Problem If User B tries to initiate a call to User A, it fails because the firewall doesnt allow outside
to inside calls (by default).

5. Problem: If symmetric RTP is not used, the RTP fails to get back inside.

6. Problem: Firewall can allow outside to inside calls from a specific/range of outside addresses, but
this is an administrative challenge with H.323 because Cisco doesnt use GKRCS (potentially large
list of outside IP addresses). SIP could fix this by putting a Proxy on either side, or making the
firewall add RecordRoute and Via.

Challenges for Encrypted VoIP Traversal of NAT/Firewall


with ALG
With the ALG or fixup protocol enabled, the firewall/NAT will have the ability to look into the Layer
4Layer 7 information within the IP payload and make all the necessary changes to the embedded IP address
and port used. This will solve most of the problems associated with VoIP and NAT/firewall. However, if there
is encryption involved, such as IPSes or Transport Layer Security (TLS), and the media and/or signaling is
encrypted, then the ALG feature will not be able to look into the Layer 4Layer 7 information and will not be
able to perform the necessary changes to the embedded IP address and port. This, in essence, will behave as if
no ALG was enabled and VoIP will not work.

Cisco VoIP Traversal of NAT and Firewall


Cisco Solutions
Below is a summary matrix for the PIX firewall, IOS firewall feature set, and IOS NAT.

PIX Firewall (with VoIP ALG or fixup protocol)

Version 5.2: Supports H.323 version 2, Registration and Status ](RAS), and NAT (no
PAT).
Version 6.0 and 6.1: Added SIP with NAT (no PAT), SCCP with NAT (no PAT), and
no MGCP support.
Version 6.2: PAT support for H.323 version 2 and SIP.

For IOS Firewall (with VoIP ALG or fixup protocol)

H.323 version 2 support with Cisco IOS Software Release 12.1(5)T.


No SIP or MGCP yet.

For IOS NAT (with VoIP ALG or fixup protocol)

H.323 version 2: Cisco IOS Software Release 12.1(5)T (without RAS) and Cisco IOS
Software Release 12.2(2)T (with RAS).
SIP: NAT and PAT available in the near future.
Skinny: Available after Cisco IOS Software Release 12.1(5)T.
MGCP: No support yet.

Other methods to used for VoIP to transverse NAT and firewall are:

The VoIP device must know the public IP address (or DNS name) of the NAT.

The NAT must be configured not to use dynamic bindings.

The NAT must be configured to statically map the public sockets to the private sockets.

The VoIP device will NAT its Layer 5 SIP/SDP addresses to look like they are on the public address
side.

Used the h323gateway voip bind srcaddr x.x.x.x command to bind the source IP address for the

Cisco VoIP Traversal of NAT and Firewall


signaling and media traffic. This allows the downstream firewall to know where the source signaling
is coming from so it can setup the trust associations or policy for the VoIP traversal through the
firewall. Furthermore, this forces the signaling and media traffic source IP address to be defined
specifically and doesnt allow the router to randomly choose an IP address from one of its interfaces.

With Cisco IOS Software Release 12.2(2)XB, there is support for SIP bind addresses with the bind
all sourceinterface y.y.y.y command.

For more information on configuring NAT, refer to Configuring Network Address Translation: Getting
Started.

Note: The disadvantage to these methods is that they require a sysadmin to configure and manage the VoIP
devices and any changes to the public address.

UDP/TCP Ports Used for VoIP


Below are the UDP/TCP ports used for VoIP for H.323, SIP, and MGCP.

For H.323

Unicast GK Discovery to UDP port 1718.

Multicast GK discovery to 224.0.1.41 UDP port 1718.

RAS to UDP port 1719.

H.225 (call signaling for hosts) to TCP port 1720.

H.245 (capability exchange) to a negotiation in the range of TCP ports 11000 through
65535.

RTP audio stream to UDP ports 16384 through 32767.

For SIP

Either the UDP or TCP port for the signaling to port 5060.

RTP audio stream to UDP port 16384 through 32767.

User agent may register with a local server on the startup by sending out a
REGISTER request to IP address 224.0.1.175 (all SIP servers multicast address
sip.mcast.net).

For MGCP version 0.1

MG and CA signaling to UDP port 2427.

RTP audio stream to UDP port 16384 through 32767.

For MGCP version 1.0

Cisco VoIP Traversal of NAT and Firewall


MG and CA signaling to MG through UDP port 2427 and CA through UDP port
2727.

Note: This is because some CAs have the MG functionality built in them.

RTP audio stream to UDP port 16384 through 32767.

Note: RTP port selection is MG specific. Depending on the number of voice ports on
the MG, the RTP port range is selected. It won't go as high as 32767 and the range
can be as small as 256.

Related Information
Voice, Telephony and Messaging Technologies
Voice, Telephony and Messaging Devices
Voice, Telephony and Messaging Software
Technical Assistance Center
Voice, Telephony and Messaging Tac eLearning Solutions

All contents are Copyright 19922002 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.

Updated: Oct 18, 2002 Document ID: 19148

Cisco VoIP Traversal of NAT and Firewall

You might also like