History log of /freebsd/sys/net/pfvar.h (Results 51 – 75 of 311)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2339ead6 29-Aug-2024 Kristof Provost <kp@FreeBSD.org>

pf: allow filtering on the receive interface

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
whic

pf: allow filtering on the receive interface

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

show more ...


# 390dc369 06-Sep-2024 Tom Jones <thj@FreeBSD.org>

pf: Add support for endpoint independent NAT bindings for UDP

With Endpoint Independent NAT bindings for UDP flows from a NATed source
address are always mapped to the same ip:port pair on the NAT r

pf: Add support for endpoint independent NAT bindings for UDP

With Endpoint Independent NAT bindings for UDP flows from a NATed source
address are always mapped to the same ip:port pair on the NAT router.
This allows a client to connect to multiple external servers while
appearing as the same host and enables NAT traversal without requiring
the client to use a middlebox traversal protocol such as STUN or TURN.

Introduce the 'endpoint-independent' option to NAT rules to allow
configuration of endpoint independent without effecting existing
deployments.

This change satisfies REQ 1 and 3 of RFC 4787 also known as 'full cone'
NAT.

Using Endpoint Independent NAT changes NAT exhaustion behaviour it does
not introduce any additional security considerations compared to other
forms of NAT.

PR: 219803
Co-authored-by: Damjan Jovanovic <damjan.jov@gmail.com>
Co-authored-by: Naman Sood <mail@nsood.in>
Reviewed-by: kp
Sponsored-by: Tailscale
Sponsored-by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11137

show more ...


# 0578fe49 30-Aug-2024 Kristof Provost <kp@FreeBSD.org>

pf: rework pf_icmp_state_lookup() failure mode

If pf_icmp_state_lookup() finds a state but rejects it for not matching the
expected direction we should unlock the state (and NULL out *state). This
s

pf: rework pf_icmp_state_lookup() failure mode

If pf_icmp_state_lookup() finds a state but rejects it for not matching the
expected direction we should unlock the state (and NULL out *state). This
simplifies life for callers, and also ensures there's no confusion about what a
non-NULL returned state means.

Previously it could have been left in there by the caller, resulting in callers
unlocking the same state twice.

MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...


# 5ab1e5f7 26-Aug-2024 Kristof Provost <kp@FreeBSD.org>

pf: improve the ICMPv6 direction check

Following bluhm's advice this changes the way we setup state keys and
perform state lookups for ICMPv6 Neighbor Discovery packets:
- replace the NS-dst with

pf: improve the ICMPv6 direction check

Following bluhm's advice this changes the way we setup state keys and
perform state lookups for ICMPv6 Neighbor Discovery packets:
- replace the NS-dst with ND target address;
- replace the NA-src with ND target address;
- replace the NA-dst with unspecified address if it is a multicast.

This allows pf to match Address Resolution, Neighbor Unreachability
Detection and Duplicate Address Detection packets to the corresponding
states without the need to create new ones or match unrelated ones.
As a side effect we're doing now one state table lookup for ND packets
instead of two.

Fixes a bug uncovered by one of the previous commits that virtually
breaks IPv6 connectivity after few minutes of use.

ok stsp henning, with and ok bluhm

PR: 280701
MFC after: 1 week
Obtained from: OpenBSD, mikeb <mikeb@openbsd.org>, 2633ae8c4c8a
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...


# 2096ad13 26-Aug-2024 Kristof Provost <kp@FreeBSD.org>

pf: sprinkle const in pf_pull_hdr()

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


# 7e65cfc9 19-Aug-2024 Mark Johnston <markj@FreeBSD.org>

pf: Make pf_get_translation() more expressive

Currently pf_get_translation() returns a pointer to a matching
nat/rdr/binat rule, or NULL if no rule was matched or an error occurred
while applying th

pf: Make pf_get_translation() more expressive

Currently pf_get_translation() returns a pointer to a matching
nat/rdr/binat rule, or NULL if no rule was matched or an error occurred
while applying the translation. That is, we don't distinguish between
errors and the lack of a matching rule. This, if an error (e.g., a
memory allocation failure or a state conflict) occurs, we simply handle
the packet as if no translation rule was present. This is not
desireable.

Make pf_get_translation() return the matching rule as an out-param and
instead return a reason code which indicates whether there was no
translation rule, or there was a translation rule and we failed to apply
it, or there was a translation rule and we applied it successfully.

Reviewed by: kp, allanjude
MFC after: 3 months
Sponsored by: Klara, Inc.
Sponsored by: Modirum
Differential Revision: https://reviews.freebsd.org/D45672

show more ...


# 1fc0dac5 15-Aug-2024 Kajetan Staszkiewicz <vegeta@tuxpowered.net>

pf: Convert struct pf_addr_wrap before sending it over netlink

The struct pf_addr_wrap when used inside of kernel operates on pointers to
tables or interfaces. When reading a ruleset the struct must

pf: Convert struct pf_addr_wrap before sending it over netlink

