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

    Moving Traffic into the right queue

    Scheduled Pinned Locked Moved Traffic Shaping
    11 Posts 3 Posters 3.0k 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.
    • L
      LeSilverFox
      last edited by

      Hi everyone…

      I’ve been using pfsence (2.1.5) 64 bit for the past 2 months, running it as a VM on my esxi host. I love it because the flexibility I got with source based routing and multiple VPN tunnels.

      Well, I ventured into the QoS arena and I got stuck pretty quick and I wonder if anyone could offer me some advise. One of my computers at home is used to connect to a remote ftp server and download a rather large files. When it happens, it practically eats up all the bandwidth, which I’d like to control by reducing its traffic priority.

      I ran the wizard and trying to use what it produced. I used the PRIQ scheduler which created 4 queues. During the wizard run, I picked the ‘penalty box’ specifying the ip address of the ftp client, thinking to limit the traffic that way. Long story short, the traffic from that pc goes in the wrong queue. It always ends up in qLink - the default queue.  I looked at the floating rules and try to make small changes - to no avail.

      I attached my FW rules. The two rules filtering traffic for 192.168.1.222 are setup for WAN and outbound.  I reset states - made no difference.

      All the other queues for DNS, etc  seem to work fine, these queues are getting traffic.

      Thanks for any pointers..

      FW_rules.png
      FW_rules.png_thumb

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

        What action do you have in your floating rules, PASS, MATCH, REJECT or BLOCK?

        1 Reply Last reply Reply Quote 0
        • L
          LeSilverFox
          last edited by

          Thanks for coming back so promptly.

          I have MATCH for both.

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

            Good.  It looks like it should be working.  Even though it's on the Floating screen, do you have a specific interface selected for the rule?  Please show the rule edit screen of your ftp rule.

            1 Reply Last reply Reply Quote 0
            • L
              LeSilverFox
              last edited by

              I have the WAN interface selected for both rules. Please see attached.

              I read a lot of posts here on traffic shaping, trying to get the gist of it and for earlier version of pfsense people were saying they needed to add a second fw rule on the LAN interface. Today, I only have a floating rule.

              floating.png
              floating.png_thumb

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

                I'm pretty sure a floating rule on WAN out will already be NAT translated so you can't match on source 192.168.1.222 there.

                It gets tricky.  I have found that if you don't care about queuing ALL traffic from that host on FTP, assign the queue on LAN in.

                If you DO care about leaving some FTP unqueued (or queued differently) then you have to get creative.

                If you have multiple public IPs you could make sure the outgoing FTP traffic always got translated to a specific IP and use that as the source address on WAN out.

                You could also create a rule above your more general rules on LAN that passes the traffic from src 192.168.1.222 dest any port 21.  In advanced, mark it with something like WAN_QFTP.  Then you could put a floating match rule on wan out that matches src any dest any tagged with WAN_QFTP and puts it in the right queue.

                There's lots of flexibility with pf but it certainly adds to the complexity when you start using it.

                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
                • L
                  LeSilverFox
                  last edited by

                  Derelict:
                  thanks for the very constructive feedback - I'll try it later when I'm back home.

                  1 Reply Last reply Reply Quote 0
                  • L
                    LeSilverFox
                    last edited by

                    One additional quick question;

                    the shaper creates a qACK for the TCP acknowledgements. How do the ACK packets end up in that queue ? I see no floating or any other rule that moves these packets into qACK. And yet, the queue is working as expected.

                    1 Reply Last reply Reply Quote 0
                    • L
                      LeSilverFox
                      last edited by

                      Derelict:

                      Thanks for your suggestion, I did what you described and it's working perfect !!!!  ;D

                      I created rules on the LAN side of the interface to catch and mark the packets and the corresponding floating rule to move them in the right queue. I added extra rules to try and test different scenarios and this approach seems very reliable.

                      Thanks everyone for guiding me to a solution..

                      PS: I also got the answer to my previous question on the how qACK gets filled - we specify this queue per floating rule at the bottom of the rule page..

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

                        I'm pretty sure a floating rule on WAN out will already be NAT translated so you can't match on source 192.168.1.222 there.

                        I also wondered if this was the problem, but I don't have a clear picture on the packet flow through the system and what gets applied when.

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

                          There are diagrams in the 2.1 book.  I'm not exactly sure where floating rules come in.

                          Here's one paste.  I am operating on the assumption that a floating rule on WAN out pushes the firewall rules on WAN back into the path and that's the proper order.  LAN rules, then floating on WAN out for outbound states.

                          ![Screen Shot 2014-11-27 at 1.45.09 PM.png](/public/imported_attachments/1/Screen Shot 2014-11-27 at 1.45.09 PM.png)
                          ![Screen Shot 2014-11-27 at 1.45.09 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2014-11-27 at 1.45.09 PM.png_thumb)

                          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.