4. Basic Shaper help needed

Basic Shaper help needed

  • C

    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?

    0

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

    0
  • C

    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.

    0

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

    0
  • S

    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.

    0
  • B

    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.


    0
  • C

    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.

    0
  • C

    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.

    0
  • C

    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.

    0

  • 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?

    0
  • C

    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??

    0
  • C

    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?

    0

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

    0
  • C

    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.

    0

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

    0
  • C

    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.

    0

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

    0
  • C

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

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

Our Mission

We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy