Firewall Rules Not Being Enforced
-
@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