VoIP phones that will not register behind a PFsense firewall



  • Ok, I have several VoIP phones that will not register behind a PFsense firewall to cloud pbx. If I move a phone to another network it registers fine all 10 do and will at the same time. The set up is as follows. Phone plugged into Poe switch that uplinks to firewall out to the internet and over the internet to cloud-hosted PBX.

    From onsite, I can get to the PBX on all the ports needed, but the phones will not register. This is my first pfsense firewall. I have read through a lot of other posts tried all the suggestions and still no love any help appreciated.



  • You might want to try the SIProxd package in your case. But It may be as simple as building some incoming WAN firewall rules from your SIP server IP address with your VoIP subnet range as the destination. With SIProxd the destination would be WAN address.


  • Netgate Administrator

    Generally speaking you should not need to do anything special for internal phones connecting an external PBX.

    Some older VoIP insists on using a fixed source port, pfSense changes the source by default. You can setup static port NATing to stop that but if all the phones are using port 5060 that will only allow one to connect. If that is the case you would need to use SIProxd. That's about the only time you should ever need to use it!

    https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-voip-phones.html

    Steve



  • @stephenw10 said in VoIP phones that will not register behind a PFsense firewall:

    Generally speaking you should not need to do anything special for internal phones connecting an external PBX.

    Some *** VoIP insists on using a fixed source port,
    Steve

    You never know.. Keep in mind that companies are still trying to avoid what happened to Vonage back in the day.. Vonage got sued for violating patents.. Companies now do things just different enough to avoid the same fate.

    Also.. VOIP was not originally designed for residential service. Not originally designed to be behind NAT.

    You have to play and experiment sometimes. SIProxd fixed my company originally. Then they changed a few things and it became unnecessary. I still use it one place. But everywhere else just need the incoming WAN rules. SIProxd however gives a little priority apparently. So I keep it here.

    Now a days I start with WAN rules.. Then static port.. then finally SIProxd until I get an unknown SIP provider working. But I have never failed to get a VOIP system to work.



  • Hello together,
    what is the final solution now?

    I used my Zoiper VOIP Accounts for many years without any problems or special rules on PFSense. It always worked properly, but since a few weeks i can't register anymore and make any calls.

    I installed the SIProxd Plugin, but didn't have any affect.

    Sometimes the softphone can register with my provider, but when i make a call, i can't hear anything.

    Any further ideas for solutions?





  • @chpalmer
    Thanks for answering!

    With the Zoiper Push Proxy enabled:
    Error 408

    Without the Zoiper Push Proxy:
    I can register, start a call, but can't hear anything in any call.

    Where in PFSense can i see, what was blocked from this device? I think, if PFSense blocks registering the account, there must be an event in PFSense somewhere or?


  • Netgate Administrator

    Can the remote end hear you when you are able to make a call?

    We had a customer using Zoiper recently and when we looked at the SIP invites it was sending some random private IP to connect to with RTP. Which of course failed. It wasn't even the local IP of the device. No idea where it was pulling it from.

    Steve



  • @stephenw10 said in VoIP phones that will not register behind a PFsense firewall:

    Can the remote end hear you when you are able to make a call?

    We had a customer using Zoiper recently and when we looked at the SIP invites it was sending some random private IP to connect to with RTP. Which of course failed.

    @Teddy

    VOIP is a funny animal.. I get weird private space IP's in my call logs sometimes.

    Teddy- Try keeping the push proxy off.

    Build an incoming firewall rule on your WAN that points to your client device(s) No port forward! Just a rule(s).

    In this picture there is no traffic as they just moved and we have yet to plug in the phones. But you can see that the carrier IP's have a separate rule but identical to the provider. Provider SIP on top and the carrier they are using as the last two rules. It is hit and miss whether the calls connect to the carrier or SIP server for RTP. In this case this is a single ATA feeding a couple of phones in a small office. More than one device could be done by expanding the destination or by creating rules for each client device.

    You need to make calls and watch your states and firewall logs and see how things are trying to connect.

    voiprules.jpg

    We are not port forwarding but simply allowing the server access to the ATA. The server already knows its way in via information it got from the SIP header.


  • Netgate Administrator

    It is my opinion that those rules on WAN are both unnecessary and can never actually pass any traffic.

    You cannot ever have packets arrive on the WAN with a private IP as destination, that is not routable over the internet.

    Without a port forward the only way that traffic could arrive is if the NAT state translating an outgoing packet is open on the WAN. If that is there then you don't need those rules since the existing state will pass it anyway.

    We did discuss this before and I do concede your VoIP experience exceeds mine. I can't see how they could possibly do anything useful though. ๐Ÿ˜•

    Steve



  • @stephenw10
    No, he can't hear me and i can't hear him.

    @chpalmer
    With Push Proxy deactivated i can register, but i still can't make successful calls. Nothing to hear.

    @stephenw10
    So, in short words you say, even with those rules you won't have success? Additionaly first i would need to find out, which IP's my provider(s) are using, right?

    That sounds all really complicated, just for the softphone...Weird, that it worked for many months without any problems. First i thought, that SNORT was the problem. But even a deactivated SNORT doesn't lead to success.


  • Netgate Administrator

    If you're connecting from a softphone behind the firewall to some external PBX it should 'just work'.

    The fact that was just working previously confirms that.

    It's almost certainly some SIP problem. The only way to really diagnose that is to pcap the SIP traffic and analyse it.
    That gets complex quickly!

    Steve



  • @stephenw10 said in VoIP phones that will not register behind a PFsense firewall:

    It is my opinion that those rules on WAN are both necessary and can never actually pass any traffic.
    I can't see how they could possibly do anything useful though. ๐Ÿ˜•

    I learned the hard way that NAT is not a security measure. Anybody that knows what they are doing can reach a target behind a NAT router (without a firewall).

    My first router was a Zonet ZSR104CP. No firewall. I constantly had traffic pounding on my Windows machine from the outside. That was a Windows 2000 machine which I put a software firewall on. So I constantly got alerts.

    With that in mind remember that the SIP header provides all the information that the provider needs to connect back to you. Even when the firewall state expires. In my case Im behind SIPRoxd here so- sip:36xxxx191x@123.456.10.13 which is my obfuscated public IP address. The SIP server believes that my SIP phone is right up against the connection with no NAT. This is shown on my provider dashboard under "connected devices"..

    If I do not use the proxy then the connection shows up as 36xxxx191x@172.31.125.25 36xxxx191x@172.31.125.26 36xxxx191x@172.31.125.27 (one instance per phone). The LAN address of the ATA/SIP client is in the header.

    In allot of cases (and probably most in residential/small business focused systems) RTP comes from the same server that the client registers SIP on. In some cases such as my provider and other commercial grade carriers the RTP can come from the actual carrier direct. So an unsolicited connection (from the RTP server) to the firewall that was actually solicited by the SIP server on the phone ata's/SIP client's behalf.

    Looking above at my picture- I came up with those addresses by watching for multiple phone calls in and out. Once I built the firewall rules in the manner Ive explained, things started working fine whereas before the connections only worked for moments after the ATA's were rebooted(same server) and never at all when SIP and RTP were separate servers. This was over ten years ago. We have been doing it the same since and never have issues.

    My provider likes to tell their customers to port forward. But considering on standard SOHO routers the only way to open the firewall on a client by client basis is to port forward I understand their goal.


  • Netgate Administrator

    If you're running siproxd, or any sort of SIP ALG/proxy, then things are very different because, as you say, all the info required is in the SIP packet.

    If you're not though then RTP traffic from some other external IP will only reach the internal client if the client has first opened the state out to it.
    pf does not look inside the packets neither does the bsd routing engine. The incoming packets are addressed to the external IP and have no reference to the internal IP. The only way they can reach an internal client is if the source/destination IP/port combination match an existing state in the firewall.

    Steve



  • @stephenw10

    I get what your saying.. really. But all I know right now is what it takes to make it work here and for my customers. It is very possible the client device initiates RTP but Ive been told it does not by one Freeswitch "expert". Ive done this both ways. Proxy and no proxy.

    Just because the customer side is a client device does not mean that the audio stream cannot be initiated from the server side. Or that both sides cannot initiate or even just push at each other unidirectionally. Allot of it is over my pay grade. But I have been working with my provider since their "beta state" days. and a customer/partner for over twelve years at this point. I did allot of research. Our office used Vonage back when they first started putting tv commercials on the air. https://youtu.be/Hfy7niwDhn8 and no it didn't just work out of the box. (we had three lines on a slow DSL connection and a crappy all in one modem). VOIP providers all do things just a little different from each other. Sprint sued Vonage and won a large judgement. Since then the threat of patent infringement has providers changing it up a bit.

    RTP traffic from some other external IP will only reach the internal client if the client has first opened the state out to it.

    Think of all the complaints of one way audio. Think of all the conversations that stop after so many seconds.

    If you open a firewall rule to a specific server port but without creating a port forward do you believe that nothing could get to that server port? If so then you are calling NAT secure, which it is not.

    ATA/SIP devices are inherently trusting devices. But whether the SIP instructions tell the device to communicate with a given RTP server or not I am not in the know. I do know that after some trial and error we made our provider work flawlessly for our clients. (non of which use any form of proxy) YMMV.

    This starts to get interesting after page 70.. https://www.comrex.com/wp-content/uploads/2016/01/BRIC-Link-II-Manual.pdf

    Not quite apples to apples and probably enough to confuse anyone trying to work both technologies.. But good background info. And generally the streams we use those for are 24/7.

    So here is a good question for anyone that knows.. What would happen if the audio stream started pushing from the server side just milliseconds before the phone client device started pushing its stream from its side? How would the firewall handle that connection? Would it first block and then allow? Or would it keep the connection closed because of the perceived "unsolicited" connection that just occurred?

    Off to a hill top for me.



  • Hello together again,
    creepy. Two days ago my PFSense wasn't able anymore to connect in anyway to my CG VPN Service. Always "decompression failure" or something like that appeared.

    The final solution was to change from adaptive LZO Compression to OMIT Preference. Then this connection worked again.

    And what started to work as well? The VOIP Connections. I don't know how this belongs together, but now i can register like always my softphones and make calls. I think we would have searched years to find this out...But well, fortunately finally now it works again. That is the most important!

    Thanks again anyway for the interesting information you posted here and the support you gave!

    Have a nice weekend


Log in to reply