Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue
-
Upgrading my SG-3100 from 2.4.4-P3 to 2.4.5, I get the following issue after it boots back up when I log in for the first time:
*Filter Reload
There were error(s) loading the rules: /tmp/rules.debug:18: cannot define table bogonsv6: too many elements. - The line in question reads [18]: table <bogonsv6> persist file "/etc/bogonsv6" @ 2020-02-11 14:45:31*
I was told to open a new thread about this. It was suggested I increase my Firewall Maximum Table Entries to several hundred thousand, I have it set to 850k and still receive this error mesage.
This is a very basic install, no weird rules or options, or even packages installed. I have duplicated the problem twice now.
-
Are you certain you upgraded to 2.4.5 and didn't somehow end up partially upgrading to 2.5.0?
This looks like https://redmine.pfsense.org/issues/9356 but that sysctl oid is not present in 2.4.5.
What do the commands following report?
uname -a
cat /etc/version
pkg info -x pfsense
-
OK, I managed to reproduce this finally on the latest snapshot.
-
OK cool. Anything you want me to try to fix it?
-
There doesn't appear to be anything that mitigates it short of disabling bogons at the moment.
I opened https://redmine.pfsense.org/issues/10254 with more details
-
I don't know if it's related to tens of error log lines: /tmp/rules.debug:31: cannot define table bogonsv6: Invalid argument; and
"There were error(s) loading the rules: /tmp/rules.debug:30: cannot define table bogonsv6: Invalid argument - The line in question reads [30]: table <bogonsv6> persist file "/etc/bogonsv6"
in latest build 2.4.5-RC Feb 13 17:39:39 EST 2020
but that RC seems to break completely routing function and 2 of 3 WAN interfaces. I have IPv6 enabled.
Previous build from Feb 13th was fine, but this had more updated packages.No-one can get out except the firewall itself. All firewall rules in LAN are showing 0/0 hits.
-
Reboot again and you'll be OK.
The higher
net.pf.request_maxcount
limit isn't getting set on the first boot with the new snapshot, but the next reboot will be fine.It didn't break routing, but the filter rules didn't load so you wouldn't have working NAT.
We're still working on it, but it's better now than it was before for most (especially ARM).
-
Is this version usable again on the arm appliances then? It sounds like you have to do the upgrade and then reboot it for it to work fully.
-
It works with large tables so long as you do the extra reboot right now. Once we put in a fix for that, it won't be necessary.
-
I can confirm this works on my sg-3100 now. You have to do the upgrade from 2.4.4 to 2.4.5, and then once it comes back up from the upgrade reboot the box one more time, and after about a minute ipv6 connectivity will work again.
-
Netgate SG-1000
Snapshot 2.4.5.r.20200223.0900I've looked at https://redmine.pfsense.org/issues/10254 and thought this might have been resolved. However it's still not working on first upgrade to this snapshot from an earlier version and a reboot is still required to load tables.
First boot-up:
[2.4.5-RC][root@]/root: sysctl net.pf.request_maxcount net.pf.request_maxcount: 65535 [2.4.5-RC][root@]/root: pfctl -f /tmp/rules.debug /tmp/rules.debug:18: cannot define table bogonsv6: too many elements. Consider increasing net.pf.request_maxcount. pfctl: Syntax error in config file: pf rules not loaded
Following reboot:
[2.4.5-RC][root@]/root: sysctl net.pf.request_maxcount net.pf.request_maxcount: 400000
-
Right, there is still an issue we're investigating.
-
@jimp Latest snapshots (Feb 28th) seem to have this sorted on the SG-1000.
Great work! -
Yeah, we're getting closer. Still some issues yet, though.
-
@jimp SG-1000 2.4.5-RC (arm) built on Fri Mar 13 00:05:30 EDT 2020
The error message has returned on this build.
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" @ 2020-03-13 06:02:21
-
@bigsy said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue:
@jimp SG-1000 2.4.5-RC (arm) built on Fri Mar 13 00:05:30 EDT 2020
The error message has returned on this build.
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" @ 2020-03-13 06:02:21
That's not the same problem. That's due to the low amount of RAM + the packages you have installed. That shouldn't be fatal like the other one, the tables do load by the time everything else is done.
See https://redmine.pfsense.org/issues/10310
-
@jimp OK thanks, my confusion came from the error message being the same as that which opens this particular thread.
This little SG-1000 is purely for testing. I've been updating 2.4.5-RC builds on a daily basis, haven't changed any packages, and that was the only time the error appeared. A later build from today (Fri Mar 13 03:05:27 EDT 2020) doesn't show the error.
-
If you look closely the error is not the same :-)
The one that was a problem in the builds says
too many elements
compared to your latest one which isCannot allocate memory
. -
@jimp Yep. Presbyopia. Spectacles on now!
-
When I upgraded to 2.4.5-RELEASE (arm) on my SG-3100 through the web interface, I started getting e-mail notifications with the bogon error. I didn't find this post, but I found older ones where, IIRC, it was recommended to set "Firewall Maximum Table Entries" to 400,000 or higher to resolve the error. It sounds like I probably encountered this issue and a reboot may have resolved my problem, but (again, IIRC) I eventually set the entry to 500,000 and rebooted. While troubleshooting a separate issue that I thought could be related to this, I checked and it was still set to 500,000 and it said 500,000 was the default, so I cleared that out and hit save. Shortly thereafter, without rebooting, I got an e-mail notification that said this:
To block bogon IPv6 networks the Firewall Maximum Table Entries value in System / Advanced / Firewall must be increased at least to 400,000
I logged back in to the web interface and the setting was showing 200,000 as the default, so I set it to 400,000 again. I left the page and went back, and it says the default is 400,000. So, two questions:
- Do I need to reboot again now (to make it use 400,000 vs 200,00) or is it still using 500,000?
- Presumably listing the wrong default is a bug, where should I report it?