sys/netpfil/pf: fix non-INET module build

pf.ko, when built as a module without 'options INET' but with 'options
VIMAGE', won't load:

link_elf_obj: symbol vnet_entry_in_loopback_mask undefined

Thi

sys/netpfil/pf: fix non-INET module build

pf.ko, when built as a module without 'options INET' but with 'options
VIMAGE', won't load:

link_elf_obj: symbol vnet_entry_in_loopback_mask undefined

This is because it uses IN_LOOPBACK(), which in the VIMAGE case uses
INET-specific symbols.

Fix by making this check conditional on #ifdef INET.

Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1157

show more ...

netpfil: Fix typos in source code comments

- s/addres/address/

MFC after: 3 days

pf: fix reply-to after rdr and dummynet

If we redirect a packet to localhost and it gets dummynet'd it may be
re-injected later (e.g. when delayed) which means it will be passed
through ip_input() a

pf: fix reply-to after rdr and dummynet

If we redirect a packet to localhost and it gets dummynet'd it may be
re-injected later (e.g. when delayed) which means it will be passed
through ip_input() again. ip_input() will then reject the packet because
it's directed to the loopback address, but did not arrive on a loopback
interface.

Fix this by having pf set the rcvif to V_iflo if we redirect to
loopback.

See also: https://redmine.pfsense.org/issues/15363
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: fix use-after-free

If we fragment the packet in pf_route() the first transmitted packet
will free the pf_mtag we have stored in pf_pdesc (pd). Ensure we
update that pointer for every packet to a

pf: fix use-after-free

If we fragment the packet in pf_route() the first transmitted packet
will free the pf_mtag we have stored in pf_pdesc (pd). Ensure we
update that pointer for every packet to avoid using a freed pointer in
pf_dummynet_route().

Reported by: CI KASAN, markj
MFC after: 1 week

show more ...

pf: fix dummynet + route-to

Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.

We mark the processing as outbound so that dummynet will re-in

pf: fix dummynet + route-to

Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.

We mark the processing as outbound so that dummynet will re-inject in
the correct phase of processing after it's done with the packet, but
that will cause us to pick the wrong pipe number. Reverse them so that
the incorrect decision ends up picking the correct pipe.

Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44366

show more ...

pf: avoid passing through dummynet multiple times

In some setups we end up with multiple states created for a single
packet, which in turn can mean we run the packet through dummynet
multiple times.

pf: avoid passing through dummynet multiple times

In some setups we end up with multiple states created for a single
packet, which in turn can mean we run the packet through dummynet
multiple times. That's not expected or intended. Mark each packet when
it goes through dummynet, and do not pass packet through dummynet if
they're marked as having already passed through.

See also: https://redmine.pfsense.org/issues/14854
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44365

show more ...

pf: support if-bound with reply-to

On reply-to we don't know what interface to bind to when we create
the state. Create any reply-to state as floating, but bind to the
appropriate interface once we'

pf: support if-bound with reply-to

On reply-to we don't know what interface to bind to when we create
the state. Create any reply-to state as floating, but bind to the
appropriate interface once we're handling the reply.

See also: https://redmine.pfsense.org/issues/15220
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: fix packet-to-big for route-to as well

When we handle a packet via route-to (i.e. pf_route6()) we still need to
verify the MTU. However, we only run that check in the forwarding case.

Set the P

pf: fix packet-to-big for route-to as well

When we handle a packet via route-to (i.e. pf_route6()) we still need to
verify the MTU. However, we only run that check in the forwarding case.

Set the PFIL_FWD tag when running the pf_test6(PF_OUT) check from
pf_route6(). We are in fact forwarding, so should call the test function
as such. This will cause us to run the MTU check, and generate an ICMP6
packet-too-big error when required.

See also: 54c62e3e5d8cd90c5571a1d4c8c5f062d580480e
See also: f1c0030bb05cfa01bdd500e50befbb425fecc4c4
See also: https://redmine.pfsense.org/issues/14290
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: add a probe point to BOUND_IFACE

It's been useful at least once, so we may as well keep it.

Sponsored by: Rubicon Communications, LLC ("Netgate")

pf: Ensure that st->kif is obtained in a way which respects the r->rpool->mtx mutex

The redirection pool stored in r->rpool.cur is used for loadbalancing
and cur can change whenever loadbalancing ha

pf: Ensure that st->kif is obtained in a way which respects the r->rpool->mtx mutex

