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

    OpenVPN SIP traffic for external phones.

    Scheduled Pinned Locked Moved Traffic Shaping
    13 Posts 7 Posters 3.8k 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
      trumee
      last edited by

      Just curious what phones you are using which support openvpn?

      1 Reply Last reply Reply Quote 0
      • V
        vianneyjs
        last edited by

        I'm using Yealink SIP-T21P E2

        1 Reply Last reply Reply Quote 0
        • P
          pahowart
          last edited by

          I messed around with the various traffic shaper options to provide QOS for my SIP phones but in the end the best one was simply putting CODELQ on the WAN and LAN interfaces.

          CODELQ correctly configured removed the so called "buffer bloat" which in my case was causing a fair bit of random jitter on the SIP phones.

          1 Reply Last reply Reply Quote 0
          • V
            vianneyjs
            last edited by

            Thank you for your input pahowart.

            Were you phones connected via OpenVPN or directly with SIP?

            1 Reply Last reply Reply Quote 0
            • awebsterA
              awebster
              last edited by

              Unless you've changed from the default, OpenVPN uses UDP port 1194.
              They traffic shaper needs to be configured to recognize this.  It will be blind to actual SIP/RTP packets inside the OpenVPN since that is between the phones and the PBX.
              You can use the shaper wizard to create a VoIP queue, and then use the floating rules to match source/dest + port and put it into the VoIP queue.

              –A.

              1 Reply Last reply Reply Quote 0
              • V
                vianneyjs
                last edited by

                Hi awebster

                Have you done this in a real world scenario?

                Could you please detail how would this work?

                Thank you!

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

                  What I've done in this case is create an interface and assign the openvpn interface to it. This way you're able to create rules on firewall floating tab which will match traffic inside the tunnel.

                  1 Reply Last reply Reply Quote 0
                  • DerelictD
                    Derelict LAYER 8 Netgate
                    last edited by

                    The easiest thing to do is just prioritize the OpenVPN tunnel itself. As has been said you will already have a rule for UDP/1194 (the default) on WAN so you can just set the queues there.

                    Keep in mind that you can queue what you send out WAN (uploads). Identifying how you queue out LAN (downloads) is more difficult. Especially with multiple LAN interfaces.

                    There are probably some magic numbers to get better latency but I haven't had much luck finding them.

                    Setting queues on an OpenVPN assigned interface to try to queue traffic inside the tunnel has resulted in a couple 100%-CPU-with-no-significant-traffic situations for me. Didn't really investigate very hard. I stopped the practice and just queue the tunnel traffic instead. YMMV.

                    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
                    • K
                      kelsen
                      last edited by

                      Although this tunnel is for SIP only, I've found myself that you can never queue inbound openvpn traffic, besides its not possible to queue another type of traffic with @Derelict's solution. thats why you need an openvpn interface.
                      I hasn't experienced 100% cpu problem with my setups, something may be wrong with yours.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        All I know is the problem started when I added queues to rules on my assigned interface and it stopped when I took them out.

                        Just throwing it out there.

                        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
                        • S
                          Savas @vianneyjs
                          last edited by

                          @vianneyjs could you share the firewall rules? I am trying to achieve the same with Snom phones that support OpenVPN, however phones do not register FreePBX running on the LAN.

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by

                            You probably want to start a new thread.

                            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
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.