Firewall Rules Not Being Enforced
-
@LPD7
it's easy to make mistakes in the beginning, but as your experience grows and you understand that the rules are evaluated from top to bottom (the first match wins, and the evaluation stops) it becomes easy to understand that a reject/block does not make any sense if you have an "allow all" above
The Anti-Lockout Rule is there exactly to prevent you from locking out of pfsense by mistake, also you can't move that rule, so you can try stuff without too much worry
Forget about "Floating" you'll never need that, it is only used on some very specific scenarios. The most common use of Floating rules is for traffic shaping but rules are automatically created by the wizard and generally, there is no need to manually take action there -
@kiokoman @SteveITS Thanks for that K......Sorry to say the CB is still able to get access despite the schedule having expired. The following is how I have the list arranged, I believe it is setup as was previously suggested. There isnt anything I have to do once reordered right, just apply changes and thats it? Also just to dbl check myself I looked at the arp table and the device ip is connected.
PS... A thought has occurred to me. If I were to put the reject rule above the pass rule then the device would/should not connect at all despite the schedule correct?
If I do that and the device can still connect then I would think that would tell us something of value right?
-
@LPD7 correct the reject would happen first.
However your pass rule isn’t matching, 0/0. Presumably because expired. So your test wouldn’t help much.
No IPv6 correct?
-
@LPD7 change your protocol to "any" for both those rules you added.
-
@SteveITS Correct no ipv6. Wouldnt the reject rule stop internet access regardless of the schedule, its not associated with a schedule. Just when I think I am getting a handle on this....pop goes the bubble.
So the left value of the states 0/0 is how many packets are captured and applied per the rule? So when you see the left side increase it means the rule is working?
-
@cswroe I was just looking at that because the states summary page shows the device is connecting via udp and the protocol in the rule is set to tcp. I will do that and see what happens. Thx.
-
@LPD7 It should if using UDP. I mentioned that above. ;)
-
@SteveITS @kiokoman Woo Hoo it seems that Protocol>Any did the trick. Did a quick test last night and it seems to have worked, will see how it goes tonight once the schedule expires and my son comes running to me wondering what happened to his youtube shorts.
Sorry Steve that I missed the UDP suggestion, well didnt miss it rather than just didnt register until I saw the states log and then things clicked.
2 quick questions: 1) When you see the rules stats (0/0) the left represents how many states are being blocked/restricted by the rule and the one to the right shows all the states seen? and 2) What would be a good rule of thumb for arranging the rules list to avoid issues? Would least restrictive to more restrictive be the way to think of it or do you have another suggestion?
Thanks so much to you both for your patience and expertise.
-
@LPD7 From memory the left side of 0/0 is currently open states (0 if blocks) and the right is bytes that matched over time.
If you keep the allow all at the bottom you only need restrictions. Order only matters if you want to allow partial access, something like:
- allow LAN subnets to This Firewall port 53
- allow LAN subnets to This Firewall port 443
- allow LAN subnets to This Firewall port 22
- deny LAN subnets to This Firewall
- allow LAN subnets to any
You can create a label on the rules page, and move it on the page to sort of create sections...e.g. access to pfSense, access to server, etc.
-
@SteveITS Yeah that whole states thing is gonna take some digging to fully comprehend.
I was thinking the left noted the number of blocks (states that matched a rule) but it doesnt sound like that. I did a search "pfsense rules states" and nothing came up that satisfied my curiosity.
It may take more digging and since its a firewall maybe the answer lies in basic firewall terminology. I will put that on my reading list.
So placing the allow all/any at the bottom passes all traffic that doesnt meet the prior rules and the order of the rules prior to "allow any" require no particular order, does that pretty much sum it up?
Sounds too simple.
I played around with the order and wound up dropping all local devices form the WAN, not sure how it happened but that gave me a bit of pause. That one was easy to correct.
The rules worked as planned and sure enough when the hour hit my son called from the kitchen "dad what happened to the internet?" With no CB or tablet to numb his brain he went to bed at 8pm...mission accomplished.
-
@LPD7 If you hover over the 0/0 it gives a summary. It's currently open states, which won't exist for a block/reject.
@LPD7 said in Firewall Rules Not Being Enforced:
require no particular order
I mean yes and no...the order is important for blocking certain types of traffic. Look at the difference between Open and Isolated interfaces here for example:
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-4200/opt-lan.html#apply-changes
@LPD7 said in Firewall Rules Not Being Enforced:
mission accomplished
-
@SteveITS @kiokoman Hello all just wanted to touch base and let you know all is working well and I have a better handle on how Rules work. I know people tend to disappear when their issues get resolved (guilty) and I wanted to acknowledge your time and expertise in resolving this issue. Thanks again.
-
@LPD7 General FYI. I went through this stuff when we had teenagers living at home, but it jus tcreated arguments about "why can't I have another 30mins" every night.
The solution was to limit bandwidth late at night. so rather than "the internet" stopping, it slowed to a crawl making browsing & gamin painfully slow !! As the internet was still working we could blame it on the provider, but bedtime prevailed !!
-