When connecting a PC to the Internet, you do not want it to be accessible for everyone or vulnerable to attacks from hackers. That is especially important if you are constantly connected, for example via broadband or a fixed line. A firewall protects the PC by only allowing approved traffic and by rejecting attacks and illegal data packets.|
On a local-area network (LAN), where several PCs or other equipment is connected, it is common to have private IP addresses on the LAN and a single common public IP address to the Internet. That is called NAT (Network Address Translation) and is often an integrated part of the firewall.
Firewalls and NAT-routers are designed for data traffic that is initiated from the inside of the private network. If instead the data traffic is initiated from the outside, and even worse, must reach a specific user on the private network, serious problems occur.
This is exactly what is happening with person-to-person communication via SIP. Therefore, it is highly important that all new firewalls and NAT routers now being installed are designed to support SIP properly and
A Ticking Time Bomb?
Most firewalls installed today do not handle SIP in an adequate way. The problem occurs for all similar protocols
(e.g., H.323) where a person on a private LAN is to be contacted. Ordinary firewalls are simply not designed for such data
traffic. It is a common misunderstanding that well known firewalls can be configured to handle SIP
traffic, but that is not the case. One problem is that the media streams (e.g., voice and video packets) are transferred over dynamically assigned UDP ports that are generally
closed. Another problem is that the SIP clients inside the firewall cannot be reached by IP addresses since these most often are private and local to the LAN. It simply does not
work, unless there is specific SIP support in the firewall.
The same applies to routers that are changing the address space, NATs. NAT
routers are used when several users share a common Internet connection with a
single IP address. Most carriers or ISPs only offer private IP addresses to their customers.
Enabling NATs and Firewalls With SIP
It is of course a fundamental problem that person-to-person communication does not reach the users on the
LANs. Various methods and equipment have been suggested to solve this problem in a number of situations, but the most general one is to eliminate the problem where it occurs
- in the firewall
itself. Firewalls including a SIP server (with a SIP proxy and SIP registrar) that dynamically controls the firewall are currently
Intertex foresaw the future impact of SIP and these problems as early as in
1998 and started developing the current architecture of the Internet Gate line with this in mind. This led to the creation of a firewall and NAT with a
built-in SIP proxy and SIP registrar, the most general architecture for SIP
handling. The SIP proxy dynamically controls the firewall, opening and closing
ports as needed. The SIP registrar keeps track of all the users inside the
firewall and makes sure that the communication is directed to the correct device.
Even more remarkable is that the SIP registrar in the IX66 can be used as the
main SIP server for a company and can even be configured to handle registrations
from the outside, making it ideal for road warrior and telecommuters.
Furthermore, with the built-in proxy and registrar it is possible to handle
encrypted SIP signaling, a feature not accomplished by other architectures.
A number of firewall vendors are planning to introduce models including a SIP ALG
(Application Layer Gateway). These ALGs usually work at a lower level than a
proxy, adjusting the data packets âon-the-fly.â. A common limitation of the ALG architecture is that it cannot handle secure, encrypted SIP signaling via TLS (Transport Layer
Security). TLS is strongly recommended by Microsoft to be used with their Live
Communications Server SIP enterprise solution.
SIP capable firewalls are not more expensive than ordinary firewalls and should be considered for all new installations of firewalls and
NATs. If not, there is a high risk that even newly installed firewalls and NATs have to be exchanged in the near
Other methods proposed for SIP firewall and NAT traversal.
STUN is a method for getting SIP through existing NATs. It works through keeping holes open in the NAT by dummy traffic and having the SIP clients emulate their âlooksâ from the outside of the protected LAN. STUN will not work for all NATs and not for real secure
firewalls, and may have some scalability and security issues. The SIP client has to implement STUN and integrate it in the SIP stack to make it
work. STUN has been enhanced with TURN and now lately work is ongoing for a further addition refered to as ICE.
There are also various tunneling approaches, creating a tunnel through the firewall and then having an far ned NAT traversal solution in a central place at the âSIP operatorâ to cope with the separate address space of the private LANs and their individual
users. Special equipment is therefore required at the SIP operator and sometimes, special equipment and software are required on the LAN or in the SIP
clients. With this approach, the users get locked into a specific SIP operator. This approach can normally not handle complex
configurations, such as inter-working between an operator and the Microsoft Greenwich
architecture, where a local SIP server on the LAN is used. Most of these solutions are not completely scalable as a central node has to handle all SIP traffic, including the media streams.
For home users, Microsoft has suggested an extension to UPnP (Universal Plug and Play) to allow Windows to control the NAT or
firewall. Several small inexpensive NATs have implemented these UPnP extensions, and thus allow SIP traversal for Windows Messenger
(which is SIP based). However, it is not secure to allow every PC on the LAN to open the
firewall, so UPnP is not acceptable for a proper firewall that should protect the LAN (In the Live Communication Server architecture, even Microsoft recommends that UPnP be disabled for high security). Another limitation is of course that UPnP control from Windows clients will not help other SIP products
(e.g., SIP phones) traverse a NAT or firewall.
White Paper - The SIP Protocol and Firewall Traversal