Firewall Rules - Interface
-
@lees said in Firewall Rules - Interface:
At point 2 (which to me is outbound)?
no that is not outbound - outbound leaving the lan interfaces would also be 1, but towards the network the interface is attached too..
-
@johnpoz traffic coming out of interface LAN1, either towards pfSense or towards LAN1 net, is both outbound, no?
-
@lees said in Firewall Rules - Interface:
either towards pfSense or towards LAN1 net, is both outbound, no?
No in lan towards pfsense is inbound.. Outbound of lan is towards the lan network.. Internal traffic ie pfsense routing the traffic is not inbound or outbound, you already let it in with the inbound rule.. You can stop it with outbound rules.. But they are as the traffic is leaving the interface towards the network.
So you could stop traffic that you allowed in on lan 1 from going to lan 2 with an outbound rule on lan2.
But an outbound rule on lan1 would only be traffic towards the lan network as it leaves lan1 interface.
-
@lees said in Firewall Rules - Interface:
@johnpoz traffic coming out of interface LAN1, either towards pfSense or towards LAN1 net, is both outbound, no?
I understand what you're saying but that is not how pfSense labels it.
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html#direction -
So, assuming I've understood correctly how all of this works...... (huge caveat there as I'm still learning myself!)
Taking your example diagram @LeeS this is how I see the logic now;
Edit: Ignore the right yellow arrod and the left blue arrow that point to nothing. Forgot to delete those as I was drawing.
Follow the logic with the different colours on the diagram;
- Scenario 1: PC 1 on LAN 1 wants to ping PC 2 on LAN 2
- Scenario 2: PC 2 on LAN 2 wants to ping PC 1 on LAN 1
With the two firewall rules;
- Interface: LAN 1. Inbound Rule - From LAN 1 Allow Traffic to Pass to LAN 2
- Interface: LAN 2. Inbound Rule - From LAN 2 Block Traffic to LAN 1
What you'll notice is that there is no concept in the above to allow say LAN 2 to reject traffic from LAN 1. Personally this is what I find really odd about this stuff, but hey, it is what it is.
Side question: @johnpoz Out of interest, I don't know the answer to this. If I was to add another rule to this example, would this block the traffic;
- Interface: LAN 3. Inbound Rule - From LAN 1 Block Traffic to LAN 3 (assuming I updated rule 1 above to allow traffic to LAN 2 and LAN 3). Would pfSense allow the traffic partially to the next step but block it so it wouldn't successfully ping? (I'm going to have a test of this to help my understanding - I think it would - since I've always been confused about the source/destination bits on the rules on the interface, but I think this is where this added complexity comes in as technically, if I've understood everything correctly, that the reason why everything is an inbound rule is because regardless of if the network packet is coming from PC 1, or inside pfSense as it moves the packet from LAN 1 to LAN 2, from the interfaces perspective it's all traffic inbound to the interface)
Anyhow, the important thing to memorise @LeeS is that when you think of firewall rules from a cloud perspective, they are abstracting a lot of this underlying gubbins to make life easier, but actually makes our lives 1000x more difficult to understand the actual inner workings of all this stuff.
So from the cloud perspective, where we wrap a Security Group around say a VPC or an EC2 (AWS) etc. Then it's hiding a lot of the actual networking packet routing gubbins from us. So a cloud "Inbound Rule" say attached to an EC2, would actually be from a pfSense perspective an Inbound Rule that allowed traffic from WAN to LAN 2 if we were hosting a website on PC 2 for a very crude example.
What is also important to consider with networking in general is that we've had decades of thought processes/documentation/tooling that is primarily designed around perimeter defence. The concept of Zero Trust networking which has been primarily driven from cloud technologies is relatively new in the grand scheme of things.
From what I've read/discussed around all of this over the years, I'm fairly convinced that is why there is such confusion when people come from a cloud first background towards a more traditional networking technologies and packet routing etc. The concepts are completely different but the terminology is extremely similar, but means completely different things. It's no wonder why it's so confusing :-D
@johnpoz @SteveITS Please do correct me if I've got anything above incorrect as you guys know this stuff way better than I do.
-
@michaelcropper said in Firewall Rules - Interface:
Follow the logic with the different colours on the diagram;
Scenario 1: PC 1 on LAN 1 wants to ping PC 2 on LAN 2
Scenario 2: PC 2 on LAN 2 wants to ping PC 1 on LAN 1With the two firewall rules;
Interface: LAN 1. Inbound Rule - From LAN 1 Allow Traffic to Pass to LAN 2
Interface: LAN 2. Inbound Rule - From LAN 2 Block Traffic to LAN 1Yup I followed you there. The LAN2 block rule may not be needed because there is a default block rule on all interfaces, but it works for clarity and logging.
Not sure I understood question 3. A rule on LAN1 to block traffic to LAN3 would not allow the packet to enter LAN1.
I thought of another analogy. Bars put bouncers/security outside the door they are protecting, not inside the door.
-
I actually think that my confusion is a bit beyond the examples given here and is more to do with direction (flow) and choices available of interface, source and destination options. The actual parameters of the rule (e.g. block port xxx, or allow TCP on port abc, etc.) to me are fairly self-explanatory (I think)
Let me try and explain my logic / thought process (bear with me, I’m sure I’m overthinking this and making it far more complicated than it is, and that my “AHA!” moment is at hand, hopefully!)
Basing my logic on the premiss that (as clearly explained by @SteveITS earlier) rules for a particular interface are based on an inbound traffic direction (maybe this is where I am falling at the first hurdle?) then, for example:
- If I wanted to create a rule on interface LAN1, I would start this by selecting Firewall > Rules and clicking on the interface on which I want the rule to be evaluated (in this case, LAN1)
- I then click one of the Add buttons to add a rule, which opens the Edit form to create the rule
- Question 1a: Why am I provided with a selection of all of the created interfaces to choose from?
o If this rule is for LAN1, then surely the only interface choice should be LAN1, as this is the interface on which I want the rule to be evaluated for traffic coming from the connected network (LAN1 net) at point 1 in my diagram (inbound)?
o The only reason I can think of for there being a choice, is if I’m trying to create a rule to evaluate traffic (again, always inbound I believe?) coming from another network (e.g. LAN2) towards LAN1.
o This being the case, then surely point 2 in my diagram is now the inbound side on LAN1 for that rule?
o However, wouldn’t it be more efficient to create the LAN1 inbound rule from LAN2 as part of the LAN2 ruleset?
- Question 1b: under what circumstances would I choose anything but LAN1 as the interface for a rule created as part of the LAN1 ruleset?
- Question 2a: Following on from my (probably incorrect, making the rest of this irrelevant?) logic in Question 1, why am I provided with a selection of sources, other than LAN1 net and possible Aliases of objects hosted on LAN1 net?
o If the premiss is that rules are based on inbound traffic to the interface, then the only possible options at point 1 in my diagram for LAN1 are surely LAN1 net or Aliases on LAN1 net?
o Again, the only reason I can think of for the options being available is if the rule is evaluating traffic inbound to the LAN1 interface at point 2 in my diagram, again making that an inbound side for LAN1 interface
o If the logic in the above bullet point is correct, then the only options available in the destination should be either the LAN1 net or Aliases of objects hosted on LAN1 net?- Question 2b: under what circumstances would I choose anything but LAN1 net (or Aliases hosted there) as the source for a rule created as part of the LAN1 ruleset?
My apologies if I have confused everyone, but this to me seems where I am not following the logic of choices available when creating the rules. I think once I understand this the penny will drop!
Thanks again to all for being patient with a pfSense newbie! It’s very much appreciated!
-
@lees said in Firewall Rules - Interface:
Question 1a: Why am I provided with a selection of all of the created interfaces to choose from?
I hadn't really thought about that. I would guess that makes it easy to copy a rule and change the interface so other interfaces can have a copy of the same rule.
I think you will find (1b) that if you change the interface in the rule, it will "move" the rule.
@lees said in Firewall Rules - Interface:
selection of sources, other than LAN1 net and possible Aliases of objects hosted on LAN1 net
They probably just don't bother limiting the list? It is technically possible to (2b) have a routed subnet that isn't assigned to a pfSense interface, and just routes through pfSense, but that's pretty rare.
-
@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
