We removed the code for these modes back in 2015, but converted such
configurations to 'scrub fragment reassemble'. It's been long enough,
drop the backwards compatibility glue too.
Reviewed by: mjg
MFC after: never
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D37460
scrub rules have defaulted to handling fragments for a long time, but
since we removed "fragment crop" and "fragment drop-ovl" in 64b3b4d611
this has become less obvious and more expensive ("reassemble" being the
more expensive option, even if it's the one the vast majority of users
should be using).
Extend the 'scrub' syntax to allow fragment reassembly to be disabled,
while retaining the other scrub behaviour (e.g. TTL changes, random-id,
..) using 'scrub fragment no reassemble'.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D37459
Allow pf (l2) to be used to redirect ethernet packets to a different
interface.
The intended use case is to send 802.1x challenges out to a side
interface, to enable AT&T links to function with pfSense as a gateway,
rather than the AT&T provided hardware.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D37193
When syncookies are in adaptive mode they may be active or inactive.
Expose this status to users.
Suggested by: Guido van Rooij
Sponsored by: Rubicon Communications, LLC ("Netgate")
Use time_t rather than uint32_t to represent the timestamps. That means
we have 64 bits rather than 32 on all platforms except i386, avoiding
the Y2K38 issues on most platforms.
Reviewed by: Zhenlei Huang
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36837
Similar to the preceding fix for layer three rules, ensure that we
recursively list wildcard anchors for ethernet rules.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36417
Fix a couple of problems with printing of anchors, in particular recursive
printing, both of inline anchors and when requested explicitly with a '*'
in the anchor.
- Correct recursive printing of wildcard anchors (recurse into child anchors
rather than rules, which don't exist)
- Print multi-part anchor paths correctly (pr6065)
- Fix comments and prevent users from specifying multi-component names for
inline anchors.
tested by phessler
ok henning
Also fix the relevant pfctl test case to reflect the new (and now
correct) behaviour).
MFC after: 3 weeks
Obtained from: OpenBSD (mcbride, f9a568a27c740528301ca3419316c85a9fc7f1de)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36416
Ensure that we pass the (base) anchorname to the kernel, not the '/*'
suffix.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36415
When the interface does not exist avoid passing host with special pf
modifiers to DNS resolution as they come up empty anyway.
Reviewed by: kp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35429
In 1e73fbd8b we fixed an issue with POM_STICKYADDRESS being checked in
the wrong struct.
Add a basic test case for this fix.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
pass inet proto icmp icmp-type {unreach}
pass route-to (if0 127.0.0.1/8) sticky-address inet
The wrong struct was being tested. The parser tries to prevent
"sticky-address sticky-address" syntax but was actually cross-rule
enforcing that ICMP filter cannot be before the use of "sticky-address"
in next rule.
MFC after: 2 weeks
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D36050
If pfctl is called with "pfctl -a ''" we read outside of the anchoropt
buffer. Check that the buffer is sufficiently long to avoid that.
Maintain the existing (and desired, because it's used as such in
/etc/periodic/security/520.pfdenied) behaviour of treating "-a ''" as a
request for the root anchor (or no anchor specified).
PR: 264128
Reviewed by: kp
Similar to ipfw rule timestamps, these timestamps internally are
uint32_t snaps of the system time in seconds. The timestamp is CPU local
and updated each time a rule or a state associated with a rule or state
is matched.
Reviewed by: kp
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34970
Since a16732d670 we always print the l3 src/destination for Ethernet
rules. Update the tests to account for this.
Sponsored by: Rubicon Communications, LLC ("Netgate")
While the kernel only performs the L3 check for
ETHERTYPE_IP/ETHERTYPE_IP6 we should always print the source and
destination addresses.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34918
Allow tables to be used for the l3 source/destination matching.
This requires taking the PF_RULES read lock.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34917
When asked to print rules recursively, correctly recurse for anchors
included in pf.conf with "anchorname/*".
PR: 262590
Reviewed by: kp
MFC after: 3 weeks
Disallow the use of tables in ethernet rules. Using tables requires
taking the PF_RULES lock. Moreover, the current table code isn't ready
to deal with ethernet rules.
Disallow their use for now.
Sponsored by: Rubicon Communications, LLC ("Netgate")
When retrieving nat rules in anchors we need to set the path just like
we do for regular rules.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Allow filtering based on the source or destination IP/IPv6 address in
the Ethernet layer rules.
Reviewed by: pauamma_gundo.com (man), debdrup (man)
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34482
Introduce pfctl_get_rules_info(), similar to pfctl_get_eth_rules_info()
to retrieve rules information (ticket and total number of rules).
Use the new function in pfctl.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D34443
Just as pfctl already does for other rules we print the ethernet rules
we would have loaded if '-n' is specified.
Sponsored by: Rubicon Communications, LLC ("Netgate")
When filtering Ethernet packets allow rules to specify a mac address
with a mask. This indicates which bits of the specified address are
significant. This allows users to do things like filter based on device
manufacturer.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Teach the 'ether' rules to accept { mac1, mac2, ... } lists, similar to
the lists of interfaces or IP addresses we already supported for layer 3
filtering.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32481
Allow packets to be tagged with dummynet information. Note that we do
not apply dummynet shaping on the L2 traffic, but instead mark it for
dummynet processing in the L3 code. This is the same approach as we take
for ALTQ.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32222
If we're not filtering on a specific MAC address don't print it at all,
rather than showing an all-zero address.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31749
Allow the evaluations/packets/bytes counters on Ethernet rules to be
cleared.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31748
Extent pfctl to be able to read configured Ethernet filtering rules from
the kernel and print them.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31738
We provide the hostid (which is the state creatorid) to the kernel as a
big endian number (see pfctl/pfctl.c pfctl_set_hostid()), so convert it
back to system endianness when we get it from the kernel.
This avoids a confusing mismatch between the value the user configures
and the value displayed in the state.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D33989
If an invalid (i.e. overly long) interface name is specified error out
immediately, rather than in expand_rule() so we point at the incorrect
line.
PR: 260958
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D34008
Add two underscore characters "__" to names of BIT_* and BITSET_*
macros to move them to the implementation name space and to prevent
a name space pollution due to BIT_* macros in 3rd party programs with
conflicting parameter signatures.
These prefixed macro names are used in kernel header files to define
macros in e.g. sched.h, sys/cpuset.h and sys/domainset.h.
If C programs are built with either -D_KERNEL (automatically passed
when building a kernel or kernel modules) or -D_WANT_FREENBSD_BITSET
(or this macros is defined in the source code before including the
bitset macros), then all macros are made visible with their previous
names, too. E.g., both __BIT_SET() and BIT_SET() are visible with
either of _KERNEL or _WANT_FREEBSD_BITSET defined.
The main reason for this change is that some 3rd party sources
including sched.h have been found to contain conflicting BIT_*
macros.
As a work-around, parts of shed.h have been made conditional and
depend on _WITH_CPU_SET_T being set when sched.h is included.
Ports that expect the full functionality provided by sched.h need
to be built with -D_WITH_CPU_SET_T. But this leads to conflicts if
BIT_* macros are defined in that program, too.
This patch set makes all of sched.h visible again without this
parameter being passed and without any name space pollution due
to BIT_* macros becoming visible when sched.h is included.
This patch set will be backported to the STABLE branches, but ports
will need to use -D_WITH_CPU_SET_T as long as there are supported
releases that do not contain these patches.
Reviewed by: kib, markj
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33235
Allow users to set a number on rules which will be exposed as part of
the pflog header.
The intent behind this is to allow users to correlate rules across
updates (remember that pf rules continue to exist and match existing
states, even if they're removed from the active ruleset) and pflog.
Obtained from: pfSense
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32750
We used to expand the $nr macro in labels into the rule number prior to
the optimisation step. This would occasionally produce incorrect rule
numbers in the labels.
Delay all macro expansion until after the optimisation step to ensure
that we expand the correct values.
MFC after: 1 week
Reported by: Özkan KIRIK <ozkan.kirik@gmail.com>
Differential Revision: https://reviews.freebsd.org/D32488
