Schedule not working for smart teenager
-
Hello, this is my first post here, as I have been unable to find the answers I am looking for throughout the forum.
My teenage little Satan has smartened up, and now the schedule stops blocking the internet access even after the requests to and from its devices are supposed to be blocked.
The rules have worked perfectly up to now, but I suspect that this devil has found a way around it (proxy, VPN, …). Killing the states, serves no purpose, as the recreate immediately, despite the package capture clearly showing traffic to and from this IP address (is this a BUG?).
The only thing that seems to kill it, is disabling the dedicated Ethernet interface for 10-15 seconds, and that would be fine, if the rules allowed me to do so.
If my monster gets online before time X, the connections remains active, despite schedules and states.
I will repeat, that the rules have worked fine until Nosferatu found a workaround. >:(I have both pass and block rules and schedules to match.
Do you have any ideas?
-
Show us what you have done.
-
Ok, so far I have followed all the suggestions that have been given on previous posts, but it has made no difference whatsoever.
- I have two schedules: Day-Pass and Night-Block.
- I have two floating rules (to cover for both LAN and Wireless) : Day-Pass and Night-Block, assigned with the respective schedule.
The rules are set as follows: - Action: Block (Pass for the pass rule)
- Interface: WAN, LAN, Wireless
-Direction: Any
Addr. Family: IPv4+6
Protocol: Any
Source: alias of the Devil containing all its IP addresses
Destination: any
Schedule: Night-Block/Day-pass respectively
Other setting: all default
I have played with the State Type, but makes no difference. (I'm frankly not sure what is its purpose)
and that is pretty much it.
-
You want to set a schedule on the pass rules and block everything else after that. I would not use floating rules. I would use interface rules.
You want to be sure you do not check the box Schedule States - Do not kill connections when schedule expires in System > Advanced, Miscellaneous.
Scheduled block rules don't really get you anything because a state is not created.
The system can only automatically kill states for those created BY THE RULE with the schedule on it. So if there is a state that exists that you should think should be killed after the schedule expires, there are ways to look at the state table and find out which rule created it.
You only need to do this on the inside (LAN, Wireless) interfaces unless you are blocking inbound (from the internet) connections.
Realize it is trivial to change an IP address on a computer.
-
Ok ,thank you for the reply.
The floating rules have worked so far, do they have limitations compared to the interface rules?
The box in Schedule states in the advanced settings, is unticked.
I think I understand what you mean, although I am confused why a block rule doesn't just block whatever matches its settings. You mentions that there are ways to look at the table and find which rule created that traffic. Can you explain?
I am aware that blocking by IP is not the best, but it is currently secure enough, as the teenager's understanding on this topic is pretty poor.
The reason the current rules are bypassed, is because it is a method (probably proxy or VPN) learned from others at school, to be able to use social media on the school WiFi.
-
If you do as I described, the VPN will be disconnected when the schedule expires and they will not be able to connect again until the pass rule is active again.
Floating rules are just confusing. You might not have quick set, etc (If you don't understand what quick is you shouldn't be using floating rules.)
Create a pass rule on the interface the clients are on that passes traffic from the alias addresses to any destination. Put a schedule on that rule that covers the times you want them to have access.
Create a REJECT rule right below that for all traffic sourced from that alias with no schedule on it to any destination.
Delete the floating rules
Clear states
And you're done.
-
Thank you,
I have removed all floating rules, and created one pass rule on schedule on the interface, and as you recommended a Reject rule just below it.I will see how it works tonight. Although I am not under the illusion that this is over, there are some promising signs. Just changing from Block to Reject, my user connectivity monitor (homemade device that has a LED to show the status of the internet connection with IP assigned to the teenager group) has changed colour from green (connection available to LAN and WAN) to blue (Connection available only to WAN). This is exactly what I was expecting, but could not get to work.
I need to understand better how the Block function works (or doesn't work in this case).
Thank you for your reply, I am keeping my fingers crossed.
-
Block does not send a response (some people call this stealth). This means the client makes a connection and has to time out before it gives up.
Reject sends a RST in response to a connection attempt. This means the client gets immediate feeedback that the connection was refused.
I generally block connections originating from the outside (WAN) and reject connections originating from the inside (LAN). Though I do not subscribe to the theory that your WAN should not respond to anything or it FAILED. My WANs always respond to pings.
-
That didn't work :-[
The states remained active, despite the rule change, or more precisely, anytime I try to kill the state, it recreates instantly.
I still had to disable the interface for a minute, clear the states, and re-enable it.I have run a Packet Capture on the incriminated device after the schedule, and attached is the result (I have changed the phone's MAC to all zeros, just because no one needs to know it).
The source/destination IP address is 159.65.16.33, owned by Digital Ocean Inc. who hosts VPN services. There are plenty of websites with help on how to bypass the school's wifi restricitons. The most popular ones seem to be Cyberghost, Windscribe, Betternet and TunnelbearBlocking that IP address is not a good solution, as it might change to anything else.
Any ideas?
-
If the state is being recreated, post it.
Post your rules.
Post your schedules.
A state will not be created unless there is a rule passing it.
If that is the case you did something wrong.
-
Thank you for finding the time to reply to me, I hope you see a silly mistake, because after I stripped all extra rules, it still doesn't work. :'(
I would like to point out that not all of the restricted devices work past the end of the schedule, only the mobile phone does, and that IP address is only part of the restricted users group.
Additionally, as I mentioned previously, once I disable the wireless interface, and wait a minute or two before re-enabling it, the rules block the connection as expected.
My next step will be to make the firewall fly out of the window, and replace it with a mechanical timer that powers off and on the wireless router. (Try bypassing that teenager!). :D
-
Are WIRELESS and LAN actually bridged?
-
yes, the are, for allowing to connect to the printers, NAS media drive and IOT server.
LAN Users and Guests are don't contain the restricted users IPs. -
What does your Interfaces > Assignments screen look like?
Execute this in Diagnostics > Command Prompt: sysctl net.link.bridge
And post the output.
-
Amendment to the previous post about the bridge. The LAN and wireless are not bridged as in "Interfaces / Bridges", but the traffic (for approved users) is allowed to flow from wireless to LAN.
Shell Output - sysctl net.link.bridge
net.link.bridge.ipfw: 0
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 0
net.link.bridge.log_stp: 0
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 1
net.link.bridge.pfil_bridge: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_onlyip: 0
-
OK then that's not a bridge. Good.
It is simply not possible for anything in Restricted Devices to create new connections when that scheduled rule is not active with that rule set.
Did you delete all the floating rules?
With the scheduled rule inactive (either outside the schedule or disabled) create a new connection using the phone that you say is able to access after the schedule.
Then look at the states like this:
pfctl -vvss | grep -A3 IP_Address_of_Phone
Like this:
pfctl -vvss | grep -A3 192.168.223.6
igb1.223 tcp 192.168.224.17:22 <- 192.168.223.6:62701 ESTABLISHED:ESTABLISHED
[2131669100 + 131072] wscale 6 [3216320702 + 39872] wscale 5
age 74:03:52, expires in 23:47:31, 5056:3070 pkts, 342933:408061 bytes, rule 330
id: 030000005b6d6c32 creatorid: 18cd6f56That is an ssh session from 192.168.223.6 to 192.168.224.17. You can see that rule 330 created that state so:
pfctl -vvsr | grep '^@330'
@330(1423868019) pass in quick on igb1.223 inet from 192.168.223.0/24 to rfc1918:3flags S/SA keep state label "USER_RULE: Bypass Policy for RFC1918"That is the rule that passed the traffic and created that state. There must be such a rule or the default deny rule would be rejecting the traffic.
Those commands can be run in the shell (ssh or console and option 8. Type exit to get the menu back) or executed at Diagnostics > Command Prompt</rfc1918:3>
-
Derelict, thank you for the putting up with me!
Yes, all floating rules have been cleared.
I will try your suggestions tonight.
-
Got it, but it is not a rule I created, or can remove; what is it?
@85(1000003811) pass out route-to (sk0 192.168.0.57) inet from 192.168.0.100 to ! 192.168.0.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself" -
Where is the one on LAN (or whatever inside interface you are concerned with - like WIRELESS)? That rule is automatic to let traffic out WAN. Be concerned with the states on LAN. Without a state on LAN the traffic cannot pass unless it is originated from the firewall itself.
-
Ok, so I figured out that this search for a hole was not going anywhere, so I have searched for alternative solutions. ???
I changed the pass rule to allow traffic on only a set of known "safe" ports, which are: 21, 22, 25, 53, 80, 443, 678, 993, 995, 8080, although most likely 80 and 443 would be enough in this case.
To my pleasure, the rule works very well, all states cease to exist, and no new ones are created. 8)
I know that this is not the perfect rule, as traffic could just go through port 80, but as it works, and it is not a security issue, I will not worry for now.I'm lead to believe that, as I can count on my two hands all of the rules I have setup, that there could be some broken hidden rules that are still lingering in the background after deleting, or PFSense upgrades.
My plan is one day to backup, delete/restore installation to "factory settings" and restore the rules and settings one by one, in order to be sure that the system is clean.
The reason why I have not done that yet, is because, I might switch the storage from CF to SSD, and therefore a completely new installation, which would make going through the system clean a waste of my time.I would like to thank Derelict for taking the time to try to fault find :)
