Section 13.7. Firewall Issues

13.7. Firewall Issues

In most networks, a firewall provides an access gateway to network resources that need to be restricted and secured. The primary method firewalls use to secure a resource is limiting network traffic to and from the resource by port number, by protocol, or by network address.

Another key use of firewalls is network address translation (NAT), which provides an exchange point for data transmitted between privately and publicly addressed IP networks. NAT keeps track of outbound sockets (those from users on the private network to the Internet) and performs the necessary packet translation as each packet traverses the firewall. This way, hosts with private addresses can access the services of hosts with public addresses, like World Wide Web servers. A side effect of NAT is that protocols that must use both outbound and inward sockets (like SIP and H.323) simply don't work.

Since firewalls are a reality of doing business on IP networks, they aren't going to be cast aside merely for the sake of SIP compatibility. As a result, they're an important topological consideration when locating VoIP resources on your network. Figure 13-4 illustrates some firewall scenarios you may encounter with VoIP.

We'll illustrate the twofold problem posed by NAT using SIP as a context. Typically, when SIP requests are sent from a privately addressed client to a publicly addressed VoIP server, their headers contain the private address of the SIP client device. If this address is being NAT-translated to some other address, the VoIP server will send its response to the wrong address (the private one, not the NAT-translated one), and the operation will fail. If the client uses the NAT-translated address (which some clients can be statically configured to use), you would still have to program your NAT firewall to forward all inward SIP traffic (ports 5060 and 5061) to the private host running the SIP client. This way, the VoIP server's responses would reach the client. The effect of this is that you'd only be able to use one SIP client at a time. So, port-forwarding doesn't really solve the problem.

Figure 13-4. NAT firewall scenarios

The second aspect of the NAT problem is the RTP media channel, which, like the signaling conversation, is also bidirectional. Connectionless UDP packets are sent to the VoIP server from the client and from the VoIP server back to the NAT firewall that stands between the client and server. Simply port-forwarding RTP traffic is finefor a single client. But a more elegant solution is needed to support a group of SIP endpoints behind a common NAT firewall.

In order to get VoIP phone calls to work through NAT firewalls, both signaling transmissions and media streams must be able to flow in both directions, to multiple clients simultaneously . Also, the endpoints must signal the appropriate IP address during call setupan IP address bound to the NAT firewall, an address that's publicly routable.

Neither of these issues has been resolved within the confines of SIP, MGCP, SCCP, or H.323, although IAX2 has solved both of them because it requires just one socket for all communications on a single call. Unfortunately, since there isn't much commercial support for IAX yet, you'll most likely get stuck dealing with the NAT allergies of the other protocols. There are several ways to tackle NAT, either by eliminating it or by cooperating with it. Read on.

13.7.1. DMZ Eliminates the Need for NAT

In a setup like example A in Figure 13-4, your IP phones won't be able to receive signaling or audio from IP endpoints outside the firewall. An easy way to solve this problem is to place the softPBX on a DMZ, where it can still be firewalled, but without having to have traffic from the private network be translated via NAT.

Traffic from the private network to the Internet is still translated, of course, but since the softPBX is on the DMZ, it can act as a media proxy for VoIP phone calls between the private network and the Internet. The softPBX can communicate without NAT in the way. A DMZ such as this is illustrated in Chapter 10.

Placing your VoIP server on a DMZ solves the NAT problem for all signaling protocolsSIP, H.323, SCCP, and MGCP.

Using a DMZ requires that you have access to more than one IP address. You'd have to obtain, at a minimum, three public IP addresses from your ISPone for the softPBX, one for the DMZ interface on the firewall, and one for the Internet- facing interface on the firewall. If you are unable to get a block of IP addresses, then you'll have to consider another solution. But if you are able, placing VoIP server resources on a DMZ is the way to go.

Setup B in Figure 13-4 is what you may be considering if you plan to have some road warriors or Internet-based subscribers accessing voice services through a server on your private network. DMZ solves the NAT problem here, too.

But there may be situations in which the Internet-based phone must be behind a NAT firewall, and there's nothing the user can do about it. Setup C in Figure 13-4 illustrates this idea. Residential broadband routers have built-in NAT firewalls, and so do the firewalls at hotels and in some coffee shops and public access points. Since you're relying upon the policy of other organizations for your voice transport, you're at the mercy of what their infrastructure permitsor doesn't.

Fortunately, there are solutions to the NAT problem that don't involve DMZ.

13.7.2. IAX Eliminates the Need for NAT

The IAX2 protocol is a great alternative to SIP in telephony applications, as long as you require only endpoint signaling and trunking. That's because SIP implements a whole lot more than these two things. IAX2 is centered around these two roles, and it does them very well. So well, in fact, that IAX2 can traverse NAT firewalls without any special configurations. IAX2 uses a single UDP socket for all signaling and media, and is therefore NAT-proof. If you can, consider using IAX as an alternative to SIP where NAT is concerned .

13.7.3. STUN Allows Coexistence with NAT

Simple Traversal of UDP NAT (STUN) is a simple protocol that allows applications to discover the presence of NAT firewalls. It also tells these applications the public IP address(es) allocated to them by the NAT firewall. STUN requires no special configuration on the part of the NAT firewall. Consequently, STUN is easy to integrate into your existing network.

But STUN does require that the client application that uses NAT traversal be equipped with a STUN client. Adoption of STUN among many IP phone vendors has been slow, to say the least. Most commercial IP telephony platforms advocate placing a media proxy on the DMZ, while others suggest avoiding the Internet altogether as preferable to using STUN. But this advice is overblown. STUN works greatwhen it's there.

STUN is defined by RFC 3489. A free, open source implementation of the client and server is available from http://www.vovida.org/applications/downloads/stun. Vovida also operates two public STUN servers that you can use in small-scale applications and for your own STUN client development. Try configuring the X-Lite softphone to use Vovida's STUN servers, either 128.107.250.38 or 128.107.250.39, to place SIP phone calls through a NAT firewall.

13.7.4. VPN Allows Coexistence with NAT

There's another solution that can help you avoid VoIP-through-NAT, if you are the proprietor of both the VoIP server and the endpoints it supports. Virtual private networks allow VPN clients on the Internet to use the same IP network address as the VPN server. Therefore, if a VPN server and a VoIP server are on the same LAN, VPN clients connecting to that VoIP server from the Internet needn't be concerned with NAT. Of course, you have the normal headaches of a VPN, such as latency and the lack of QoS. But if your VPN is good enough, it saves you from the NAT problem.