Feature #10186
closedAbility to do inverse matching of tags in floating rules
100%
Description
Summary:
I would love to be able to set up floating rules that match traffic on an interface that has NOT been tagged with a certain tag (inverse matching). Essentially, I would like to be able to implement the following type of pf-rules in pfSense:
block out quick on RED_NET ! tagged RED_NET_OK
Example Use Case
Suppose you have a highly sensitive network on the "RED" interface. No traffic is allowed to go out on the "RED" interface unless it comes in on the "ORANGE" interface and targets one of a few explicitly allowed services. Ideally, the rules securing that no disallowed traffic enters the "RED" network should be few and simple to ensure that no changes by mistake breaks the protection. A simple way to do this is to add a floating rule that blocks all traffic out on the "RED" interface that has not been explicitly tagged as permitted (a policy based approach).
Solution
With my rather limited understanding of the internals of pfSense, I am guessing this could be implemented in the following way (also suggested by jimp at the forum):
1. Change the code that generated the PF rules to check for a leading "!" in the value of the "tagged" field. If there is a leading "!", the codes should add a "!" before the "tagged" keyword of the rule and remove the "!" from the name of the tag in the rule.
2. Change the input validation code of the floating rule create/edit form to allow a leading "!" in the tagged field value
A slightly better solution could be to add a "Invert match" checkbock for "tagged" similar to the ones used for source and destination matching. To avoid changing the underlying data model; the value of the checkbox could be saved as a leading "!" in the value of the "tagged" field of the rule.
Thank you in advance!
Updated by Jim Pingle over 4 years ago
- Project changed from pfSense Packages to pfSense
- Category set to Rules / NAT
- Assignee set to Jim Pingle
- Priority changed from High to Normal
- Target version set to 2.5.0
Updated by Viktor Gurov over 4 years ago
Updated by Jim Pingle over 4 years ago
- Status changed from New to Pull Request Review
Updated by Renato Botelho over 4 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
PR has been merged. Thanks!
Updated by Viktor Gurov over 4 years ago
- Status changed from Feedback to Resolved
Renato Botelho wrote:
PR has been merged. Thanks!
tested on 2.5.0.a.20200119.2335
works as expected