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

    Basic Shaper help needed

    Scheduled Pinned Locked Moved Traffic Shaping
    18 Posts 4 Posters 3.5k 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.
    • C
      ck42
      last edited by

      I've read pages and posts and blogs and the PFS book trying to wrap my head around this, but I have to throw up my hands in defeat…  :o
      I need some help here.

      Quick summary:
      pfsense: 2.1.5
      Home office
      SIP phone
      gigE LAN (flat network, for now)
      50/10 Mbps connection

      Want to shape traffic for:
      VoIP
      Steam games
      General Internet traffic

      Biggest priority is ensuring SIP phone is being shaped as well as possible.

      With that, here's what my setup looks like after running the wizard.  Decided, based what I understand, to simply use PRIQ.  It's seemed most appropriate for my needs.

      1. First question is, what Bandwidth should I specify here?  Since this is the "LAN" shaper, should I put 1 Gbit/s?

      2. Next Q:  In the qLink under "LAN":  What exactly is this queue used for?  It auto-populated with a Queue limit of '500 and set itself to "Default Queue".  Is this appropriate?

      3. The qOthersLow/High were auto-created when I began selected different types of Internet protocols (mail, http, IPsec, etc., etc).  This queue, along with all the other types besides qLink, have NO Queue limit specified.  Is this appropriate?

      In the "WAN" shaper:

      1. Despite the fact that I specified both the UP and DOWN speed in the wizard, I only see that the UP speed has been populated - as seen here (9Mbit/s).  I only put 90% of the actual rating. Did same for the DOWN speed.  Where should I be seeing the DOWN speed listed?

      2. Under the "WAN" shaper, I have a qDefault queue, which is set to be the 'Default'.  Why do I have a qDefault under WAN and not under LAN?

      After resetting the states, here's what the Queues look like.  Currently, there's Steam gaming occuring and an active VoIP call in progress.  In the VoIP queue, I allocated 125Kbps.

      1. So looking at this, what does the red horizontal bar represent?  The fullness of the queue I'm guessing?

      2. What is the qLink telling me?  Is this normal?  Why does it seem to be full?  It always stays at 100%, even when there's virtually no traffic going up or down.

      #8) Why is there almost no bandwidth being consumed on the VoIP call queue?  Yes, I did select the VoIP prioritization option in the Wizard.

      When running Speed Tests, I can see the "LAN" qLink go up to 26Mbps on the download portion, and on the Upload portion of the test, the "WAN" qDefault goes to 4Mbps.  Sound right?

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        I don't have a lot of time so I'll be brief…

        1.  PRIQ shapers don't care about bandwidth, so leave that field blank.
        2.  qLink is your default LAN queue.
        3.  That's fine.
        4.  Again, PRIQ doesn't care about bandwidth allocation, it only cares about packet priority based on class.  Higher priority packets always go first.
        5.  qLink is your default LAN queue.
        6.  Yes, AFAIK.
        7.  Your VoIP queue is empty because your floating rule that dirrects VIP traffic into qVoIP is wrong somehow.  Look at Firewall - Rules - Floating and see what's going on.  Post the rule here as well as the IP address(es) of your VoIP phones and/or VoIP server.

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

          Appreciate you taking the time to go through the questions, KOM.  Even if the responses were brief, still very helpful.

          Regarding #8, VoIP queue apparently not being used:  Here's the floating rules that were auto-generated.

          There are only two that were created.  The Source/Destination value is an alias I created.  Also, not sure if it matters, but I'm also running a transparent proxy service - BUT….I've created an exception for the static IP address of the SIP phone so that it bypasses the proxy server.

          Also, it appears that when using the wizard, it requires you to enter bandwidth values, even after having chosen PRIQ.

          1 Reply Last reply Reply Quote 0
          • KOMK
            KOM
            last edited by

            You're positive that you have a correct alias for Phone_SIP_Server?  When you say transparent proxy, are you talking about Squid?

            As for the wizard, it's a one-size fits-all GUI.  Bandwidth totals up/down are used by the HFSC shaper to do its calculations.  PRIQ doesn't use it, but it doesn't surprise me that the wizard bugs you for it.  You can enter anything.

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

              Perhaps your rule might work better if you used the port for SIP instead of the server IP under the floating rule section. This way ANY SIP traffic will get shaped how you want it.

              1 Reply Last reply Reply Quote 0
              • B
                BeerCan
                last edited by

                The rule should be working as it is if the alias is correct.  You can go to status –> system logs and click on the resolver tab.  In there you can see if the alias was resolved correctly.  It will look something like this

                Aug 16 00:16:02	filterdns: adding entry 64.2.142.188 to table voipservers on host outbound.vitelity.net
                

                FWIW my floating rule looks similar.  The first 2 entries were for some external phones but those entries are now removed.

                2014-07-11_165824.jpg
                2014-07-11_165824.jpg_thumb

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

                  I'm as sure as what the rep from phone.com told me.  I can also see in the logs that the address is actually resolving.  ???

                  Regarding the transparent proxy - yes, I'm running Squid.

                  @KOM:

                  You're positive that you have a correct alias for Phone_SIP_Server?  When you say transparent proxy, are you talking about Squid?

                  As for the wizard, it's a one-size fits-all GUI.  Bandwidth totals up/down are used by the HFSC shaper to do its calculations.  PRIQ doesn't use it, but it doesn't surprise me that the wizard bugs you for it.  You can enter anything.

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

                    That's an idea…
                    I'll try that and see if it makes any difference!

                    @sideout:

                    Perhaps your rule might work better if you used the port for SIP instead of the server IP under the floating rule section. This way ANY SIP traffic will get shaped how you want it.

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

                      Yep, I see an entry in the logs that basically looks like that.  It is resolving.

                      @BeerCan:

                      The rule should be working as it is if the alias is correct.  You can go to status –> system logs and click on the resolver tab.  In there you can see if the alias was resolved correctly.  It will look something like this

                      Aug 16 00:16:02	filterdns: adding entry 64.2.142.188 to table voipservers on host outbound.vitelity.net
                      

                      FWIW my floating rule looks similar.  The first 2 entries were for some external phones but those entries are now removed.

                      1 Reply Last reply Reply Quote 0
                      • KOMK
                        KOM
                        last edited by

                        Squid redirects port 80 traffic to 3128 or whatever the Squid port is, so it shouldn't have any effect on your queue rules.  Is your SIP server a device on your local subnet?

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

                          So, playing around with the floating rules and monitoring firewall logs and states, I can see that something isn't working here.

                          I've modified the floating rule for outbound connections so that it's looking for a SRC port range from 5060-5070
                          I've configured the floating rules to be set to log-on-match.

                          I've confirmed in the states table listing, after establishing an outbound call to my cell phone, that there is a state entry for the SIP phone using port 5060 and 5070
                          192.168.0.135 is the static IP assigned to the SIP phone.  72.1.46.10 is the translated address for the SIP proxy. (the same one I was using for my alias)

                          udp 72.1.46.10:6060 <- 192.168.0.135:5070 MULTIPLE:MULTIPLE
                          udp 192.168.0.135:5070 -> 76.97.14.107:56835 -> 72.1.46.10:6060 MULTIPLE:MULTIPLE
                          udp 72.1.46.10:6060 <- 192.168.0.135:5060 NO_TRAFFIC:SINGLE
                          udp 192.168.0.135:5060 -> 76.97.14.107:2557 -> 72.1.46.10:6060 SINGLE:NO_TRAFFIC

                          Also, I'm seeing these other entries that are using non-SIP related ports.  Not sure what these are for:

                          udp 72.1.46.24:26598 <- 192.168.0.135:16056 MULTIPLE:MULTIPLE
                          udp 192.168.0.135:16056 -> 76.97.14.107:8831 -> 72.1.46.24:26598 MULTIPLE:MULTIPLE
                          udp 72.1.46.22:31574 <- 192.168.0.135:16058 MULTIPLE:MULTIPLE
                          udp 192.168.0.135:16058 -> 76.97.14.107:50117 -> 72.1.46.22:31574 MULTIPLE:MULTIPLE

                          So after establishing the call, I see the above related entries in the state table, but I do NOT see any logging occurring in the firewall logs.  ??? :o

                          So if I don't see this activity being entered in the logs, then PFS isn't recognizing this SIP traffic as matching the floating outbound rule….which means PFS is not putting this traffic in the qVoIP queue!

                          So the question then is....why isn't the outbound traffic matching the floating rule??

                          [EDIT]

                          Try playing around with the Outbound floating rule some more to try and get things to match and have it show up in the firewall logs.  Now using the SIP phone's IP address as the SRC.

                          Looking more closely at the firewall logs, I can see when after making an outbound call, there's a log for a 'block' that is due to my SIP outbound floating rule.  This makes NO sense!

                          The UPSTREAM being referenced is the floating rule, which is simply configured to match the source (phone@192.168.0.135) to ANY/ANY (below)

                          Is something broken here??

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

                            my SIP phone is on the local subnet.  The SIP server is on the 'net, owned by the SIP service provider.

                            @KOM:

                            Squid redirects port 80 traffic to 3128 or whatever the Squid port is, so it shouldn't have any effect on your queue rules.  Is your SIP server a device on your local subnet?

                            1 Reply Last reply Reply Quote 0
                            • KOMK
                              KOM
                              last edited by

                              I would delete your shaper and start again.  Ensure 72.1.46.10 is your VoIP_Server alias.  Create a simple PRIQ shaper with just VoIP support and use your alias as the provider.  Then make some test calls and see if there is traffic in qVoIP.

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

                                I've actually blown everything out (shaper) before this…a couple of times.
                                I'm not sure how I can verify the IP addresss of the SIP server, short of contacting the provider and asking them...again (I actually asked them for the IP address initially, but they didn't know...could only tell me the FQDN, which I figured was fine).

                                I'm assuming then that from what you're seeing in the screenshots, that nothing is specifically configured wrong, right?  You're thinking that the system is just confused somehow and want me to wipe everything out and start again?

                                @KOM:

                                I would delete your shaper and start again.  Ensure 72.1.46.10 is your VoIP_Server alias.  Create a simple PRIQ shaper with just VoIP support and use your alias as the provider.  Then make some test calls and see if there is traffic in qVoIP.

                                1 Reply Last reply Reply Quote 0
                                • KOMK
                                  KOM
                                  last edited by

                                  Yep.  Start again with something simple and then build on it.  When I asked about your alias, I meant in your Alias table in pfSense.  If you have the alias misconfigured, the rule won't ever match the traffic.  For testing purposes, use the IP address instead of the alias.  You can always change it later.

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

                                    So…something a little interesting. :)

                                    I decided, despite the weird behavior with the firewall log not showing a match...and that it's blocking that earlier connection outbound, I tried to just make an outbound call and watch the qVoIP queue anyway.

                                    Queue is working!!  >:( :o ;D

                                    Tested with an inbound call.  (This floating rule hasn't been modified and looks the same as it always has - using the alias).  Queue is working.

                                    Okay...so thinking maybe somewhere along the line I unknowingly fixed something 'somewhere', I decided to change the OUTbound floating rule back to its previous auto-generated state.
                                    Queue no longer working!

                                    For now, I'm just going to configure the outbound rule to match the SRC address of the SIP phone.  Apparently, there's an issue with having the Outbound rule match when the DST is the SIP server.  BTW, the fact that the queue works for inbound must mean that the SIP server alias must be correct.....so therefore, it should work on the OUTbound side too.

                                    1 Reply Last reply Reply Quote 0
                                    • KOMK
                                      KOM
                                      last edited by

                                      Interesting.  I'm glad to her it's working for you.  I wonder why it didn't work with the auto rules.

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

                                        Unless I have something configured somewhere that I'm not seeing that is causing this, it would seem to be bug.

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