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>
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>
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.
firewalls are remote, and this command will kill the network connection
to them), prompt the user for confirmation of this command.
Also, add the '-f' flag which ignores the need for confirmation the
command, and if there is no controlling tty (isatty(STDIN_FILENO) !=0)
assume '-f'.
If anyone is using ipfw flush in scripts it shouldn't affect them, but you
may want to change the script to use a 'ipfw -f flush'.
Reviewed by: alex
now completely consistent across all IP protocols and should be quite a
bit faster.
Use getprotoname() extensively, performed minor cleanups of admin utility.
The admin utility could use a good kick in the pants.
Basicly, these were the minimal changes I could make to the code
to get it up to tollerable shape. There will be some future commits
to clean up the basic architecture of the firewall code, and if
I'm feeling ambitious, I may pull in changes like NAT from Linux
and make the firewall hooks comletely generic so that a user can
either load the ipfw module or the ipfilter module (cf Darren Reed).
Discussed with: fenner & alex
This stuff should not be too destructive if the IPDIVERT is not compiled in..
be aware that this changes the size of the ip_fw struct
so ipfw needs to be recompiled to use it.. more changes coming to clean this up.
that the english in Ugen's two replacement pages is not too impenetrable! :-)
[Note: Poul - please pull these into the BETA branch along with the
other firewall changes]
Submitted by: ugen