The struct pf_addr_wrap when used inside of kernel operates on pointers to
tables or interfaces. When reading a ruleset the struct must contain
counters calculated from the aforementioned tables and interfaces. Both the
pointers and the resulting counters are stored in an union and thus can't be
present in the struct at the same time.

The original ioctl code handles this by making a copy of struct pf_addr_wrap
for pool addresses, accessing the table or interface structures by their
pointers, calculating the counter values and storing them in place of those
pointers in the copy. Then this copy is sent over ioctl.

Use this mechanism for netlink too. Create a copy of src/dst addresses. Use
the existing function pf_addr_copyout() to convert pointers to counters both
for src/dst and pool addresses.

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

show more ...


# 6c479edc 15-Aug-2024 Kajetan Staszkiewicz <vegeta@tuxpowered.net>

pf: Fix indentation in struct pf_ksrc_node

This is a purely cosmetic change to simplify future diffs.

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


# 9ae91f59 19-Jul-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert DIOCGETADDR to netlink

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


# 644b7b5a 19-Jul-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert DIOCGETADDRS to netlink

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


# 271f1469 17-Jul-2024 Kristof Provost <kp@FreeBSD.org>

pf: vnet-ify pf_hashsize, pf_hashmask, pf_srchashsize and V_pf_srchashmask

These variables are tunables, so in principle they never change at runtime.
That would mean they don't need to be tracked p

pf: vnet-ify pf_hashsize, pf_hashmask, pf_srchashsize and V_pf_srchashmask

These variables are tunables, so in principle they never change at runtime.
That would mean they don't need to be tracked per-vnet.

However, they both can be decreased (back to their default values) if the
memory allocations for their respective tables fail, and these allocations are
per-vnet. That is, it's possible for a few vnets to be started and have the
tuned size for the hash and srchash tables only to have later vnets fail the
initial allocation and fall back to smaller allocations. That would confuse
the previously created vnets (because their actual table size and size/mask
variables would no longer match).

Avoid this by turning these into per-vnet variables.

MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

show more ...


# d909f06b 16-Jul-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert DIOCADDADDR to netlink

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


# 66b8cac8 24-Jun-2024 Mark Johnston <markj@FreeBSD.org>

pf: Sprinkle const qualifiers in state lookup routines

State keys are trivially const in lookup routines, so annotate them as
such. No functional change intended.

Reviewed by: kp
MFC after: 1 week

pf: Sprinkle const qualifiers in state lookup routines

State keys are trivially const in lookup routines, so annotate them as
such. No functional change intended.

Reviewed by: kp
MFC after: 1 week
Sponsored by: Klara, Inc.
Sponsored by: Modirum
Differential Revision: https://reviews.freebsd.org/D45671

show more ...


# b6196537 20-Jun-2024 Mateusz Guzik <mjg@FreeBSD.org>

pf: fix the "keepcounters" to stop truncating to 32-bit

The machinery to support 64-bit counters even on 32-bit kernels had a
bug where it would unitentionally truncate the value back to 32-bits
whe

pf: fix the "keepcounters" to stop truncating to 32-bit

The machinery to support 64-bit counters even on 32-bit kernels had a
bug where it would unitentionally truncate the value back to 32-bits
when transferring to a new counter. This resulted in buggy be behavior
on 64-bit kernels as well.

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

show more ...


# ba2a9207 07-Jun-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert DIOCBEGINADDRS to netlink


# d9ab8999 07-Jun-2024 Kristof Provost <kp@FreeBSD.org>

pf: migrate DIOCGETLIMIT/DIOCSETLIMIT to netlink

Event: Kitchener-Waterloo Hackathon 202406


# 30bad751 05-Jun-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert DIOCGETTIMEOUT/DIOCSETTIMEOUT to netlink


Revision tags: release/14.1.0
# 9dbbe68b 30-May-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert DIOCCLRSTATUS to netlink

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


# 6ee3e376 24-May-2024 Kristof Provost <kp@FreeBSD.org>

pf: fix incorrect anchor_call to userspace

777a4702c changed how we copy out the anchor_call string, and
incorrectly limited it to 8 (4 on 32-bit systems) bytes. Fix that so we
get the full anchor p

pf: fix incorrect anchor_call to userspace

777a4702c changed how we copy out the anchor_call string, and
incorrectly limited it to 8 (4 on 32-bit systems) bytes. Fix that so we
get the full anchor path, rather than just the first few characters.

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

show more ...


Revision tags: release/13.3.0
# 706d465d 26-Feb-2024 Kristof Provost <kp@FreeBSD.org>

pf: convert kill/clear state to use netlink

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


# 777a4702 12-Jan-2024 Kristof Provost <kp@FreeBSD.org>

pf: implement addrule via netlink

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


# 54c62e3e 17-Jan-2024 Kristof Provost <kp@FreeBSD.org>

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 ...


# 04932601 07-Dec-2023 Kristof Provost <kp@FreeBSD.org>

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 ...


# baf9b6d0 01-Dec-2023 Kristof Provost <kp@FreeBSD.org>

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 ...


# f92d9b1a 28-Nov-2023 Kristof Provost <kp@FreeBSD.org>

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 ...


12345678910>>...13