Schedule not working for smart teenager
-
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 :)
-
Probably nothing lingering.
The generated ruleset that is loaded is at /tmp/rules.debug
The actual running ruleset can be seen with pfctl -sr
The latter is a view directly into the active rules.
Glad you found a solution that works for you.