Firewall Rules Not Being Enforced

[kiokoman]

@LPD7
that passes traffic will only block it on other hours if a separate block rule exists underneath it

rules should be:
permit with schedule
block permanently (without schedule)

under System > Advanced on the Miscellaneous there is an option that say "Do not kill connections when schedule expires", be sure it is NOT checked

maybe post a new screenshot of the rules

[LPD7]

@kiokoman Do not kill connections when schedule expires is not checked. Rules SS has not changed with the exception of changing Destination>This Firewall to Any. Can you elaborate on the rules comment you made. I have it setup as both permit with schedule and deny per the schedule to see if either worked so I can troubleshoot but neither works. Can you give an example as to how you would setup per your comment? Thanks for your input.

[SteveITS]

@LPD7 see the two paragraphs here:
https://docs.netgate.com/pfsense/en/latest/firewall/time-based-rules.html#time-based-rules-logic

Your second rule is a block rule though. However it doesn’t actually need a schedule:

• allow during schedule
• block always

But it sounds like your allow rule isn’t working, is that where we are? I would post the edited rules again.

[LPD7]

@SteveITS Hi Steve I have deleted the rule using the IP address and will use the alias I setup as it will simplify things. Yes, correct, the rule is not working.

The alias is setup with the static IP assigned to the device.

The schedule below are the times/days I want to allow access. Anything outside the times/days is to be denied.

The rules below are using the alias. If you notice the schedule icons have changed since my initial post. If I am reading it correctly it seems they are contradicting one another which may be the issue.

I am going to look at the link you provided to see if I can see where I may have gone wrong. Let me know if you see something or how I can get this working. Thank you.

[SteveITS]

@LPD7 In general, you'd want to remove the schedule from the block/reject rule. Then traffic is allowed by the first rule, but if the first rule doesn't exist (schedule=off) then traffic hits the block rule.

As written the block rule would also be removed when the AaronsCB schedule expires.

If you are seeing 0/0 on the rule then it isn't matching. So, the traffic either isn't coming from AaronsCB (e.g. incorrect alias, or IPv6 not IPv4), or not TCP (e.g. UDP/voice).

Because we can't administer my son's school Chromebook and we didn't want to disable IPv6 for our home, we ended up blocking the Chromebook by MAC address, which is a feature in pfSense Plus. Otherwise IPv6 will use temp addresses so the IP often varies.

[LPD7]

@SteveITS Thanks Steve. So let me make sure I understand. If I remove the reject rule then the device will be able to access the internet within the days/times permitted and anything outside of that will be automatically rejected?

He is not currently using the device which is why there is 0/0 but again since not working correctly I wouldnt expect to see anything.

Yeah I cant block by mac within PFS CE which is why I assigned a static IP, this will still work right?

[SteveITS]

@LPD7 don’t remove the reject rule, remove its schedule. 2 rules:

• Access allowed during schedule
• Denied all other times

Static IPv4 will work if it’s not using IPv6.

If the rule isn’t matching then that’s a different problem.

[LPD7]

@SteveITS Ok I went and removed the schedule from the reject rule I had created.

I will have to wait until later after the expiration of the schedule to see if it works.

So if I understand correctly, the schedule takes the lead and once expired the reject rule takes over.

So for every rule which uses a schedule you have to have a reject rule to cover all other time frames? If this is true does this logic apply to other types of rules (having to have the reject rule)?

From what you see do you think the issue will be resolved?

Will post an update once I can test this.

Thanks for your help.

[LPD7]

@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.

[SteveITS]

@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.

[kiokoman]

@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

[LPD7]

@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.

[LPD7]

@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?

[SteveITS]

@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.

[kiokoman]

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

[LPD7]

@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.

[kiokoman]

@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

[LPD7]

@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?

[SteveITS]

@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?

[cswroe]

@LPD7 change your protocol to "any" for both those rules you added.