Lead Image © studiom1, 123RF.com

Lead Image © studiom1, 123RF.com

Transparent SIP communication with NAT

Number, Please

Article from ADMIN 55/2020
We show you how to secure transparent IP address transitions through NAT firewalls and gateways for Voice over IP.

Mapping internal IP addresses to external IP addresses is essential for Voice over IP (VoIP) communications through network address translation (NAT) gateways and firewalls. Session Initiation Protocol (SIP) is the signaling protocol for establishing VoIP connections; however, SIP-based communications have problems working through firewalls and session border controllers, and all too often, VoIP calls or some unified communications functions fail because of NAT. In this article, I show you how IT managers can resolve these issues with the session traversal utilities for NAT (STUN), traversal using relays around NAT (TURN), and Interactive Connectivity Establishment (ICE) techniques to ensure transparent transitions and improve overall SIP security.

NAT Characteristics

Some years ago, the limited availability of IP addresses led to the development of various strategies by the Internet Engineering Task Force (IETF) for covering a wide environment with the available addresses. One of the intermediate solutions, called NAT (RFC 3022) [1] or PAT (port and address translation), uses conversion between private and public IP addresses.

NAT uses tables to assign the IP addresses of a private (internal) network to public IP addresses (Figure 1). The internal IP addresses remain hidden. NAT services exchange the sender and receiver IP addresses in the IP header. The simplest form of address conversion is known as static NAT. Address translation converts a private IP address sent from a private address space into a public IP address to be received in a public address space. In the reply packet, this conversion takes place in reverse order.

Figure 1: NAT links the internal network with the Internet through the translation of IP addresses.

The types of NAT systems include:

  • Full cone NAT: IP address conversion takes place independently of a previous outbound connection on the basis of fixed address entries. Every user of the external network can send their packets to the public IP port. The packets are automatically forwarded from the NAT system to the computer with the corresponding address.
  • Restricted cone: Address mapping is only performed if it was triggered by an outgoing connection. If an internal computer sends its packets to an external computer, the NAT system uses mapping to translate the client address. The external computer can then send its packets directly back to the internal client (via address mapping). However, the NAT system blocks all incoming packets from other senders.
  • Port-restricted cone: Similar to restricted cone NAT, address mapping only takes place if it was triggered by an outgoing connection (identified by the IP and port address).
  • Symmetric cone: Fundamentally different from the NAT mechanisms described so far, mapping from the internal to the public IP port address depends on the target IP address of the packet to be transmitted. For example, if a client with the address pair is transmitting to external computer B, address mapping is performed to the external address pair If the same client sends its packets from the same port ( to a different destination address (computer A), it is mapped to the address The external hosts (A and B) can only send their packets to the respective NAT mapping address. Any attempt by an external machine to send the packets to another address mapping will result in the packets being dropped.

PAT Mechanisms

The PAT mechanism maps all IP addresses of a private network to a single public IP address (Figure 2). In this way, a completely private network only needs a single registered public IP address. Some manufacturers also refer to the PAT function as "hidden NAT." In practice, if two internal computers share an external IP address on the basis of the private IP addresses, an address conflict inevitably occurs. If both internal computers communicate simultaneously with external communication partners, the NAT component must decide to which internal computer the received packet will be forwarded. Because the routing or forwarding decision is based only on the IP addresses integrated into the IP header, this problem cannot be solved.

Figure 2: PAT translates all internal IP addresses into just one public IP address.

As with dynamic address mapping, the NAT component only has to create a corresponding mapping table during the connection setup and, with that, is able to assign the individual connections to the correct IP addresses. The NAT process simply searches the mapping table for the connection to which the packet belongs. If there is a match, the address is converted and forwarded to the right IP address on the internal network – theoretically.

In practice, however, this process is far more complicated. For example, two internal machines communicate with a common external IP address and both transmit a DNS request to the DNS server operated by the ISP for the company in question. The DNS server operated by the ISP resides on the external network from the point of view of the DNS clients, which means that all DNS queries always pass through the NAT process and address conversion always takes place.

The DNS clients transmit their DNS requests to the DNS server on the public network. The packets transmitted to the public IP network thus contain the following IP/TCP/UDP information: the same IP source address, the same IP destination address, and the same destination port number (UDP port 53 for DNS queries). Only the source port numbers differ in the DNS queries, and it is exactly this information that is used to identify the internal connections.

Most operating systems start the assignment of the sender ports with the value 1025 and then assign the source port numbers sequentially to the individual connections. Under certain circumstances, both IP transmitters can use the same source port numbers for communication with the DNS server. In this case, a conflict is unavoidable. To avoid this statistical possibility of a perfect address equation, the PAT process not only converts the IP addresses but also the port numbers, ensuring that the internal IP components always use an individual port number to communicate with the external IP resources.

SIP Log Problems

SIP, according to RFC 3261 [2], is today's standard signaling mechanism for real-time communication streams in an IP environment. However, SIP-based communication also has a flaw: A terminal device on the LAN cannot communicate directly with a communication partner if one or more NAT functions (e.g., in firewalls) exist in the communication channel for security reasons.

When NAT converts IP addresses as described above, some protocols, including SIP, communicate the endpoint addresses when establishing a connection. If the addresses do not match, the terminals do not communicate. Several NAT traversal methods can now be used to eliminate this problem – but more about that later.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Supporting WebRTC in the enterprise
    WebRTC has the potential to bring high-quality, easily developed, and interoperable real-time voice, video, and data communication to all manner of applications in web browsers.
  • Spanning Tree Protocol
    Ethernet is so popular because it simply works and is inexpensive. However, the administration side looks a bit more complicated: For the network to run smoothly, the admin might need to make important decisions about the Spanning Tree protocol.
  • Understanding Layer 2 switch port security
    What happens when an intruder with a laptop parks at an empty cubicle and attaches to your local network? If you don't want to find out, it might be time to think about implementing some switch port security.
  • Software-defined networking in OpenStack with the Neutron module
    In classical network settings, software-defined networking (SDN) is a nice add-on, but in clouds, virtual networks are an essential part of the environment. OpenStack integrates SDN technology through the Neutron module.
  • Troubleshooting and analyzing VoIP networks
    A special VoIP analyzer lets you control the available bandwidth and quality of voice transmission by monitoring relevant network parameters.
comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=