freebsd stable - Apr 2021 - using interface groups in pf tables stopped working in 13.0-RELEASE

In pf I use the interface group syntax alot to make the configuration more
readable. All interfaces are assigned to a group representing its use/vlan name.

For example:

ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot vlan'
up"
ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"

ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt vlan?
up"
ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64?

in pf.conf I use these group names all over the place. But since I upgraded to
13.0-RELEASE it no longer works to define a table using the :network syntax and
interface groups:

table   <nat_addresses> const { trusted:network mgmt:network dmz:network
guest:network edmz:network \
        admin:network iot:network client:network }

If I reload the configuration I get the following:
# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

I have tried to use just one network, double check the interface group setting
and so on, but with no luck.

to use actual interface works just fine:

table   <nat_addresses> { igb1.300:network }

but using the group fails:

# ifconfig -g mgmt
igb1.300

table   <nat_addresses> { mgmt:network }

# pfctl -f /etc/pf.conf
/etc/pf.conf:12: cannot create address buffer: Invalid argument
pfctl: Syntax error in config file: pf rules not loaded

Any ideas? 

Thanks!

/Peter.

> On 14 Apr 2021, at 16:16, Peter Ankerst?l <peter at pean.org> wrote:
> 
> In pf I use the interface group syntax alot to make the configuration more
readable. All interfaces are assigned to a group representing its use/vlan name.
It seems that the rest of my ruleset is also affected by this, and interface
groups combined with :network no longer work.

For example I have this anchor:
    anchor in from trusted:network {
    }

which before resolved to 
    anchor in inet from 172.25.0.0/24 to any {
    }

but now resolves to:
    anchor in inet6 all {
    }

/Peter.

On 2021-04-14 07:16, Peter Ankerst?l wrote:
> In pf I use the interface group syntax alot to make the configuration more
> readable. All interfaces are assigned to a group representing its use/vlan 
> name.
> 
> For example:
> 
> ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot
vlan' up"
> ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"
> 
> ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt
vlan? up"
> ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64?
> 
> in pf.conf I use these group names all over the place. But since I upgraded
> to
> 13.0-RELEASE it no longer works to define a table using the :network syntax
> and
> interface groups:
> 
> table   <nat_addresses> const { trusted:network mgmt:network
dmz:network
> guest:network edmz:network \
>         admin:network iot:network client:network }
> 
> If I reload the configuration I get the following:
> # pfctl -f /etc/pf.conf
> /etc/pf.conf:12: cannot create address buffer: Invalid argument
> pfctl: Syntax error in config file: pf rules not loaded
Some changes in the pf source have been made over the last couple
of months. The error returned appears to be related. It appears
that your running into a table size/count and memory allocation
related error. The first change moved/changed memory allocation to
kernel space, requiring one to increase allocation via loader.conf(5).
It was recently moved back to userspace allowing one to make changes
to a running system via sysctl.conf(5) or the commandline.
IOW if your on the recent change you should be able to simply
increase your table count by executing something like:
# echo "set limit table-entries <larger-table-count>" | pfctl -m
-f -
OTOH if your stuck with the change in kernelspace, increase
net.pf.request_maxcountby some amount in loader.conf(5). If you are on the newer
userspace
change, you can issue the sysctl(8) command at your terminal for
net.pf.request_maxcountas well.

HTH

--Chris
> 
> I have tried to use just one network, double check the interface group 
> setting and
> so on, but with no luck.
> 
> to use actual interface works just fine:
> 
> table   <nat_addresses> { igb1.300:network }
> 
> but using the group fails:
> 
> # ifconfig -g mgmt
> igb1.300
> 
> table   <nat_addresses> { mgmt:network }
> 
> # pfctl -f /etc/pf.conf
> /etc/pf.conf:12: cannot create address buffer: Invalid argument
> pfctl: Syntax error in config file: pf rules not loaded
> 
> Any ideas?
> 
> Thanks!
> 
> /Peter.
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"

On 14 Apr 2021, at 16:16, Peter Ankerst?l wrote:
> In pf I use the interface group syntax alot to make the configuration 
> more readable. All interfaces are assigned to a group representing its 
> use/vlan name.
>
> For example:
>
> ifconfig_igb1_102="172.22.0.1/24 group iot description 'iot
vlan' up"
> ifconfig_igb1_102_ipv6="inet6 2001:470:de59:22::1/64"
>
> ifconfig_igb1_300="172.26.0.1/24 group mgmt description 'mgmt
vlan?
> up"
> ifconfig_igb1_300_ipv6="inet6 2001:470:de59:26::1/64?
>
> in pf.conf I use these group names all over the place. But since I 
> upgraded to 13.0-RELEASE it no longer works to define a table using 
> the :network syntax and interface groups:
>
> table   <nat_addresses> const { trusted:network mgmt:network 
> dmz:network guest:network edmz:network \
>         admin:network iot:network client:network }
>
> If I reload the configuration I get the following:
> # pfctl -f /etc/pf.conf
> /etc/pf.conf:12: cannot create address buffer: Invalid argument
> pfctl: Syntax error in config file: pf rules not loaded
>
I can reproduce that.

It looks like there?s some confusion inside pfctl about the network 
group. It ends up in pfctl_parser.c, append_addr_host(), and expects an 
AF_INET or AF_INET6, but instead gets an AF_LINK.

It?s probably related to 250994 or possibly 
d2568b024da283bd2b88a633eecfc9abf240b3d8.
Either way it?s pretty deep in a part of the pfctl code I don?t much 
like. I?ll try to poke at it some more over the weekend.

Best regards,
Kristof