Is SIPROXD still needed in 2.0?
-
@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.
http://doc.pfsense.org/index.php/VoIP_Configuration
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:
http://doc.pfsense.org/index.php/Static_Port
-
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.