Cannot define table bogons

mcdiesel

I'm seeing the same issue.

Just upgraded from 2.1 to 2.2.4, on a system that has been very stable.

pfSense on kvm on proxmox on qcow2 disks

Same error messages.

Traffic flowing within openvpn, but not to internet.

doktornotor

Either run


/etc/rc.update_bogons.sh 0

or really just disable the bogons snake oil.

phil.davis

Is there actually a file /etc/bogons ?

There is code in /etc/inc/filter.inc that should create an empty bogons file if it is not there already:

	if (!file_exists("/etc/bogons"))
		@file_put_contents("/etc/bogons", "");

Actually that will not work on nanoBSD (if the file system is mounted RO) as far as I can see. But you seem to be on a full install.

Look in /etc/inc/filter.inc and see if that code is there. Maybe Snort package does something weird to that?

doktornotor

/etc/bogons is distributed with the release. (Trimmed down 10 line version.)

https://github.com/pfsense/pfsense/blob/RELENG_2_2/etc/bogons

phil.davis

Yes, I wonder how it can go missing completely when it comes in the vanilla install. And specially when there is code to put back an empty one of it does go missing.

doktornotor

Hmmm, I think empty file is not useful anyway, will produce error on loading the rules either way.

phil.davis

@doktornotor:

Hmmm, I think empty file is not useful anyway, will produce error on loading the rules either way.

I just checked this - cleared out /etc/bogons and /etc/bogonsv6 to 0 bytes, enabled the bogons block on WAN. The rule set has all the bogon stuff in it and load fine. bogons and bogonsv6 show up empty from Diagnostics->Tables. So an empty file will result in an empty table and of course nothing being blocked, but at least no error loading rules.

mcdiesel

Appologies for the delay in reply, a truck hit a power pole near us, downing the pole and the 11kv feeder, taking out power. UPS kicked in but VDSL died. The roadside service cabinet was very near the pole. The VDSL cards were fried, huge black scorch marks and exploded components on the cards. Telco tech said he'd replaced dozens of these cards, even from lightening, but never seen a pair this bad.

Anyway, issue seems to be with the either the syntax of the table statement or the thing that processes it.

The system is a full install, as it's a VM.

The bogons table is fairly straightforward. It's not damaged. Updating it doesn't make a difference. Deleting the bogons file altogether causes the parser to not insert a table load statement for bogons file.

This just kicks the can down the road to the next table statement, in this case the table vpn_networks on line [19].

This block of table statements is from #Snort tables, but snort has been uninstalled (because there was some yuck in the logs about syntax errors that I didn't have time to chase down)

So the snort table lines shouldn't even be inserted into the rules file, so the snort package uninstaller is not ripping out all that it has inserted into the rules builder.

So I tried re-installing the snort package 3.2.6, in case having it back would make it run it's rules properly. No luck, still the same error

