How does SIP get through a firewall or NAT?
sagitraz 16-June-2008 09:49:01 AM
Comments


TUN 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.

There are also various tunneling approaches, creating a tunnel through the firewall and then having an ALG 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.

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 Greenwich 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) to traverse a NAT or firewall.
Posted by gsmxprt


Posted: 30-June-2008 11:55:08 AM By: gsmxprt

TUN 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.

There are also various tunneling approaches, creating a tunnel through the firewall and then having an ALG 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.

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 Greenwich 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) to traverse a NAT or firewall.