How do I match tagged traffic?
-
@skilledinept
When you use tagged VLANs, all devices have to use the same VLAN ID. For example, I have my guest WiFi on VLAN 3. So, I configured VLAN 3 on pfsense, my Cisco switch and Unifi AP for the guest SSID.
-
@JKnott Hey thanks,
But what I mean was marking, I didn't want to use tagging because it's ambiguous but that's how it's called in the UI--it's odd bc in the docs they use they use marking/matching. Thanks anyway.
If you know how how to policy filter, I believe that's what's called, I'd appreciate the help though. This is the one feature I've never been able to figure out. :/
-
@skilledinept said in How do I match tagged traffic?:
If you know how how to policy filter
On what exactly? If you don't want a device on network going out, then block it - you don't need to tag it and then use a floating rule?
What exactly are you wanting to accomplish?
-
@johnpoz I'm not looking to actually filter but rather policy route but with tags.
I want to learn this so I can create more complex rulesets and to modify routes without having to go through every internal interface -- rarely they're fewer than the external ones -- create rules that wouldn't otherwise work because of the lack of reply-to and see what else can be done. :)
I have to learn how to create a simple rule pair first, on which I keep failing miserably before I get distracted or something.
Could you tell me how is the floating rule set up, please? The gateway isn't chosen in the gateway section like on LAN rules, is it?
-
@skilledinept off the top not sure how the gateway selection in an outbound rule would come into play. With outbound rules the nat has already happened. So match could be used to block or allow traffic out a specific interface.
Do you have multiple gateways using the same source IP??
-
@johnpoz said in How do I match tagged traffic?:
off the top not sure how the gateway selection in an outbound rule would come into play.
[I meant to answer sooner but it took a while to retest and stitch screenshots, sorry]
Yes, I figured as much--well, except for the NAT part. What I know, very loosely is that the WAN interfaces (or other interface) that pass the tagged traffic become the only ones that are allowed to do so. Which would mean that tagging traffic in the LAN interfaces is actually consequential and cannot (the tag) just be discarded so the rule is evaluated using the without it. Since the WAN interface itself is the counterpart for the mark, it assumes the role of the gateway — and validates my unverified notion that the matching tags act like floodgates, where there's one traffic is allowed to go out like a more carefree multi-WAN — therefore there's no need for gateway.
I learned most of this from a presentation playing in the background several years ago. It was before I even knew what pfSense was. I can't find the video anymore, it was about VoIP in some Mikrotik seminar (ouch).
This is the real ruleset:
I'm not load balancing if that's what you mean for several gateways for a source. I do have several gateways, tunnels, I'm not load balancing though. Some traffic (DNS for DCs) is tiered+load-balanced but it doesn't apply to the test group. Before answering, I downsized the scope to a single host and bypassed all the rules (screenshots above) double-checked it matches the example from earlier.
-
In the screenshots the tag doesn't match. It just an accidental keystroke while taking the screenshots, it wasn't saved. Both rules have the same tag:
udef_v. -
@skilledinept said in How do I match tagged traffic?:
How does the floating rule matches the traffic out?
Did you find this doc section? The paragraph above that discusses direction. Going out WAN the packets have all been NATted so you can't ID by LAN IP.
For instance a floating rule on LAN to tag VoIP traffic from certain IPs, and another floating rule on WAN to put that tagged packet in the qVoIP queue to prioritize it.
-
@steveits said in How do I match tagged traffic?:
Going out WAN the packets have all been NATted so you can't ID by LAN IP.
Yep, but that's taken care by the tag isn't it?: "This is a useful way to act on WAN outbound traffic from one specific internal host that could not otherwise be matched due to NAT masking…".
Then it goes "on a LAN rule, (…) Then on a floating rule, quick, outbound on WAN, use Tagged with the same string to act on the traffic matched by the LAN rule." I thought that was what I had. Apparently I don't.
Thanks for answering, BTW.
-
I disabled the floating rule and echo reqs started flowing in my test host. The marking the traffic on itself doesn't make a condition to evaluate. Having a rule that matches the mark, however, does. And, it "steals" the traffic with the mark but it doesn't steer it:
I removed interface selection from the floating rule, saved, applied, cleared states et voilà, on y va.
Added a gateway on the floating rule just to rule it out, heh, saved, applied, cleared. Dead.
Then I started experimenting:
- I selected the desired gateway interface in the floating rule, traffic kept flowing except it was NATted from the default gateway.
- I tried changing the direction every which way(
in,out,both), nope. - I tried adding the desired gateway interface in addition to the interface where the traffic is sourced from, no. (floating rule
if:lan_z0009,wan_z2522usdetroit) - I tried the default gateway (
wan_gpon) from where traffic would otherwise exit. nope. - After each modification of interface I also modified the direction for each. Save-Apply-Clear-Repeat.
Then I reread the docs really slow out loud, 'cause that's how devices work, everybody knows that.
Marking and Matching
(...)
It can also be used similarly for applying shaping outbound on WAN from traffic specifically tagged on the way into the firewall.It stood out: specifically tagged on the way in… and shaping. What's used for queues and shaping? Match.
Match Action
The match blablah… for purposes of assigning traffic to queues or limiters for traffic shaping. Match rules do not work with Quick enabled.
I was making conspiracy theories now but it's worth the shot: I changed the action from
passtomatch. Retried everything plus an extra step for quick and non-quick. Save-Apply-Clear-Repeat. Traffic actually kept flowing but NAT wasn't changed. Somehow I managed to change the direction of the echo requests though. :)
It sort of worked except for NAT, which was the biggest appeal, at least of the way I thought things worked. It was distressingly fun. Thanks for your help!
-
@skilledinept said in How do I match tagged traffic?:
Then I reread the docs really slow out loud
LOL. That has helped me in life too. Glad you got it sorted. I also have found it helpful to look at states when matching traffic because things like a web server response (download) are via an incoming state (HTTP get).
