VoIP phones that will not register behind a PFsense firewall
-
@chpalmer
Thanks for answering!With the Zoiper Push Proxy enabled:
Error 408Without 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?
-
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.
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.
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.
-
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.
-
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.
-
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
-
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
