Configuration of your Firewall / NAT Router to use SwyxWare SIP Trunks (kb2988)

Summary

From version 5.00 of SwyxWare on it's possible to configure SIP links to do phone calls via IP (Internet telephony) and not only via ISDN or analog lines. SwyxWare SIP links can be registered at SIP providers like CallUK etc.
Please refer to the manual for general information about the configuration of SIP links. This article explains the necessary configuration changes of your firewall for successful use of SIP links.

Note: Since SwyxWare v6.00 the term SIP trunk is used instead of SIP link.

Information 

The Swyx LinkManager handles the SIP registration, call control and transmission of audio streams. For successful communication via the internet it's necessary to add some rules to your firewall configuration.

More than one scenario is possible for locating the Swyx LinkManager inside the network, but inside this article we describe the most common situation with the Linkmanager installed at the same machine the SwyxServer is running on and this machine is placed inside the local area network with a private IP addresses. We assume the machine with the Swyx LinkManager has the IP address 192.168.100.5. The clients of the LAN (SwyxIt! and SwyxPhones) have private IP addresses, too (192.168.100.x). IP connections from the private area to the public internet usually travers a NAT router which is at the same time a firewall. This NAT router has one port placed inside the private area (e.g. 192.168.100.1) and a second port inside the public internet (e.g. 217.194.238.2).

Usually IP connections are established from the private area to the public internet via the NAT router and e.g. a webserver which is connected from a client with a private IP address only "sees" the public IP address of the NAT router and sends its answers to this public IP address of the NAT router. The NAT router establishes a table with lots of entries. Each entry holds information about the connections from a client with IP address and port of the client to the destination of the connection with the public IP address and port of the NAT router's external port/leg for this connection. Therefore the NAT router "knows" to which client it has to send the answers from a public server to.

This mechanism is used by the Swyx LinkManager on startup of the service to determine the public IP address and port used for the SIP communication. The Swyx LinkManager uses the STUN protocol for this task and additionally uses STUN to determine the public IP address and ports of the audiostreams transmitted via the NAT router during calls to put this information into the SIP call control messages. With the help of STUN the Linkmanager analyses the different possible kind of ways the NAT/masquerading table is handled by the NAT router. Please refer to the RFC 3489 for the details about the STUN protocol.

Summarizing, the STUN messages, the SIP messages and the audio streams are transmitted through the NAT router. Therefore the firewall blocking usually all unknown traffic must be configured to allow these data flows.

The following rules should be configured at this firewall:

• The Swyx LinkManager sends STUN messages from port 65002 to the configured STUN server. Usually the STUN server receives these messages at port 3478, but there maybe exceptions (e.g. SIPGate uses port 10000 instead of 3478). It should be possible to receive the STUN answer messages, too.
• SIP messages are sent from port 65002 of the Linkmanager to the SIP port of the provider, which is usually the well known port 5060. It should be possible to send the SIP messages the other way round, too.
• For the audio streams to the internet the Swyx LinkManager of SwyxWare v5.00 uses the ports 56000-57000, beginning from SwyxWare v5.01 the LinkManager uses the ports 55000-56000!. It's not possible to define a destination port, because we don't know what SIP client is used a the destination (e.g. X-Lite client). Again the packets must be allowed to go back, too.

Regarding the above informations the firewall rules may look like this:

• Enable transmission of UDP traffic for STUN, SIP and audio from the IP address of the LinkManager and ports 56000-57000 (v5.00), 55000-56000 (v5.01) and 65002 to the STUN port 3478 and the SIP port 5060 (Sample: IP:192.168.100.5, port:56000-57000 (v5.00), 55000-56000 (> v5.01), 65002 => IP:any, port: 3478, 5060)
• Enable receiving of UDP traffic for SIP and STUN messages to port 65002 of the LinkManager from any IP address and port (Sample: IP:any, port:any => IP: 192.168.100.5, port: 65002)
• Enable transmission of UDP audio streams (Sample: IP:192.168.100.5, port: 56000-57000 (v5.00), 55000-56000 (> v5.01) => IP:any, port: any)
• Enable receiving of UDP audio streams (Sample: IP:any, port: any => IP: 192.168.100.5, port:56000-57000 (v5.00), 55000-56000 (> v5.01))

You may simplify the above rules, but regarding the configuration of QoS rules it's a good idea to devide the rules into audio and call control traffic which makes it very simple to attach the QoS rules. Swyx found out, that especially the Lancom routers/firewalls support the QoS rules and audio prioritization in a very efficient way.

Regarding SIP ENUM links you need to add a portforwarding rule. ENUM links are not registered at a SIP provider. ENUM links simply listen for incoming SIP messages. Therefore it's necessary to configure at the NAT router that all incoming packets at the external IP address of the NAT router at port 5060 are forwarded to the IP address of the machine where the Swyx LinkManager is running on and listening on port 65002 (Sample: Port: 5060 at external IP address of NAT router => IP: 192.168.100.5, port: 65002).

BTW: SwyxWare resolves ENUM numbers with the DNS endings *.e164.arpa (the official ITU project) and *.e164.org (alternative project).

The LinkManager sends the STUN messages every 10 seconds if no other traffic is send to force the NAT router to keep the NAT/masquerading table entries in use valid. Additionally the STUN messages are used to detect changes of the external IP address of the NAT router. This makes it possible to use the SwyxWare behind DSL connections which are disconnected at least every 24 hours by the IP provider and forces the NAT router to attach a new IP address to its external port.

It's not recommended to place the LinkManager into a DMZ, because SwyxWare clients (SwyxIt! and SwyxPhones) need to send/receive the audio streams directly to the LinkManager, but machines inside DMZs usually cannot be contacted by local area clients and/or vice versa.