Question on Firewall Schedules in pfSense 2.3.2
-
I'm trying to create a schedule to setup an ALLOW rule for a period of time so I can control when my kid is watching TV (since all of our services are streaming).
The docs here https://doc.pfsense.org/index.php/Firewall_Rule_Schedules state:
"Firewall rules can be scheduled so that they are only active at certain times of day or on certain specific days or days of the week."
When I try to create a schedule in pfSense, I'm entering my start time and end time, and give it a description, but it won't allow me to add the schedule without adding at least one date. Thing is, I want to to be an on-going rule.. I don't want this for one specific date on the calendar, nor do I want to have to manually click every date from now until August 2017.
With the way the doc is written, and with the way one would expect scheduling to work, this seems like a bug. Can anyone confirm if this is a bug, or if there is a way to "wild card" the date so it's an on-going deal?
Thanks!
– Ron
-
Click individual date to select that date only. Click the appropriate weekday Header to select all occurrences of that weekday.
So if you want the same thing to fire every day, select all weekdays using the weekday headers (Sun, Mon, Tue, etc). Only on Mondays, select only Monday.
-
IIRC with the older config, it didn't work if you left it open but had some block rules – the states would remain open and not cleared. Instead, you had to block everything and then create rules when to allow access. I wonder if it still behaves this backwards way.
-
It doesn't seem to work… I am having the same issue with states remaining after the scheduled PASS expires.
I have UpNP off, block rule above pass rule in the LAN tab..
I have been using PF for years but it seems the last release or two, something has changed or broken the way states are cleared when the schedule changes?
:o
-
No idea. I don't use scheduling at all, but I remember the way you had to do it wasn't intuitive unless you understood what was going on behind the scenes.
-
Something is broken on the last release.. I have removed the pass rules in the LAN tab and both aliases can still access all blocked services.
Manually clearing states works initially however, the states re-establish after a few mins..
-
Unpossible. Every time I lab this when someone says it doesn't work it works just fine.
If there is not a matching pass rule on LAN traffic will be blocked.
-
Thanks for the reply but this is the case.. Something must have gone wrong with the last update..
Looks like a re-install :'(
-
Doubtful. But a reinstall takes 5 minutes + packages so if you think that might be the case, it can't hurt.
-
Thanks, reinstall tonight and report.
-
I thought i would try an older config backup before reinstalling PF from scratch.
It looks like everything is working again… Scheduled blocks are fine and firewall log entries are as expected.
Previously, no LAN blocks were working and nothing was showing in the firewall logs.. Not sure what went wrong but the older config reload fixed my issues for now.
Would be nice to know what went wrong? :o
-
Ok, problem back again.. The only thing I can point to is after modifying the schedules the scheduled 'pass' rule does not seem to work. After I manually clear states, the links are broken and the schedule shows the correct status in the 'pass' rule but after another cycle, the scheduled 'pass' doesn't kill states.
-
No one has a similar issue or any suggestions?
-
Looks like this is an old/unsolved problem…
To solve it you can add a cron job to clear all states for that IP ( or more IP's ) after time schedule is not active with this command:
/sbin/pfctl -k IP example: /sbin/pfctl -k 192.168.103.100
Just remember:
- first rule will allow to pass traffic on time schedule for that IP.
- second rule will deny traffic for that IP.
- cron will clear all states for that IP ( 1 minute after first rule is not active ).
-
Yes, seems to be an ongoing issue..
After a reboot, everything works fine for a week or so and then the states don't clear properly..
-
I am still having this issue. . I have narrowed it down to when I make a change to a schedule this problem occurs.
I have tried resetting states and reloading the firewall rules after the schedule change but after the timed block/pass, some states remain active and require a manual clearing of states.
As long astory the schedules are not altered, everything works as expected..
I shouldn't have to reboot after a schedule change?
-
I should hope not. If this is something you can reproduce faithfully, you could post your steps here for others to confirm, and then enter a bug at Redmine to address it.
-
Could you please have a look at my rules?
I have blocked out the kids names but what I have are all IP's setup in aliases, a bandwidth limiter and different schedules for blocking steam ports (alias again) and to completely block internet using PASS rules in the schedule.
![lan rules.JPG_thumb](/public/imported_attachments/1/lan rules.JPG_thumb)
![lan rules.JPG](/public/imported_attachments/1/lan rules.JPG) -
Are you sure the Steam ports being blocked should be source ports? Source ports are usually random to specific destination ports.
-
Good question, my understanding is the 'source' in this situation would be the host on the LAN, as per the rule?
The block works if applied manually and also most of the time however as I mentioned, if I modify a schedule, reload the firewall rules and reset states the scheduled block stops working and requires a reboot of the firewall..
-
Source ports are almost always random. Destination ports are almost always static.
For instance to pass connections only to HTTP servers you would pass source LAN net port any dest any port 80 on the LAN interface.
-
So you are suggesting to change the port alias to destination? Like the utorrent rule I have setup in the picture?
-
I am suggesting you make sure your rules match the traffic you are trying to match.
-
I am suggesting you make sure your rules match the traffic you are trying to match.
I tried swapping my rules around as you seemed to suggest :-\ and nothing is blocked/filtered after changing to 'destination' in the LAN tab..
Again, my configuration does work fine except when the schedules are changed.. A reboot is required to get the new schedule to work correctly.
-
Yeah I doubt that it works with source ports..
Quick google shows these as the ports.
Steam Client
UDP 27000 to 27015 inclusive (Game client traffic)
UDP 27015 to 27030 inclusive (Typically Matchmaking and HLTV)
UDP 27031 and 27036 (incoming, for In-Home Streaming)
TCP 27036 and 27037 (incoming, for In-Home Streaming)
UDP 4380.As Derelict mentions it is almost ALWAYS any for source port, dest would be the port your looking at in firewall rules. Unless your talking say active ftp session for data where the source port is 20. Or maybe in a dns zone transfer where your talking 53 to 53, etc. The cases where you would set a specific source port are few and specific. Steam would NOT be one of them.
So not sure what you think is working.. But that rule would not work.. What do you have in your steam alias??
If your saying your schedules do not work until you reboot, my guess would be you have active states open for the traffic your trying to block and your reboot flushes them. Which you can do without a reboot.
-
Yeah I doubt that it works with source ports..
Quick google shows these as the ports.
Steam Client
UDP 27000 to 27015 inclusive (Game client traffic)
UDP 27015 to 27030 inclusive (Typically Matchmaking and HLTV)
UDP 27031 and 27036 (incoming, for In-Home Streaming)
TCP 27036 and 27037 (incoming, for In-Home Streaming)
UDP 4380.As Derelict mentions it is almost ALWAYS any for source port, dest would be the port your looking at in firewall rules. Unless your talking say active ftp session for data where the source port is 20. Or maybe in a dns zone transfer where your talking 53 to 53, etc. The cases where you would set a specific source port are few and specific. Steam would NOT be one of them.
So not sure what you think is working.. But that rule would not work.. What do you have in your steam alias??
If your saying your schedules do not work until you reboot, my guess would be you have active states open for the traffic your trying to block and your reboot flushes them. Which you can do without a reboot.
It does work, lastnight it worked as expected..
-
Those rules are almost certainly wrong. Based on the information available on the steam site they are wrong.
Steam might try to use those as source ports which would cause them to pass and might try different source ports when they are blocked and fail to match the proper rules.
Look at Diagnostics > States and enable logging on those rules to see what's really happening.
You can create a pass rule from the source machines AFTER that block steam rule and enable logging on it to see what's getting passed.
-
Those rules are almost certainly wrong. Based on the information available on the steam site they are wrong.
Steam might try to use those as source ports which would cause them to pass and might try different source ports when they are blocked and fail to match the proper rules.
Look at Diagnostics > States and enable logging on those rules to see what's really happening.
You can create a pass rule from the source machines AFTER that block steam rule and enable logging on it to see what's getting passed.
The rules or aliases are wrong?
If they are wrong, why are they working until I alter the schedule?
-
Impossible to answer without seeing the actual states and firewall logs.
Your alias looks fine, though I would make a TCP alias and rule and a UDP alias and rule.
-
Impossible to answer without seeing the actual states and firewall logs.
Your alias looks fine, though I would make a TCP alias and rule and a UDP alias and rule.
So I need to create seperate TCP and UDP rules even though the firewall rule has an option for TCP/UDP for a particular rule?
-
There is no reason to pass UDP-only ports as TCP as well.
-
There is no reason to pass UDP-only ports as TCP as well.
So, it doesn't matter for what I am trying to work out then… only for security, which I understand.
Have you read the complete thread?
-
Yes. You exhibit a fundamental misunderstanding of how firewall rules work, the ports you are trying to control, and generally dismiss anyone who tries to correct you.
-
Yes. You exhibit a fundamental misunderstanding of how firewall rules work, the ports you are trying to control, and generally dismiss anyone who tries to correct you.
Wow, anyone else have anything constructive to add?
-
Yes. You exhibit a fundamental misunderstanding of how firewall rules work, the ports you are trying to control, and generally dismiss anyone who tries to correct you.
Obviously I do not understand, hence the questions.
I have not dismissed anyone?
-
Are you sure the Steam ports being blocked should be source ports? Source ports are usually random to specific destination ports.
Back to your original question, as far as my understanding goes, the 'source' is the client on the LAN. Changing the ports or in this case the alias to 'destination' does not work at all.
Also, I do understand that usually source ports are random when forwarding ports (NAT) however is this the case in situations like this?
I do appreciate you responding however, you have not offered any solutions, only suggesting things are 'wrong'.
Again, first post - "As long as the schedules are not altered, everything works as expected.."
My issue was with altering the schedules and states, not with the rules themselves. I posted the rules to make sure I wasn't making a simple mistake.
I am no expert and I do read and try to work it out myself before asking for assistance.
Being a moderator on this forum, I would have expected a little less criticism and more assistance from you.. :o
-
I do appreciate you responding however, you have not offered any solutions, only suggesting things are 'wrong'.
Have you read the whole thread?
Things are not as you think they are. Source and destination ports are not what you think they are.
Every time someone tries to get that point across to you you say "but it sometimes works." Reasons have been given why that might be the case.
Yet here you are saying it doesn't work as you expect. That's because things do not work how you think they do.
None of this has anything to do with pfSense. It is basic IP networking.
Here's what you do. Forget about steam. Pick one IP address and one service. A good one might be DNS queries to DEST ADDR: 8.8.8.8 (HINT: SOURCE PORT: any DEST PORT: TCP/UDP 53) Figure out how to properly pass or block that traffic from a specific local host. Once you have that down the rest will be easy.
-
Here's what you do. Forget about steam. Pick one IP address and one service. A good one might be DNS queries to DEST ADDR: 8.8.8.8 (HINT: SOURCE PORT: any DEST PORT: TCP/UDP 53) Figure out how to properly pass or block that traffic from a specific local host. Once you have that down the rest will be easy.
Ok, I have created a simple BLOCK rule on the LAN tab in the firewall rules. I have assigned an ALIAS to the IP address and assigned the ALIAS to my iPad. When placing the ALIAS in DESTINATION all traffic is passed. When placing the ALIAS in SOURCE, all traffic is BLOCKED.
I have attached the working firewall rule and a snip of the logs.
-
Right. In that case you ARE filtering on the source to destination any.
-
Right. In that case you ARE filtering on the source to destination any.
That is how I have my Steam rules setup. wiht an ALLOW schedule. The issue I am experiencing is after modifying a schedule, not all states are flushing correctly after the schedule expires. I had a look in the firewall logs lastnight and they were UDP states. Could this be due to the way I have my alias setup? IE- all ports setup as TCP/UDP? You mentioned to seperate the ports and create seperate aliases and rules?