Help marking (tagging/matching) traffic

[senseivita]

Yesterday I noticed the main firewall was rejecting traffic. I was really hard to find but it finally appeared as a single TCP RST in a capture. I lost all day on that line. It had been working for months month indicating, I think, my rules were so carelessly put together that would fail on certain circumstances only; the worst kind. These were outbound floating rules BTW.

I want to assign outbound/gateway-ed interface to traffic on the way out, sort of like a dam, if you will, or a bouncer where only traffic with the right tag is allowed out over a certain interface(s). (I just figured this out, next)

A while back the bufferbloat doc was helpful putting floating rules into a new perspective of being capable of filtering what it seems "outside of the firewall", because the modifications done on that article are done from the interface after NAT on the way to the gateway, like the postrouting chain on Mikrotik. It was really, really helpful, but I still can't make the tag field work.

Because of the fact that tags survive NAT, it would mean that if traffic was already chosen to be natted with an interface's IP address, even if I could steer it away from it, it would still be alreadt natted with the wrong IP address, therefore choosing interface on the way out is out of the question, correct? I kind of realized this on the last paragraph. However, it would still be useful — and the thing that interest me the most — is an alternative way of negated rules to prevent traffic from escaping over the wrong gateway.

I made a little drawing to explain myself better:

The empty grayed out floating rules area, is there only visualize their place, or my understanding of them at least. It's empty because I don't know if action=match floating rules are needed--though those are inbound floating rules so they'd be the same as interface rules, right? "Inside of the firewall". I need to learn proper terminology too.

Could you help me out to construct an example rule using tags? As of my latest enlightenment, I think on the outbound side interface selection isn't such a big deal as it is preventing the tagged traffic from reaching said interface's gateway, however, I've seen the light so many times I'm starting to think it may have left me 🤬 blind because I still can't make it work.

Thanks!

[SteveITS]

@skilledinept I'm not sure I understand your goal, but if it's to control routing policy routing may be easier.

I've used tagging for traffic shaping from specific devices, because otherwise the outbound packets are seen "after NAT." So, two rules:

1. floating LAN, source VoIPDevices alias, tag=VoIPQ
2. floating WAN, source any, tagged=VoIPQ, queue=qVoIP

Then that can be used to match UDP coming off of PCs, for instance Teams or video calls when the destination is unknown.

[senseivita]

@steveits Oh!

(I'm still processing… )

OK. Got it, so I wasn't that far off and thanks for answering, BTW. What's the action for each rule though?

I'm already using policy routing, very complex policy routing mostly because of DNS, which got so much worse when DoH went mainstream. :(

Check out one of my interfaces, trusted users, reserved DHCP-only:

Firefox zoomed out to 50% so it would fit.

I digress though, I had this issue which I solved already but I still would like to know how to set this — policy filtering — up just for closure, I've tried it on several occasions and I would always end up frustrated and ranting and whatnot, yeah...not proud. After cooling off I would realize I forgot to flush the states but by then I already undid a ton of stuff or something, more time passes then I get the bug again already having forgotten all about last time and the cycle repeats. It's masochistic at best.

If you just tell me what are the actions for rules 1 (tag VoIPQ) and 2 (tagged VoIPQ), I'll be forever in your debt…my first born, a kidney, sexual favors, join a cult, anything.

Thanks again!

[Bob.Dig]

@skilledinept Another example is a VPN Killswitch via tags.
On one interface you have PBR with a gateway set other than WAN. Also traffic gets tagged in that rule.
On WAN you have a broader rule which blocks everything that was tagged before.
So if a packet intended for the VPN-Gateway goes out the WAN interface, it will be blocked.
"Killswitch" done.

[SteveITS]

@skilledinept said in Help marking (tagging/matching) traffic:

What's the action for each rule though?

The Action can just be Match since (I assume) you're not trying to also allow or block the traffic in these rules, just put it in a queue.

Using Quick or not depends on whether you want other floating rules to process. Without Quick, last match wins.