Cannot define table 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