The redirection pool stored in r->rpool.cur is used for loadbalancing
and cur can change whenever loadbalancing happens, which is for every
new connection. Therefore it can't be trusted outside of pf_map_addr()
and the r->rpool->mtx mutex. After evaluating the ruleset, loadbalancing
decission is made in pf_map_addr() called from within pf_create_state()
and stored in the state itself.

This patch modifies BOUND_IFACE() so that it only uses the information
already stored in the state which has been obtained in a way which
respects the r->rpool->mtx mutex.

Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D43741

show more ...

Revert "pf: Ensure that st->kif is obtained in a way which respects the r->rpool->mtx mutex"

This commit is correct, but was misattributed. Revert so we can re-apply
with the correct author set.

Th

Revert "pf: Ensure that st->kif is obtained in a way which respects the r->rpool->mtx mutex"

This commit is correct, but was misattributed. Revert so we can re-apply
with the correct author set.

This reverts commit 6d4a140acfdf637bb559d371c583e4db478e1549.

show more ...

pf: Ensure that st->kif is obtained in a way which respects the r->rpool->mtx mutex

The redirection pool stored in r->rpool.cur is used for loadbalancing
and cur can change whenever loadbalancing ha

pf: Ensure that st->kif is obtained in a way which respects the r->rpool->mtx mutex

The redirection pool stored in r->rpool.cur is used for loadbalancing
and cur can change whenever loadbalancing happens, which is for every
new connection. Therefore it can't be trusted outside of pf_map_addr()
and the r->rpool->mtx mutex. After evaluating the ruleset, loadbalancing
decission is made in pf_map_addr() called from within pf_create_state()
and stored in the state itself.

This patch modifies BOUND_IFACE() so that it only uses the information
already stored in the state which has been obtained in a way which
respects the r->rpool->mtx mutex.

Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D43741

show more ...

sys/netpfil/pf/pf.c: remove an extra semicolon

Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/959

sys/netpfil/pf/pf.c: remove an extra semicolon

Signed-off-by: rilysh <nightquick@proton.me>
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/959

pf: ensure dummynet gets the correct direction after route-to

If we apply a route-to to an inbound packet pf_route() may hand that
packet over to dummynet. Dummynet may then delay the packet, and la

pf: ensure dummynet gets the correct direction after route-to

If we apply a route-to to an inbound packet pf_route() may hand that
packet over to dummynet. Dummynet may then delay the packet, and later
re-inject it. This re-injection (in dummynet_send()) needs to know
if the packet was inbound or outbound, to call the correct path for
continued processing.

That's done based on the pf_pdesc we pass along (through
pf_dummynet_route() and pf_pdesc_to_dnflow()). In the case of pf_route()
on inbound packets that may be wrong, because we're called in the input
path, and didn't update pf_pdesc->dir.

This can manifest in issues with fragmented packets. For example, a
fragmented packet will be re-fragmented in pf_route(), and if dummynet
makes different decisions for some of the fragments (that is, it delays
some and allows others to pass through directly) this will break.

The packets that pass through dummynet without delay will be transmitted
correctly (through the ifp->if_output() call in pf_route()), but
the delayed packets will be re-injected in the input path (and not
the output path, as they should be). These packets will pass through
pf_test(PF_IN) as they're tagged PF_MTAG_FLAG_DUMMYNET. However,
this tag is then removed and the packet will be routed and enter
pf_test(PF_OUT) where pf_reassemble() will hold them indefinitely
(as some fragments have been transmitted directly, and will never hit
pf_test(PF_OUT)).

The fix is simple: we must update pf_pfdesc->dir to PF_OUT before we
pass the packet to dummynet.

See also: https://redmine.pfsense.org/issues/15156
Reviewed by: rcm
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: bind route-to states to their route-to interface

When we route-to the state should be bound to the route-to interface,
not the default route interface. However, we should only do so for
outbound

pf: bind route-to states to their route-to interface

When we route-to the state should be bound to the route-to interface,
not the default route interface. However, we should only do so for
outbound traffic, because inbound traffic should bind on the arriving
interface, not the one we eventually transmit on.

Explicitly check for this in BOUND_IFACE().

We must also extend pf_find_state(), because subsequent packets within
the established state will attempt to match the original interface, not
the route-to interface.

Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43589

show more ...

pf: only check MTU for IPv6 packets when forwarding

When the packets are generated locally (i.e. PFIL_FWD is not set) we
might generate overly large packets and rely on the NIC to fragment it
for us

pf: only check MTU for IPv6 packets when forwarding

