Ingress Filtering question
-
Hi, this is a newbie question. I really tried doing my homework but I'm not finding any answers online. If somebody could flip me a link to where this is answered I'd be grateful.
On a Pfsense device I have two interfaces both with DHCP enabled.
LAN - 192.168.1.1 /24
IOT - 192.168.2.1 /24(Well, the LAN interface is the default one that comes with the setup. I only created the IOT interface.)
For the LAN Firewall rules I have the following: Anti-Lockout and the “Default to allow LAN to any rule” (IP v4 & v6)
For the IOT Firewall rules there are none. At the bottom it says “No rules defined. All incoming connections on this interface will be blocked until pass rules are added.”
I have a machine on a LAN interface port with a 192.168.1 address and it is able to ping 192.168.2.1.
How is this possible?
Why can the 192.168.1 machine ping something on the IOT interface if the IOT does not have any rules defined to allow traffic to ingress or egress. I've noted, as expected, that I cannot ping 192.168.1.1 from a 192.168.2 address.
I have read through the documentation to try and answer this question but I'm just not finding anything.
On the page about ingress filtering it says this:
“The default ingress policy on pfSense
software is to block all traffic as there are no allow rules on WAN in the default ruleset.”Since there are no rules on the IOT interface, I would expect ingress blocking behavior as well.
Thanks in advance. Thanks in advance
-
@HChin_ ingress from the iot network.. Ie if you have a client on the iot network say at 192.168.2.x then no it wouldn't be able to talk to 192.168.2.1 or any other IPs with no rules on the iot network.
Your lan rules allow all right so why would you not be able to talk to pfsense 2.1, your not ingress into the 2.1 interface from the 192.168.2 network..
Even if you had devices on 192.168.2.x you could talk to those from your lan because the return trafffic from 192.168.2.x would be allowed by the state created when your lan rules allowed your lan client to talk to the 2.x address.
Think of pfsense as a house, and the interfaces as door and windows on the house.. Your standing in the middle of the house. Someone trying to come into the house is ingress.. Someone leaving the house out of a window or door is egress..
If you want to do egress rules - you would need to do those on floating tab.f Interface tab rules are only inbound into the interface from the network that interface is attached too.
-
@johnpoz, thanks for your reply. It is helping me to understand a little better; especially your analogy of the house.
If I understand this correctly, when I setup the interfaces in pfsense and assign them all different IP address ranges these networks “live in the same house” and can see each other - unless the firewall rule for a given “network” prevents it. Is that correct?
You wrote: “Your lan rules allow all right so why would you not be able to talk to pfsense 2.1“
Before your house analogy I thought all the networks were in their own house. So while 192.168..1.x could send packets out (because the LAN rule allows it) I thought the absence of any rules on 192.168.2.x would prevent incoming packets into that network. That's how I understood the message at the bottom of the firewall rules to say. “No rules defined. All incoming connections on this interface will be blocked until pass rules are added.” And I still find the message confusing - but guess it means blocking packets from the WAN.
Thanks for your help.
-
@HChin_ said in Ingress Filtering question:
No rules defined. All incoming connections on this interface will be blocked until pass rules are added.”
But states are evaluated before rules. Pfsense is a stateful firewall, if you needed bidirectional rules you're talking just a packet filter from way back in the day before stateful firewalls ;) They were such a pita - hehehe, yeah dating myself haha
This gives users some issues creating block rules - if you allowed x to talk to y and x did talk to y and after you created a rule to block x from talking to y. X would still be allowed until the already existing state has been removed or timed out on its own, etc.
But a state can not be created unless a firewall rule allows the state to be created.
If it worked the way you were thinking then even if pfsense allowed something behind it to talk to say 8.8.8.8 and you have no rules on the wan, then 8.8.8.8 answer would be denied. The reason 8.8.8.8 is allowed to get back to the client behind pfsense is when you allowed the traffic with your lan rules a state was created to allow the return traffic.
Maybe looking in the state table under diagnostics will help you understand?
-
@johnpoz Hello again...
according documentation, rules are evaluated per interface on the incoming traffic.So i have added block rule with source LAN6 - destination LAN11, on the LAN11 interface. Why this is not evaluating correctly ?? LAN6 can ping devices on LAN11.
-
@Bambos my guess would be the state still existed from previous allow.
If you allow something and test it, a state is created to.. Until that state goes away either times out on its own, the clients close the session or you kill the state putting in a block will not work until there is no state. States are evaluated before rules.
Or you have a floating rule that allowed it.. You see that 0/0 under states. Means that rule was never evaluated.
Btw why do you have block bogon on something you calling a lan - in what possible scenario would a bogon show up inbound to your lan interface? And your rules should normally be set to lan6_local anyway as source - so there would never be a rule that allows anything but lan6 addresses, so bogon would never work anyway.
Bogon on a local network interface doesn't make any sense - and can cause you problems, rfc1918 is part of bogon.. But I believe pfsense pulls out rfc1918 from it.
I see hits on that rule.. What rules do you have in floating?
-
@johnpoz Hello Johnpoz,
i'm aware about the states , so i'm resetting the states just to be sure from diagnostic, states, reset states.I'm trying to figure out the firewall rules per interface , it looks that on LANs is not the same as WAN. on WAN the flow is considered as inbound and by default all is block, so we add only the allow rules.
For LAN's it seems that is reversed. the evaluation is for outgoing traffic , by default is all allow and we add block rules.Example: Traffic between 2 LANS. Let's say LAN6 and LAN11.
All 4 possible scenarios below:what would be the affective result of a block rule on LAN6 interface with:
source: LAN6 net, destination : LAN11 net
source: LAN11 net, destination : LAN6 netwhat would be the affective result of a block rule on LAN11 interface with:
source: LAN6 net, destination : LAN11 net
source: LAN11 net, destination : LAN6 netIs there any scenarios from above that are not effective? what i mean is: if the evaluation on LAN's is on the outbound, then having the block rule with the LAN net as destination will never be evaluated. i hope is clear what i'm asking.
-
@Bambos said in Ingress Filtering question:
what would be the affective result of a block rule on LAN6 interface with:
source: LAN6 net, destination : LAN11 net
source: LAN11 net, destination : LAN6 netblocking lan11 as source on your lan6 interface is pointless - there would never be source traffic inbound to lan6 interface from the lan11 network.
same goes for your lan 11 network rules, lan6 could never be source of traffic into the lan11 interface.
If you do not want lan6 to talk to lan11, then block destination lan11 on the lan6 interface. Keeping in mind that rules are evaluated top down, first rule to trigger wins.. So if you have a allow rule for any above your block to lan11 it would never trigger.
Rules in floating are evaluated before interface rules. Inbound into an interface is traffic entering that interface from the network its attached too. Do you have any group rules they are evaluated after floating, but before interface rules.
edit: here pinging from my lan (192.168.9/24) to my dmz network (192.168.3/24)
You see I can ping, I then create a rule block icmp to my dmz subnet from my lan subnet on the lan interface.. No more ping, and notice the rule shows that it has been evaluated because its no longer 0/0
If you rule blocking is not being evaluated, then you have some rule in floating or groups allowing it, or there is an existing state allowing it. Or you have a rule above it allowing it. Or when you talk from device A in lan6 to device B in lan11 its not going through pfsense.
-
@johnpoz said in Ingress Filtering question:
blocking lan11 as source on your lan6 interface is pointless - there would never be source traffic inbound to lan6 interface from the lan11 network.
why is that ?? if the traffic originated from LAN11, the LAN11 will be as a source of the packet when arrives to LAN6 interface for evaluation. I'm i missing something ?
(This is the point i'm trying to clarify).Assuming that this is the philosophy principal of pfsense:
then we agree. i have replicate your test on my LAN's.
so it's true that the evaluation of LAN firewall rules, happens on the outbound of the interface , as opposite happening on the WAN, when happening on the inbound. At least that is what i understand.please comment / clarify. (there is nothing in floating)
-
@Bambos All traffic entering vlan 6 would have a source IP of vlan6... How would vlan 11 ever be source IP into vlan 6 interface??
Lets say vlan 6 network is 192.168.6/24, and vlan11 is 192.168.11/24
If you have a client on vlan6 at 192.168.6.100, and it wants to talk to device on vlan11 lets say 192.168.11.200
How in the hell would the traffic this 6.100 box sends to pfsense to its vlan6 interface have a source IP of 192.168.11 something? Its source IP would be 192.168.6.100
In no scenario would there ever be a vlan 11 source IP as inbound traffic into vlan6 interface..
-
@Bambos said in Ingress Filtering question:
happens on the outbound of the interface
NO.. How is a rule on vlan6 seeing traffic into it from 192.168.6.x going to 192.168.11.y outbound???
Think of a doorman standing infront of your front door, and someone wants to enter the house (pfsense).. If he checks his list before he lets you enter the house - how is that outbound???
Do you stop the guy with his muddy shoes from entering the house after he has already entered (pfsense) or do you stop him before he even touches the frontdoor and say hey wait your not on the allow list - take your muddy shoes and go away.. Or does the doorman sit inside the house, and let the guy just step into the house with his muddy shoes before he says hey wait a minute your not allowed.
Put yourself inside pfsense - looking at your interface - windows in your house.. Is the traffic entering the interface from the outside into pfsense, or is leaving pfsense into the network attached to the interface.
The only place you can do outbound filtering is the floating tab.
-
@johnpoz hello my friend. I'm doing an effort to get on the same page with you.
i guess i have different understanding with the terminology maybe.
for WAN is clear, inbound is incoming and outbound is outgoing.outbound : in relation to what ? to the network interface of the originated network, or in relation to the whole firewall ?
do you mean that this is not the case for LAN's ? Traffic originated from LAN6, going to LAN11, how would you describe this with this terminology ?
(i would see that as outbound from LAN6 / inbound to LAN11) -
@Bambos again pretend pfsense your house - and your standing in the middle.. Is the traffic coming into your house (inbound) window or door.. Or is it leaving your house, again window or door - if its leaving pfsense its outbound, if its entering pfsense (your house) you are inside the house - then its inbound.
This is no different than your wan interface that you clearly understand - why would you think any of your other interfaces would be any different.
Traffic leaving a pc on your lan6 would be inbound to lan 6 interface.. and outbound of your lan11 interface - to whatever device is on the lan11 network.. Your setting rules on pfsense (your inside) pfsense.. If you do not want lan6 device to talk to lan11 device where do you set the rule - inbound on lan6..
So this traffic doesn't track mud all over your house!
if for some reason you have your heart set on blocking it from leaving lan11 into the lan11 network then this rule would have to be set int he floating tab as outbound on interface 11..
But there rarely any reason to do that.. Just top this traffic at interface of lan6 from even entering pfsense.
-
@johnpoz i found that post as well from 2022. Something similar was going on :)
https://forum.netgate.com/topic/173715/firewall-rules-interface
I think i see what you mean, please confirm the below diagram (assuming no floating rules used).
-
@Bambos exactly what you got in that image, router inbound == router ingress. And excluding floating rules, the direction is always ingress in a firewall rule in pfSense.
The pfSense doc explains it, too:
https://docs.netgate.com/pfsense/en/latest/firewall/fundamentals.html#stateful-filtering -
@patient0 thanks for your comment.
As new to pfSense, the web Gui interface menu for firewall rules per interface, in relation to my false thinking / believe that we "defend" each network interface for the "inbound traffic" in relation to the interface, (that's why we put there the firewall rules), lead me to this false understanding.
The next version of this diagram would be to have also the NAT actions on the lines outbound traffic in relation to the firewall. (and maybe change some positioning.
i'm waiting for John to see this :) he is really doing the effort for everyone.
-
@Bambos said in Ingress Filtering question:
t we "defend" each network interface for the "inbound traffic" in relation to the interface, (that's why we put there the firewall rules), lead me to this false understanding.
How is that - that is exactly what your doing.. INBOUND into the interface..
How did that lead you to false understanding?
Your diagram is correct.
Be it a bit busy - not sure why you need lan egress labeled.. Yeah if you have some PC on your lan, and its putting traffic on the lan - that is egress from that PC.
-
@johnpoz said in Ingress Filtering question:
How did that lead you to false understanding?
i mean like i'm in LAN, looking to the incoming traffic and apply the firewall rules to limit the traffic. So according to this diagram, i was thinking that for LAN interfaces i was applying rules for the outbound of firewall / interface / LAN ingress traffic, so we can limit traffic going to that network (to protect that network) because we are on the firewall rules of it's interface.
Instead of that, as what i'm learning now, i have to put the firewall rules to the outgoing traffic of the other interface (because this is where is the filtering happening).
Also after reading through your comments, on this post and also others, assuming the pf filtering happening before the packet entering the interface, and NAT happening before the packet leave the interface, it seems that the NAT positioning for LAN is the correct, instead of the Guest. Last we have 3 different designs for interface attachment to the routing plane. which one you feel is more close to reality ?
