Firewall Rules - Interface
-
Maybe because I'm a newbie and still learning the firewall rules configuration, but the pfSense documentation and the description in the Firewall / Rules / Edit form seem contradictory / confusing (at least to me).
When creating a new rule (lets say for a LAN interface for discussion's sake), the Interface drop down on the form has the following description underneath it:
"Choose the interface from which packets must come to match this rule."
However, in the documentation, the following is written:
"The Interface drop down specifies the interface receiving traffic to be controlled by this rule. Remember that on interface and group tab rules, traffic is only filtered on the interface where the traffic is initiated. Traffic initiated from the LAN destined to the Internet or any other interface on the firewall is filtered by the LAN ruleset."
So is the rule inbound (following the documentation description) or outbound (following the Edit form description) or, (more likely
) am I misreading both?Many thanks for any and all helpful feedback!
-
@lees It's correct.
The firewall interface receives traffic from the network connected to it.
All rules apply to the inbound traffic from the network plugged into that interface. -
@lees Jarhead is right. Put another way, if you create a rule on LAN and put WAN Net (or a public IP, etc.) as the source, the rule is essentially ignored because traffic will never arrive on the LAN port from WAN Net. Packets are processed as they enter the firewall, so that rule should be on WAN not LAN.
-
@Jarhead / @SteveITS - many thanks for your responses!
OK, I got it (I think!):
Rules created for a "LAN" interface are there to filter packets coming into it (so it is receiving them) for its attached network (e.g. LAN net), and so the rules are therefore controlling where those packets can go as they leave the LAN interface (so these are coming from the LAN interface)
Did I understand that correctly?
-
@lees said in Firewall Rules - Interface:
Rules created for a "LAN" interface are there to filter packets coming into it (so it is receiving them) for its attached network (e.g. LAN net),
yes
@lees said in Firewall Rules - Interface:
so the rules are therefore controlling where those packets can go as they leave the LAN interface (so these are coming from the LAN interface)
Nope. :) Outbound packets can be handled by pfSense but only via floating rules which are more complex and should probably be avoided unless necessary and one has an understanding of how they differ from normal rules.
The firewall rule allows the packet in and the packet is addressed/going to its destination so it doesn't get to change its direction while passing through the firewall. So one can block/allow the packet as it arrives.
This thread had a similar question and discussion about the rules/interfaces/inbound/outbound: https://forum.netgate.com/topic/173529/allow-vlan-traffic-to-internet
-
@LeeS take a look at the thread that has been linked to where I have been asking all the same questions.
Basically the way that cloud platforms treat inbound/outbound traffic (which makes sense logically in my head), is completely the opposite way around when it comes to pfSense as it looks at rules from a different perspective.
Cloud platforms look at firewall rules from the perspective of the VM, aka. AWS Security Groups etc. pfSense looks at firewall rules from the perspective of the physical/virtual port of the firewall. Hence just think about this as the opposite way around.
-
@michaelcropper I did indeed start to read through that thread (a few times, and smiled as I see someone asking the same questions I have, and relieved!) at the suggestion of @SteveITS and it looks like I'm thinking of it in the same way you are / were and it's bending my head (probably because I have AWS / CISCO approach in my head still)
So, rules created under an interface: they are relative to that interface, but at what point of that interface?
-
At point 1 in my dagram below (which to me is inbound)?
-
At point 2 (which to me is outbound)?
-
Both (as both could be seen as inbound AND outbound for each interface?
-
-
@lees At point 1, as the packet arrives. So a rule on LAN1 allowing port 80 from LAN1 Net to LAN 2 Net only affects packets from LAN1 Net. Packets from WAN or LAN2 do not see that rule.
From pfSense's (floating rules) point of view, outbound is as the packet leaves pfSense. Which I suppose is also point 1, but in the other direction.
-
@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 ;)
