Pfsense NAT with Digium phones and Switchvox

  • So after a TON of trial and error testing / researching online, I have decided to post my scenario here to see if what I am trying to do is possible… (sorry for the long post in advance :) )

    Basically, I am trying to setup a pfsense firewall that can sit in front of 10-20 Digium phones that connect to a remote Switchvox PBX so that voice calls and Digium phone apps work consistently.

    I should state that I have a "working" configuration as you will see below, but it is not ideal and I need some assistance to make it more streamlined...

    Here is my setup (IPs are fictional)

    Remote Switchvox PBX

    • hosted in data center on IP (No NAT at datacenter)

    Office Location (20 Digium phones - mix of models D40 and D70s)

    • pfsense 2.0.3 (also tried version 2.0)
    • private LAN Subnet:
    • public WAN IP:

    If pfsense is setup with Automatic outbound NAT rules, each of the phones boot up and connect to the PBX for provisioning and SIP voice calls without issue.  Firewall Optimization Options is set to conservative BTW.

    Digium's built in phone apps (like visual voicemail and call parking lot) connect to the PBX just fine at first.  After a few hours, however, the Digium phone apps timeout and stop working.  SIP voice calls still function flawlessly.

    Packet captures and troubleshooting with Digium support revealed that the issue was the source port that the firewall was assigning to the phone for the Digium phone app connections was changing after a few hours.  Thus, the PBX was expecting the phone to be connecting from a source port of XXXX, but now was coming from YYYY, resulting in an unauthorized connection.

    Digium support recommended that we enable the static port option for outbound NAT.  Sure enough, that solved the issue with the Digium phone apps and all 20 phones are working great now...

    So what's the problem you ask?  Here it goes...

    Customer now wants to add 2 new Digium phones to the office network.

    When the first new phone is connected to the network (ie. one that does not have a state established yet), the firewall's static port option causes the device's source port to not be re-written (ie. the phone will go out as udp 5060, using the WAN IP of the firewall -  Phone connects without issue and so far so good...

    When the second new phone is connected to the network, it too will attempt to go out as udp 5060 since the static port option is enabled.  Unfortunately, because the previous phone already went out as, the firewall can't have the device go out as the same address, so instead, the firewall sends out the packets with the private LAN source IP (ie.  This obviously will not work as the PBX will receive this packet and the return packet will never make it back.  This results in the phone not being able to boot up since the connection to the PBX can not be established do to the static port option on the firewall.  Why the firewall sends the packets out as the private IP is a mystery to me, but I digress...

    So here is what currently has to happen to get the 2 new phones online:

    1. Make sure an existing state does not exist in the NAT table for both phones (delete the states if they exist)

    2. Disable the static port option on the outbound NAT rule in the firewall temporarily.

    3. Boot up the 2 new phones so they connect and are assigned a re-written source port.

    4. Re-enable the static port option on the outbound NAT rule in the firewall.

    What a pain in the butt...

    So my question is - is there a way to have the firewall's outbound NAT rules set to "static port" yet still have the SIP phones assigned a random source port initially when they connect to the network, and retain that assigned port indefinitely so it does not change?  I understand that I could create static DHCP mappings for every phone and then build in individual outbound NAT rules for each IP address so that I could assign each phone a static source port, but that is ridiculous.

    Any insight would be appreciated...

Log in to reply