PRIQ on different interfaces
-
Quick question. Does the priority span interfaces or are they unique to each interface?
As an example, if I have a LAN1 default queue set to priority 1 and a LAN2 default priority set to 2, will LAN2 have a higher priority when going out to WAN?
Thanks
-
Priorities are assigned to queues and queues are assigned to interfaces. Packets don't get prioritized, queues do.
Does the priority span interfaces or are they unique to each interface?
Nope. They are unique per interface.
I should also mention that priorities are only applied to packets leaving an interface. This makes your question kind of moot. It doesn't matter which interface your packets enters, all that matters is what rule matches and which queue your rules assign a packet to. Of course you can have a rule on your LAN interfaces that makes packets get placed in different queues based on which interface they enter.
-
Good to know.
How would I handle prioritizing one LAN over the other? If priority is outbound of the interface, and NAT rules are processed before firewall rules are evaluated, wouldn't that make it impossible to have one LAN take precedence over the other, as the source address would always be the WAN address?
Thanks again.
-
@mbarnes:
Good to know.
How would I handle prioritizing one LAN over the other? If priority is outbound of the interface, and NAT rules are processed before firewall rules are evaluated, wouldn't that make it impossible to have one LAN take precedence over the other, as the source address would always be the WAN address?
Thanks again.
I think you are correct that if you place a floating rule on your WAN that tries to match a new egress state, you cannot tell which LAN interface the state is coming from because of NAT, but if you place a rule on the appropriate LAN interfaces, then you know which interface the state is coming from.
So. Match on the ingress of the LAN interface instead of the egress on the WAN interface.
Of course, someone else may know more about how to better use the firewall and give more ideas, but I figured I'd try to be helpful since no one else has yet.
-
Noted.
Does that still work for outbound traffic? That is, if the state is LAN -> WAN, and I'm matching outbound on LAN, does that work? What about the Ack/Queue? Does the logic flip if matching the other way? Does throttling/prioritizing Queue and Ack work the same if limiting both upload and download speed regardless of the connection initiation direction? Or am I looking at this from the perspective of how PF works and actually ALTQ doesn't have the same concept of "direction"?
Thanks a bunch.
-
Your questions are more related to how the firewall works and not traffic shaping.
if the state is LAN -> WAN, and I'm matching outbound on LAN, does that work?
Traffic going from LAN to WAN is entering the LAN and exiting the WAN. Matching outbound LAN will not match that.
The firewall is quite simple except for floating rules. Even then, it's still simple, just less simple. The simplest way is to just place a pass rule on your LAN interface that assigns the state to whatever queue you want. The general idea is the state is created and assigned on the interface that first sees the new state. The one exception to rules applying to ingress only is floating rules being able to apply
This may help a bit https://doc.pfsense.org/index.php/What_are_Floating_Rules
-
Another option I've seen mentioned but not actually done much with is to use a rule to mark the packet on one side, and match the mark on the other side.
In rules, advanced options, advanced features.
-
Another option I've seen mentioned but not actually done much with is to use a rule to mark the packet on one side, and match the mark on the other side.
In rules, advanced options, advanced features.
Do you mean to "mark" using 802.1p?
-
No; as far as I understand it these "marks" are internal to the firewall.
http://www.openbsd.org/faq/pf/tagging.html
Quote from link above: "Tags are internal identifiers. Tags are not sent out over the wire."
-
Ahh, internal metadata. I didn't see anything in the rule UI. I'd be interested in this.
-
IIRC, if traffic is assigned to qArbitrary, then when the reply traffic arrives, if there is a similarly named qArbitrary on that interface, the traffic is automatically assigned to that queue.
I dunno if that is useful or not, but there it is. :)
-
Ahh, internal metadata. I didn't see anything in the rule UI. I'd be interested in this.
It's there, but VERY understated. One box for marking (put on a rule on one side) one box (lower) for matching (put on a rule on the other side) Both are in the Advanced features section on the bottom of the rule page which you may have to scroll down to even see, and then in the Advanced Options part of that.
The text below the first one sayeth: You can mark a packet matching this rule and use this mark to match on other NAT/filter rules. It is called Policy filtering
The text below the second sayeth: You can match packet on a mark placed before on another rule.
-
Ahh.. Seems to be a text field. I wonder if it's actually internally doing string compares. If it is, shorter strings are better.