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

    Queue matching: Floating vs Interface rules

    Scheduled Pinned Locked Moved Traffic Shaping
    5 Posts 2 Posters 2.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.
    • M
      moikerz
      last edited by

      I'm a little confused on how to match traffic to a queue, vs firewalling traffic. I think I have it, but I just want some confirmations or clarifications.

      I have traffic identified on the Floating Rules tab, set as 'Match' only, and directing said traffic to the relevant queue.

      I also have the traffic identified on the WAN and LAN tabs, set as 'Pass', and also directing said traffic to the relevant queue.

      It seems like I have a setup with unnecessary clutter. Which is the best way to match traffic to queues? Via the WAN/LAN, or via Floating Rules? I was thinking of using the Floating Rules to 'Match', and the WAN/LAN rules to pass/block - would this be better?

      See attachments for firewall rules.
      pfsense_fw_floatingrules.jpg
      pfsense_fw_floatingrules.jpg_thumb
      pfsense_fw_wanrules.jpg
      pfsense_fw_wanrules.jpg_thumb
      pfsense_fw_lanrules.jpg
      pfsense_fw_lanrules.jpg_thumb
      pfsense_fw_vlan9rules.jpg
      pfsense_fw_vlan9rules.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • N
        Nullity
        last edited by

        General rule is to match traffic (firewall rule) on the interface where the traffic originates.
        Traffic-shaping queues only shape data being transmitted.

        If traffic leaves the WAN through "qArbitrary", when the related traffic returns it will be assigned automatically to "qArbitrary" on the LAN (if the queue exists on the interface).

        So, most of the time you only need to match traffic at the origin and name your queues accordingly.

        Be careful PASSing traffic on WAN as that is allowing traffic from the internet.

        Please correct any obvious misinformation in my posts.
        -Not a professional; an arrogant ignoramous.

        1 Reply Last reply Reply Quote 0
        • M
          moikerz
          last edited by

          Good, thank you for the clarification.

          @Nullity:

          If traffic leaves the WAN through "qArbitrary", when the related traffic returns it will be assigned automatically to "qArbitrary" on the LAN (if the queue exists on the interface).

          Referencing your comment above in bold:
          If traffic exits on qArbitrary, then the queue logically must exist on the return leg of the journey (unless it's asymmetric routing). Else it would never have been in the queue in the first place. Is this correct?

          1 Reply Last reply Reply Quote 0
          • N
            Nullity
            last edited by

            @moikerz:

            Good, thank you for the clarification.

            @Nullity:

            If traffic leaves the WAN through "qArbitrary", when the related traffic returns it will be assigned automatically to "qArbitrary" on the LAN (if the queue exists on the interface).

            Referencing your comment above in bold:
            If traffic exits on qArbitrary, then the queue logically must exist on the return leg of the journey (unless it's asymmetric routing). Else it would never have been in the queue in the first place. Is this correct?

            The return packet (download traffic) will be queued at the LAN queue. (Technically, downloads are throttled as a side-effect of rate-limiting packets being transmitted to LAN.)

            Asymmetric routing is unrelated, AFAIK. The firewall rules deal with assignment of packets to the queues, while the queues only deal with scheduling any packets they are assigned.

            Please correct any obvious misinformation in my posts.
            -Not a professional; an arrogant ignoramous.

            1 Reply Last reply Reply Quote 0
            • M
              moikerz
              last edited by

              Got it - thanks!

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