Professional Documents
Culture Documents
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.
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.
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.
NATs do not modify Layer 4, Layer 5, Layer 6, and Layer 7 addresses embedded within the IP
payload.
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).
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.
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.
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.
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.
RTP/RTCP both use a dynamic port for the audio media ranging from 16384 to 32767 for all Cisco
products.
The following diagram illustrates the H.323 message type with an embedded IP addresss and port number.
The following diagram illustrates MGCP Message Type with the embedded IP address and port number used.
! Inform Cisco CallManager with the UDP to be used for RTP audio media.
{ StationMessageID 0x0002;
UINT32 rtpMediaPort; };
For example, lets take SIP at the VoIP signaling protocol below.
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).
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.
For example:
1. User A is able to call User B, since the firewall allows inside to outside sessions (by default).
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.
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.
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 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
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.
For H.323
H.245 (capability exchange) to a negotiation in the range of TCP ports 11000 through
65535.
For SIP
Either the UDP or TCP port for the signaling to port 5060.
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).
Note: This is because some CAs have the MG functionality built in them.
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.