Remove "goto charg" from the action parser.
This is a prerequisite for the further split of the gigantic
compile_rule().
Differential Revision: https://reviews.freebsd.org/D40490
MFC after: 2 weeks
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Packet Mark is an analogue to ipfw tags with O(1) lookup from mbuf while
regular tags require a single-linked list traversal.
Mark is a 32-bit number that can be looked up in a table
[with 'number' table-type], matched or compared with a number with optional
mask applied before comparison.
Having generic nature, Mark can be used in a variety of needs.
For example, it could be used as a security group: mark will hold a security
group id and represent a group of packet flows that shares same access
control policy.
Reviewed By: pauamma_gundo.com
Differential Revision: https://reviews.freebsd.org/D39555
MFC after: 1 month
The manual describes "if*" form only while kernel uses fnmatch(3)
and allows use for more versatile shell-like patterns.
Note that explicitly and provide an example.
MFC after: 3 days
It was renamed during review of D1776 but this entry slipped through.
PR: 243284
Reported by: pprocacci@gmail.com
Obtained from: Chad Jacob Milios <milios@ccsys.com>
Running "dnctl" vs "/sbin/dnctl" gave different results, because we
looked at the entire argv[0] string, rather than the basename.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D37431
By analogy with IP address matching, add a way to use ipfw radix
tables for MAC matching. This is implemented using new ipfw table
with mac:radix type. Also there are src-mac and dst-mac lookup
commands added.
Usage example:
ipfw table 1 create type mac
ipfw table 1 add 11:22:33:44:55:66/48
ipfw add skipto tablearg src-mac 'table(1)'
ipfw add deny src-mac 'table(1, 100)'
ipfw add deny lookup dst-mac 1
Note: sysctl net.link.ether.ipfw=1 should be set to enable ipfw
filtering on L2.
Reviewed by: melifaro
Obtained from: Yandex LLC
MFC after: 1 month
Relnotes: yes
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D35103
Extend the dnctl (dummynet config) tool to be able to read commands from
a file, just like ipfw already does.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D33627
Introduce a link to the ipfw command, dnctl, for dummynet configuration.
dnctl only handles dummynet configuration, and is part of the effort to
support dummynet in pf.
/sbin/ipfw continues to accept pipe, queue and sched commands, but these can
now also be issued via the new dnctl command.
Reviewed by: donner
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D30465
This allows the maximum value of 4294967295 (~4Gb/s) instead of previous
value of 2147483647 (~2Gb/s).
Reviewed by: np, scottl
Obtained from: pfSense
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31582
Document the existing behavior, which is currently only available by
reading third party documentation or the source code itself.
PR: 254617
Submitted by: Oliver Kiddle
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D30189
Fix some erronous lines in the example section.
PR: 248943
Submitted by: Jose Luis Duran
MFC after: 2 weeks
Reviewers: ae, manpages (gbe)
Differential Revision: https://reviews.freebsd.org/D30191
Hostnames starting with "tablearg" are considered as a functional
argument instead of a literal.
Reported by: ae
Reviewers: ae
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30208
The argument parser does not recognise the optional port for an
"tablearg" argument. Fix simplifies the code by make the internal
representation expicit for the parser.
PR: 252744
MFC: 1 week
Reported by: <bugs.freebsd.org@mx.zzux.com>
Approved by: nc
Tested by: <bugs.freebsd.org@mx.zzux.com>
Differential Revision: https://reviews.freebsd.org/D30164
ipfw -[tT] prints statistics of the last access. If the rule was never
used, the counter might be not exist. This happens unconditionally on
inserting a new rule. Avoid printing statistics in this case.
PR: 255491
Reported by: Haisheng Zhouz
Reviewed by: ae
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D30046
Most of table types currently supported by ipfw have only one
algorithm implementation. When user creates such tables, allow
to omit algo name in arguments. E.g. now it is possible:
ipfw table T1 create type number
ipfw table T2 create type iface
ipfw table T3 create type flow
PR: 233072
MFC after: 1 week
Sponsored by: Yandex LLC
to be a true RFC 6598 NAT444 setup, where each network segment (e.g. user,
subnet) can have their own dedicated port aliasing ranges.
Reviewed by: donner, kp
Approved by: 0mp (mentor), donner, kp
Differential Revision: https://reviews.freebsd.org/D23450
Verify that the option is passed, error out if it's not.
The problem can be trivially triggered with `ipfw add allow ext6hdr`.
PR: 253169
Reviewed by: kp@
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D28447
- no blank before trailing delimiter
- missing section argument: Xr inet_pton
- skipping paragraph macro: Pp before Ss
- unusual Xr order: syslogd after sysrc
- tab in filled text
There were a few multiline NAT examples which used the .Dl macro with
tabs. I converted them to .Bd, which is a more suitable macro for that case.
MFC after: 1 week
Properly handle the case, when some opcode keywords follow after
the `frag` opcode without additional options.
Reported by: Evgeniy Khramtsov <evgeniy at khramtsov org>
This is a follow up change to r364321 after a discussion about the style.
All near by places use extra blanks in format strings, and while use of the
format string to provide the extra blank may need more cycles than adding 1
to twidth, it generates shorter code and is clearer in the opinion of some
reviewers of the previous change.
Not objected to by: emaste
MFC after: 3 days
From the PR:
When I run `ipfw -t list` on release/12 or current, I get misaligned
output between lines that do and do not have a last match timestamp,
like so:
00100 Tue Aug 11 03:03:26 2020 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
(specifically, the "allow" and "deny" strings do not line up)
PR: 248608
Submitted by: Taylor Stearns
MFC after: 3 days
"df", "rf" and "offset". This allows to match on specific
bits of ip_off field.
For compatibility reasons lack of keyword means "offset".
Reviewed by: ae
Differential Revision: https://reviews.freebsd.org/D26021
This is mostly an exercise to set variables to NULL/0 when declared, but
one was ensuring a string variable was set before printing it.
We should never see "<unknown>" in a printed rule; if we do then this code
definitely has some bugs that need addressing.
struct _ipfw_dyn_rule is defined as packed, and as a result, its
uint64_t fields are misaligned on some 32-bit platforms. Since
pr_u64() is explicitly supposed to handle this case, avoid using a
uint64_t * for the input pointer to make sure that the compiler won't
(correctly) warn about the misalignment.
Reported by: jenkins
MFC with: r363164
NAT instance.
The NAT44 group of opcodes for IP_FW3 socket option is modern way
to control NAT instances and this method can be used in future to
switch from numeric to named NAT instances, like was done for ipfw
tables.
The IP_FW_NAT_DEL opcode is the last remnant of old ipfw_ctl control
plane that doesn't support versioned operations. This interface will
be retired soon.
Reviewed by: melifaro
MFC after: 10 days
Sponsored by: Yandex LLC
In libalias, a new flag PKT_ALIAS_UNREGISTERED_RFC6598 is added.
This is like PKT_ALIAS_UNREGISTERED_ONLY, but also is RFC 6598 aware.
Also, we add a new NAT option to ipfw called unreg_cgn, which is like
unreg_only, but also is RFC 6598-aware. The reason for the new
flags/options is to avoid breaking existing networks, especially those
which rely on RFC 6598 as an external address.
Submitted by: Neel Chauhan <neel AT neelc DOT org>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22877
