A few basic questions about features from a NOOB -
-
…today I found some states (I think it was one of these game IPs) 1.5 hours after the block kicked in and a subsequent pfctl -F state.
I don't believe any longer in any of those firewalls, rules, whatsoever. An open browser is apparently enough to restart the states, no idea how that works...
-
Try what I do. I know it works because right on the hour, he walks out of his room and gets a snack every day. If the game he was playing was still working, he would be still in there!.
-
"1.5 hours after the block kicked in and a subsequent pfctl -F state."
Your sure your command ran and cleared the states? If pfctl -f or -F, clears the states and your rules don't allow traffic then something is clearly not right in the rules or the states were not cleared would be my guess.
-
I have a Cron job to do pfctrl -F state 1 min after the block rule kicks in (allow rules didn't work either and I had to have more than one, due to the general limitations on ports/IPs). An eMail Service says 1 h later:
"This is a periodic report from your firewall
Current report: states >NAME< 21:00
Command output: states (pfctl -ss | grep 10.zzz.yyy.xxx)"
i.e. there are no states, which I checked by hand several times. But half an hour later I found 6-8 states to this notorious ivony.com IP (216.66.6.120). Unfortunately I killed them and took no screenshot in advance…
-
Can you post up your rules so we can take a look at what they are and what your trying to do.. I thought you wanted to block his access completely.. Off the top if your saying new states are being created when your trying block them, then your rules are not correct for what your trying to do.
-
Hello again and many thanks for your patience! :-)
Here the first 3 rules of my LAN set. The first is the default, the second blocks some domain names (as in alias "blocklist") for the kids IPs (alias "junx", IPs are correct, trust me :-D ).
The third rule blocks all WAN access according to a schedule called "majo", see below, which kicks in at 21:00. At 21:00 the eMail report for the states (pfctl -ss | grep 10.xxx.yyy.zzz) of one of the IPs blocked is EMPTY, completely empty, Null, NADA, NIENTE…
EDIT: But I found now that this is not the truth, there ARE states alive at that time, checked by hand (Diagnostics -> States). What is wrong with the eMail report job? :o
The browser at the kids computers is still alive at that time, of course. Two minutes later the Cron job does (?) its job
pfctl -F state
EDIT: However, the states are still alive, not in the eMail report (completely empty), but when I check manually. When I go to Status -> eMail Reports and press "Send now", there ARE states, but not according to the eMail sent out automatically.... STRANGE indeed!
Now I'm no longer willing to watch this and do
Diagnostics -> States -> filter for kids IP and press KILL
States are gone now... dunno if they come up again if they manipulate with their browsers, normally they should NOT. ;)
So actually the problem appears to be related to my Cron job and the eMail Reports on states send out. Apparently. Or any other explanations? ???
 -
Well another thing is when are the states being created from your schedule there is 1 minute while its off. so at 23:59:01 its off til 23:59:59, then turns back on at 00:00
Just pointing out a possible flaw.. You would need to validate that the states are gone.. Why your email says they are none, but when you check is odd yes.
-
Same game today:
21:00 firewall block rule
21:00 eMail report for "pfctl -ss | grep 10.XXX.YYY.ZZZ" COMPLETELY EMPTY
21:01 Cron job "01 21 * * * root pfctl -F state"so far so good, but
21:14 I check states for the blocked IP via Diagnostics -> States and find: 32 states alive AS WELL AS by press "SEND NOW" for the eMail Report job for 21:00, same result dozends of states alive…
I erased the Cron job as well as the eMail report jobs yesterday and made them new. Makes no difference, as you see. Don't know what to do next...
-
Question:
Found this in my logs:
php: rc.start_packages: The command '/usr/local/etc/rc.d/cron.sh stop' returned exit code '1', the output was ''
Might this result in impaired Cron functionality?
-
That's not necessarily a problem. Cron is stopped and restarted along with all packages, usually in response to an IP change on one of your interfaces though could be a config change etc. As long as it starts again correctly it shouldn't be causing an issue though you could end up with multiple instances if it wasn't stopped correctly for example.
Steve
-
Status -> Services shows Cron as up and running
Diagnostics -> Sockets shows only one instance for Cron
Re-installed Cron package, but I still don't see proper functioning, as apparently the states are not killed (pfctl -F state) and the output from eMail reports (performed via Cron jobs) doesn't provide accurate information on the states present.
No idea why…
-
..got an idea why. Question:
In wich directory are the commands executed in the Diagnosics -> Execute Command window of the GUI?
Is it /usr/bin/ ?
That could make my Cron job for killing states work, if I find the right directory to execute the Cron job in…
-
To display the location of your current working directory, enter the command
pwd
The output should look similar to:
/home/user
-
Hey, many thanx!
Apparently it's
/usr/local/www
… I'll try that this evening... :-D
-
Make sure you use the absolute path to all the commands in your cron job. That way it doesn't matter where it's executed from.
Edit: Or, importantly, that the process executing the cron job may not have the same default paths as a shell prompt.Steve
-
Definitely! But at first you have to know the correct absolute path! ;)
-
Stephen is correct always use absolute paths in the scripts.
To find the location of a file, you can run the following command.
find / -name pfctl
-
OK, then it should be /sbin/pfctl … Try this today
What I really don't understand is the problem with the eMail Reports. When I press "Send Now" at the setup page for the respective job everything is fine and the eMail contains the information on the states for the requested IP. But when the Cron runs the respective php script the eMail contains no states at all... tried the /sbin/ path for the eMail Report command, too, let's see if it works... :-D
-
Can you post the commandline?
-
@chemlud:
….
21:00 eMail report for "pfctl -ss | grep 10.XXX.YYY.ZZZ" COMPLETELY EMPTY
...;)
Edit: Crazy, I tried the command (without /sbin/) on another box for a different IP (without a block rule at the firewall tab) and there the Cron-sent eMail Report is correct, including the states info for the requested IP. Dunno what's wrong here…
