Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Is SIPROXD still needed in 2.0?

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    22 Posts 7 Posters 8.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      torontob
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • H
        hankjrfan00
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • E
          eri--
          last edited by

          You still need sipproxd in some cases.
          The answer to why we do not do something autmagically is:

          1. nobody took the time to do it
          2. 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.

          1 Reply Last reply Reply Quote 0
          • K
            Kevin
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • T
              torontob
              last edited by

              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

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                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.

                @Kevin:

                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

                1 Reply Last reply Reply Quote 0
                • T
                  torontob
                  last edited by

                  @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

                  1 Reply Last reply Reply Quote 0
                  • E
                    eri--
                    last edited by

                    Search the internet for SIP+pf and that will come out eventually why the limitation.

                    1 Reply Last reply Reply Quote 0
                    • K
                      Kevin
                      last edited by

                      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.php

                      We 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.

                      1 Reply Last reply Reply Quote 0
                      • D
                        danswartz
                        last edited by

                        @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.

                        @Kevin:

                        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…)

                        1 Reply Last reply Reply Quote 0
                        • T
                          torontob
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • D
                            danswartz
                            last edited by

                            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…

                            1 Reply Last reply Reply Quote 0
                            • T
                              torontob
                              last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • S
                                SeventhSon
                                last edited by

                                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.

                                1 Reply Last reply Reply Quote 0
                                • T
                                  torontob
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • C
                                    cmb
                                    last edited by

                                    @torontob:

                                    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.

                                    @torontob:

                                    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.

                                    @torontob:

                                    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.

                                    1 Reply Last reply Reply Quote 0
                                    • C
                                      cmb
                                      last edited by

                                      @danswartz:

                                      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.

                                      1 Reply Last reply Reply Quote 0
                                      • D
                                        danswartz
                                        last edited by

                                        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.

                                        1 Reply Last reply Reply Quote 0
                                        • T
                                          torontob
                                          last edited by

                                          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

                                          1 Reply Last reply Reply Quote 0
                                          • D
                                            danswartz
                                            last edited by

                                            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…

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.