If we fail to open /dev/pf don't try to close it again. That would result in
errno getting overwritten by close(), hiding potentially useful information.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
The list of addresses is potentially very large. Larger than we can fit in a
single netlink request, so we indicate via the PFR_FLAG_START/PFR_FLAG_DONE
flags when we start and finish, so the kernel can work out which addresses need
to be removed.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Set the number of rulesets (i.e., anchors) directly attached to the
anchor and its path in pfctl_get_ruleset().
While here, add a test to document this behavior.
PR: 290478
Reviewed by: kp
Fixes: 041ce1d690 ("pfctl: recursively flush rules and tables")
MFC after: 2 days
Differential Revision: https://reviews.freebsd.org/D53358
Remember to also free ncounters.
Fixes: c00aca9a71 ("pf: Show pf fragment reassembly counters.")
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
time_t has a different size on different platforms (i.e. 32-bit on i386, 64-bit
on others). Rather than always exporting it as 64-bits use the platform-native
size.
This means we can safely write directly into a time_t variable, which we can't
do on i386 eif we export 64 bits.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Framgent count and statistics are stored in struct pf_status. From
there pfctl(8) and systat(1) collect and show them. Note that pfctl
-s info needs the -v switch to show fragments.
input claudio@; OK henning@
Obtained from: OpenBSD, bluhm <bluhm@openbsd.org>, 19e99d0613
Sponsored by: Rubicon Communications, LLC ("Netgate")
internal representation of icmp type/code in pfctl(8)/pf(4) does not
fit into u_int8_t. Issue has been noticed and kindly reported by
amalinin _at_ bh0.amt.ru via bugs@.
OK bluhm@
Obtained from: OpenBSD, sashan <sashan@openbsd.org>, 1fdb608f55
Sponsored by: Rubicon Communications, LLC ("Netgate")
These libraries don't install anything, so they shouldn't have a
PACKAGE setting. This avoids surprising behaviour in future if
e.g. manpages are added to an internal library.
Reported by: des
Differential Revision: https://reviews.freebsd.org/D51901
The 'nadd' returned by these calls is the number of addresses actually added
or deleted. It can differ from the number userspace sent to the kernel if the
addresses are already present (or not present for the delete case).
This meant that if all of the addresses were already handled the kernel would
return zero, putting us in an infinite loop.
Handle this, and extend the test case to provoke this scenario.
Reported by: netchild@
Fixes: bad279e12d ("pf: convert DIOCRDELADDRS to netlink")
Fixes: 8b388995b8 ("pf: convert DIOCRADDADDRS to netlink")
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add up to 64 addresses at once. We are limited by the netlink socket buffer, so
we can only add a limited number at once.
Sponsored by: Rubicon Communications, LLC ("Netgate")
The function pf_map_addr() and source tracking operate on a single
address family. This made sense before introducing address family
translation. When combining af-to with route-to or with sticky-address,
the next-hop or the NAT address are of different address family than
the source address. For example in NAT64 scenaro an IPv6 source address
is translated to an IPv4 address and routed over IPv4 gateway.
Make source nodes dual-AF, that is have a separate source AF and
redirection AF. Store route AF in struct pf_kstate, export it to pfctl.
When loading rules with redirection pools with pfctl store address
family of each address. When printing states don't deduce next-hop's
address family from af-to, use the one stored in state.
Reviewed by: kp
Approved by: kp
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D51659
The PFNL_CMD_CLR_ADDRS command returns a PF_T_NBR_DELETED, not a PF_TS_NZEO.
Handle this correctly.
While here add a test case to verify we return the expected counts when adding
or flushing addresses to/from a table.
PR: 288353
Sponsored by: Rubicon Communications, LLC ("Netgate")
Allow pf to limit packets to a specified maximum size. This applies to all
packets, and if reassembly is enabled, looks at the reassembled size, not the
size of individual fragments.
Sponsored by: Rubicon Communications, LLC ("Netgate")
allows things like
pass in proto icmp max-pkt-rate 100/10
all packets matching the rule in the direction the state was created are
taken into consideration (typically: requests, but not replies).
Just like with the other max-*, the rule stops matching if the maximum is
reached, so in typical scenarios the default block rule would kick in then.
with input from Holger Mikolon
ok mikeb
Obtained from: OpenBSD, henning <henning@openbsd.org>, 5a4ae9a9cb
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D50798
Zero out the struct pfctl_src_node before we read the next one. Avoid having
stray stack information (or the previous source node) influence our result.
Sponsored by: Rubicon Communications, LLC ("Netgate")
uma doesn't like setting a limit on a zone which previously had none.
At startup pf applies the default limit to all zones, so we can assume a limit
was always set. We cope with the uma limitation by translating a limit of '0'
(i.e. unlimited) to INT_MAX. This is high enough that we'll never realistically
hit this limit, but it keeps uma happy.
Add a test case to provoke this, and while we're here also fix syncookie
handling of a 0 state limit.
See also: d53927b0ba
Reported-by: syzbot+02b784f183f79d4c07e4@syzkaller.appspotmail.com
Sponsored by: Rubicon Communications, LLC ("Netgate")
For every state pf creates up to two source nodes: a limiting one
struct pf_kstate -> src_node and a NAT one struct pf_kstate -> nat_src_node.
The limiting source node is tracking information needed for limits using
max-src-states and max-src-nodes and the NAT source node is tracking NAT
rules only.
On closer inspection some issues emerge:
- For route-to rules the redirection decision is stored in the limiting source
node. Thus sticky-address and source limiting can't be used separately.
- Global source tracking, as promised in the man page, is totally absent from
the code. Pfctl is capable of setting flags PFRULE_SRCTRACK (enable source
tracking) and PFRULE_RULESRCTRACK (make source tracking per rule). The kernel
code checks PFRULE_SRCTRACK but ignores PFRULE_RULESRCTRACK. That makes
source tracking work per-rule only.
This patch is based on OpenBSD approach where source nodes have a type and each
state has an array of source node pointers indexed by source node type
instead of just two pointers. The conditions for limiting are applied
only to source nodes of PF_SN_LIMIT type. For global limit tracking
source nodes are attached to the default rule.
Reviewed by: kp
Approved by: kp (mentor)
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D39880
As suggested by henning.
Which unbreaks ie route-to after the recent pf changes.
With much help debugging and pointing out of missing bits from claudio@
ok claudio@ "looks good" henning@
Obtained from: OpenBSD, jsg <jsg@openbsd.org>, 7fa5c09028
Sponsored by: Rubicon Communications, LLC ("Netgate")
Just as we did in the kernel in e9255dafa1
Suggested by: glebius
Reviewed by: glebius, melifaro
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D48460
The general syntax is:
pass in inet from any to 192.168.1.1 af-to inet6 from 2001::1 to 2001::2
In the NAT64 case the "to" is not needed in af-to and the IP is extraced
from the IPv6 dst (assuming a /64 prefix).
Again most work by sperreault@, mikeb@ and reyk@
OK mcbride@, put it in deraadt@
Obtained from: OpenBSD, claudio <claudio@openbsd.org>, 0cde32ce3f
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47790
Now that we can NAT64 we can have states where the wire and stack address
families (and protocol) are different. Update the state export code to account
for this.
We keep exporting address family and protocol outside of the key, for backwards
compatibility. This'll return misleading information to userspace in the NAT64
case, but it's assumed that userspace will either understand NAT64 (and thus
look for them in the correct place), or not configure it.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47787
We won't follow this fully, because it involves breaking syntax changes
(removing nat/rdr rules and moving this functionality into regular rules) as
well as behaviour changes because NAT is now done after the rules evaluation,
rather than before it.
We import some related changes anyway, because it paves the way for nat64
support.
This change introduces a new pf_kpool in struct pf_krule, for nat. It is not yet
used (but will be for nat64) and renames the existing 'rpool' to 'rdr'.
Obtained from: OpenBSD, henning <henning@openbsd.org>, 0ef3d4febe
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D47783
Return errno rather than -1 on error. This allows pfctl to report much
more useful errors.
Reported by: Alexander Leidinger <Alexander@Leidinger.net>
MFC after: 1 week
add support to pf for filtering a packet by the interface it was received
on. use the received-on IFNAME filter option on a pf.conf rule to restrict
which packet the interface had to be received on. eg:
pass out on em0 from $foo to $bar received-on fxp0
ive been running this in production for a week now. i find it particularly
usefull with interface groups.
no objections, and a few "i like"s from henning, claudio, deraadt, mpf
Obtained from: OpenBSD, dlg <dlg@openbsd.org>, 95b4320893
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D46577
Kristof Provost