+ add a missing call to dn_rule_delete() when flushing firewall
rules, thus preventing possible panics due to dangling pointers
(this was already done for single rule deletes).
+ improve "usage" output in ipfw(8)
+ add a few checks to ipfw pipe parameters and make it a bit more
tolerant of common mistakes (such as specifying kbit instead of Kbit)
PR: kern/10889
Submitted by: Ruslan Ermilov
This allows for more flexible ipfw configuration files using
`variables' to describe frequently used items in the file, like the
local IP address(es), interface names etc. Both m4 and cpp are useful
and supported; with m4 being a little more unusual to the common C
programmer, things like automatic rule numbering can be achieved
fairly easy.
While i was at it, i've also untangled some of the ugly style inside
main(), and fixed a bug or two (like not being able to use blank lines
when running with -q).
A typical call with preprocessor invocation looks like
ipfw -p m4 -Dhostname=$(hostname) /etc/fwrules
Someone should probably add support for this feature to /etc/rc.firewall.
Any packet that can be matched by a ipfw rule can be redirected
transparently to another port or machine. Redirection to another port
mostly makes sense with tcp, where a session can be set up
between a proxy and an unsuspecting client. Redirection to another machine
requires that the other machine also be expecting to receive the forwarded
packets, as their headers will not have been modified.
/sbin/ipfw must be recompiled!!!
Reviewed by: Peter Wemm <peter@freebsd.org>
Submitted by: Chrisy Luke <chrisy@flix.net>
not reinitialized to 1 after calling getopt. This results in parsing
errors on all but the first rule. An added patch also allows '#'
comments at the end of a line.
PR: 6379
Reviewed by: phk
Submitted by: Neal Fachan <kneel@ishiboo.com>
offset is non-zero:
- Do not match fragmented packets if the rule specifies a port or
TCP flags
- Match fragmented packets if the rule does not specify a port and
TCP flags
Since ipfw cannot examine port numbers or TCP flags for such packets,
it is now illegal to specify the 'frag' option with either ports or
tcpflags. Both kernel and ipfw userland utility will reject rules
containing a combination of these options.
BEWARE: packets that were previously passed may now be rejected, and
vice versa.
Reviewed by: Archie Cobbs <archie@whistle.com>
consequence, ipfw's list command now adjusts its output at runtime
based on the largest packet/byte counter values.
NOTE:
o The ipfw struct has changed requiring a recompile of both kernel
and userland ipfw utility.
o This probably should not be brought into 2.2.
PR: 3738
accommodate the expanded name, the ICMP types bitmap has been
reduced from 256 bits to 32.
A recompile of kernel and user level ipfw is required.
To be merged into 2.2 after a brief period in -current.
PR: bin/4209
Reviewed by: Archie Cobbs <archie@whistle.com>
these are quite extensive additions to the ipfw code.
they include a change to the API because the old method was
broken, but the user view is kept the same.
The new code allows a particular match to skip forward to a particular
line number, so that blocks of rules can be
used without checking all the intervening rules.
There are also many more ways of rejecting
connections especially TCP related, and
many many more ...
see the man page for a complete description.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
