Upgrade 2.0RC1 -> 2.03 killed my Trixbox VOIP



  • I upgraded from 2.0 RC1 to 2.03 rel (i386).

    With no other change in the configuration or the firewall rules (I even restored from a backup to be sure), I am having issues with incoming calls to my Trixbox (Asterix derivative).

    NAT is NOT enabled. pfS is routing and firewalling.

    The Trixbox VOIP server (on a VM) registers with the SIP provider (Voicepulse) no problem. My extensions (on a different provider/subnet) register and function normally, I can still make outbound calls (dialing, voice both ways) successfully.

    But incoming calls fail: I see an entry in the pfS log for the incoming call, appears to pass to the Trixbox IP (which has not changed) - but it never arrives at the Trixbox, the log does not show anything at all.

    Of course I've rebooted anything in sight, and then some. Again, I have made NO config or rule changes other than the firmware upgrade.

    What could possibly be going on?



  • @jamullian:

    But incoming calls fail: I see an entry in the pfS log for the incoming call, appears to pass to the Trixbox IP (which has not changed) - but it never arrives at the Trixbox, the log does not show anything at all.

    Which pfSense log shows the incoming call? Please post a sample entry.

    Perhaps one of your port forward rules didn't import correctly from the old configuration. If I recall correctly, there used to upgrade problems with some configuration items that included "unusual" characters. I have no idea if that is relevant to your situation.

    Perhaps a VOIP related package isn't running.



  • Config upgrade not likely related, those issues were 1.x to 2.x. By the time 2.0 was RC those things were in the past.

    Not having NAT in the equation eliminates all the common VoIP issues. Double check that you really have NAT disabled, Firewall>NAT, Outbound, should be nothing configured on the tab there and manual outbound NAT should be selected.

    You say you see the entry in the log for the incoming call, you referring to traffic you're passing on a rule with logging enabled?

    Packet capture to confirm/deny whether the traffic is leaving the internal interface.



  • @wallabybob:

    @jamullian:

    But incoming calls fail: I see an entry in the pfS log for the incoming call, appears to pass to the Trixbox IP (which has not changed) - but it never arrives at the Trixbox, the log does not show anything at all.

    Which pfSense log shows the incoming call? Please post a sample entry.

    From the firewall log:

    Pass  Apr 18 16:09:20 WAN   ..93.190:5060   ...:5060 UDP



  • @cmb:

    Not having NAT in the equation eliminates all the common VoIP issues. Double check that you really have NAT disabled, Firewall>NAT, Outbound, should be nothing configured on the tab there and manual outbound NAT should be selected.

    You say you see the entry in the log for the incoming call, you referring to traffic you're passing on a rule with logging enabled?

    1)  I'm not clear about the NAT disable: If I check "Manual Outbound NAT rule generation" and Save, a whole bunch of new rules appear below, such as

    WAN  127.0.0.0/8 * * * * 1024:65535 NO    Auto created rule for localhost to WAN
    etc

    Is it really safe to delete these? I am wary of messing everything up  :-\  seeing as it all worked fine before the upgrade (and there are plenty of other Firewall rules being observed, just nothing I introduced in the NAT section)

    2)  The log entry is indeed a Pass entry from the Firewall:

    "Green Pass icon"  Apr 18 16:09:20  WAN      ..93.190:5060      ...:5060  UDP

    (Naturally I have obfuscated the IP addresses, there are not really any * in the entry)



  • When you're routing public IPs, you should have manual outbound NAT selected and no outbound NAT rules configured. With automatic outbound NAT, or manual outbound with rules there, you're going to be NATing your traffic outbound. Having NAT where you shouldn't will create complications with VoIP.

    The "no outbound NAT rules" specifically refers to scenarios where there are only public IPs behind the firewall. If you have some private IP subnets behind it, you need outbound NAT rules with the source of the private subnets, and just make sure there are no outbound NAT rules specifying source "any" or source of your internal public IP subnets.



  • Thank you cmb, that is very helpful to my understanding.


Log in to reply