Schedule not working for smart teenager
-
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.