Question about rule sourcing
-
Question 1:
In reading through various docs on pfsense firewall rules, I'm confused by the various drop downs in the source box of rules. Why could you ever have a source from outside the interfaces network (foreign source)?If I understand the documents correctly, packets are filtered on the interface from which the originate. So, if you send a packet from LAN to Somewhere, in order for it to make it somewhere, you have to allow that on the LAN interface rule.
However, why would you ever have a rule that is on LAN interface, but source is OPT1 net (for example) ??
Rather, how could a packet from OPT1 net ever originate from the LAN interface?Only thing I can think of: is it possible to have a host configured to be on OPT1 network, but physically connected to LAN (I suppose LAN would have to be the gateway as well)?
Question 2:
I tried to block all traffic to OPT 1 which didn't originate from OPT 1 net (i.e. this network can only talk to itself). However, when I ping from LAN to OPT1, it still gets through. Pings from OPT1 to LAN do not get through and I can see them blocked (as expected). If I understand correctly, in order to keep LAN from pining OPT1, I would have to put a rule on LAN that blocks packets going to OPT1 (since the origin would be LAN interface).I'm thinking it would be easier to have a block rule on OPT1 that checks ingressing packets (So I don't have to setup rules on all interfaces I don't want talking to OPT1…) Is this possible?
Reference:
https://doc.pfsense.org/index.php/Firewall_Rule_Basics
"Firewall rules control what traffic is allowed to enter an interface on the firewall."https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting#Interface_Selection
"The rules will be placed on the interface they entered from. If a packet is going from the LAN to the pfSense box, then out to the Internet, the rules still enter on the LAN. If a packet is coming from the Internet to the pfSense box, the rule goes on the WAN interface." -
Question 1:
Network issue, deliberately bogus packets, hardcoded IPs. Lets say LAN is 192.168.2.0/24, OPT1 is 10.1.1.0/8. You have a host with fixed ip of 10.1.1.3 plugged into a switch that is plugged into the LAN port. You will now see an "OPT1" sourced packet on LAN interface. You write a bit of code that opens a raw socket and creates an IP packet, in it you stuff an IP address of 1.2.3.4 and send it out. In the above case doesn't matter if you see it on LAN or OPT1 you get a source IP of "not this network".Question2: take screenshots of your rules for all your interfaces, it makes it easier to help.
Are you saying you have a rule on OPT1 that says "block all traffic that is not sourced from OPT1 network"? If so, then traffic from LAN will pass, unless you have a LAN rule that says "block all traffic destined for OPT1". Exactly like you thought."Ingressing packets": ingress depends on where you are standing, and which way you are looking. Stand on OPT1, look out towards the external world (OPT1 network). That is the OPT1 ingress direction. Look in towards the inside of the pfSense box: that is OPT1 egress.
-
https://doc.pfsense.org/index.php/Firewall_Rule_Basics
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
Maintaining a firewall might amount to some care and work.
-
@mer:
Question 1:
Network issue, deliberately bogus packets, hardcoded IPs. Lets say LAN is 192.168.2.0/24, OPT1 is 10.1.1.0/8. You have a host with fixed ip of 10.1.1.3 plugged into a switch that is plugged into the LAN port. You will now see an "OPT1" sourced packet on LAN interface. You write a bit of code that opens a raw socket and creates an IP packet, in it you stuff an IP address of 1.2.3.4 and send it out. In the above case doesn't matter if you see it on LAN or OPT1 you get a source IP of "not this network".Question2: take screenshots of your rules for all your interfaces, it makes it easier to help.
Are you saying you have a rule on OPT1 that says "block all traffic that is not sourced from OPT1 network"? If so, then traffic from LAN will pass, unless you have a LAN rule that says "block all traffic destined for OPT1". Exactly like you thought."Ingressing packets": ingress depends on where you are standing, and which way you are looking. Stand on OPT1, look out towards the external world (OPT1 network). That is the OPT1 ingress direction. Look in towards the inside of the pfSense box: that is OPT1 egress.
Thank you mer. I think question 1 is clear to me now. Basically no reason to have a rule where source is from a network other than interface's network unless there is a known specific scenario (hard coded ips, etc.)
For question 2:
That makes sense. No worries about the rule, I figured it wouldn't work since the rules apply to packets on the interface they originate from.However, is it possible to block packets incoming to the interface? Perhaps the correct word here is "incoming from LAN, but outbound for a host connected to OPT1… deny it at OPT1"
Ex)
LAN [a] –->{b} OPT1
OPT2[c]–->{b} OPT1
OPT3[d]–->{b} OPT1Current method is to put a rule at 'a', 'c', and 'd' (on LAN/OPT2/OPT3 ) to block packets going to OPT1
However, I want a rule at 'b' which blocks anything coming from LAN/OPT2/OPT3. This way I only have 1 rule to maintain instead of 3.
Or I could have one rule that blocks everything and separate rules to allow just a few specific things onto the OPT1 network -
Q1: generically "anti-spoof" rules are a good thing. Inbound packets (packets coming into the pfSense box from outside) that have the IP address of that interface is either someone trying something bad or a network thing is misconfigured. There are lots of opinons as to "proper and correct" rules, so this is my opinion. But if you have a system with a known "incorrect" address for that network segment, you could have specific rules to cover it (pass or block rules)
Q2: incoming from LAN destined for OPT1. Yes a better way of stating it. A single rule preventing that typically would be a routing decision, not a firewalling decision. pfSense has floating rules that get applied to all the interfaces (except for maybe WAN, I'm not sure about that), there may be a way to specify a floating rule to do what you want (again, I'm not sure on that).
Remember that "order counts" when you are defining rules. If you put a block all ahead of any pass rules, bad things happen. if you have console or ssh access to the pfSense box (or under the Diagnostics->Command in the webGUI) enter the command "pfctl -sr". That dumps the rules that are currently loaded in the order of execution. A few minutes with google (search for pf rules) you can start to understand them.
-
How often does your network change? Is it really that hard to make three rules?
You can make an interface group and use one rule or you can make a floating rule and use one rule.
But once you're set up with the rules on each interface, what's the problem?
