Question on when a rule would trigger
-
I've seen it mention that in a case of
1. Allow Lan subnet->Lan subnet
2. Allow any -> This firewall
3. Block RFC1918
4. Allow AnyRule #1 should never trigger
I've always included it anywayLooking at my rules, I see it has fired off a few times. Any idea what specific traffic could trigger it?
-
Lan traffic that is not destined for the router will never hit it because the hosts on network can talk to each other without first going to the router. The only traffic that will hit it regardless is broadcasts/multicasts.
-
Rule 1 will also trigger when connecting to the firewall itself if the traffic is originating from the lan subnet to the firewall ip on that subnet…
-
Rule 1 is pointless. It would allow access to the pfsense IP in that subnet, but bad way to do it. If you want to allow access to pfsense interface IP in that network then use the lan address drop down. Your this firewall rule allows access to any IP pfsense has be it lan segment or wan.
Are you using the antilock rules? Those would allow access to pfsense on 80,443,22 or other port if using different ones. So your firewall rule would allow for dns. But you really should be more specific if your wanting to get restrictive. so if you want to ping, and dns to pfsense lan IP then that would be the specific rule you would want to use.
Your block rfc rule could be combined with your any any rule on the end and just use a ! rule for your rfc1918. So dest NOT rfc1918 allow - this makes it 1 rule vs having 2.
-
Rule 1 is pointless. It would allow access to the pfsense IP in that subnet, but bad way to do it. If you want to allow access to pfsense interface IP in that network then use the lan address drop down. Your this firewall rule allows access to any IP pfsense has be it lan segment or wan.
Are you using the antilock rules? Those would allow access to pfsense on 80,443,22 or other port if using different ones. So your firewall rule would allow for dns. But you really should be more specific if your wanting to get restrictive. so if you want to ping, and dns to pfsense lan IP then that would be the specific rule you would want to use.
Your block rfc rule could be combined with your any any rule on the end and just use a ! rule for your rfc1918. So dest NOT rfc1918 allow - this makes it 1 rule vs having 2.
What cases could be causing the rule to trigger in the screenshot I'm attaching.
I get that it's not the perfect way to do it, but I know if I remove it as is in this setup, whatever is triggering it will get blocked by the rule 2 spots below it.
-
That rule will match traffic from LAN net to LAN address (which is included in LAN net) as was correctly pointed out already by @JasonJoel.
The rule is pointless unless it is passing traffic to LAN address (or maybe other VIPs on the LAN interface) that you need to be passed.
If you're wondering what the traffic is, enable logging on the rule and watch the logs.
There are no "rare events." Traffic is either same-subnet (not requiring router services) or it's not.
-
"whatever is triggering it will get blocked by the rule 2 spots below it."
That is not how it works, first rule to trigger wins no other rules below that will be evaluated.
Rules are evaluated top down, first 1 that triggers stops further evaluation. Rules need to be ordered in this fashion.
-
That rule will match traffic from LAN net to LAN address (which is included in LAN net) as was correctly pointed out already by @JasonJoel.
The rule is pointless unless it is passing traffic to LAN address (or maybe other VIPs on the LAN interface) that you need to be passed.
If you're wondering what the traffic is, enable logging on the rule and watch the logs.
There are no "rare events." Traffic is either same-subnet (not requiring router services) or it's not.
I get that logic, but if it's 100% accurate, it would never have fired at any point because it would be routing by the switch and never touching pfsense.
My hardware setup is Pfsense – Wire -- Switch -- Everything else.
The only thing on that subnet that isn't on the far end of the switch is pfsense itself.
I get that the rule SHOULDN'T do anything, but as my screenshot shows, there is something hitting it that's matching it.
Perhaps I'm misunderstanding but the way everyone keeps explaining it, it should never fire, but if I look at the state by clicking it, it's showing an IP to a broadcast IP.
So, if that's getting passed, wouldn't removing it cause it to be blocked by the RFC1918 block rule that comes next?
"whatever is triggering it will get blocked by the rule 2 spots below it."
That is not how it works, first rule to trigger wins no other rules below that will be evaluated.
Rules are evaluated top down, first 1 that triggers stops further evaluation. Rules need to be ordered in this fashion.
I meant if I remove the rule that everyone is saying does nothing.
The rule 2 down blocks all RFC1918 as a destination. So without that pass, whatever is triggering it would be blocked as that block happens prior to the allow any at the bottom.
-
No, you don't get it. A rule with a source of LAN net and a dest of LAN net will match traffic with a source of LAN Net and a dest of LAN address (pfSense itself). Traffic to pfSense itself, aka LAN address has to be passed by firewall rules on pfSense LAN.
Like I said, enable logging on the rule and watch the logs.
So, if that's getting passed, wouldn't removing it cause it to be blocked by the RFC1918 block rule that comes next?
Yes, if LAN net is included in alias Local Networks.
https://doc.pfsense.org/index.php/Firewall_Rule_Basics
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
-
I do understand and I don't need to turn logging on, I know exactly which scenario would hit that rule
So in that case, since I'm
1. Blocking all RFC1918 traffic on LAN with a generic rule
2. Only have the anti-lockout rule with allows specific ports to the firewall
3. Am running a reverse proxy both inside and out on the firewall (for ports not covered by the anti-lockout rule)I DO want that LAN to LAN rule to exist then for that traffic.
Because that would not pass without that rule, correct?
-
It would be more correct to have source LAN net dest LAN address. but, in practice, they will pass the same traffic.
I believe that rules should be as narrow as necessary to do the job.
You should know what on your firewall needs to be accessed and have a rule for that. Otherwise not.
-
It would be more correct to have source LAN net dest LAN address. but, in practice, they will pass the same traffic.
I believe that rules should be as narrow as necessary to do the job.
You should know what on your firewall needs to be accessed and have a rule for that. Otherwise not.
Is there a specific reason to include the source in that rule?
-
Only because it's the only legitimate traffic that should be arriving on that interface so why allow illegitimate traffic into your firewall on purpose?
Many, many people specify any there.
-
^ Agreed the only traffic that should be hitting the lan interface is lan network traffic, unless you have downstream router? I like to see the specific network as the source for lan side networks, this tells you there is no downstream networks off this interface. Unless they are natted.
