The NAT and Firewall Traversal Problem for VoIP
(from voip.com.vn)
The NAT and Firewall Traversal Problem
for VoIP
Figure 1 illustrates the NAT and firewall traversal problem for VoIP. Home users connect to the Internet using broadband routers from various vendors, such as Belkin, D-Link, LinkSys and NetGear. Users connect using wireless hotspots at Internet cafes or hotels, which also use routers from vendors, such as NetGear and SonicWall. Also, business users connect to the Internet using firewall products such as Cisco PIX, Juniper NetScreen, and CheckPoint FW1. Businesses sometimes also set up web-proxies such as Squid or Microsoft ISA for accessing the Web by their employees. Now suppose all the users behind all of these NAT and firewall devices/solutions want to make VoIP calls between each other. Will all of these calls work using traditional VoIP technologies? The answer is no. Most VoIP calls will not work through these NATs and firewalls. This is referred to as the NAT and firewall traversal problem - or simply the NAT traversal problem.
Figure 1: Broadband users connect to Internet using a plethora of NATs and firewalls. For widespread adoption, VoIP calls needs to work through them seamlessly.
Recently, there have been a lot of mobile phone products with Wi-Fi VoIP features (single-mode Wi-Fi or dual mode cellular plus Wi-Fi). According to Infonetics Research, the number of Wi-Fi phones would double or triple each year until 2009 reaching a worldwide market of $3.7 billion [12]. Now suppose a lot of users have these Wi-Fi phones, and they move around with these phones to use them from wherever they are - at homes, Internet cafes and offices. They will not only face the same NAT traversal problem, but worse, their connections and their network configurations, may change frequently. This further emphasizes the NAT traversal problem as it will severely limit users capability to communicate.
The NAT/Firewall Traversal Challenge
Homes and businesses are increasingly installing intermediary devices between their computer and their Internet connections. These devices - usually a router - provide a number of capabilities, with the most common being that of a NAT and/or a firewall.
NAT traversal is complicated by many contributing factors:
NATs break VoIP protocols
The idea of a NAT is to allow several devices to share a single public IP address. Figure 2a shows how a router connects several computers using private IP addresses to the Internet using a single public IP address. The router allows the computers to access the public Internet by modifying each IP packet to and from these computers by using a two-way mapping between private IP addresses and transport ports to the router's public IP address and transport ports. The rewriting of addresses by the NAT is usually performed using a lookup table, where mappings between internal address/port pairs and external address/port pairs are stored.
This technique facilitates sharing a single public IP address among many computers that use private IP addresses. However, this technique imposes a few problems for VoIP calls. Figure 2b shows the problem when Carol makes a VoIP call using SIP from behind her NAT device. To establish the call, Carol needs to share the IP address and a UDP transport port where she will receive voice data. However when Carol uses the private IP address and local UDP port to receive voice for the SIP call, voice packets from the remote party connected to public Internet will never reach Carol because private IP addresses are not routable in the public Internet.
Another property of NATs is that the port mapping is kept only if there is traffic in both directions. For example, if Carol is in a call with Ellen, and for a while only Ellen talks (i.e. Carol does not send any packets to Ellen), then Carol's NAT may close the mapping, which effectively terminates the call.
Firewalls do not allow uninvited packets and close inactive connections
The main purpose of a firewall is to protect an internal network from unauthorized access by entities on external networks. Firewalls normally allow incoming traffic from external hosts only if the session was initiated from the internal network. Therefore, incoming calls, coming from un-trusted external sources, are filtered out by the firewall, and the application fails to establish connection between the end users. Firewalls are not only present in most routers, but are also available in most modern operating systems (e.g. Windows firewall in Windows XP).
Figure 2 shows the problem as described above. The firewall allows media from Ellen to reach Carol, because Carol initiated the call. However, the incoming call from Dave could not pass through the firewall, as no data packets were sent to Dave from Carol. Therefore, the call between Carol and Dave fails to establish. A firewall can, however, be configured in any number of ways, such as only allowing TCP traffic out to the public Internet and preventing the use of UDP.
Cascaded NATs
NAT configuration may be cascaded which adds one or more levels of complexity to the problem. In this scenario, one router is connected to the Internet using public IP addresses, and provides a private IP address to a second set of routers. Each of the second set of routers may itself provide separate private IP addresses to one or more hosts. For VoIP, the challenge is for any host connecting to any of these routers may call each other, or it may also call any other host in the public Internet (or behind yet another router in another location).
UPnP gateways expect application control
Sometimes residential routers expect application control using the UPnP protocol to access the Internet. If UPnP is enabled on a router, which is the default case for many Asian countries such as Japan and Korea, the VoIP application needs to speak the UPnP protocol with the device to enable sending/receiving of data to/from the Internet.
Enterprise firewalls block UDP and sometimes enforce web-proxies
Most businesses or enterprises use strong firewall rules where UDP is usually blocked. Thus all communications need to use TCP transport. In some cases only Internet communications that these businesses allow is browsing the Internet through some web-proxies (such as Squid or Microsoft ISA). In such environments, VoIP calls cannot use UDP, and therefore need to use TCP transport or HTTP-tunneling.
Figure 2: The NAT traversal challenge
While NATs/firewalls play a very important role in securing and enhancing the usability of an internal network, they impose a significant problem in setting up VoIP calls between end users. Application developers cannot make assumptions about how traffic can pass into or out of these private networks.
The NAT and Firewall Traversal Problem
for VoIP
Figure 1 illustrates the NAT and firewall traversal problem for VoIP. Home users connect to the Internet using broadband routers from various vendors, such as Belkin, D-Link, LinkSys and NetGear. Users connect using wireless hotspots at Internet cafes or hotels, which also use routers from vendors, such as NetGear and SonicWall. Also, business users connect to the Internet using firewall products such as Cisco PIX, Juniper NetScreen, and CheckPoint FW1. Businesses sometimes also set up web-proxies such as Squid or Microsoft ISA for accessing the Web by their employees. Now suppose all the users behind all of these NAT and firewall devices/solutions want to make VoIP calls between each other. Will all of these calls work using traditional VoIP technologies? The answer is no. Most VoIP calls will not work through these NATs and firewalls. This is referred to as the NAT and firewall traversal problem - or simply the NAT traversal problem.
Figure 1: Broadband users connect to Internet using a plethora of NATs and firewalls. For widespread adoption, VoIP calls needs to work through them seamlessly.
Recently, there have been a lot of mobile phone products with Wi-Fi VoIP features (single-mode Wi-Fi or dual mode cellular plus Wi-Fi). According to Infonetics Research, the number of Wi-Fi phones would double or triple each year until 2009 reaching a worldwide market of $3.7 billion [12]. Now suppose a lot of users have these Wi-Fi phones, and they move around with these phones to use them from wherever they are - at homes, Internet cafes and offices. They will not only face the same NAT traversal problem, but worse, their connections and their network configurations, may change frequently. This further emphasizes the NAT traversal problem as it will severely limit users capability to communicate.
The NAT/Firewall Traversal Challenge
Homes and businesses are increasingly installing intermediary devices between their computer and their Internet connections. These devices - usually a router - provide a number of capabilities, with the most common being that of a NAT and/or a firewall.
NAT traversal is complicated by many contributing factors:
NATs break VoIP protocols
The idea of a NAT is to allow several devices to share a single public IP address. Figure 2a shows how a router connects several computers using private IP addresses to the Internet using a single public IP address. The router allows the computers to access the public Internet by modifying each IP packet to and from these computers by using a two-way mapping between private IP addresses and transport ports to the router's public IP address and transport ports. The rewriting of addresses by the NAT is usually performed using a lookup table, where mappings between internal address/port pairs and external address/port pairs are stored.
This technique facilitates sharing a single public IP address among many computers that use private IP addresses. However, this technique imposes a few problems for VoIP calls. Figure 2b shows the problem when Carol makes a VoIP call using SIP from behind her NAT device. To establish the call, Carol needs to share the IP address and a UDP transport port where she will receive voice data. However when Carol uses the private IP address and local UDP port to receive voice for the SIP call, voice packets from the remote party connected to public Internet will never reach Carol because private IP addresses are not routable in the public Internet.
Another property of NATs is that the port mapping is kept only if there is traffic in both directions. For example, if Carol is in a call with Ellen, and for a while only Ellen talks (i.e. Carol does not send any packets to Ellen), then Carol's NAT may close the mapping, which effectively terminates the call.
Firewalls do not allow uninvited packets and close inactive connections
The main purpose of a firewall is to protect an internal network from unauthorized access by entities on external networks. Firewalls normally allow incoming traffic from external hosts only if the session was initiated from the internal network. Therefore, incoming calls, coming from un-trusted external sources, are filtered out by the firewall, and the application fails to establish connection between the end users. Firewalls are not only present in most routers, but are also available in most modern operating systems (e.g. Windows firewall in Windows XP).
Figure 2 shows the problem as described above. The firewall allows media from Ellen to reach Carol, because Carol initiated the call. However, the incoming call from Dave could not pass through the firewall, as no data packets were sent to Dave from Carol. Therefore, the call between Carol and Dave fails to establish. A firewall can, however, be configured in any number of ways, such as only allowing TCP traffic out to the public Internet and preventing the use of UDP.
Cascaded NATs
NAT configuration may be cascaded which adds one or more levels of complexity to the problem. In this scenario, one router is connected to the Internet using public IP addresses, and provides a private IP address to a second set of routers. Each of the second set of routers may itself provide separate private IP addresses to one or more hosts. For VoIP, the challenge is for any host connecting to any of these routers may call each other, or it may also call any other host in the public Internet (or behind yet another router in another location).
UPnP gateways expect application control
Sometimes residential routers expect application control using the UPnP protocol to access the Internet. If UPnP is enabled on a router, which is the default case for many Asian countries such as Japan and Korea, the VoIP application needs to speak the UPnP protocol with the device to enable sending/receiving of data to/from the Internet.
Enterprise firewalls block UDP and sometimes enforce web-proxies
Most businesses or enterprises use strong firewall rules where UDP is usually blocked. Thus all communications need to use TCP transport. In some cases only Internet communications that these businesses allow is browsing the Internet through some web-proxies (such as Squid or Microsoft ISA). In such environments, VoIP calls cannot use UDP, and therefore need to use TCP transport or HTTP-tunneling.
Figure 2: The NAT traversal challenge
While NATs/firewalls play a very important role in securing and enhancing the usability of an internal network, they impose a significant problem in setting up VoIP calls between end users. Application developers cannot make assumptions about how traffic can pass into or out of these private networks.
Leave a Reply Cancel Reply