Siproxd: Part One

SiproxdSiproxd is a proxy/masquerading daemon for the SIP protocol. It handles registrations of SIP clients on a private IP network and performs rewriting of the SIP message bodies to make SIP connections work via a masquerading firewall (NAT). It allows SIP software clients or SIP hardware clients to work behind an IP masquerading firewall or NAT router.

SIP, or Session Initiation Protocol, is a standardized set of formats for communicating messages used to initiate, control, and terminate interactive Unicast or Multicast user sessions with multimedia services such as Internet telephone calls, video conferencing, chat, file transfer and online games. Originally developed in 1996 (and standardized in 2002 under the name RFC 3261 by the Internet Engineering Task Force), SIP is the most widely used communication protocol and is the protocol of choice for most VoIP phones to initiate communication. By itself, SIP does not work via masquerading firewalls, as the transferred data contains IP addresses and port numbers. Thus, using SIP over a firewall requires solutions to traverse NAT, but such solutions may have disadvantages or may not be applied in certain situations. Siproxd does not aim to be a replacement for these solutions; however, in some situations it may bring advantages.

Siproxd: Installation and Configuration

Siproxd runs on a variety of Unix variants. It is currently known to work on:

  • Linux
  • FreeBSD
  • OpenBSD
  • SunOS
  • Mac OS X

Installation of the siproxd package in pfSense is easy. Navigate to System -> Packages, scroll down to sixproxd in the packages list, and press the “plus” button (+) to install siproxd. On the next page, press the “Confirm” button to confirm installation, which should take less than two minutes.


Once siproxd is installed, you can begin configuration by navigating to Services -> siproxd. There are three tabs: “Settings“, “Users“, and “Registered Phones“. On the “Settings” tab there are several general settings. Check the “Enable siproxd” check box to enable or disable siproxd. The “Inbound interface” dropdown box allows you to select the inbound interface (usually WAN). You can also select the “Outbound interface” (usually LAN). The “Listening port” edit box allows you to enter the port on which to listen for SIP traffic (default port is 5060). The “Default expiration timeout” specifies the timeout (in seconds), provided that the REGISTER request does not contain an Expires header or an “expires=” parameter.

Under “RTP Settings“, you can configure settings for the Real-time Transport Protocol (RTP), a standardized packet format for delivering audio and video over IP networks. The “Enable RTP proxy” dropdown box allows you to enable or disable the RTP proxy (default is enabled). In the next two edit boxes, you can enter the lower and upper bounds for the RTP port range (the default is 7070 to 7079). Finally, you can enter the “RTP stream timeout”, the number of seconds after which an RTP stream will be considered dead and proxying it will stop (the default is 300 seconds).

The next section is “Dejittering Settings“, which allows you to set an artificial delay to de-jitter RTP data streams (both input and output). The default is zero (no dejittering).

Next is “SIP over TCP Settings“. Here can can configure a “TCP Inactivity timeout” to set the amount of time (in seconds) after which an idling TCP connection will be disconnected. The “TCP Connect Timeout” defines how many milliseconds siproxd will wait for a successful connect when establishing an outgoing SIP signaling connection. “TCP Keepalive” is used for TCP SIP signaling. If this parameter is greater than zero, empty SIP packets will be sent every n seconds (where n is the number specified) to keep the connection alive. The default value is zero (off).

In the next article, we will continue our look at configuring siproxd.


External Links:

The official Siproxd site.

Siproxd on SourceForge.

Real-time Transport Protocol on Wikipedia

Reader’s Mailbag: 1-7-2015

I received an e-mail from a reader stating that even though he had an internet connection, he could not access the internet through his pfSense firewall. It occurred to me that there might be several reasons why this might be the case:

  • pfSense’s WAN interface isn’t connected to the uplink/modem.
  • The local network isn’t connected to pfSense’s LAN interface.
  • The WAN and LAN interfaces are set up correctly, but there may be another configuration issue (e.g., traffic between the WAN and LAN is blocked).

I am assuming the user’s setup (when functioning) looks something like this:

	LAN <-> pfSense box  <-> WAN <-> Internet

I advised as a first step to try to ping a server on the internet. If this is successful, then at a minimum, we know the WAN interface is set up correctly. If not, then we have a WAN configuration issue, which could be one of the following:

  • The network interface card (NIC) for the WAN interface is broken and needs to be replaced.
  • The WAN interface is functioning, but it is not connected to the internet (usually through a modem).
  • The WAN interface is functioning and is connected to the internet, but it has not been configured properly.

If the WAN interface is set up correctly, then we have other issues to consider. We have internet connectivity and can access the internet from our pfSense box, but not from the LAN. If we can ping another host on the LAN, then the LAN is functioning. If not, then we need to find out why; the issue could be a malfunctioning or misconfigured NIC and/or router or switch.

If we can ping other computers on the LAN, then the problem may still be a configuration issue with the router. We need to make sure the router is pointed towards the LAN; the default gateway address, wherever it is set on your router, needs to be set to pfSense’s LAN address. Also, if you are using your router to do DHCP, you need to make sure this is set up properly as well.

Another possibility is to have your standalone router configured as a wireless access point (WAP). In this case, you still need to make sure the default gateway is the IP address of pfSense’s LAN interface. You also need to make sure the uplink port on the router is connected to pfSense’s LAN interface. Since your router will not be doing DHCP assignment, you need to set up pfSense to do this. You can do this by going to Services -> DHCP server, clicking on the tab for the LAN interface, and clicking on the “Enable DHCP server on LAN interface” checkbox. At a minimum, you will want to define a “Range” for DHCP assignment (make sure it does not conflict with your router IP address or any of the IP addresses for pfSense’s interfaces). Press the “Save” button at the bottom of the page to save the changes.

If we know the router/switch is set up properly and the gateway is pointed towards the pfSense LAN interface, it may be possible that pfSense is somehow blocking traffic between the LAN and WAN. At this point, we probably should check the firewall rules and make sure this is not the case.

I think this should be a good start for anyone trying to troubleshoot a similar conncectivity issue, but it is not necessarily an exhaustive guide. If anyone has any further suggestions, I’d love to hear them.

External Links:

The official pfSense site

© 2013 David Zientara. All rights reserved. Privacy Policy