nat-to
and
rdr-to
rule options, respectively
route-to
, reply-to
and
dup-to
rule options
Tables are created either in pf.conf(5) or by using pfctl(8).
table
directive in
pf.conf
,
The following attributes may be specified for each table:
const
- the contents of the table cannot be changed once the
table is created.
When this attribute is not specified,
pfctl(8) may be used to add
or remove addresses from the table at any time, even when running with a
securelevel(7) of two
or greater.
persist
- causes the kernel to keep the table in memory even
when no rules refer to it.
Without this attribute, the kernel will automatically remove the table
when the last rule referencing it is flushed.
table <goodguys> { 192.0.2.0/24 } table <rfc1918> const { 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } table <spammers> persist block in on fxp0 from { <rfc1918>, <spammers> } to any pass in on fxp0 from <goodguys> to anyAddresses can also be specified using the negation (or "not") modifier, such as:
table <goodguys> { 192.0.2.0/24, !192.0.2.5 }The
goodguys
table will now match all addresses in the
192.0.2.0/24 network except for 192.0.2.5.
Note that table names are always enclosed in < > angled brackets.
Tables can also be populated from text files containing a list of IP addresses and networks:
table <spammers> persist file "/etc/spammers" block in on fxp0 from <spammers> to anyThe file
/etc/spammers
would contain a list of IP addresses
and/or
CIDR
network blocks, one per line.
pfctl
# pfctl -t spammers -T add 203.0.113.0/24This will also create the <spammers> table if it doesn't already exist. To list the addresses in a table, run:
# pfctl -t spammers -T showThe
-v
argument can also be used with -T show
to
display statistics for each table entry.
To remove addresses from a table, run:
# pfctl -t spammers -T delete 203.0.113.0/24For more information on manipulating tables with
pfctl
,
see the pfctl(8) man page.
self
keyword.
The table will then contain all IP addresses assigned to that interface
or group, or to the machine (including loopback addresses), respectively.
One limitation when specifying addresses is that 0.0.0.0/0
and
0/0
will not work in tables.
The alternative is to hard code that address or use a
macro.
table <goodguys> { 172.16.0.0/16, !172.16.1.0/24, 172.16.1.100 } block in on dc0 pass in on dc0 from <goodguys>Any packet coming in through
dc0
will have its source address
matched against the table <goodguys>
: