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

SOLVED: Having a maddening time getting a SIP Codec to work correctly.

Scheduled Pinned Locked Moved NAT
30 Posts 5 Posters 5.7k 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.
  • F
    FTL_Ian
    last edited by Dec 4, 2016, 9:30 PM Nov 14, 2016, 6:25 PM

    I have two audio-over-IP devices called the Comrex Access.  One is a rackmount, the other a portable version you can take on the road.

    Right now they are both behind a pfsense hardware router.

    UDP on ports 5060, 6014, and 6015 are being forwarded to the rackmount.

    I've created static ports as well for UDP from the rackmount.

    The device is unable to connect properly to a different audio-over-IP device (brand is Tieline) that is set into SIP mode at a radio station.  I say properly because the Comrex does connect, however no audio data is transmitted to or from the Tieline.

    For the sake of testing, I hooked up my Comrex Access portable unit and flipped the forwards and static ports to it.  It was able to connect properly to the Tieline.

    One strange difference between the two Comrex units, is the rackmount's status readout reports that its NAT TYPE is "Port Fwd." while the portable unit says its is "Symmetric".  Both should have identical configurations and are connected to the same router, and I don't know enough about networking to ascertain why the different NAT TYPEs are showing up.

    I've looked and looked and tried various configurations but nothing can get the connection to the Tieline on the rackmount to work.

    That alone is frustrating, but worse, the Comrex is supposed to allow for incoming connections from SIP clients.  Well, the incoming calls connect, but no audio data is sent or received by the Comrex (on both the rackmount and portable - when ports are supposedly being properly forwarded).  As a test, I disconnected my cable modem from the pfsense and plugged it directly into the Comrex portable unit.  Connecting with a SIP client was no problem then, so it's pretty clear that pfsense is doing something to my packets.

    I've now spent several hours trying to troubleshoot this, so I'm coming to you for help.  Any suggestions?  :(

    I blog regularly at http://FreeKeene.com

    1 Reply Last reply Reply Quote 0
    • F
      FTL_Ian
      last edited by Nov 15, 2016, 6:56 PM

      Talked with Comrex Tech support today and they said my load balancing could be causing the issue.  I have two internet connections here.  I'll see if I can switch to failover, or is there a way to make sure certain LAN IPs are not subject to load balancing?

      I blog regularly at http://FreeKeene.com

      1 Reply Last reply Reply Quote 0
      • F
        FTL_Ian
        last edited by Nov 21, 2016, 10:07 PM

        I believe I've figured out how to set my Comrex unit to avoid the load balancer, via the LAN Firewall Rules - I made one that goes above the load balancing rule that drives all the Comrex sourced traffic through my Time Warner connection.

        However, this has still not solved the problem.

        I spoke again with Comrex today and they suggested forwarding TCP in addition to the required UDP on ports 6014 and 6015 so a port checker would be able to see it if it was working.

        I did that and when we checked it, the ports were coming back as closed.  Prior to that the ShieldsUP scanner listed them as "Stealth"

        So, now it seems like my port forward isn't working properly and I'm not sure why.

        I blog regularly at http://FreeKeene.com

        1 Reply Last reply Reply Quote 0
        • K
          KOM
          last edited by Nov 21, 2016, 10:23 PM

          Post screens of your NAT port forward and WAN firewall rules, sanitized of public details of course.  You an also go through this list and verify all is proper:

          https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

          1 Reply Last reply Reply Quote 0
          • F
            FTL_Ian
            last edited by Nov 22, 2016, 5:53 AM

            Thanks for the reply.

            Here are the port forwards, which include 5060, 6014, and 6015 - what their SIP compatibility requires be forwarded to the Comrex unit.

            Also, the WAN rules that were created automatically when the port forwards we made.

            Finally, the LAN rules that I made to avoid load balancing for the Comrex unit.

            Thanks for helping this non-IT-pro.

            LAN_RULES.png
            LAN_RULES.png_thumb
            WAN_Rules.png
            WAN_Rules.png_thumb
            Port_Forwards.png
            Port_Forwards.png_thumb

            I blog regularly at http://FreeKeene.com

            1 Reply Last reply Reply Quote 0
            • K
              KOM
              last edited by Nov 22, 2016, 3:21 PM

              Your NATs look OK unless I've missed something.  I would temporarily disable pfBlocker and test again.

              1 Reply Last reply Reply Quote 0
              • F
                FTL_Ian
                last edited by Nov 22, 2016, 8:52 PM

                I'll try that, but pfBlocker was installed after this problem started.  I just happened to discover that package as I was trying to figure all this out.

                Just tried disabling it, but no change.

                The radio station unit is no longer available for testing, so I'm using a program called Linphone (it's an Android SIP client) to connect to the Comrex.  As before, it connects, but no data is transmitted or received by the Comrex.

                I know the Linphone is setup correctly because the Comrex company has one of their units on the public internet that I can connect to with Linphone.  Linphone is on 4G, so not the same network as the Comrex, which is on my Time Warner WAN.

                I'm attaching two screenshots of the states that are active for the IP of my cell phone while I connect to the Comrex through PFSense router via Linphone.  I connect successfully, but no audio data is transferred, and after 30 seconds or so, Linphone crashes.

                When I capture packets associated with the Cell Phone IP it shows packets leaving my WAN IP from port 6014 and going to the Cell Phone IP port 7076.

                When I use my Comrex to connect to Comrex's test unit via SIP, it works fine.  Packet capture shows packets leaving and coming, states show multiple states on ports 6014 and 6015 whereas as you can see when I dial into my Comrex from Linphone those ports show single/no traffic.

                I'm so confused.  Thanks for any insights and suggestions you might have!

                Comrex_SIP_States_No_Static_Port.jpg
                Comrex_SIP_States_No_Static_Port.jpg_thumb
                Comrex_SIP_States_Static_Ports.jpg
                Comrex_SIP_States_Static_Ports.jpg_thumb

                I blog regularly at http://FreeKeene.com

                1 Reply Last reply Reply Quote 0
                • K
                  KOM
                  last edited by Nov 22, 2016, 9:18 PM

                  Anything related in the firewall log being blocked on WAN?

                  I use Polycom VoIP phones here and they just work without any voodoo.  No port forwards required.  They reach out and keep the states open for inbound signalling and data.

                  1 Reply Last reply Reply Quote 0
                  • F
                    FTL_Ian
                    last edited by Nov 22, 2016, 10:28 PM Nov 22, 2016, 9:39 PM

                    No entries for the Cell Phone IP in the firewall logs when I connect via Linphone.

                    If I turn off the port forwards, firewall blocks to the Cell Phone IP show up on port 5060, as they should.

                    I blog regularly at http://FreeKeene.com

                    1 Reply Last reply Reply Quote 0
                    • K
                      KOM
                      last edited by Nov 22, 2016, 9:58 PM

                      It's probably an advanced network option like strict NAT or static source ports or something like that.  Search these forums for keywords like SIP, VoIP, no audio as I've seen these types of cases before but I haven't paid them much attention.

                      1 Reply Last reply Reply Quote 0
                      • chpalmerC
                        chpalmer
                        last edited by Nov 22, 2016, 11:43 PM

                        Destination on your WAN firewall rules should be the IP address of the Comrex box.. or the IP subnet that covers multiple boxes.

                        Get rid of any port forwarding and see how that works out for you.

                        Broadcast stuff we use is all T-1 so this is out of the knowledge base. But ROIP and VOIP is usually visited once a week or so.

                        Triggering snowflakes one by one..
                        Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                        1 Reply Last reply Reply Quote 0
                        • F
                          FTL_Ian
                          last edited by Nov 23, 2016, 9:21 PM

                          It is.  "Comrex_Access_Rack" is an alias for the LAN IP for the Comrex box.

                          I blog regularly at http://FreeKeene.com

                          1 Reply Last reply Reply Quote 0
                          • K
                            KOM
                            last edited by Nov 23, 2016, 9:29 PM

                            Again, no concrete help but some reading that may point the way.

                            https://doc.pfsense.org/index.php/VoIP_Configuration

                            https://doc.pfsense.org/index.php/Static_Port

                            https://forum.pfsense.org/index.php?topic=63424.0

                            1 Reply Last reply Reply Quote 0
                            • F
                              FTL_Ian
                              last edited by Nov 23, 2016, 9:37 PM

                              @chpalmer:

                              Destination on your WAN firewall rules should be the IP address of the Comrex box.. or the IP subnet that covers multiple boxes.

                              Get rid of any port forwarding and see how that works out for you.

                              Getting rid of the port forward doesn't make sense, and doesn't work - that just makes Linphone not connect at all.

                              I blog regularly at http://FreeKeene.com

                              1 Reply Last reply Reply Quote 0
                              • chpalmerC
                                chpalmer
                                last edited by Nov 24, 2016, 9:03 AM

                                @FTL_Ian:

                                Getting rid of the port forward doesn't make sense, and doesn't work - that just makes Linphone not connect at all.

                                Just a test.

                                In the SIP world it does make sense because the client SIP device reports in its header its NAT address.

                                Triggering snowflakes one by one..
                                Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                                1 Reply Last reply Reply Quote 0
                                • F
                                  FTL_Ian
                                  last edited by Nov 24, 2016, 5:11 PM

                                  I did get rid of the 6014 and 6015 port forwards and that made no difference.  It still connects, but no data is transferred.

                                  I've tried all the troubleshooting links I can find.  There must be something that will work, but I'm baffled as to what it is.  Having spent nearly two weeks on this, I'm getting close to contacting support.

                                  I blog regularly at http://FreeKeene.com

                                  1 Reply Last reply Reply Quote 0
                                  • DerelictD
                                    Derelict LAYER 8 Netgate
                                    last edited by Dec 3, 2016, 11:21 PM

                                    Have any documentation from Comrex describing exactly what they need from a firewall - NAT in particular?

                                    Chattanooga, Tennessee, USA
                                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                    1 Reply Last reply Reply Quote 0
                                    • F
                                      FTL_Ian
                                      last edited by Dec 3, 2016, 11:28 PM

                                      They say to forward ports 5060, 6014, and 6015 UDP to the unit and it needs a static IP.  I've since assigned the unit to avoid load balancing as I'm on a dual-WAN, but that didn't solve the problem.

                                      Here's their guide to connect Linphone SIP client with the Comrex:
                                      http://www.comrex.com/wp-content/uploads/2016/01/Linphone-technote-for-ACCESS-and-BRIC-Link.pdf

                                      Works fine when I connect to their test, works fine when I plug the Comrex directly into my cable modem, so it's definitely not a problem with Linphone or the Comrex - seems like something in PFsense is getting in the way.

                                      I blog regularly at http://FreeKeene.com

                                      1 Reply Last reply Reply Quote 0
                                      • DerelictD
                                        Derelict LAYER 8 Netgate
                                        last edited by Dec 3, 2016, 11:45 PM

                                        That's great but there is nothing to get in the way there.

                                        I see no mention of outbound connections from the codec so delete any static port outbound NAT you have created. It won't help and might break something else.

                                        What are the contents of all your aliases?

                                        I see no mention of TCP in that document. Why is your SIP forward TCP/UDP?

                                        You do not need to worry about Multi-WAN on inbound connections from clients. pf reply-to handles that and is automatic as long as that connection is set up as a WAN (Has a gateway set on the interface). That is unless the default gateway on the codec is not set to pfSense LAN in which case you'll have all sorts of asymmetric routing issues.

                                        Chattanooga, Tennessee, USA
                                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by Dec 3, 2016, 11:48 PM

                                          This right?
                                          http://www.comrex.com/wp-content/uploads/2016/02/ACCESS-Rack-Manual.pdf

                                          Are you running v3.0 firmware? If not then you need to be forwarding different ports.

                                          In the case of SIP, this
                                          must be three discrete ports (For Comrex codecs these are UDP 5060, 5014
                                          and 5015)
                                          <6014 and 6015 with 3.0 firmware>

                                          Do you see any blocked traffic in the firewall log from the client IP you are trying to connect from?

                                          Steve

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                            This community forum collects and processes your personal information.
                                            consent.not_received