PFsense SIP (VoIP) and NAT compatibility - And ALIX offload on gateway faillure

  • Back to our experience with VoIP / SIP (Centrex) handling with PFsense 2.1.4 (ALIX and LiveCD).
    Here is a solution that works for us and that did not involved any trade off for functionnality.

    ATTENTION : This workaround WILL NOT deal with voice quality, only the correct SIP management by the PF. Voice quality are related to loaded links or bad connections : you might rather look for "Traffic Shapping" posts or concider changing xDSL operator for one who buy direct trafic (peering) with your SIP Provider.

    For your information, we work in France for French companies that are using VoIP services from both EU and US Services Providers. I precise the French context as norms / standards / best practices may differ from another continent / country which would make this post not universal (hope it would…).

    Here are the kind of problems we used to experience with SIP and PFsense :

    • Internal call transferts becomming one way or taking long time to achieve,
    • One way communication,
    • Inbound calls working 10 mins then gone,
    • Call failed,
    • Presence buttons giving wrong feedback,
    • Outgoing calls taking long delay (10 sec) to start composing / or Ingoing calls taking long delay (10sec) to establish after hanging up.

    Here is the quick solution what worked for us (explained hereafter) :

    • Disabling Siproxd package,
    • Activate AON NAT, forcing static NAT for all UDP port, except 5060.

    After that, the advanced gateway tunning and other system tunables was espacially done to get small ALIX and PF behave better on crappy lossy or loaded links, or more reliable with LAN routing gates (MPLS routers for instance).

    Here is the main configuration we have at customer office :

    • Customers are using SIP services (Centrex like or Asterisk like) –> i.e. Many phone devices / soft phones on the LAN behind an xDSL link (single WAN IP provided by ISP), connecting to a single SIP architecture / SIP outbound proxy.
    • Between 10 and 50 SIP devices on the LAN.
    • Not using STUN.
    • Using Outbound SIP proxy given by VoIP service Provider.
    • SIP Registration timers : 3600 sec (while some are using 300 / 600 / 1500 / 1800 etc...).
    • SIP services are using UDP ONLY.
    • Customers use MultiWan (generally 1 ADSL and 1 SDSL with different ISP) for SIP and Internet redundancy.
    • No personal / private PBX used on the LAN : the VoIP service is made through a one and only public outbound proxy given by the VoIP service provider, phones all connecting to that unique IP.

    Generally, in many posts it's reported that PFsense doesn't handle those things properly for proper SIP management :

    • Timeouts (UDP sessions being dropped in a very short time). (this has never been a problem for us and our configuraitons)
    • NAT (NAT handling is a problem with SIP port for SIP Registration Subscribe etc… as PFsense changes the NAT port too often making phone registering on different ports).

    Here are the configuration we use :

    • "Rules" –> Not any special Rule or FLoating rule to set. We are using multiWAN in fail over mode, so the only rule we changed was to add our gateway group instead of default PF routing table.
    • "Rules" –> We still have include a pass rule from SIP provider IPs and SIP ports used (on each xDSL interfaces, normal interface rule, not floating), but we think this is obsolete now. You might not consider applying those rules.
    • "IP Do-Not-Fragment compatibility" –> checked (checked by default on every PF we manage because of presence of MACchintosh or NFS or other Linux based routers). Not usefull for SIP reliability i guess but here is our conf though…
    • "Firewall Optimization Options" –> Normal (Conservative as said on many posts is not compulsory for the UDP timeout handling, the problem we experienced was not a problem of timeout, but a NAT problem. Plus, on small ALIX architecture, or in fail over gateway this is not recommended… unless "state killing on GW faillure" has been checked...).
    • "NAT Reflection mode for port forwards" –> Enabled (Proxy + NAT). (compulsory for NAT purposes)
    • "net.inet.ip.redirect" –> set to 0 (in some configs using Internet and MPLS links, we have routers on the same LAN net (not the gateway, juste a route to another customer's net)). We strongly recommend to desactivate this option, not especially for VoIP handling.
    • "Load Balancing"  "Allow default gateway switching" –> Checked as we use Multi Wan (2 WAN handled by the PFsense's interfaces)
    • "State Killing on Gateway Failure" –> Uncked for us ! (In France links are becomming more and more lossy, and ADSL links produces natural loss on loads, making PF think the link is down.). This option can be set to ON (wich is better as you will handle multi WAN redundancy better) but gateway timers has to be adjusted, see below. For political or process reason, we want to manage it NOT Automatically, but under our action.
    • "System->Routing->Gateways" "Edit your Gateway-> Advanced-> Packet Loss threshold" = 20 / 40 (default 10/20)
    • "System->Routing->Gateways" "Edit your Gateway-> Advanced-> Probe Interval" = 5 (default 1sec)
    • "System->Routing->Gateways" "Edit your Gateway-> Advanced-> Down" = 60 (default 10sec)
      For those 3 points above, PFsense is too much "sensitive" on flapping or loaded xDSL link, default configs making PF think the link was downs but actually on load. Plus if using ALIX architecture that have poor resources, those configuration will assure you to keep your CPU very low on a gateway failure or over flapping links fo whatso reason.
    • Uninstall SIP Proxy Package.
    • Configure NAT OUTBOUND to MANUAL !!!!!!!!!! And here is the trick.

    How we configured our manual NAT :
    The goal is to make PFsense using static ports for all UDP port EXCEPT for the SIP signalisation wich NATted port must be unique from a device to another.
    Of course Mode has been set to "Manual Outbound NAT rule generation - AON".

    For each interfaces (for us it was ADSL interface and SDSL/ADSL interface) AND for each LAN network (interfaces) using VoIP service we set

    • a rule for port 500 (Static port)
    • a rule for UDP 5060 port (not static) (Wich is actually an exclusion)
    • a rule for UDP any port (static port)
    • a (not static) compulsory rule to have your PF itself to use NAT too.

    Here is an exemple for our AON:
    –--------------------------------------- being the LAN net.

    Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description
      ADSL  *  *  500  ADSL address  *  YES   
      ADSL  udp/*  *  udp/5060  ADSL address  *  NO   
      ADSL  udp/*  *  udp/*  ADSL address  *  YES   
      ADSL  *  *  *  ADSL address  *  NO   
      ADSL  *  *  *  ADSL address  *  NO  1024:65535 
      SDSL  *  *  500  SDSL address  *  YES   
      SDSL  udp/*  *  udp/5060  SDSL address  *  NO   
      SDSL  udp/*  *  udp/*  SDSL address  *  YES   
      SDSL  *  *  *  SDSL address  *  NO   
      SDSL  *  *  *  SDSL address  *  NO  1024:65535

    If you want to migrate from Automatic NAT to Manual, we recommend you to create all the NAT rules BEFORE switching to MANUAL. On some PFsense versions you may see the rules automatically generated even if you are set to Automatic. We didn't had those rules pre-set so we did migrate that way, to be sure not to loose PFsense access management…

    This is a workaround we share for you to try to troubleshoot your own VoIP problems. We managed it like that, and we hope this post will help you in some ways.

    For your interest, we started our workaround with this post :

  • I wanted to say thanks for taking the time in this detailed write-up. I am facing similar issues with a customer's VOIP provider. We replaced an existing SonicWall solution with a pfSense-based appliance (the SonicWall was having horrible problems with the VOIP).

    The pfSense appliance installed like a dream. Since then, the VOIP issues had been slightly better, but still existed. Your post was detailed enough so I could apply your findings to our setup. We'll see how things improve over time. I'll post back here if I develop useful follow-up.

Log in to reply