Firewall Rules - Interface
-
@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.
-
@michaelcropper said in Firewall Rules - Interface:
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.
Your not ordering a sweatshirt on amazon here for gosh sake..
Example of uses clicking shit they don't understand and not reading - but pfsense should "prevent" this in UI
So when you go to create a rule it asks you for source IP or network, range - this is where you have a problem because it lists all the networks on pfsense..
To set a source port on the traffic - you have to clicked the ADVANCED BUTTON, with a warning
"The Source Port Range for a connection is typically random and almost never equal to the destination port. In most cases this setting must remain at its default value, any."
Yes users still seem to open up the advance tab and set the source port from any to the same port as their destination.. my 443 443 example, even though this is a very uncommon setup - it could be possible for that to be a valid configuration.
This this is the UI going out of its way to warn the user - hey you prob don't want to do anything here unless you really know what your doing - still happens... Bad UI, or just bad user?
So again - if you don't know what interface or network you want as source on a rule you are creating - you shouldn't be within 100 feet of the firewall plain an simple.. I didn't know it presented my optX network as source on my Lan network.. That is not UI issue, that is just plain not understanding what your doing or even wanting to do.
They know what they want to do
I would say no they don't know, or they wouldn't be selecting optX network as source into their Lan network, etc. But it happens all the time.. But lets not blame the user of the tool, blame the tool - because the UI should be so easy to use that the user doesn't even know what they are doing ;)
-
@michaelcropper Your right, there is much space for improvement but also pfSense is a firewall appliance for businesses, not a home-router.