When the packets are generated locally (i.e. PFIL_FWD is not set) we
might generate overly large packets and rely on the NIC to fragment it
for us. In that case we'd reject a valid packet.

Reported by: Herbert J. Skuhra <herbert@gojira.at>
Tested by: Herbert J. Skuhra <herbert@gojira.at>
Fixes: 54c62e3e5d8cd90c5571a1d4c8c5f062d580480e
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: work around icmp6 packet-too-big not being sent when binat-ing

If we're applying NPTv6 we pass a packet with a modified source and/or
destination address to the network stack.

If that packet th

pf: work around icmp6 packet-too-big not being sent when binat-ing

If we're applying NPTv6 we pass a packet with a modified source and/or
destination address to the network stack.

If that packet then turns out to be larger than the MTU of the sending
interface the stack will attempt to generate an icmp6 packet-too-big
error, but may fail to look up the appropriate source address for that
error message. Even if it does, pf would still have to undo the binat
operation inside the icmp6 packet so the sending host can make sense of
the error.

We can avoid both problems entirely by having pf also perform the MTU
check (taking the potential refragmentation into account), and
generating the icmp6 error directly in pf.

See also: https://redmine.pfsense.org/issues/14290
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43499

show more ...

pflow: add RFC8158 NAT support

Extend pflow(4) to send NAT44 Session Create and Delete events.
This applies only to IPFIX (i.e. proto version 10), and requires no
user configuration.

Sponsored by:

pflow: add RFC8158 NAT support

Extend pflow(4) to send NAT44 Session Create and Delete events.
This applies only to IPFIX (i.e. proto version 10), and requires no
user configuration.

Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43114

show more ...

pf: store state creation/expiration timestamps with milisecond precision

The primary beneficiary is pflow(4), which expects milisecond precision
in timestamps.

Sponsored by: Rubicon Communications,

pf: store state creation/expiration timestamps with milisecond precision

The primary beneficiary is pflow(4), which expects milisecond precision
in timestamps.

Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43112

show more ...

pf: allow pflow to be activated per rule

Only generate ipfix/netflow reports (through pflow) for the rules where
this is enabled. Reports can also be enabled globally through 'set
state-default pflo

pf: allow pflow to be activated per rule

Only generate ipfix/netflow reports (through pflow) for the rules where
this is enabled. Reports can also be enabled globally through 'set
state-default pflow'.

Obtained from: OpenBSD
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43108

show more ...

pflow: import from OpenBSD

pflow is a pseudo device to export flow accounting data over UDP.
It's compatible with netflow version 5 and IPFIX (10).

The data is extracted from the pf state table. St

pflow: import from OpenBSD

pflow is a pseudo device to export flow accounting data over UDP.
It's compatible with netflow version 5 and IPFIX (10).

The data is extracted from the pf state table. States are exported once
they are removed.

Reviewed by: melifaro
Obtained from: OpenBSD
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43106

show more ...

pflog: pass the action to pflog directly

If a packet is malformed, it is dropped by pf(4). The rule referenced
in pflog(4) is the default rule. As the default rule is a pass
rule, tcpdump printed

pflog: pass the action to pflog directly

If a packet is malformed, it is dropped by pf(4). The rule referenced
in pflog(4) is the default rule. As the default rule is a pass
rule, tcpdump printed "pass" although the packet was actually
dropped. Use the actual action, rather than the rule's action, or an
attempt at guessing the correct action.

Inspired by OpenBSD's 'pflog(4) logs packet dropped by default rule with block.' commit.

Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: don't clobber log flag

If we decide to discard a packet due to unexpected IP options or
unsupported headers we set pd.act.log. However, this can later get
overwritten when we copy the state's sa

pf: don't clobber log flag

If we decide to discard a packet due to unexpected IP options or
unsupported headers we set pd.act.log. However, this can later get
overwritten when we copy the state's saved actions over.

Merge the two log fields to ensure we log as expected.

Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...

pf: remove incorrect fragmentation check

We do not need to check PFDESC_IP_REAS while tracking TCP state.
Moreover, this check incorrectly considers no-data packets (e.g. RST) to
be in-window when t

pf: remove incorrect fragmentation check

We do not need to check PFDESC_IP_REAS while tracking TCP state.
Moreover, this check incorrectly considers no-data packets (e.g. RST) to
be in-window when this flag is not set.

Sponsored by: Rubicon Communications, LLC ("Netgate")
Approved by: so
Security: FreeBSD-SA-23:17.pf

show more ...