Using siproxd to allow VoIP through a firewall

Session Initiation Protocol (SIP) is a popular open standard for implementing Voice over Internet Protocol (VoIP) telephone calls. Siproxd is a SIP proxy server that can help you with network connectivity issues for SIP clients behind firewalls.

One major reason that you might use siproxd is to get around network address translation issues with SIP. Siproxd can run on a firewall machine that is directly connected to the Internet, meaning no address translation is needed. Clients on the intranet behind the firewall can then connect to siproxd.

A typical setup for providing Internet access on a home network is to have a single host exposed to the Internet that provides a Web proxy and email services. In such a setup network packets are not allowed to be sent directly to the Internet from machines on the intranet. In this situation siproxd can allow desktop machines to use SIP while maintaining the security offered by a firewall that does not directly forward any network packets to the Internet.

The recently released version 0.7.0 of siproxd uses the recent version 3 of libosip2, which is significant because distributions such as Fedora offer version 3.0.3 of libosip2 by default and only ship version 2.x of libosip2 in a compatibility package. Siproxd packages exist for in Ubuntu universe and openSUSE 10.3.

For this article we’ll build siproxd from source on a Fedora 8 machine. When building version 0.7.x of siproxd, first install libosip2-devel, then follow the standard ./configure; make; sudo make install dance. Alternatively, if you install rpmdevtools and docbook-utils-pdf, then running rpmdev-setuptree; rpmbuild -ta siproxd-0.7.0.tar.gz should produce RPM files on a Fedora 8 machine (and maybe other distributions and versions).

You can allow packets to and from siproxd with the iptables commands below, which assume that the Internet connection is on the interface eth0. Port 5060 is listed as sip in /etc/services and is used for call session management. Ports 7070 to 7089 are used for RTP traffic. SIP uses Real-time Transport Protocol (RTP) for sending and receiving the actual voice and video data.

iptables -I INPUT  -m udp -p udp -i eth0 --dport 5060      -j ACCEPT
iptables -I INPUT  -m udp -p udp -i eth0 --dport 7070:7089 -j ACCEPT
iptables -I OUTPUT -m udp -p udp -o eth0 --sport 5060      -j ACCEPT
iptables -I OUTPUT -m udp -p udp -o eth0 --sport 7070:7089 -j ACCEPT

To configure siproxd you must edit /etc/siproxd.conf. Depending on how you installed siproxd, that file may already exist. An example is also included in the doc/siproxd.conf.example file in the siproxd-0.7.0 tarball.

The if_inbound and if_outbound settings in /etc/siproxd.conf specify the network interface to the intranet and Internet respectively. hosts_allow_reg defines the subnet that can register with siproxd — typically 192.168.0.0/24; you will want to set it to the address of the intranet. If you wish to be able to receive incoming calls, you should also set hosts_allow_sip to specify the networks from which calls can originate. The user directive can be used to tell siproxd what Linux user to run the daemon as — typically either nobody or sip. For initial setup, configuring silence_log = 0 and debug_level = -1 can be handy to see why things are failing.

To run siproxd, either execute the daemon directly or use the supplied init.d script:

siproxd -c /etc/siproxd.conf &
echo 'siproxd -c /etc/siproxd.conf &' >> /etc/rc.local

or

service siproxd start
chkconfig siproxd on

Once the server is configured and running, you need to configure your SIP client to use the new SIP proxy. There are many open source SIP clients, such as Ekiga and WengoPhone. For Ekiga, the preference is under Protocols/SIP Settings, and all that you need is the IP address of the intranet server, which should be the IP address of the network interface listed in if_inbound in /etc/siproxd.conf on the Internet firewall.

Using Ekiga and running all my calls through siproxd I was able to make test calls to voiptalk.org numbers and a list of numbers Ekiga provides for testing. At times during testing I received a “call denied” message from some of the voiptalk test numbers, most likely due to limitations on the number of times they can be used in quick succession per account.

If you have implemented Quality of Service (QoS) filtering on the firewall with multiple traffic classes as described in A Practical Guide to Linux Traffic Control, then adding the following rules to iptables should allow you to have an acceptable SIP conversation even while your Internet link is being fairly heavily used:

INETIF=eth0
iptables -t mangle -A POSTROUTING -o $INETIF -p udp --dport 5060 -j CLASSIFY --set-class 2:1
iptables -t mangle -A POSTROUTING -o $INETIF -p udp --sport 7070:7079 -j CLASSIFY --set-class 2:1