Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue

jimp

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

jimp

OK, I managed to reproduce this finally on the latest snapshot.

behemyth

OK cool. Anything you want me to try to fix it?

jimp

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

mikahe

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.

jimp

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).

behemyth

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.

jimp

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.

behemyth

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.

bigsy

Netgate SG-1000
Snapshot 2.4.5.r.20200223.0900

I'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

jimp

Right, there is still an issue we're investigating.

bigsy

@jimp Latest snapshots (Feb 28th) seem to have this sorted on the SG-1000.
Great work!

jimp

Yeah, we're getting closer. Still some issues yet, though.

bigsy

@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 &lt;bogonsv6&gt; persist file &quot;/etc/bogonsv6&quot;
@ 2020-03-13 06:02:21

jimp

@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 &lt;bogonsv6&gt; persist file &quot;/etc/bogonsv6&quot;
@ 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

bigsy

@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.

jimp

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 is Cannot allocate memory.

bigsy

@jimp Yep. Presbyopia. Spectacles on now!

ngnym

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?

jimp

@ngnym said in Upgrade to 2.4.5 > 2.4.4-p3 SG-3100 ipv6 bogon list issue:

Do I need to reboot again now (to make it use 400,000 vs 200,00) or is it still using 500,000?

On 2.4.5 there are two separate issues here. The pf table limit can be set immediately and it will use whatever value you put in there after the next filter reload. There is also a pf request limit which must be set and that only takes effect at boot time.

Presumably listing the wrong default is a bug, where should I report it

It's reporting the size as it was when the page was loaded, apparently, and not what the calculated default for the system would be. That may be a bug, though it should probably report both.