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