Is SIPROXD still needed in 2.0?
-
Hi Everyone,
With the issues of ALG and SIP, can anyone confirm that multiple endpoints behind pfsense 2.0 can connect without worry or extra joodoo voodoo to a single SIP server on the outside world? Or are the SIP packets re-written?
I still see a few people complaining and I can't understand why this (which is really an issue) not fixed in this amazing software where it's supported in a cheap $10 router out there…
Thanks
-
I do not know the official answer but I can confirm that I still have problems with SIP phones connecting from the LAN side of pfSense. I have not tried it in Beta 5 though.
-
You still need sipproxd in some cases.
The answer to why we do not do something autmagically is:- nobody took the time to do it
- the skills needed to do it are not the same as writing php pages
Mostly that is the reason but not that plans are not there for it.
-
I have had no problems since late b3 early b4 with the services I use. We connect to a carrier based Broadsoft SIP service. I have deployed b5 at about 6 sites ranging from 3 to 20 phones per site so far.
I was never been able to get SIPproxd to work properly with my SIP provider anyway. m0n0wall has always worked without fail with my setup. I have never been able to get a satisfactory explanation as to why pfSense has issues, but I keep trying it from time to time. Magically it started working properly out of the box several months ago. I have tried to narrow down what changed and when, but haven't found it.
-
Yeah, and that's a shame that it doesn't work. I guess with so many users using pfSense solely for VoIP the dev team should put a more emphasis on this basic feature to work out properly.
If Siproxd doesn't work then what's the point of including it and indeed I am having issues with it as well. It doesn't even retain the values I put in there based on the documentation on the wiki or in the book.
I think SIP should be a solid thing now and it shouldn't be a guessing game. I can't imagine why pfSense wouldn't allow SIP packets to flow like they are generated and why assigning a port to each client should be a hard deal?
Thanks
-
There isn't anything fancy needed for the majority of VoIP configurations, a default 2.0 config works fine with most all scenarios. The only time you need siproxd is if your provider requires proper public IPs within SIP packets, which isn't all that common. It does work just fine when it's needed though.
Magically it started working properly out of the box several months ago. I have tried to narrow down what changed and when, but haven't found it.
we went back to not doing static port on SIP by default several months ago.
-
@cmb:
The only time you need siproxd is if your provider requires proper public IPs within SIP packets, which isn't all that common. It does work just fine when it's needed though.
I am sorry I got to disagree with you all the way. All providers require public IP in the SIP packet otherwise they won't be able to respond back. If you send a SIP packet with your internal IP then the provider attempts to send back to internal IP (which actually maybe part of their network structure as well) and so you never receive a response back.
I still don't understand and I guess no one likes to explain why pfsense doesn't do what a low grade end-user router can do with SIP and not pfSense? I am not trying to bash or blame but rather wanting to know where the fault lies and what the structure of the program is that makes this a hard task.
From the pfSense wiki reads, I gather that pfSense doesn't do a good job or a complete job of re-writing the source port and and that is why it break the SIP packets. Otherwise if pfSense allows an option for OS chosen random port or if it does translate the SIP packets back to the original port from OS there won't be an issue. I understand there might be some work involved but pretty much all VoIP servers now adays comply by SIP RFC so fixing the SIP packets should be a very time consuming job. In addition, maybe an option to allow the OS to use whatever port it wants would work as well. There could be a check mark in-front of each of the DHCP endpoints to allow for this.
Thanks
-
Search the internet for SIP+pf and that will come out eventually why the limitation.
-
Thanks Chris. No plans to change it back I assume?
I can confirm that pfSense works out of the box with Spirit Telecom's Broadsoft Switch
http://www.spirittelecom.com/voice_spirit.phpWe are also a Windstream VAR and they are deploying a Broadsoft switch as well. I do not see any reason it would have problems either. That pretty much covers the Eastern through Midwest USA with a decent carrier based SIP solution.
One other thing to note and something we are seeing is that most of the business we deal with want a hosted solution (no asterisk box in the rack). The carrier based solutions are typically completely managed by the carrier anyway. The router/firewall we put on the customer side is for the customers data only and does not handle any SIP traffic. We do sell a BYOB solution from Spirit and pfSense does the job quite well.
We are rolling out a 22 phone office at the end of the month with pfsense and will let you know how it goes.
-
@cmb:
There isn't anything fancy needed for the majority of VoIP configurations, a default 2.0 config works fine with most all scenarios. The only time you need siproxd is if your provider requires proper public IPs within SIP packets, which isn't all that common. It does work just fine when it's needed though.
Magically it started working properly out of the box several months ago. I have tried to narrow down what changed and when, but haven't found it.
we went back to not doing static port on SIP by default several months ago.
The SIP port was never what hosed me - it was rewriting the RTP ports :( That's why I am forced to use static port (and keep answering the same question on pbx in a flash forum, among others…)
-
Okay, so it's killing me that some people must have STATIC PORT set to YES and some claim they must keep it to NO for the SIP to work. It's really confusing and time consuming when there is no single solution or well documented solution to it. I agree that there are wide variety of non-compatible devices out there but for the most part for cow's sake Asterisk is having a huge share of the market and it should work nicely with pfSense. Don't you agree?
And 2.0 may have some or all the issues fixed but it seems like there isn't going to be a stable version out until next year at the pace it's going….
So, to be practical, why can't we just have a feature that allows or takes the OS random port even if it poses "a security threat" like it's mentioned in this link:
-
I guess I find the logic behind why source ports are rewritten to be much less compelling nowadays. Almost any host I will have behind a pfsense firewall is running a modern OS with modern TCP stack, none of which is really exposed to malefactors, so I'd rather just have things work like every other firewall package (e.g. don't mess with what the NAT'ed hosts pass you). Sorry if this sounds pissy - not intended that way…
-
I agree with you danswartz.
From the pfsense wiki:
By default, pfSense rewrites the source port on all outgoing packets. Many OS's do a poor job of source port randomization, if they do it at all. This makes IP spoofing easier, and makes it possible to fingerprint hosts behind your firewall from their outbound traffic. Rewriting the source port eliminates these potential (but unlikely) security vulnerabilities
Can anyone explain how this is related to IP Spoofing and if IP Spoofing is REALLY even possible AT ALL? I wish I know a bit more about what is said here or I wish this paragraph was explained in well detail to make me kapish. Any light sheded on this would be great.
-
Getting a but offtopic but here goes:
When for example a Windows XP client sends stuff, it does so by incrementing the sourceport by one for each new connection. When you know what the sourceport is going to be, you can send spoofed packets in that way. You have a WAY higher higher chance to get your packets though. Sending false responses before the legit server can respond.
It is an unlikely attack vector though.
-
I am not sure if this poses a threat at all.
First of all if there are multiple OSs of Windows or whatever on the same network they may clash by picking the same port, so my understanding was that no matter what OS picks up for the random port there is a chance that the router may assign it a different port for outgoing packet yet. And once there is a response back then the ROUTER translates it back to the port that the OS wished it to send to and so the OS receives it.
As for as spoofing goes, first of all it doesn't answer anything about IP SPOOFING (literally impossible thing to do) and spoofing packets I doubt is possible either because all packets must come from the IP that packet was sent to. And since IP SPOOFING is not possible if the program has the SLIGHTEST logic built into it then it will reject any attacks. Most of programs use libraries like .Net and etc….which already take care of these basic things.
I am still not kapish / can't buy it, but thanks for the input.
-
All providers require public IP in the SIP packet otherwise they won't be able to respond back.
From the pfSense wiki reads, I gather that pfSense doesn't do a good job or a complete job of re-writing the source port and and that is why it break the SIP packets.
Wrong and wrong. On the first point, most do not use the IP within the SIP packet from the phones, rather the source IP. On the second, in 1.2.3 and 2.0 prior to several months ago, 5060 didn't have its source port rewritten by default as all other traffic does, which would cause issues with registering more than one phone to a single outside public IP, that's why the above linked info is there re: rewriting the source port. That's done by default now as it's the scenario that basically always works.
I agree that there are wide variety of non-compatible devices out there but for the most part for cow's sake Asterisk is having a huge share of the market and it should work nicely with pfSense. Don't you agree?
It does with a completely default 2.0 config, or making sure you're rewriting the source port on earlier releases.
So, to be practical, why can't we just have a feature that allows or takes the OS random port
That's precisely what static port does and always has.
-
I guess I find the logic behind why source ports are rewritten to be much less compelling nowadays.
A bigger reason is proper NAT handling in all scenarios, not an issue with your typical full blown OS, Windows, Mac, BSD, Linux, but many SIP phones and a wide variety of embedded devices send traffic using a static source port and without rewriting it you can run into trouble handling NAT because of the way PF does NAT. Only one pair of source and destination ports per remote and local public IP. i.e. you have one public IP on your firewall, and 10 SIP phones sending source and destination port 5060 to one remote PBX public IP, only one of those is going to be handled properly unless you rewrite the source port.
-
Fair enough. Might be nice to have a global switch that enables/disables this, so folks don't need to diddle the default outgoing NAT.
-
CMB,
Now, that makes sense. So, therefore leave the NAT OUTBOUND to AUTOMATIC rather than AON and pfSense will take of the NATing all those 10 phone devices that want to use 5060 and will randomize ports and well get back to the phone when there is a packet received on that randomized phone since it knows what internal IP the phone has.
That is cool. However, why do I have to setup 10000-20000 for NAT PORT FORWARD to my Asterisk server which sets behind pfSense v1.2.3 for the both way audio to work? Should pfSense recognize that I established a connection from inside and should it allow the traffic that is coming (which is set to OPEN on Firewall to go to destination network /24) from the provider?
Or it doesn't work because initially the Asterisk server opens connection with 5060 and subsequently the provider ask for RTP media port and since it wasn't initiated from inside the pfSense firewall lan therefore pfSense doesn't know where to send it? Hence it's not SIP aware?
Please shed some light on above as well.
Thanks
-
To elaborate on what was happening to me: my asterisk would rewrite the source IP in the header, as my voip provider wanted - so far so good. Unfortunately, it would also put the port number for RTP in there and that didn't get rewritten by pfsense for audio stream, so returning audio didn't work (one-way audio.) That is the one and only reason I use static port. I briefly tried siproxd back in the 1.2.3 days and never got it to work reliably for me. If I cared (and I don't really), I guess I could have two rules: a static port rule for UDP from the asterisk server and a default non-static rule below that for everyone else…
-
Okay, so STATIC works if you have only 1 Asterisk server. Or you don't even need static port since pfSense does the re-writting on all ports except for SIP and stuff need for VPN. That is per book. If you have more than one Asterisk server and that is what I am working on right now then some tingling is needed. To complicate things more, also one of my Asterisk servers accepts clients from Outside.
But I think I am getting my way into RTP ports now and restricting each Asterisk to 1000 UDP ports for RTP and hence I should be able to handle 250 channels with 1000 ports.
1- I would love to hear some comments on my previous post please.
2- Does anyone know why 4 UDP port is used for media with a single call? Is that part of the SIP RFC?Thanks
-
That is cool. However, why do I have to setup 10000-20000 for NAT PORT FORWARD to my Asterisk server which sets behind pfSense v1.2.3 for the both way audio to work?
Because the phones initiate the RTP, if you have remote phones and want the RTP to get in from outside you have to open that. If you're just communicating outbound through a normal SIP trunk to an outside provider, you don't, as everything comes in over the connections initiated outbound.