SG-5100 UDP States still alive after schedule expires. [2.4.5-RELEASE (amd64)]
-
-
-
It can take a bit for someone who actually uses the same options as you to come along.. Most here are volunteers.
Since you appear to be chugging along at diagnosis many of us will read and learn and then go off and think about it without commenting.
-
No further diagnosis to do. It is broken until they get around to fixing it.
But I am looking for a way to kill just the pertinent states without the inelegant solution of killing all states everywhere. So at least it is a more realistic workaround. As it is, if my wife is on a game or other logged in session, when any schedule expires, it kicks her (or me) off of what we were doing and we have to rejoin.
I had hoped that moving to "prosumer" equipment, that this would have worked correctly. I hope this does not offend anyone. This is as opposed to a $15K piece of equipment from one of the equipment giants.
As I mentioned, I added my comments to the bug reported on redmine in July of last year (2019). The same issue was brought up on the forums in February of 2017. I suspect that the poster may be the one who posted the bug on redmine, but I have no way of knowing, just guessing from the verbiage in both the post and bug report.
In any case, I was just having some fun with the pokes via cultural references (Simpsons and Pink Floyd).
I am actually quite disappointed, because the schedule is the primary reason I made the move to pfSense. I like a lot of things about it, but the firewall creating states to allow traffic back in via the intermediate state is very bad and a security risk.
In any case, no worries, I was just poking - LOL.
Phizix
-
It sounds like there is a way to run processes (even Python) on the box. If I had a script that could read all the states just before the schedule expires and kill all states to and from the hosts on that rule, plus any WAN rules that have them as the "original source", then I could make it work.
Phizix
-
Did you try the workaround in the thread you posted? https://forum.netgate.com/post/679884
"have a scheduled pass rule (which you already have) that expires and kills state at the same time as the scheduled block rule becomes active"
(or permanent block and scheduled allow, further down...https://forum.netgate.com/post/680667)I haven't used schedules all that much sorry, just once for limiters.
-
@teamits (Steve) ,
That is what I already have. I have a scheduled pass rule followed immediately by a block for that same alias group that is in the schedule.
The issue is that although the schedule expiring kills all states directly to and directly from the IPs in the alias, it does NOT kill the "intermediate" state where the firewall is the source and the "original source" is one of the IPs in the alias. This intermediate state appears to be spawned under one of the auto-generated NAT rules and is not subject to the state killing under the schedule expiration.
It is this intermediate state that then allows the firewall to spawn a new state from the information in that intermediate state that re-establishes the link back to the machine in the list. As far as I can tell it spawns this return state under another one of the auto-generated NAT rules, which is NOT governed by the scheduled rule at all.
Thank you for the suggestion.
Phizix
-
Actually, I don't know for sure these "hidden rules" are outbound NAT rules. I am only guessing. I can only see what the "pfctl -vvsr" command reports for rules in question as shown below:
@64(1000008011) pass out route-to (igb0 47.SPC.MY.GW) inet from 47.SPC.MY.IP to ! 47.SPC.RNG.0/21 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
@63(1000007913) pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
Phizix
-
@Phizix said in SG-5100 UDP States still alive after schedule expires. [2.4.5-RELEASE (amd64)]:
Actually, I don't know for sure these "hidden rules" are outbound NAT rules. I am only guessing. I can only see what the "pfctl -vvsr" command reports for rules in question as shown below:
@64(1000008011) pass out route-to (igb0 47.SPC.MY.GW) inet from 47.SPC.MY.IP to ! 47.SPC.RNG.0/21 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
@63(1000007913) pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
Phizix
Do you have any proxy package or something like Squid filtering running on the firewall? If so, maybe that is involved in the "hidden" rule state you mention.
-
I have three packages installed on the firewall -- pfBlockerNG-devel, Snort, and Cron. Beyond that i have no other packages or proxy installed.
pfBlockerNG-devel is blocking ads and some other lists I subscribe to.
Snort is set only to report suspicious traffic, but not block anything.
Cron is to set up the "pfctl -F state" to kill all states when the schedule expires.
I am guessing they are the auto-generated NAT outbound rules because they are part of the outbound mapping from my local IPs to the destination IPs.
You can look at the complete rules posted in the beginning rules. There are other rules I can't account for, but these are the two rules connected with the communication to internet sites under the scheduled allow rule. One rule maps from the LAN IP to the external IP, but then the firewall uses rule "64" to create the intermediate state that maps from the Firewall's external IP (from Spectrum) to one of the websites in question. In the state report under Diagnostics\States it shows the local LAN IP as the "Original source" IP, but the Firewall's external IP as the "Source" IP. The ports matches the state created under the allow by schedule rule, but of course the outbound port from the firewall has a NAT port from the firewall on that rule.
Does that clarify or muddy the waters?
Phizix
-
@Phizix said in SG-5100 UDP States still alive after schedule expires. [2.4.5-RELEASE (amd64)]:
I have three packages installed on the firewall -- pfBlockerNG-devel, Snort, and Cron. Beyond that i have no other packages or proxy installed.
pfBlockerNG-devel is blocking ads and some other lists I subscribe to.
Snort is set only to report suspicious traffic, but not block anything.
Cron is to set up the "pfctl -F state" to kill all states when the schedule expires.
Iam guessing they are the auto-generated NAT outbound rules because they are part of the outbound mapping from my local IPs to the destination IPs.
You can look at the complete rules posted in the beginning rules. There are other rules I can't account for, but these are the two rules connected with the communication to internet sites under the scheduled allow rule. One rule maps from the LAN IP to the external IP, but then the firewall uses rule "64" to create the intermediate state that maps from the Firewall's external IP (from Spectrum) to one of the websites in question. In the state report under Diagnostics\States it shows the local LAN IP as the "Original source" IP, but the Firewall's external IP as the "Source" IP. The ports matches the state created under the allow by schedule rule, but of course the outbound port from the firewall has a NAT port from the firewall on that rule.
Does that clarify or muddy the waters?
Phizix
Well, it would indicate that your original hypothesis is more likely correct. Unfortunately I don't know how you can address it short of writing your own script of some type (maybe in PHP) to do sort of semi-automatically what you did manually to connect the dots of states to LAN device IPs and then kill states associated with those connections.
This may not be a high priority issue for the developers in the grand scheme of things. While important to you I'm sure, and maybe to other users that use the scheduled rules feature, I doubt that is anywhere near a majority of pfSense users. Thus other things may be perceived as more pressing and grab the developers' time. Also don't forget this is free software. Netgate and the developers make their money from hardware and the paid support and stuff like TNSR, not from the Community Edition of pfSense. That's not to say they will never be interested, but it's likely a degree of priority thing.
If you have the skills to create the fix and post it as a pull request to Github for pfSense, I'm sure they will take a look and possibly merge it into the next version. That's kind of the idea behind open-source community-supported software like pfSense.
-
I did not expect that it would be elevated to top priority, that is why I am asking about other methods.
I also understand where they make their money. That is why I bought the SG-5100 instead of some third party hardware.
I will look at learning php for a workaround, and maybe at some point explore the code on Github. I can conceptually write up what the process that needs to spawn when a schedule ends should do, but I don't know the language enough at this point to write code.
In fact here is what it should do conceptually at the expiration of a schedule. It should first grab a snapshot of all states spawned under the rule. Then it should look for secondary related states - i.e. that match the LAN IP:Port to NAT states that have the same LAN IP:Port as the "Original source" and kill all of them too.
I really like the power of the pfSense software, but I am not a fan of rules that are not easy to connect back to a GUI rule object, even if it is not editable. For example, all of the firewall rules can be traced by looking at the Tracking ID in the rule or in the hover over and then using "pfctl -vvsr" and searching for the ID. But for the auto-generated outbound NAT rules no Tracking ID can be accessed in the GUI to trace. Also, by the way, the rules we are talking about are not in the backup xml created when you save.
I will keep plugging at it. Overall, it is still a damn sight better than any consumer firewall.
However I will again point out that regenerating a return state when the outbound state and matching inbound state that spawned the intermediate firewall state in the first place is killed just seems like very bad behavior indeed for any firewall software. To me this is the main takeaway irrespective of the schedule expiration.
In point of fact, I can recreate the same situation without the schedule expiration, by killing the state from a LAN IP:Port mapped to a Internet IP:Port, and the matching return state from the Internet IP:Port to the LAN IP:Port. The intermediate rule from the firewall itself to the Internet IP:Port will then cause a return state to be spawned back to the LAN IP:Port. This seems like a hack-able vulnerability to me.
Cheers, and have a great weekend!
Phizix
-
All,
After running for a week with the "pfctl -F state" method, it seems that most of the TV's never miss a beat since they seem to have enough buffered to keep going while reconnecting. My Amazon devices on the other hand are unresponsive for several minutes while reestablishing connection. DOH!
And my wife, that is another matter altogether. She is pretty unhappy when it boots her out of what she is doing at the time and she has to reconnect.
"C'est la vie."
Phizix
-
This is exactly what I've experienced since I recently decided to move over pfSense.
I went throughout studying, spending lot of time and money to be able to add security and properly schedule the use of internet at home, I've been able to achieve a lot, then I hit this wall.It didn't take long for people to realize they can establish a VPN connection just before the schedule kick in, opening the door to everything again...
I encourage more people to report it, with the hope dev raise the priority and finally resolve this long known issue.
Thanks for your effort, please let me know if you find a solution.pfSense 2.4.5-RELEASE (amd64) built on Tue Mar 24 15:25:50 EDT 2020 FreeBSD 11.3-STABLE
Intel i3 box, AES-NI enable, 4 Eth (1 WAN, 3 LAN)molepy
-
Thanks for the reply. What I am currently using works, but is VERY KLUGE.
I hate that it kill all states, but that is the only way to make it work.
Phizix
