Unable to edit rules due to bogonsv6? (I've tried the Max Table Entries setting)
-
Hey guys. I recently have been unable to update Firewall rules and every few minutes I get an error saying:
"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"I've looked on these forums and Google. It seems to be a common error and everything points to updating the "Firewall Maximum Table Entries" setting. After changing it to 400000 with no luck, I tried 800000, but it still does not work.
The only change I did before this started happening was updating to the most recent version after noticing there was an update.
I am running a Netgate 3100 on 22.01. Please let me know if you can help or if I can provide any more info. Thank you in advance!
-
Is it possible you're exhausting the available RAM?
Are you actually using IPv6? If not there is no reason to load the rules that use the table at all.
Steve
-
@stephenw10
According to the dashboard I am using 14% of 2017 MiB. I am not using IPv6, but I didn't want to just disable it in case there was a deeper problem I may be ignoring by doing that.It should be able to work with IPv6 on, right? It has for the past three years I've owned the router.
-
@a1itto It should work fine on a 3100 as we have it on one, but we have that router set to 2 million table entries. The bogonsv6 table is ~128,000 entries currently. You can see what tables you have loading in Diagnostics/Tables.
-
@steveits
That's odd.. it says 0
"Table last updated on Sat Feb 26 04:50:01 2022 GMT. 0 records."I also just updated the max table entries to 2000000.
-
@a1itto said in Unable to edit rules due to bogonsv6? (I've tried the Max Table Entries setting):
I am not using IPv6
Then for what reason should you want or need to download and store in a table the IPv6 bogon table for??????? Which is going to be freaking HUGE!!
The whole point of blocking bogon in the first place come into question to be honest. As a point of principle sure.. Ok this these IPs should not route on the internet - so if some traffic hits my interface saying its from this IP I shouldn't allow it.
Then again this IP doesn't route on the internet - so why would I be seeing traffic from this source IP in the first place.. If if I did - where would it be coming from other than the local network my wan is connected to, And if I allowed it to hit my port forwards - who freaking cares I have it open to the whole freaking internet anyway.
Not allowing or routing bogon from a netizen point of view - yeah you shouldn't route it, you should allow traffic it from it.. But then again the IPv6 space is freaking HUGE!!!! and guess what its list of bogon is freaking HUGE!!! the idea of even caring to store this in some table so I could block it from talking to some service I have open to the whole public internet on the off chance that some IP hits some IPv6 service I have open to the internet - but oh wait your IP is listed to not route anywhere and nobody routes this network so the only way you could possible talk to me is if you were on my local isp network, and I allow anyone to talk to this IP anyway but not you because your are "bogon" is just pointless..
Just disable trying to load this table!! you stated your not even using IPv6 - so what does it matter if this table takes 2k or 2TB to load - why are you loading it if you don't use IPv6 anyway. And even if you did - in the big picture how would a bogon source IP even get to you and if it even did what would it matter because you have opened your address up to the whole freaking planet anyway..
-
Yeah, I agree. I would disabling blocking bogons unless you have port forwards or other incoming allowed connections.
Steve
-
@johnpoz Perhaps a default config? I can look for a way to disable the IPv6 ones. I wasn't against not blocking IPv6 bogons, but I was more worried about just disabling IPv6 entirely.
edit: I disabled blocking bogons and the error went away, which is great. Thank you!
I still feel like something is broken though and this was just a way to work around it. Is it possible to disable blocking only the IPv6 ones?
-
@a1itto said in Unable to edit rules due to bogonsv6? (I've tried the Max Table Entries setting):
but I was more worried about just disabling IPv6 entirely.
Why is that - you stated your not using it.. Can you name 1 service that would require you to have an IPv6 address?
My isp doesn't even offer IPv6 - I can only use it through a tunnel, which I do in a limited sense as testing only. My main machine doesn't have it enabled - guess what, there is not one thing on the internet that I would have any need or want to get to that I can not.
The IPv6 bogon table has 130k some entries in it.. What else are you running that would use a lot of table entries? Any pfblocker with IPv6? Do you have aliases created that try and load lots of different countries complete IP space?
My max tables entries are set to 1.6million - if your going to do things that require lots of possible entries than you need to set it to a level that would allow you to do that, like playing with IPv6..
-
@johnpoz Because I may use it in the future. I would rather find the root cause of the issue and fix it rather than turn off a feature I'm not using today just to have the issue again when my setup can support IPv6.
-
@a1itto said in Unable to edit rules due to bogonsv6? (I've tried the Max Table Entries setting):
when my setup can support IPv6.
Dude that could be 10-20 years before they start turning off IPv4.. Maybe even longer - do you really think say next week amazon.com is going to say you know what, only IPv6 now.. They don't even have it now ;) Either does twitter ;).. Or ebay even.. While sure IPv6 is the future, that future is not any time soon that is for sure. Even like 4th biggest site really on the planet.. baidu.com doesn't have it..
Again - set the table limit up, mine is at 1.6 million, set it 3.2 million your trying to load a lot of tables like you know china's IPv6 space in pfblocker..
