Firewall Rules Not Being Enforced
-
@SteveITS Ok the permit schedule is cfgd to expire at 17:00 (5pm), it is now 17:45 and the device in question can still access the internet. I am baffled why this is not working as it is not a complex function.
I have included the info below. Let me know if you have any thoughts or want to see something else. Does the order within the rules list make a difference? These are at the bottom of the list.
Intelligence is not a substitute for common sense.
Intel i5-3427 * 1.80GHz * 8GB Memory * 100GB HDD
Putting legacy equipment into service and out of landfills. -
@LPD7 Yes rules process in order so if traffic matches a rule above, it will never reach these rules. Presumably why they show 0/0.
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@LPD7
traffic never matches that rule if you have 0/0
maybe you have another rule above that permits the traffic or the alias is wrong -
@SteveITS @kiokoman Morning all...This is what the rules list looks like. I did some rearranging of order yesterday to test and did notice that there is an impact depending on where things reside in the list order. Based on that experience the first 2 must remain where they are or internet access gets dropped for the network, They were setup by default, I did not add them.
Also yesterday after having done the rearranging I saw that the CB Reject rule had accumulated a few packets/bytes but did not prevent the device from accessing the internet. I pulled this SS a few minutes ago so that has reset and the device has not been online yet so everything is now back to 0/0.
Also working on the notion that list order has an impact and that the first match "wins", wouldnt the reject rule automatically prevent the device from gaining internet access as it is above the pass rule?
Following that logic shouldnt the reject rule be nested below the pass rule? This would not address the current issue but is something to be aware of.
Based on this can anyone take a guess as to why the device can still access the internet outside the scheduled time?
This is not a difficult concept and the setup is pretty straight forward but why its not working is really a head scratcher.
-
@SteveITS @kiokoman Ok just to do a bit more testing I created a reject rule for the pc I am using and since I am able to submit this post the rule does not seem to work. Does this provide any additional insight into the issue?
Intelligence is not a substitute for common sense.
Intel i5-3427 * 1.80GHz * 8GB Memory * 100GB HDD
Putting legacy equipment into service and out of landfills. -
@LPD7 your top rule allows LAN to any so the entire rest of the rules will never match. Move your rules above the allow all.
-
so the order of the rules should be:
1 AaronsCB - TimeLimitAaronsCB_Pass
2 AaronsCB - TimeLimitAaronsCB_Reject
3 LAN_0 subnets - Default allow LAN to any rule -
@kiokoman @SteveITS Wow thats great news, after thinking about it I should have posted a SS of the list in its entirety and this would have been resolved in an instant.
With that said, I have been reading a number of PFS documentation pages on the rules and am still murky on how to order the rules list. It goes over floating vs interface groups vs interface tab but without a test box I am hesitant to go nuts in case something goes wrong.
Do either of you have a mnemonic or other trick to help order the rules list to ensure proper filtering and prevent issues?
My thought is that I am going to leave the anti lockout rule at the #1 spot until I look into the options I have read about that address this to make the box more secure and put the "default allow lan to any" rule at the bottom and then arrange additional rules like AaronsCB in order of what I would call magnitude, meaning those with the greatest impact or most restrictive being lower down the list...does this make sense?
I am just thinking ahead to get my mind around how to best approach this. I am not going to have many rules but I will be adding a couple more down the road.
Also for the state column, what should I see when packets are being seen and blocked by the rule? When you hover over it you see states and bytes among other things and am looking to know more so I can interpret what I see.
I have to run out for a bit and will get on this when I get back and see what happens, the pass rule will have expired by then so should see no internet access on the CB.
Thanks much for the help.
-
@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?
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@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
Pre-2.7.2/23.09: Only install packages for your version, or risk breaking it. Select your branch in System/Update/Update Settings.
When upgrading, allow 10-15 minutes to restart, or more depending on packages and device speed.
Upvote 👍 helpful posts! -
@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.
