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?