There were error(s) loading the rules: /tmp/rules.debug:19: cannot define table vpn_networks: Invalid argument - The line in question reads [19] table { 10.0.1.0/24 10.1.1.0/24 10.0.4.0/24 }
```. 

Still also limited traffic flow (only vpn, no internet), because the rules aren't loading properly, bailing out at line 19.  However snort is completely unconfigured, so that may be a problem, the default install with no config, no rules might not be enough for it to work, or at least not stop other things working.

But wait, there is a setting…,
_Keep Snort Settings After Deinstall   Settings will not be removed during package deinstallation._

Untick that, uninstall snort, still same error….

pfctl -f /tmp/rules.debug
/tmp/rules.debug:19: cannot define table vpn_networks: Invalid argument
/tmp/rules.debug:20: cannot define table negate_networks: Invalid argument
/tmp/rules.debug:160: rule expands to no valid combination
pfctl: Syntax error in config file: pf rules not loaded


Following phil.davis suggestion, let's wrestle with /etc/inc/filter.inc and comment out the snort table bits…snort2c & virusprot.

Nup, error moves to line 16, remains on the vpn_networks line. The table <bogons>line remains in, but is no longer causing an issue.  Bit reluctant to remove the vpn_networks line, as I'm doing all this over the openVPN to the other side of the city.  Setup ssh alternate access method via the outer router. Note to self, add a management interface to virtual host server.

So commenting out table <vpn_networks>disolves the rule load error.  The line 160 error above was my mistake, I had a ipv6 rule when ipv6 was all turned off.

So do we have traffic? No.  :'(

Ok, so ordinary trouble shooting be possible?  Firewall logs show ordinary DNS queries to a vpn dns server are blocking, so looks like that missing table <vpn_networks>has busted stuff.

Turn the table vpn_networks back on, reload filter rules, back to same error

loader There were error(s) loading the rules: /tmp/rules.debug:16: cannot define table vpn_networks: Invalid argument - The line in question reads [16]: table { 10.0.1.0/24 10.1.1.0/24 10.0.4.0/24 }

pfctl -f /tmp/rules.debug
/tmp/rules.debug:16: cannot define table vpn_networks: Invalid argument
/tmp/rules.debug:17: cannot define table negate_networks: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded


Ok, stuck now, what is the correct syntax for pf rules?</vpn_networks></vpn_networks></bogons>

mcdiesel

Missing commas perhaps?

This http://www.openbsd.org/faq/pf/tables.html page has commas seperating the list of vpn networks. The /tmp/rules.debug file doesn't

So is /etc/inc/filter.inc#filter_get_vpns_list() being naughty, building an array without commas? Surely that issue would have been struck before now.

Seems not, space is likely just as good a seperator as comma.


loader There were error(s) loading the rules: /tmp/rules.debug:16: cannot define table vpn_networks: Invalid argument - The line in question reads [16]: table { 10.0.1.0/24, 10.1.1.0/24, 10.0.4.0/24 }...

pfctl -f /tmp/rules.debug
/tmp/rules.debug:16: cannot define table vpn_networks: Invalid argument
/tmp/rules.debug:17: cannot define table negate_networks: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

cat /tmp/rules.debug | grep table
table <vpn_networks>{ 10.0.1.0/24, 10.1.1.0/24, 10.0.4.0/24 }
table <negate_networks>{ 10.0.1.0/24, 10.1.1.0/24, 10.0.4.0/24 }</negate_networks></vpn_networks>

??? What next?

mcdiesel

Ok, how about those underscores in the table name?

Nup


There were error(s) loading the rules: /tmp/rules.debug:16: cannot define table vpnnetworks: Invalid argument - The line in question reads [16]: table { 10.0.1.0/24, 10.1.1.0/24, 10.0.4.0/24 }...

Why does the line in question read table { instead of table vpnnetworks {


pfctl -f /tmp/rules.debug
/tmp/rules.debug:16: cannot define table vpnnetworks: Invalid argument
/tmp/rules.debug:17: cannot define table negatenetworks: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Ok, how about manually….


pfctl -t vpnnetworks -T add 10.1.1.0/24
1 table created.
pfctl: Invalid argument.

Interesting. So it's not even a table syntax or parsing error. It's pf itself not liking perhaps the network?

mcdiesel

To eliminate cruft issues, did a clean install of 2.1 on the same virtual host.

Configured bare minimum config, sitting beside the other instance, on the same networks.

Then apply 2.2.4 auto upgrade

Reboot, bingo, back to the /etc/bogons error.

mcdiesel

Clean install 2.2.4 on same proxmox platform, /etc/bogons errors.

mcdiesel

In case it's relevant, hardware is an hp ml110 g3 which runs a p4 at 3ghz, and noteably, no VT (ie no cpu hardware virtualizaton support)

doktornotor

Maybe it's just proxmox being POS?

seidler2547

@mcdiesel:

In case it's relevant, hardware is an hp ml110 g3 which runs a p4 at 3ghz, and noteably, no VT (ie no cpu hardware virtualizaton support)

That's interesting, because I'm seeing the same issue on a fresh 2.3.2 install, under libvirt+qemu, no VT (need to send someone to change the BIOS setting). So I would guess that's a software emulation error when parsing the file in a VM without hardware virtualization.

I tried to change the CPU model but to no avail.

Stefan

individual-it

I have the same problem in a QEMU VM with pfsense 2.4 development

this line in the default bogons file does make the trouble:
169.254.0.0/16

deleting this one line solves the problem.
but then if I change e.g. 127.0.0.0/8 to 127.0.0.0/16 it does not work again
So how can /16 be different to /8 in that case?

That is really strange because it seems to be alright in a VirtualBox VM

alyberty

I have the same problem too on libvirt+qemu (no kvm, no VT-X/AMD-V).
The Hypervisor is Debian jessie
-> libvirtd (libvirt) 1.2.9
-> qemu-system-x86_64 | QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6)
-> pfsense 2.3.3-RELEASE-p1 (amd64)

I tried different cpu emulation types (currently: QEMU Virtual CPU version 2.1.2).

I couldn't fix/silence the bogons error message by only removing 169.254.0.0/16.
I removed all, and only left "0.0.0.0/0" in the file.

I noticed some other operations don't work as expected.
While the generated outbound NAT rules don't work, the exact same rule works if I only match to /7 (or anything below /8) rather then /24.
These rules should be equivalent (for my setup), but are not handled this way. Could this be a problem from the QEMU virtualization not correctly performing the CIDR matching?

When I have time I'll try to use the same configuration on qemu with kvm as emulator, checking if it works.

Has anyone of you noticed something similar? Is someone successfully using pfsense on qemu (without kvm)?
The packets generated by pfsense are otherwise correct so virtio (https://doc.pfsense.org/index.php/VirtIO_Driver_Support) shouldn't be the problem.

d.carmignani

Hi, I also had this error, in my case it happened using qemu as hypervisor. With KVM it works correctly instead, so it's probably an issue of virtualization