Firewalls and NAT Interaction

Most corporate LANs or intranets connect to the public Internet through a firewall. A firewall is filtering software usually in a router or hub that is used to protect the LAN behind it from various kinds of attacks and unauthorized access. Firewalls are also increasingly being used in home network routers and wireless hubs and in PCs themselves. Sometimes they are used to prevent users behind the firewall accessing certain resources in the Internet. In the simplest deployment, a firewall can be thought of as a one-way gate: It allows outgoing packets from the intranet to the Internet, but blocks incoming packets from the Internet unless they are responses to queries. Only certain types of requests from the Internet will be allowed to pass through the firewall, such as HTTP requests to the corporate Web server, SMTP e-mail messages, or DNS queries to the authoritative DNS for the corporate domain. The firewall does this by keeping track of TCP connections opened and filtering ports.

Firewalls pose a particularly difficult challenge to SIP sessions. Because SIP can use TCP and a well-known port, configuring a firewall to pass SIP is not too difficult. This does not help the media path, however, which uses RTP over UDP on various ports and will be blocked by most firewalls. A firewall or a proxy that controls the firewall needs to understand SIP, be able to parse an INVITE request and 200 OK response, extract the IP addresses and port numbers from the SDP, and open up "pin holes" in the firewall to allow this traffic to pass. The hole can then be closed when a BYE is sent or a session timer expires. An alternative is an ALG-a B2BUA that is trusted by the firewall. The firewall then allows SIP and RTP traffic, which terminates on the ALG and blocks all other traffic. The authentication and security policies of allowing or denying SIP sessions are then controlled by the SIP ALG instead of in the firewall itself.

Network address translators (NATs) also cause serious problems for SIP. A NAT can be used to conserve IPv4 addresses, or can be used to hide the IP address and LAN structure behind the NAT. It is used on a router or firewall that provides the only connection of a LAN to the Internet, a so-called stub network. A NAT allows nonunique IP addresses to be used internally within the LAN. When a packet is sent from the LAN to the Internet, the NAT changes the nonglobally unique address (usually addresses in the range 10.x.x.x, 172.16.x.x - 172.29.x.x and 192.168.x.x) in the packet header to a globally unique address from a pool of available addresses. Addresses can also be statically assigned. This means that every node on the network does not have to have a globally unique IP address. Responses from the Internet are translated back to the nonunique address. A NAT, however, is not completely transparent to higher layers. For a signaling protocol such as SIP, a NAT can cause particular problems.

Because responses in SIP are routed using Via header fields, a device behind a NAT will stamp its nonroutable private IP address in its Via header field of messages that it originates. When the request is forwarded outside the intranet by the NAT, the UDP and IP packet headers will be rewritten with a temporarily assigned global Internet address. The NAT will keep track of the binding between the local address and the global address so that incoming packets can have the UDP and IP headers rewritten and routed correctly. However, IP addresses in a SIP message, such as Via and Contact header fields, or IP addresses in SDP message bodies will not be rewritten and will not be routable.

To partially solve the message routing problem, SIP has a mechanism for detecting if a NAT is present in a SIP message path. Each proxy or user agent that receives a request checks the received IP address with the address in the Via header field. If the addresses are different, there is a NAT between them. The unroutable Via header field is fixed with a received tag containing the actual global IP address. Outside the NAT, the response is routed using the received IP address. Inside the NAT, the Via address is used. This does solve the message response routing problem (except when the port number is also wrong), but not the media problems.

Another problem with NATs is the time span of the NAT address binding. For a TCP connection, this is not an issue-the binding is maintained as long as the connection is open. For a UDP SIP session, the time period is determined by the application. If a binding were removed before a BYE was sent terminating the session, the connection would effectively be closed and future signaling impossible. A keep-alive mechanism may be needed to refresh this binding.

A SIP ALG coresident with the NAT solves many of these problems. The ALG would rewrite the media IP addresses in the SIP messages and would not allow the NAT to remove the address binding until a BYE was sent or a session timer had expired. However, NATs are often deployed deep inside a service provider's network that is not associated with providing SIP service, and hence has no incentive to upgrading the NATs to allow this service to work.

Even without ALGs or upgrades in NATs, it is possible to use SIP to establish a media session through many types of NATs. The protocols described in the next section allow a SIP client to discover the presence and type of NATs between it and the public Internet, learn its public IP address, and possibly fix the incorrect addresses in the SIP and SDP messages.