Firewall Rules - Interface
-
@steveits Yeah I would think prob just a UI thing, easier to just list all the interfaces, then limit it to that specific interface or a cidr/host etc..
As to 2b, yeah if the interface is actually a transit network to another router you would have to allow for the downstream networks coming into that transit interface.
-
@LeeS Re. Q1a / Q1b - Yeah, that is just extremely poor UX. What I've noticed is that if I'm on the LAN 1 interface, and I select from the dropdown LAN 2 when adding a rule, it actually adds the rule to LAN 2 interface, even though I clicked Add when I was on LAN 1. This absolutely causes needless confusion as it should not be possible to select anything other than the interface you navigated from.
Here's how to add new feature requests / improvements into the queue, https://redmine.pfsense.org/projects/pfsense/issues?set_filter=1&tracker_id=2
I've just put a request in to upgrade this as I feel that this very small addition will make a huge impact for the UX and to avoid confusion. Let's see if this gets accepted/rejected by the community - https://redmine.pfsense.org/issues/13384
-
OK! Now I think we're getting to the bottom of the / my "issue"!
If I understand correctly the responses above from @johnpoz and @SteveITS , my conclusions are kind of right? :-
Interface Selection on New Firewall Rules
When creating a new firewall rule for any given interface, the selection for which Interface this is evaluated on will (almost?) always be the interface for the network from which traffic originates / is initiated. For example, if a new rule is to be created for LAN1, then the interface to select is always LAN1 as traffic to be evaluated will (always?) be coming from the LAN1 network which is "attached" to the LAN1 interface.
@MichaelCropper - I had a look at the feature request you added but I think the sentiment of the request is not quite accurate. In it, you say:
"it should default to OP2 (in this example), aka the Interface from which I choose to Add/Edit a rule on"
Actually, that already is the default action that the form delivers, so in that respect it's working correctly.
The "problem" (if it can be called a problem) is that there is a choice of interfaces and other options which seem to be "irrelevant" to the interface on which the rule is being created. This causes confusion to "pfSense-newbies" (of which I most definitely class myself as one) because if a choice is presented (even though the correct option is selected by default) then a newbie will think that a choice should be made and starts questioning how to determine which one should be chosen, when in actual fact, he / she probably should not even touch the selection menu because it defaults to the correct one already.
It's entirely possible of course that this is intentional, but as has been said, this is either not clearly stated / documented or (at least its seems that) it's bad / lazy design (just dump a list of all the possibilities into a selection menu, rather than dynamically filtering and displaying the legitimate possibilities - in my opinion, this is what the feature request should be about)
This of course leads into the next section of the New Rule Edit form: Source, where I think the same / similar "problem" / confusion exists:
Source Selection on New Firewall Rules
The drop-down box for Source also lists all the existing interfaces and associated networks as options, similar to that for the Interface drop-down box, with the addition of a few extras. In the pfSense documentation these extras are described as:
- Any: Matches any address
Really? If so, that means that the interface (LAN1 for example) is not just evaluating traffic inbound from its own network (LAN1 net in this example) as concluded earlier, but it is also able to evaluate traffic inbound from ANY network (LAN2 net, LAN3 net, etc.) and means the original premiss that an interface only evaluates traffic inbound from its own network is therefore incorrect. That being the case, both 1 and 2 in my diagram earlier can be either inbound (ingress) points as well as outbound (egress) points, depending on what is selected in the rule creation for source and destination.
- Single host or Alias: Matches a single IP address or alias name. When this is active, an alias name may be typed in the Source Address field.
Makes sense, but the same question arises as for the Any option: can the Alias contain objects from ANY network, or only from the network of the interface (LAN1 in our example here) on whch it is being created?
- Network: Uses both an IP address and subnet mask to match a range of addresses.
Again, same question: is this a range of addresses from (extending our example) LAN1 net, or from any network (or even a range spanning multiple networks)?
- the PPPoE Clients and L2TP Clients options seem more advanced and I'm assuming less common as choices
The Interface Net and Interface Address options are lists of net and addresses for each interface as we've been discussing, but the descriptions are interesting and possibly revealing the answers to my questions:
- Interface Net: An entry in this list is present for each interface on the firewall. These macros specify the subnet for that interface exactly, including any IP alias VIP subnets that differ from the defined interface subnet.
This suggests that traffic CAN originate from ANY interface and not just the network of the interface we are creating the rule on. This would again contradict the premiss made earlier that rules are only created based on the network for the interface we are creating a rule on.
- Interface Address: An entry in this list is present for each interface on the firewall. These macros specify the IP address configured on that interface
Again, same as above.
I have similar / some other questions on the Destination selections, but I think I've ranted on enough!
-
@lees said in Firewall Rules - Interface:
made earlier that rules are only created based on the network for the interface we are creating a rule on.
Not always true - again, if the interface is a transit network.
You know - sometimes when running a firewall for your network, you actually need to understand what your doing.. Options are presented because there options, not every network is the same. Maybe your creating a floating rule - where you can use multiple interfaces, etc.
While true - if creating a rule on lan interface, highly unlikely wan would be the source. But filtering the possible sources depending on what interface your on becomes a programming complexity... When you have to assume the operator actually understands what they are doing.
If you want to write the code that provides only the valid selections for any given situation and every possible interface or configuration - then have at it, sure they would welcome your PR..
Your asking for limitations on choices based on what could be valid. This becomes problematic in "knowing" all the possible variables of what a user might be doing, how the network is configured if they are on source or destination, or they are in floating and then limiting to only valid choices.
Vs just presenting the admin of the firewall, the choices and believe they actually know what they are doing ;)
-
@johnpoz wow, I think you just suggested that I don't know what I'm doing?
Sorry to have to disappoint you but I've been in the industry for over 25 years and know exactly what I'm doing, hence the reason I'm able to ask the questions I'm asking so that I can "map" what pfSense is doing to what the rest of the global industry does. I know pfSense is a fabulous product and has a fantastic development base, but you should not judge a "pfSense newbie" as a general newbie, they're not the same.
I guess I will leave my questioning and this thread there by thanking you very much for your input and my apologies for wasting your time.
-
@lees not wasting anyone time discussing a topic.
And I wasn't saying you don't know what your doing - what I am saying is trying to limit choices when there are almost limitless possibilities and different scenarios where choosing say optX net vs OptY net
While sure optX is not really a viable source for optY interface - it is a valid selection for destination. What about if a floating rule, what about on a bridge that might bridge multiple networks? etc..
What if rule is for outbound on Lan interface in floating, and I don't want the source of the traffic as outbound to come from source optX. There are lots of variables to come into play determining what exactly could be valid in a specific setup, on a specific interface on a specific source or destination, etc. So lets program in all the possible checks to make sure the rule is valid to present the user only "valid" settings - vs just presenting them the choices.
So vs just presenting the possible networks as choices, you feel the developers time would be better spent making sure the new user doesn't shoot themselves in the foot by making a rule that would never work.. Say optY as source on optX interface is where they should spend their time. Not a lot of bang for your buck if you ask me.
Someone that is admin a firewall should understand that hey your not going to have wan net as a source into your Lan interface, etc.
If you feel it is so easy to do that hey why haven't they done it - again your more than welcome to submit the PR..
I am not a developer, but have worked with enough of them and have dabbled in my day with scripts and routines.. If you have a routine that presents the possible choices its much easier to just use that routine where those choices could be used vs having to have different code for each and every possible scenario and filtering on what is valid or not valid for this specific scenario. This isn't an interface grandma is suppose to be able to use correctly - this is an interface for a firewall - where you would hope that the person doing the rules understand what is a valid source or destination for their rule they are writing.
edit: How many people do you think put in say normal gas into their diesel vehicle? While diesel nozzle is normally too big to fit into gas cars - the gas nozzle will fit into a diesel.. Shouldn't they fix this? I mean they could make so its impossible - just shape the nozzle so in no scenario could they fit into each other.. Or do they make a call on doing that cost too much time or money for something the operator should clearly know what fuel to use.
You have been in the business a long time - what firewall do you know that prevents an invalid rule from being created? Cisco you can put both trunk and switchport settings on a port - that is invalid config, why doesn't cisco prevent this?
-
@lees said in Firewall Rules - Interface:
if a choice is presented (even though the correct option is selected by default) then a newbie will think that a choice should be made and starts questioning how to determine which one should be chosen, when in actual fact, he / she probably should not even touch the selection menu because it defaults to the correct one already.
If one goes to Rules/LAN and creates a rule using WAN, note the rule will be on the WAN tab (and the UI takes you there upon saving).
As I alluded to above I think it's intentional for copying. One can copy a rule, which opens up the edit page, change the interface (to LAN2, etc.) and save. If they remove other interfaces from the list, they will probably need to create another way to copy rules to a new interface.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#rules-and-interfaces
(to save a click, "Traffic is filtered only by the ruleset configured on the interface where the traffic is initiated. Traffic coming from a system on the LAN destined for a system on any other interface is filtered by only the LAN rules.")
That's probably somewhere in the not-troubleshooting pages but I didn't see it in a quick look. -
@steveits said in Firewall Rules - Interface:
As I alluded to above I think it's intentional for copying. One can copy a rule, which opens up the edit page, change the interface (to LAN2, etc.) and save
Yes that does indeed make sense to make them all available for copying.
-
@michaelcropper said in Firewall Rules - Interface:
I've just put a request in to upgrade this as I feel that this very small addition will make a huge impact for the UX and to avoid confusion. Let's see if this gets accepted/rejected by the community - https://redmine.pfsense.org/issues/13384
No, please don't do that, I prefer it just the way it is! Once you make a dozen or so firewall rules, on a wide range of interfaces, this will become second nature. It's perfect just the way it is now. Really, in my opinion, it's not as bad as you're making it out to be.
-
I think I've had a change of heart about this topic!
I've thought long and hard about why there is a choice of interface when creating a new rule, thinking it can't just be because it's easier to just dump all the available interfaces. There had to be a reason why it's presented that way.
Then it dawned on me. That's exactly what is required when creating a new rule. I thought about what @MichaelCropper said when he wrote:
"What I've noticed is that if I'm on the LAN 1 interface, and I select from the dropdown LAN 2 when adding a rule, it actually adds the rule to LAN 2 interface, even though I clicked Add when I was on LAN 1"
Think about it. It actually proactively prevented you from creating an invalid rule on the LAN1 interface by moving it to LAN2 where is should be.
The clue is in the description under the pull-down menu of interfaces:
"Choose the interface from which packets must come to match this rule."
Remembering the premiss throughout this whole thread - that rules are based on inbound traffic to an interface - this suddenly made a lot of sense. If you are trying to create a rule on LAN1 to say block traffic coming from LAN2 and select LAN2 as the interface, then of course it's going to move it to LAN2, as that's where the traffic is coming from. It actually prevented an invalid rule being created in the LAN1 ruleset. So perhaps the ability to select an interface is there by design to prevent invaild rules being created!
It's still a little counterintuitive by having them available in the first place though I guess, after all, if they're not available in the first place then they can't be incorrectly selected, but at least if another interface is selected, pfSense does move it to where it should be.
-
One thing I have noticed though: when testing this out on 2 interfaces (LAN1 and LAN2), if I create a rule on LAN1 to allow all LAN1 net traffic to any, even if there are no rules created on LAN2 (which I thought means that all traffic is implicity blocked), I can still ping LAN2 devices from LAN1....so that's a bit confusing!
-
pfSense software is a stateful firewall, which means it remembers information about connections flowing through the firewall so that it can automatically allow reply traffic. This data is retained in the State Table. The connection information in the state table includes the source, destination, protocol, ports, and more: Enough to uniquely identify a specific connection.
Using this mechanism, traffic need only be permitted on the interface where it enters the firewall. When a connection matches a pass rule the firewall creates an entry in the state table. Reply traffic to connections is automatically allowed back through the firewall by matching it against the state table rather than having to check it against rules in both directions
-
@bob-dig many thanks! Makes perfect sense now
-
@lees you understand there are 3 places there are drop downs when you create a rule - it defaults to the interface your on when you click add..
The top one - but there is also source and destination
Yes if you change the top one it will put the rule there, because your specifically calling out what interface to put the rule on.
Thought you were talking about the source and destination drop downs.. You can put a rule on optA, but have source be optX - which would almost never be correct.
Thought you wanted to have the drop down filter your source to only be the interface your creating the rule on vs presenting you the full list.
But if was creating an outbound rule in floating you could end up with source different then the interface.
-
@lees Flush the state table after ever firewall rule change while you're getting used to this to completely rule this out. It adds about 10 seconds onto ever tweak you make, but it saves way more than that debugging cached rules (aka. state table). There are ways to flush individual rules too, but it takes longer than 10 seconds to find them :-)
-
It's been a good discussion has this thread and has helped me as I've been talking through it too.
What is clear though is that the UX is poor. By any standard measure of good UX, pfSense fails miserably. But hey, once you know that it's bad UX and not something you're not understanding it all makes sense.
It's like opening an Xmas advent calendar only to find there is no chocolate behind the door. Good UX is simple, don't have a door.
A good book on good usability, while quite old now, still relevant - Don't Make Me Think by Steve Krug - https://www.amazon.co.uk/Dont-Make-Me-Think-Usability/dp/0321344758
The job of any good developer is to make the system fool proof. No-one should have to know what they are doing, they should be guided at every step.
I don't know anything about floating rules yet, but from what I can tell reading the comments that to me, if I was building the pfSense WebGUI would be to have two admin screens, one for Standard Firewall Rules, and another for Floating Firewall Rules.
The reality is networking stuff is complex, and is an extremely difficult topic to understand if people aren't a traditional network admin and/or have been through the usual courses like CCNA and others etc. I'm pretty sure 'certain' big networking vendors make this stuff difficult to understand on purpose to justify the cost of their hardware.
-
@michaelcropper said in Firewall Rules - Interface:
No-one should have to know what they are doing
That is one of the stupidest things I think I have ever heard.
This isn't a ui to a freaking TV.
-
@johnpoz That's where the world is heading in every aspect of tech whether we like it or not.
The future skills are in building the tools to enable this idiot proof tech. Not in configuring tech.
-
@michaelcropper doesn't matter how pretty or easy to use the UI..
Still have to understand what a source port or IP is and destination IP, what protocol.
Sorry you still have to understand what your doing - even if the gui tries to keep you from shooting yourself in the foot.
Sure they could limit the selection to make it harder to shoot yourself.
See it all the time user puts in source port as 443 and destination port as 443.. That is highly unlikely a valid setup.. But it "could" be valid you have no idea what some application might do, etc.
If they prevent me from putting in 443 as the source port, and I actually want that - then the UI sucks.. So again going back to in what scenario is what valid or correct when there are so many variables..
The operator has to understand what the variables mean..
Poor Engineer blames his tools if you ask me.. It gave me too many choices - I didn't know what to put in ;)
As to floating tab - and where should you put rules that could be on multiple interfaces at the same time.. Where should you put rules that are doing outbound vs inbound. Where should you put rules that are suppose to happen before rules you place on the interface for marking traffic on say multiple interfaces at the same time.
So you call it bad design, I call it not understanding what your doing.. Blaming the tool because you don't know how to do something. But the tool should prevent me from shooting myself, and the tool should make it so I don't have to understand anything - it should just know what I meant to do, and not what I told it to do.. While that works on a TV, do you want to see this channel in the guide or not.. It doesn't work for a firewall.
-
@johnpoz I don't disagree with your point.
Good UX is segmenting UI for the average user which accounts for 95% of use cases VS the pro user which accounts for 5% of use cases which requires the ultimately flexibility.
To put this into context in an area that is nothing related to pfSense. A big green 'buy now button' on an ecommerce store can significantly increase sales over a button that is smaller or less obviously placed on the page which results in reduced sales.
Humans have more important things to worry about when using a system. They know what they want to do, the purpose of any system is to make this as easy as possible for the different users to achieve their goal.
This is the basis of good UX and design in any system.
It's not a case of limiting what people can/can't do, merely giving the user a guided experience to ensure they can achieve their goals as easily as possible.
The reality is that in the networking world in general, the UIs have often been so bad and designed in the early 90s in many cases and updated at best annually or with the next hardware firmware upgrade, that it's kind of the normal and people have got so used to bad design. pfSense is awesome in comparison to some of the horrific user interfaces I've seen on networking hardware. Likewise, this is one of the reasons why Ubiquiti / UniFi has become so popular (still a long way to come, but certainly leading the way).
In the world of web tech, it's normal to see upgrades multiple times per day and A/B experiments to use data to justify changes based on actual user experience rather than individual opinions. In reality, no-one is right, other than the users as a whole and it's so simple to track this stuff these days.
I had a bit of a dig into the change process for the pfSense GUI and it seems that this is quite a slow process for any changes to be made.
