[SOLVED] 2.4.3 - /rc.filter_configure_sync: cannot define table bogonsv6
-
People are also seeing it in 2.4.2+ as well, so not just a 2.4.3 thing. But pops up soon after the install/upgrade, triggering the error message.
Yes Confirmed.
I'm Running Pfsense 2.4.2 (X64) and these errors showed up in my logs yesterday (April 2, 2018).
I haven't seen none since today but i have upend my entries to 500000 to prevent a re occurrence.Regards
-
I assume what's happening is the monthly cron job that downloads and installs the latest bogons file is slowly working it's way through the community. So regardless of version, people will start popping in here one by one with the issue over the next ~25 - 30 days.
I assume what's likely happening on new installs (and likely upgrades), is that part of the post processing setup is to download the latest file, then schedule it to download again in 30 days time. That's why I think I am seeing it on fresh installs, right after initial setup wizard.
-
April 3 2018 bogons: 100,001 rows
ipv6 bogon prefixes 95,997
ipv4 bogon prefixes 4004bogon table size: 100,001 rows
If 2x are required to reload the table, then 200K seems slightly too small ;)
I now notice that my 2.4.2 systems are choking the same way as my freshly updated 2.4.3 systems if I both update bogons and reload the filter.
-
New to pfSense and after installing 2.4.3 on a new install this popped up in my alerts.
Unfortunately until I resolved this issue none of my port forwards would work at all.I bumped up the number of entries to 500,000 and my port forwards started working immediately.
This is just an FYI in case you can't get your port forwards to work to anyone else who is very new to pfSense.
-
The thing I don't understand is why it was 200K for you by default in the first place. I'm still on 2.3.4 and my default for "Firewall Maximum Table Entries" is 2M. (2 000 000). Did they reduce the default on purpose ?
-
Without going through the git revisions, I would say yes that somewhere between your release and the 2.4 releases it got changed to two hundred thousand 200,000. If you look at the link in the op for the bug ticket to get it fixed, the wording reads of changing the old default value of 200k to 400k. Letting you know that yes, 200k was the current default.
What I am also thinking is that maybe some add on packages, like pfblocker or snort etc., change this default value to a higher number based off the nature of what new rules they will likely need. This is purely speculative.
-
The thing I don't understand is why it was 200K for you by default in the first place. I'm still on 2.3.4 and my default for "Firewall Maximum Table Entries" is 2M. (2 000 000). Did they reduce the default on purpose ?
I've wondered the same thing. I'm on 2.4.3 and the default for "Firewall Maximum Table Entries" is 2M (2,000,000) on my system. I upgraded from 2.4.2 p1 but I don't remember what it was then and I don't remember ever changing it. Not sure where all these people are getting that their system has 200K as default.
-
The thing I don't understand is why it was 200K for you by default in the first place. I'm still on 2.3.4 and my default for "Firewall Maximum Table Entries" is 2M. (2 000 000). Did they reduce the default on purpose ?
I've wondered the same thing. I'm on 2.4.3 and the default for "Firewall Maximum Table Entries" is 2M (2,000,000) on my system. I upgraded from 2.4.2 p1 but I don't remember what it was then and I don't remember ever changing it. Not sure where all these people are getting that their system has 200K as default.
what additional packages do you have installed?
-
The thing I don't understand is why it was 200K for you by default in the first place. I'm still on 2.3.4 and my default for "Firewall Maximum Table Entries" is 2M. (2 000 000). Did they reduce the default on purpose ?
I've wondered the same thing. I'm on 2.4.3 and the default for "Firewall Maximum Table Entries" is 2M (2,000,000) on my system. I upgraded from 2.4.2 p1 but I don't remember what it was then and I don't remember ever changing it. Not sure where all these people are getting that their system has 200K as default.
what additional packages do you have installed?
I only have the APC UPS Daemon package installed. Everything else is just the default install. I don't have any of the other packages like PfBlockerNG, Squid or Squidguard installed.
-
The thing I don't understand is why it was 200K for you by default in the first place. I'm still on 2.3.4 and my default for "Firewall Maximum Table Entries" is 2M. (2 000 000). Did they reduce the default on purpose ?
I've wondered the same thing. I'm on 2.4.3 and the default for "Firewall Maximum Table Entries" is 2M (2,000,000) on my system. I upgraded from 2.4.2 p1 but I don't remember what it was then and I don't remember ever changing it. Not sure where all these people are getting that their system has 200K as default.
what additional packages do you have installed?
I only have the APC UPS Daemon package installed. Everything else is just the default install. I don't have any of the other packages like PfBlockerNG, Squid or Squidguard installed.
interesting. My install was just a vanilla 2.4.3. as soon as the config wizard was done, the error was already there.
-
Am I losing my mind?
I just updated another 2.4.2 system to 2.4.3, but noticed the new default is 400,000 entries whereas this thread started because the default was 200,000 entries just yesterday. "Ah, they did a minor point-release and updated the default" I reasoned.
However, when I went to the machines that I'd manually overridden from 200,000 to 400,000 I noticed that their defaults had also changed, even though they have not been updated (i.e. via point-release). Huh? Aren't the defaults hard-coded into the release?
What I've seen here would be more consistent with the defaults being periodically fetched from somewhere. Is that true?
-
I haven't looked at the code but I think there is a logic problem in that "the system default is X." I think it just says whatever the field is set to instead of actually computing what the default would actually be.
For instance, I didn't see this overrun on bogonsv6 because mine was set to 2,000,000 by something/someone/probablyme. It said "the default on this system is 2,000,000"
-
LOL.
By george you're right. Looks like on my system, the "system default" looks a an awful lot like Pi, but I've overridden it to 400,000 ;)
-
As a beginner, thank you very much for your explanation!
I have set entries to 500K
-
I'd like to thank you all as well for explaining this! Very helpful in resolving this issue.
-
I guess the big question here is why?
Why do we need to increase the Firewall Maximum Table Entries from 200k (default) to 500k all of a sudden? I have been running pfSense a long time and have never had to make this change. So what changed all of a sudden?
It's great there is a solution but there isn't any real explanation as to why we have to change this value?
Thanks,
-
The size of the IPv6 bogons table in the April update changed and pushed some systems over the edge.
The default has been changed to 400000 in 2.4.4
The timing of the bogons table monthly update and the release of 2.4.3 was simply coincidental.
-
I'm confirming that after I upgraded from 2.4.2_1 to 2.4.3, I had the same type of error:
Filter Reload
There were error(s) loading the rules: /tmp/rules.debug:19: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [19]: table <bogonsv6> persist file "/etc/bogonsv6"
@ 2018-04-09 09:15:46Changing the Firewall Maximum Table Entries from 200000 to 500000 and rebooting solved the problem.
-
Tricky situation
-
if increase the maximum entries size from 200k to 400k, then rules modification and filters reload work without need of reboot
-
BUT, then i lose all my bandwidth, coming from 140Mb/s to 1Mb/s
-
if i use back 200k instead of 400k, then i have the bug back, but my bandwidth is back to 140mb/s !!!
What the hell is that issue ???
-
-
I have the same problem, even increased to 4,000,000, it does not make the error go away.
Tried several values, increasing from default (listed as 200,000) to current 4,000,000 with reboots.Only solution i have for now is to "uncheck" the allow IPv6 Traffic in the System / Advanced / Networking section.
No more errors.
So i guess the bogonsv6 data is not loaded now?Have run PFSense for years without problems, 4 physical interfaces configured with about 10 VLANS, reasonable amount of rules, aliases etc.
Should i continue to increase the number and try? 4,000,000 already seems excessive. -
Your experience does not mirror countless others.
Are you sure you are changing maximum table entries and not maximum states? They are completely different things.
-
yes, i'm sure, did not touch the default for Max Firewall States.
![Screen Shot 2018-04-10 at 02.32.01.png](/public/imported_attachments/1/Screen Shot 2018-04-10 at 02.32.01.png)
![Screen Shot 2018-04-10 at 02.32.01.png_thumb](/public/imported_attachments/1/Screen Shot 2018-04-10 at 02.32.01.png_thumb) -
Zero reason for 4,000,000 there. Try 400000. Maybe you are really running out of RAM at 4,000,000.
It really is working for everyone but you.
-
Well, solved it, but don't understand.
Did at least 10 WebGUI reboots, system did really reboot, but kept having the problem.
Finally did a complete system shutdown, removed power and restarted, problem is gone.After that I changed the 4,000,000 back to 400,000 as you suggested and it still works.
(i had previously increased in increments 200K, 400K, 800K etc, did not change a thing)so, weird but solved, thanks for your help. :)
-
My buddy is having this exact same issue on a fresh 2.4.3 install on a Dell R210 II with E3-1320 v2. He has the bogons error, and when we changed it to 400,000 the error went away, but his internet speed TANKED. I'll tell him to leave it at 400,000 and to save and restart. If that doesn't work, shutdown, pull power and pop it back in. I have no idea why it would be different between the two options, except one is setting run level 6, the other run level 0.
-
I suppose it's possible there is an issue with processing the tables if the table size is increased but I have not seen it. In any case a simple reboot should fix it. That is strange.
-
My buddy was able to change the Max Table Entries to 400k and rebooted. His slowness went away. However, he still want receiving the same 250Mb down that he was getting on speedof.me. We tried a different speed test site (Comcast's as that's his ISP) and he was receiving 400Mbps. We confirmed this with the interfaces traffic graph on the dashboard.
This seems like a bad bug. Netgate should think about issueing a p1 immediately to fix this issue along with new install media. My friend nearly gave up on pfSense. I convinced him otherwise, but for a complete newbie with no one to go to, this could be a deal breaker.
-
It should be taken care of in the next release.
-
I understand that it should be, but it seems like a large bug if a fresh install kicks the error, but also causes very slow speeds. A fresh install should just work. Seems like a simple thing for Netgate to do. Not to mention it being the right thing to do.
-
Well keep in mind this isn't really an issue with the build itself. It's caused from the fact the bogons file (which gets downloaded) has now just barely exceeded the default 200k allocation.
While I agree with you that it's frustrating, and it caught me on a fresh install as well, it's not just specific to 2.4.3. It "should" be happening on all older releases as well that are downloading updated bogons and still have the default 200K value.
I assume for the dev's to come and issue a single commit to the exist 2.4.3 release branch, recompile, and then re-upload, they are likely just going to address in the next point release, which hopefully isn't too far behind. Something like a 2.4.3_p1 release.
I think it's just timing that the updated, larger bogons file came into play at the same time 2.4.3 was released.
Speed wise, I will say I have not seen a single issue as far as my bandwidth is concerned after updating to 400K (the new upcoming default), you are the first to say anything like that. I see my full 500Mbps down and 50Mbps up, consistently.
-
Confirmed - We started getting these errors in the last few weeks out of nowhere, no config changes on
2.3.2-RELEASE-p1 (amd64)
-
I still get this error:
There were error(s) loading the rules: /tmp/rules.debug:18: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [18]: table <bogonsv6> persist file "/etc/bogonsv6"
@ 2018-04-29 13:12:47And I have alread set Firewall Maximum Table Entries to 400000
and do the reload filters.Why?
-
Have you rebooted?
-
@joltman:
Have you rebooted?
Yes, in addition I have found that If I go to "System/General Setup" and click save without changing anyting it appears again.
Does it make any sense?Ops it looks like there was an empty space after the 400000