SIP Links Configuring the Firewall for a SIP Trunk
Configuring the Firewall for a SIP Trunk
The LinkManager is responsible for logon to the SIP provider, the creation of the SIP connection and the forwarding of external voice data. The firewall must be configured appropriately in order for the LinkManager to be able to communicate with SIP providers and opposite terminals on the public Internet.
The following example will illustrate how to configure the firewall:
In order to do this, the LinkManager and SwyxServer must be installed on the same computer.
The SwyxServer is located on the local network and, therefore, has a private IP address (e.g., The employee workstations running Desktop Clients and SwyxPhones are also located in this private IP address range (192.168.100.x). The route from the private IP range to the Internet runs via an NAT (Network Address Translation) router, which also acts as a firewall. This NAT router is on the one hand within the private IP address range (e.g. and on the other hand within the public Internet IP network (e.g.
SwyxWare supports the NAT types "Full Cone NAT", "Restricted Cone NAT" and "Port Restricted Cone NAT".
In general, the communication from the private IP address range functions in such a way that the NAT router is used to create a connection into the Internet and, for example, the webserver reached while surfing only sees the public IP address of the NAT router ( and it sends its answers or the web contents to this public IP address only. The NAT router has a table in which it records the connections made by clients from the private IP range to the Internet and which it uses to route the responses from the public range back to the clients in the private IP address range. This table consist primarily of entries in which the private IP address and the port of the client are associated with the public IP address and the port of the NAT router for a connection via the NAT router into the Internet. In this manner, responses from the Internet can be forwarded to the NAT router and from this router to the corresponding client. This connection is only maintained for a matter of seconds, depending on the router.
The use of SIP in connection with firewalls or NAT is rather complex, because most firewalls/NAT routers cannot assign the dynamically-mapped ports to the signaling connection. In this context, the network protocol STUN can be of help.
STUN is a network protocol that recognizes the existence and type of firewalls and NAT routers and takes this information into consideration. It enables the uncomplicated use of devices (e.g. SIP telephones) and programs in networks that should receive information from the Internet.
STUN helps to identify the current public IP address of the line. This is necessary in order for the opposite terminal to correctly address and return your call data.
For more information on the STUN protocol, please see the corresponding RFC standard (RFC 3489).
Fig. 14-3: SIP/STUN
STUN messages are sent at least every 10 seconds by the LinkManager (as long as there is no other data traffic circulating via the corresponding port. in order to ensure that the NAT router's NAT table (masquerading) cannot be destroyed again and that potential changes to the external IP address of the NAT router can be transmitted.. This means that the SIP links of SwyxWare can also be operated behind a DSL connection that is terminated every 24 hours by the IP provider and thus receives a new IP address.
Therefore, STUN messages, SIP logon, the SIP connection creation, and the voice data are sent via the NAT router.
If a firewall exists, it must be disabled for this type of communication only. The rules required for this are described below and must be configured in the appropriate syntax in your firewall.
The LinkManager sends STUN messages from port 65002 to the configured STUN server. The destination port for STUN messages is usually port 3478 but there are exceptions, e.g. SIPGate uses port 10000.
STUN response messages should also be allowed. SIP messages are sent by the LinkManager from port 65002 to the SIP port of the SIP provider. The SIP port is usually the well-known port 5060. The return route for the responses should also be enabled.
The LinkManager uses ports 55000-56000 for sending and receiving voice data on the Internet. The destination address and the destination port cannot be limited in advance because this is solely dependent on the SIP opposite terminal, which is unknown (e.g., X-Lite Client, GMX Netphone or similar).
The reverse direction must also be cleared. This results in the following set of rules for the firewall:
* Clearance for sending UDP, STUN and SIP messages as well as audio packets from the IP address and ports 55000-56000 and 65002 of the LinkManager to STUN port 3478 of any STUN server and SIP port 5060 of a SIP provider (e. g., IP:, Port: 55000 - 56000, 65002=“>“ IP: [STUN Server]/[Proxy Server], Port: 3478, 5060).
* Enabling of receipt of UDP, SIP and STUN messages at port 65002 of the LinkManager.
IP: [STUN server]/[Proxy server], port: any = ">" IP:, port: 65002
* Enabling of outgoing voice data of the LinkManager.
IP:, Port: 55000 - 56000 = ">" IP: any, port: any
* Enabling of incoming voice data to the LinkManager.
IP: any, port: any = ">", IP:, Port: 55000 - 56000
The above rules can also be formulated in a different way. However, this model is appropriate if your firewall supports QoS for the audio data streams (as with e.g. LANCOM routers/firewalls).