#!/usr/bin/env perl
#-*- Mode: perl; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*-

# Time configurator. Designed to be architecture- and distribution independent.
#
# Copyright (C) 2000-2001 Ximian, Inc.
#
# Authors: Chema Celorio <chema@ximian.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU Library General Public License as published
# by the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU Library General Public License for more details.
#
# You should have received a copy of the GNU Library General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

# Best viewed with 100 columns of width.


BEGIN {
require "___scriptsdir___/general.pl";
require "___scriptsdir___/platform.pl";
require "___scriptsdir___/util.pl";
require "___scriptsdir___/file.pl";
require "___scriptsdir___/xml.pl";
require "___scriptsdir___/service.pl";
require "___scriptsdir___/parse.pl";
require "___scriptsdir___/replace.pl";
}


# --- Tool information --- #

$name = "internetsharing";
$version = "0.1.0";
@platforms = ("redhat-7.0", "redhat-7.1",
              "mandrake-7.2", "turbolinux-7.0");

$description =<<"end_of_description;";
       Configures your system clock, timezone and time server list.
end_of_description;

$progress_max = 365;


# --- XML parsing --- #


# Scan XML from standard input to an internal tree.

sub xml_parse
{
  my ($tree, %hash);
  
  # Scan XML to tree.

  $tree = &xst_xml_scan;

  # Walk the tree recursively and extract configuration parameters.
  # This is the top level - find and enter the "networking" tag.

#  while (@$tree)
#  {
#    if ($$tree[0] eq "time") { &xml_parse_time($$tree[1], \%hash); }
#
#    shift @$tree;
#    shift @$tree;
#  }

  return(\%hash);
}


# <networking>...</networking>

sub xml_parse_time
{
  my $tree = $_[0];
  my $hash = $_[1];

  shift @$tree;  # Skip attributes.

  while (@$tree)
  {
#    if    ($$tree[0] eq "local_time"){ $$hash{"local_time"} = &xml_parse_local_time ($$tree[1]); }
#    elsif ($$tree[0] eq "timezone") { $$hash{"timezone"} = &xst_xml_get_word ($$tree[1]); }
#    elsif ($$tree[0] eq "sync")     { $$hash{"sync"} = &xml_parse_sync ($$tree[1]); }

    shift @$tree;
    shift @$tree;
  }
}

# --- XML printing --- #


sub xml_print
{
  my $h = $_[0];
  my @sync;

  @scalar_keys = qw (ip_forwarding_installed);

  $sync = $$h{"sync"};

  &xst_xml_print_begin ();

  
#  &xst_xml_print_vspace ();
#  &xst_xml_print_hash ($$h{"local_time"}, "local_time");
#  &xst_xml_print_vspace ();
  
#  &xst_xml_print_vspace ();
#  &xst_xml_print_line ("<sync active='" . &xst_print_boolean_yesno ($sync_active) . "'>\n");
 
#  &xst_xml_enter ();
#  foreach $server (@$sync)
#  {
#    &xst_xml_print_line ("<server>$server</server>\n");
#  }
#  &xst_xml_leave ();
  
#  &xst_xml_print_line ("</sync>\n");
#  &xst_xml_print_vspace ();

  &xst_xml_print_scalars ($h, @scalar_keys);
  &xst_xml_print_vspace ();

  &xst_xml_print_end ();
}

# Main operations

sub get
{
  my $hash;

  $hash = &conf_get ();

  &xst_end();
  &xml_print ($hash);
}


sub set
{
  my $hash;

  $hash = &xml_parse ();

  &conf_set ($hash);
  
  &xst_end();
}


# --- Filter config: XML in, XML out --- #


sub filter
{
  my $hash;

  $hash = &xml_parse ();
  &xst_end();
  &xml_print ($hash);
}

# ---     ---- #
sub xst_ishare_rules_get_ipchains
{
    my ($file) = @_;
    my $fd;
    my $line;

    $fd = &xst_file_open_read_from_names ($file);
    
    while (($line = <$fd>))
    {
        chomp $line;

        print $_;
    }

}

# --- Main --- #

# get, set and filter are special cases that don't need more parameters than a ref to their function.
# Read general.pl.in:xst_run_directive to know about the format of this hash.

$directives = {
  "get"    => [ \&get,    [], "" ],
  "set"    => [ \&set,    [], "" ],
  "filter" => [ \&filter, [], "" ]
    };

$tool = &xst_init ($name, $version, $description, $directives, @ARGV);
&xst_platform_ensure_supported ($tool, @platforms);
&xst_run ($tool);

# Portable code.
sub conf_get
{
  my %dist_attrib;
  my $hash;

  %dist_attrib = &conf_get_parse_table ();

  $hash = &xst_parse_from_table ($dist_attrib{"fn"},
                                 $dist_attrib{"table"});
  return $hash;
}

sub conf_set
{
  my $values_hash = $_[0];
  my %dist_attrib;

  %dist_attrib = &conf_get_replace_table ();

  $res = &xst_replace_from_table ($dist_attrib{"fn"}, $dist_attrib{"table"},
                                  $values_hash);

  return $res;
}

sub conf_get_parse_table
{
  my %dist_map =
  (
   "redhat-7.0"   => "redhat-7.0",
   "redhat-7.1"   => "redhat-7.0",
   "mandrake-7.2" => "redhat-7.0",
   "turbolinux-7.0" => "redhat-7.0",
   );

  my %dist_tables =
      (
       "redhat-7.0" =>
       {
         fn =>
         {
           IPCHAINS_CONF     => "/etc/sysconfig/ipchains",
         },
         table =>
             [
              [ "ip_forwarding_installed", \&xst_service_sysv_installed,   "ipchains" ],
              [ "rules",                   \&xst_ishare_rules_get_ipchains, IPCHAINS_CONF],
              ]
                },
       );

  my $dist = $dist_map {$xst_dist};
  return %{$dist_tables{$dist}} if $dist;

  &xst_report ("platform_no_table", $xst_dist);
  return undef;
}

sub conf_get_replace_table
{
  my %dist_map =
  (
   "redhat-7.0"   => "redhat-7.0",
   "redhat-7.1"   => "redhat-7.0",
   "mandrake-7.2" => "redhat-7.0",
   "turbolinux-7.0"   => "redhat-7.0",
   );

  my %dist_tables =
      (
       "redhat-7.0" =>
       {
         fn =>
         {
           IPCHAINS_CONF => "/etc/sysconfig/ipchains",
         },
         table =>
             [
              [ "ip_forwarding_installed", \&xst_service_sysv_set_status, 8, "ipchains" ],
              ]
                },
       );

  my $dist = $dist_map {$xst_dist};
  return %{$dist_tables{$dist}} if $dist;

  &xst_report ("platform_no_table", $xst_dist);
  return undef;
}




$man_pages =<<"end_of_manpages;";

IPTABLES(8)					      IPTABLES(8)


NAME
       iptables - IP packet filter administration

SYNOPSIS
       iptables -[ADC] chain rule-specification [options]
       iptables -[RI] chain rulenum rule-specification [options]
       iptables -D chain rulenum [options]
       iptables -[LFZ] [chain] [options]
       iptables -[NX] chain
       iptables -P chain target [options]
       iptables -E old-chain-name new-chain-name

DESCRIPTION
       Iptables	 is  used  to  set  up, maintain, and inspect the
       tables of IP packet filter  rules  in  the  Linux  kernel.
       Several	different tables may be defined.  Each table con­
       tains a number of built-in chains  and  may  also  contain
       user-defined chains.

       Each  chain  is	a  list of rules which can match a set of
       packets.	 Each rule specifies what to  do  with	a  packet
       that  matches.	This is called a `target', which may be a
       jump to a user-defined chain in the same table.


TARGETS
       A firewall rule specifies criteria for  a  packet,  and	a
       target.	 If  the  packet does not match, the next rule in
       the chain is the examined; if it does match, then the next
       rule is specified by the value of the target, which can be
       the name of a user-defined chain or  one	 of  the  special
       values ACCEPT, DROP, QUEUE, or RETURN.

       ACCEPT  means  to  let  the packet through.  DROP means to
       drop the packet on the floor.  QUEUE  means  to	pass  the
       packet  to userspace (if supported by the kernel).  RETURN
       means stop traversing this chain and resume  at	the  next
       rule  in	 the  previous	(calling) chain.  If the end of a
       built-in chain is reached or a rule in  a  built-in  chain
       with target RETURN is matched, the target specified by the
       chain policy determines the fate of the packet.

TABLES
       There are current three independent tables  (which  tables
       are  present  at any time depends on the kernel configura­
       tion options and which modules are present).

       -t, --table
	      This option specifies  the  packet  matching  table
	      which the command should operate on.  If the kernel
	      is configured with  automatic  module  loading,  an
	      attempt will be made to load the appropriate module
	      for that table if it is not already there.

	      The tables are  as  follows:  filter  This  is  the
	      default  table.	It  contains  the built-in chains
	      INPUT (for packets coming	 into  the  box	 itself),
	      FORWARD (for packets being routed through the box),
	      and OUTPUT (for  locally-generated  packets).   nat
	      This  table is consulted when a packet that creates
	      a new connection is encountered.	 It  consists  of
	      three  built-ins:	 PREROUTING (for altering packets
	      as soon as they  come  in),  OUTPUT  (for	 altering
	      locally-generated	  packets  before  routing),  and
	      POSTROUTING (for altering packets as they are about
	      to go out).  mangle This table is used for special­
	      ized  packet  alteration.	  It  has  two	 built-in
	      chains:  PREROUTING  (for altering incoming packets
	      before routing) and OUTPUT (for  altering	 locally-
	      generated packets before routing).

OPTIONS
       The options that are recognized by iptables can be divided
       into several different groups.

   COMMANDS
       These options specify  the  specific  action  to	 perform.
       Only  one  of  them  can	 be specified on the command line
       unless otherwise specified below.  For all the  long  ver­
       sions  of  the  command	and option names, you need to use
       only enough letters to ensure that iptables can	differen­
       tiate it from all other options.

       -A, --append
	      Append one or more rules to the end of the selected
	      chain.  When the source  and/or  destination  names
	      resolve  to  more	 than one address, a rule will be
	      added for each possible address combination.

       -D, --delete
	      Delete one or more rules from the	 selected  chain.
	      There  are  two  versions of this command: the rule
	      can be specified as a number in the chain (starting
	      at 1 for the first rule) or a rule to match.

       -R, --replace
	      Replace  a  rule	in  the	 selected  chain.  If the
	      source and/or destination names resolve to multiple
	      addresses,  the  command will fail.  Rules are num­
	      bered starting at 1.

       -I, --insert
	      Insert one or more rules in the selected	chain  as
	      the  given  rule number.	So, if the rule number is
	      1, the rule or rules are inserted at  the	 head  of
	      the  chain.   This  is  also the default if no rule
	      number is specified.

       -L, --list
	      List all rules in the selected chain.  If no  chain
	      is selected, all chains are listed.  It is legal to
	      specify the -Z (zero) option as well, in which case
	      the  chain(s) will be atomically listed and zeroed.
	      The exact output is affected by the other arguments
	      given.

       -F, --flush
	      Flush  the  selected  chain.  This is equivalent to
	      deleting all the rules one by one.

       -Z, --zero
	      Zero the packet and byte counters	 in  all  chains.
	      It is legal to specify the -L, --list (list) option
	      as well, to see  the  counters  immediately  before
	      they are cleared. (See above.)

       -N, --new-chain
	      Create  a new user-defined chain by the given name.
	      There must be no target of that name already.

       -X, --delete-chain
	      Delete the  specified  user-defined  chain.   There
	      must  be no references to the chain.  If there are,
	      you must delete  or  replace  the	 referring  rules
	      before the chain can be deleted.	If no argument is
	      given, it will attempt to delete every  non-builtin
	      chain in the table.

       -P, --policy
	      Set  the	policy for the chain to the given target.
	      See the section  TARGETS	for  the  legal	 targets.
	      Only non-user-defined chains can have policies, and
	      neither built-in nor  user-defined  chains  can  be
	      policy targets.

       -E, --rename-chain
	      Rename  the  user	 specified chain to the user sup­
	      plied name.  This is cosmetic, and has no effect on
	      the structure of the table.

       -h     Help.  Give a (currently very brief) description of
	      the command syntax.

   PARAMETERS
       The following parameters make up a rule specification  (as
       used  in	 the add, delete, insert, replace and append com­
       mands).

       -p, --protocol [!] protocol
	      The protocol of the rule or of the packet to check.
	      The  specified  protocol	can  be	 one of tcp, udp,
	      icmp, or all, or it can be a numeric value,  repre­
	      senting  one of these protocols or a different one.
	      A	 protocol  name	 from  /etc/protocols	is   also
	      allowed.	  A  "!"  argument  before  the	 protocol
	      inverts the test.	 The number zero is equivalent to
	      all.   Protocol  all  will match with all protocols
	      and is taken as default when this option	is  omit­
	      ted.

       -s, --source [!] address[/mask]
	      Source  specification.   Address	can  be	 either a
	      hostname, a network name, or a  plain  IP	 address.
	      The  mask	 can  be either a network mask or a plain
	      number, specifying the number of 1's  at	the  left
	      side  of	the  network mask.  Thus, a mask of 24 is
	      equivalent to 255.255.255.0.  A "!" argument before
	      the  address specification inverts the sense of the
	      address. The flag --src is a convenient  alias  for
	      this option.

       -d, --destination [!] address[/mask]
	      Destination  specification.  See the description of
	      the -s (source) flag for a detailed description  of
	      the  syntax.   The  flag --dst is an alias for this
	      option.

       -j, --jump target
	      This specifies the target of the rule;  i.e.,  what
	      to  do if the packet matches it.	The target can be
	      a user-defined chain (other than the one this  rule
	      is  in),	one  of the special builtin targets which
	      decide the fate of the packet  immediately,  or  an
	      extension	 (see  EXTENSIONS below).  If this option
	      is omitted in a rule, then matching the  rule  will
	      have  no effect on the packet's fate, but the coun­
	      ters on the rule will be incremented.

       -i, --in-interface [!] [name]
	      Optional name of an interface via which a packet is
	      received	(for  packets entering the INPUT, FORWARD
	      and PREROUTING chains).  When the "!"  argument  is
	      used  before  the	 interface  name,  the	sense  is
	      inverted.	 If the interface name	ends  in  a  "+",
	      then any interface which begins with this name will
	      match.  If this option is omitted, the  string  "+"
	      is  assumed,  which  will	 match with any interface
	      name.

       -o, --out-interface [!] [name]
	      Optional name of an interface via which a packet is
	      going to be sent (for packets entering the FORWARD,
	      OUTPUT and POSTROUTING chains).  When the "!" argu­
	      ment  is	used before the interface name, the sense
	      is inverted.  If the interface name ends in a  "+",
	      then any interface which begins with this name will
	      match.  If this option is omitted, the  string  "+"
	      is  assumed,  which  will	 match with any interface
	      name.

       [!]  -f, --fragment
	      This means that the rule only refers to second  and
	      further  fragments  of  fragmented  packets.  Since
	      there is no way to tell the source  or  destination
	      ports  of	 such  a  packet  (or  ICMP type), such a
	      packet will not match any rules which specify them.
	      When  the	 "!" argument precedes the "-f" flag, the
	      rule will only match  head  fragments,  or  unfrag­
	      mented packets.

       -c, --set-counters  PKTS BYTES
	      This  enables  the  administrater to initialize the
	      packet and byte counters of a rule (during  INSERT,
	      APPEND, REPLACE operations)

   OTHER OPTIONS
       The following additional options can be specified:

       -v, --verbose
	      Verbose output.  This option makes the list command
	      show the interface address, the  rule  options  (if
	      any), and the TOS masks.	The packet and byte coun­
	      ters are also listed, with the suffix 'K',  'M'  or
	      'G' for 1000, 1,000,000 and 1,000,000,000 multipli­
	      ers respectively (but see the  -x	 flag  to  change
	      this).   For  appending,	insertion,  deletion  and
	      replacement, this causes	detailed  information  on
	      the rule or rules to be printed.

       -n, --numeric
	      Numeric output.  IP addresses and port numbers will
	      be printed in numeric format.  By default, the pro­
	      gram  will  try to display them as host names, net­
	      work names, or services (whenever applicable).

       -x, --exact
	      Expand numbers.  Display the  exact  value  of  the
	      packet  and  byte	 counters,  instead  of	 only the
	      rounded number in K's (multiples of 1000) M's (mul­
	      tiples of 1000K) or G's (multiples of 1000M).  This
	      option is only relevant for the -L command.

       --line-numbers
	      When listing rules, add line numbers to the  begin­
	      ning  of	each  rule,  corresponding to that rule's
	      position in the chain.

       --modprobe=<command>
	      When adding or inserting rules into  a  chain,  use
	      command  to  load	 any  necessary modules (targets,
	      match extensions, etc).

MATCH EXTENSIONS
       iptables can use extended packet matching modules.   These
       are  loaded in two ways: implicitly, when -p or --protocol
       is specified, or with the -m or --match options,	 followed
       by  the	matching  module name; after these, various extra
       command line options become available,  depending  on  the
       specific	 module.  You can specify multiple extended match
       modules in one line, and you can	 use  the  -h  or  --help
       options	after  the  module  has been specified to receive
       help specific to that module.

       The following are included in the base package,	and  most
       of  these  can  be preceded by a !  to invert the sense of
       the match.

   tcp
       These extensions are loaded if `--protocol tcp' is  speci­
       fied. It provides the following options:

       --source-port [!] [port[:port]]
	      Source  port  or port range specification. This can
	      either be a service  name	 or  a	port  number.  An
	      inclusive	 range	can  also be specified, using the
	      format port:port.	 If the first  port  is	 omitted,
	      "0"  is assumed; if the last is omitted, "65535" is
	      assumed.	If the second port greater then the first
	      they will be swapped.  The flag --sport is an alias
	      for this option.

       --destination-port [!] [port[:port]]
	      Destination port or port range  specification.  The
	      flag --dport is an alias for this option.

       --tcp-flags [!] mask comp
	      Match  when  the	TCP  flags are as specified.  The
	      first argument is the flags which we  should  exam­
	      ine,  written  as	 a  comma-separated list, and the
	      second argument is a comma-separated list of  flags
	      which  must be set.  Flags are: SYN ACK FIN RST URG
	      PSH ALL NONE.  Hence the command
	       iptables	  -A   FORWARD	 -p    tcp    --tcp-flags
	      SYN,ACK,FIN,RST SYN
	      will  only match packets with the SYN flag set, and
	      the ACK, FIN and RST flags unset.

       [!] --syn
	      Only match TCP packets with the SYN bit set and the
	      ACK and FIN bits cleared.	 Such packets are used to
	      request TCP  connection  initiation;  for	 example,
	      blocking	such  packets coming in an interface will
	      prevent incoming TCP connections, but outgoing  TCP
	      connections  will	 be unaffected.	 It is equivalent
	      to --tcp-flags SYN,RST,ACK SYN.  If  the	"!"  flag
	      precedes	the  "--syn",  the sense of the option is
	      inverted.

       --tcp-option [!] number
	      Match if TCP option set.

   udp
       These extensions are loaded if `--protocol udp' is  speci­
       fied.  It provides the following options:

       --source-port [!] [port[:port]]
	      Source  port  or port range specification.  See the
	      description of the --source-port option of the  TCP
	      extension for details.

       --destination-port [!] [port[:port]]
	      Destination  port or port range specification.  See
	      the description of the --destination-port option of
	      the TCP extension for details.

   icmp
       This  extension	is  loaded if `--protocol icmp' is speci­
       fied.  It provides the following option:

       --icmp-type [!] typename
	      This allows specification of the ICMP  type,  which
	      can be a numeric ICMP type, or one of the ICMP type
	      names shown by the command
	       iptables -p icmp -h

   mac
       --mac-source [!] address
	      Match source MAC address.	 It must be of	the  form
	      XX:XX:XX:XX:XX:XX.  Note that this only makes sense
	      for packets entering  the	 PREROUTING,  FORWARD  or
	      INPUT  chains  for  packets coming from an ethernet
	      device.

   limit
       This module matches at a limited rate using a token bucket
       filter:	it can be used in combination with the LOG target
       to give limited logging.	 A rule using this extension will
       match  until this limit is reached (unless the `!' flag is
       used).

       --limit rate
	      Maximum average matching rate: specified as a  num­
	      ber,   with   an	 optional  `/second',  `/minute',
	      `/hour', or `/day' suffix; the default is 3/hour.

       --limit-burst number
	      The maximum initial number  of  packets  to  match:
	      this  number  gets  recharged by one every time the
	      limit specified above is not reached,  up	 to  this
	      number; the default is 5.

   multiport
       This  module matches a set of source or destination ports.
       Up to 15 ports can be specified. It can only  be	 used  in
       conjunction with -p tcp or -p udp.

       --source-port [port[,port]]
	      Match if the source port is one of the given ports.


       --destination-port [port[,port]]
	      Match if the destination port is one of  the  given
	      ports.

       --port [port[,port]]
	      Match  if the both the source and destination ports
	      are equal to each other and to  one  of  the  given
	      ports.

   mark
       This  module  matches  the netfilter mark field associated
       with a packet (which can be  set	 using	the  MARK  target
       below).

       --mark value[/mask]
	      Matches  packets with the given unsigned mark value
	      (if a mask is specified, this  is	 logically  ANDed
	      with the mark before the comparison).

   owner
       This  module  attempts to match various characteristics of
       the packet creator, for locally-generated packets.  It  is
       only valid in the OUTPUT chain, and even this some packets
       (such as ICMP ping responses) may have no owner, and hence
       never match.

       --uid-owner userid
	      Matches if the packet was created by a process with
	      the given effective user id.

       --gid-owner groupid
	      Matches if the packet was created by a process with
	      the given effective group id.

       --pid-owner processid
	      Matches if the packet was created by a process with
	      the given process id.

       --sid-owner sessionid
	      Matches if the packet was created by a  process  in
	      the given session group.

   state
       This  module,  when  combined  with  connection	tracking,
       allows access to the connection tracking	 state	for  this
       packet.

       --state state
	      Where  state  is a comma separated list of the con­
	      nection  states  to  match.   Possible  states  are
	      INVALID  meaning that the packet is associated with
	      no known connection, ESTABLISHED meaning	that  the
	      packet  is  associated  with a connection which has
	      seen packets in both directions, NEW  meaning  that
	      the  packet has started a new connection, or other­
	      wise associated with a  connection  which	 has  not
	      seen  packets in both directions, and RELATED mean­
	      ing that the packet is starting a	 new  connection,
	      but is associated with an existing connection, such
	      as an FTP data transfer, or an ICMP error.

   unclean
       This module takes no options, but attempts to match  pack­
       ets  which seem malformed or unusual.  This is regarded as
       experimental.

   tos
       This module matches the 8 bits of Type of Service field in
       the IP header (ie. including the precedence bits).

       --tos tos
	      The argument is either a standard name, (use
	       iptables -m tos -h
	      to see the list), or a numeric value to match.

TARGET EXTENSIONS
       iptables	 can  use  extended target modules: the following
       are included in the standard distribution.

   LOG
       Turn on kernel logging of  matching  packets.   When  this
       option is set for a rule, the Linux kernel will print some
       information on all matching packets (like most  IP  header
       fields)	via  the  kernel  log  (where it can be read with
       dmesg or syslogd(8)).

       --log-level level
	      Level of logging (numeric or see syslog.conf(5)).

       --log-prefix prefix
	      Prefix log messages with the specified  prefix;  up
	      to  29  letters long, and useful for distinguishing
	      messages in the logs.

       --log-tcp-sequence
	      Log TCP sequence numbers. This is a  security  risk
	      if the log is readable by users.

       --log-tcp-options
	      Log options from the TCP packet header.

       --log-ip-options
	      Log options from the IP packet header.

   MARK
       This  is	 used  to set the netfilter mark value associated
       with the packet.	 It is only valid in the mangle table.

       --set-mark mark

   REJECT
       This is used to send back an error packet in  response  to
       the  matched  packet:  otherwise it is equivalent to DROP.
       This target is only valid in the INPUT, FORWARD and OUTPUT
       chains, and user-defined chains which are only called from
       those chains.  Several options control the nature  of  the
       error packet returned:

       --reject-with type
	      The  type	 given can be icmp-net-unreachable, icmp-
	      host-unreachable,	  icmp-port-unreachable,    icmp-
	      proto-unreachable, icmp-net-prohibitedor icmp-host-
	      prohibited, which return the appropriate ICMP error
	      message  (port-unreachable  is  the  default).  The
	      option echo-reply is also allowed; it can	 only  be
	      used  for	 rules which specify an ICMP ping packet,
	      and generates a ping reply.   Finally,  the  option
	      tcp-reset can be used on rules which only match the
	      TCP protocol: this causes a TCP RST  packet  to  be
	      sent  back.   This  is  mainly  useful for blocking
	      ident probes which frequently  occur  when  sending
	      mail  to broken mail hosts (which won't accept your
	      mail otherwise).

   TOS
       This is used to set the 8-bit Type of Service field in the
       IP header.  It is only valid in the mangle table.

       --set-tos tos
	      You can use a numeric TOS values, or use
	       iptables -j TOS -h
	      to see the list of valid TOS names.

   MIRROR
       This is an experimental demonstration target which inverts
       the source and destination fields in  the  IP  header  and
       retransmits  the	 packet.   It is only valid in the INPUT,
       FORWARD and PREROUTING  chains,	and  user-defined  chains
       which  are  only	 called from those chains.  Note that the
       outgoing packets are NOT	 seen  by  any	packet	filtering
       chains,	connection  tracking  or  NAT, to avoid loops and
       other problems.

   SNAT
       This target is  only  valid  in	the  nat  table,  in  the
       POSTROUTING  chain.   It specifies that the source address
       of the packet should be modified (and all  future  packets
       in this connection will also be mangled), and rules should
       cease being examined.  It takes one option:

       --to-source  <ipaddr>[-<ipaddr>][:port-port]
	      which can specify a single new source  IP	 address,
	      an inclusive range of IP addresses, and optionally,
	      a port range (which is only valid if the rule  also
	      specifies	 -p  tcp or -p udp).  If no port range is
	      specified, then source  ports  below  512	 will  be
	      mapped  to other ports below 512: those between 512
	      and 1023 inclusive will be mapped	 to  ports  below
	      1024,  and  other	 ports	will be mapped to 1024 or
	      above. Where  possible,  no  port	 alteration  will
	      occur.

   DNAT
       This  target  is	 only valid in the nat table, in the PRE­
       ROUTING and OUTPUT chains, and user-defined  chains  which
       are  only called from those chains.  It specifies that the
       destination address of the packet should be modified  (and
       all  future  packets  in this connection will also be man­
       gled), and rules should cease being  examined.	It  takes
       one option:

       --to-destination <ipaddr>[-<ipaddr>][:port-port]
	      which  can  specify  a  single  new  destination IP
	      address, an inclusive range of  IP  addresses,  and
	      optionally,  a  port  range (which is only valid if
	      the rule also specifies -p tcp or -p udp).   If  no
	      port  range is specified, then the destination port
	      will never be modified.

   MASQUERADE
       This target is  only  valid  in	the  nat  table,  in  the
       POSTROUTING  chain.   It	 should only be used with dynami­
       cally assigned IP (dialup)  connections:	 if  you  have	a
       static  IP  address, you should use the SNAT target.  Mas­
       querading is equivalent to specifying a mapping to the  IP
       address of the interface the packet is going out, but also
       has the effect that connections	are  forgotten	when  the
       interface  goes	down.	This is the correct behavior when
       the next dialup is unlikely to  have  the  same	interface
       address	(and  hence  any established connections are lost
       anyway).	 It takes one option:

       --to-ports <port>[-<port>]
	      This specifies a range  of  source  ports	 to  use,
	      overriding  the  default SNAT source port-selection
	      heuristics (see above).  This is only valid with if
	      the rule also specifies -p tcp or -p udp).

   REDIRECT
       This  target  is	 only valid in the nat table, in the PRE­
       ROUTING and OUTPUT chains, and user-defined  chains  which
       are only called from those chains.  It alters the destina­
       tion IP address to send the packet to the  machine  itself
       (locally-generated  packets  are	 mapped	 to the 127.0.0.1
       address).  It takes one option:

       --to-ports <port>[-<port>]
	      This specifies a destination port or range or ports
	      to use: without this, the destination port is never
	      altered.	This is only valid with if the rule  also
	      specifies -p tcp or -p udp).

EXTRA EXTENSIONS
       The  following  extensions  are not included by default in
       the standard distribution.

   ttl
       This module matches the time  to	 live  field  in  the  IP
       header.

       --ttl ttl
	      Matches the given TTL value.

   TTL
       This  target  is	 used to modify the time to live field in
       the IP header.  It is only valid in the mangle table.

       --ttl-set ttl
	      Set the TTL to the given value.

       --ttl-dec ttl
	      Decrement the TTL by the given value.

       --ttl-inc ttl
	      Increment the TTL by the given value.

   ULOG
       This target provides userspace logging of  matching  pack­
       ets.  When this target is set for a rule, the Linux kernel
       will multicast this packet through a netlink  socket.  One
       or  more userspace processes may then subscribe to various
       multicast groups and receive the packets.

       --ulog-nlgroup <nlgroup>
	      This specifies the netlink group	(1-32)	to  which
	      the packet is sent.  Default value is 1.

       --ulog-prefix <prefix>
	      Prefix  log  messages with the specified prefix; up
	      to 32 characters long, and useful fro  distinguish­
	      ing messages in the logs.

       --ulog-cprange <size>
	      Number  of bytes to be copied to userspace. A value
	      of 0 always copies the entire packet, regardless of
	      its size. Default is 0

       --ulog-qthreshold <size>
	      Number  of  packet  to queue inside kernel. Setting
	      this value to,  e.g.  10	accumulates  ten  packets
	      inside the kernel and transmits them as one netlink
	      multpart message to userspace.  Default is  1  (for
	      backwards compatibility)

DIAGNOSTICS
       Various error messages are printed to standard error.  The
       exit code is 0  for  correct  functioning.   Errors  which
       appear  to  be  caused  by  invalid or abused command line
       parameters cause an exit code of 2, and other errors cause
       an exit code of 1.

BUGS
       Check is not implemented (yet).

COMPATIBILITY WITH IPCHAINS
       This  iptables  is  very similar to ipchains by Rusty Rus­
       sell.  The main difference is that the  chains  INPUT  and
       OUTPUT  are  only  traversed  for  packets coming into the
       local host and originating from	the  local  host  respec­
       tively.	Hence every packet only passes through one of the
       three chains; previously a  forwarded  packet  would  pass
       through all three.

       The  other  main difference is that -i refers to the input
       interface; -o refers to the output interface, and both are
       available for packets entering the FORWARD chain.

       iptables	 is  a	pure packet filter when using the default
       `filter' table, with  optional  extension  modules.   This
       should  simplify	 much  of the previous confusion over the
       combination of IP masquerading and packet  filtering  seen
       previously.   So the following options are handled differ­
       ently:
	-j MASQ
	-M -S
	-M -L
       There are several other changes in iptables.

SEE ALSO
       The iptables-HOWTO, which details more iptables usage, the
       NAT-HOWTO,  which  details NAT, and the netfilter-hacking-
       HOWTO which details the internals.

AUTHORS
       Rusty Russell wrote iptables, in early  consultation  with
       Michael Neuling.

       Marc Boucher made Rusty abandon ipnatctl by lobbying for a
       generic packet selection framework in iptables, then wrote
       the mangle table, the owner match, the mark stuff, and ran
       around doing cool stuff everywhere.

       James Morris wrote the TOS target, and tos match.

       Jozsef Kadlecsik wrote the REJECT target.

       Harald Welte wrote the ULOG target, TTL	match+target  and
       libipulog.

       The  Netfilter  Core  Team is: Marc Boucher, James Morris,
       Harald Welte and Rusty Russell.



			   Aug 11, 2000				1
------------------------------------------------------------------------------



IPCHAINS(8)					      IPCHAINS(8)


NAME
       ipchains - IP firewall administration

SYNOPSIS
       ipchains -[ADC] chain rule-specification [options]
       ipchains -[RI] chain rulenum rule-specification [options]
       ipchains -D chain rulenum [options]
       ipchains -[LFZNX] [chain] [options]
       ipchains -P chain target [options]
       ipchains -M [ -L | -S ] [options]

DESCRIPTION
       Ipchains	 is  used to set up, maintain, and inspect the IP
       firewall rules in the Linux kernel.  These  rules  can  be
       divided	into  4 different categories: the IP input chain,
       the IP output chain, the IP  forwarding	chain,	and  user
       defined chains.

       For each of these categories, a separate table of rules is
       maintained, any of which might refer to one of  the  user-
       defined chains.	See ipfw(4) for more details.

TARGETS
       A  firewall  rule  specifies  criteria for a packet, and a
       target.	If the packet does not match, the  next	 rule  in
       the  chain  is  then  examined; if it does match, then the
       next rule is specified by the value of the  target,  which
       can  be	the  name  of a user-defined chain, or one of the
       special values ACCEPT, DENY, REJECT,  MASQ,  REDIRECT,  or
       RETURN.
       ACCEPT  means  to  let  the packet through.  DENY means to
       drop the packet on the floor.  REJECT means  the	 same  as
       drop,  but  is  more  polite and easier to debug, since an
       ICMP message is sent back to the	 sender	 indicating  that
       the  packet  was	 dropped.  (Note that DENY and REJECT are
       the same for ICMP packets). [Note: this is incorrect; set­
       ting  ICMP  to REJECT will cause ICMP port unreachables to
       be sent!]
       MASQ is only  legal  for	 the  forward  and  user  defined
       chains,	and  can only be used when the kernel is compiled
       with CONFIG_IP_MASQUERADE  defined.   With  this,  packets
       will  be	 masqueraded as if they originated from the local
       host.  Furthermore, reverse packets will be recognized  as
       such and they will be demasqueraded automatically, bypass­
       ing the forwarding chain.
       REDIRECT is only legal  for  the	 input	and  user-defined
       chains  and can only be used when the Linux kernel is com­
       piled  with  CONFIG_IP_TRANSPARENT_PROXY	 defined.    With
       this,  packets  will be redirected to a local socket, even
       if they were sent to a  remote  host.   If  the	specified
       redirection  port  is  0,  which is the default value, the
       destination port of a packet will be used as the	 redirec­
       tion  port.   When  this target is used, an optional extra
       argument (the port number) can be supplied.
       If the end of a user-defined chain is reached, or  a  rule
       with  target  RETURN is matched, then the next rule in the
       previous (calling) chain is examined.  If  the  end  of	a
       builtin	chain  is  reached,  or a rule in a builtin chain
       with target RETURN is matched, the target specified by the
       chain policy determines the fate of the packet.

OPTIONS
       The options that are recognized by ipchains can be divided
       into several different groups.

   COMMANDS
       These options specify the specific action to perform; only
       one  of	them can be specified on the command line, unless
       otherwise specified below.  For all the long  versions  of
       the  command and option names, you only need to use enough
       letters to ensure that ipchains can differentiate it  from
       all other options.

       -A, --append
	      Append one or more rules to the end of the selected
	      chain.  When the source  and/or  destination  names
	      resolve  to  more	 than one address, a rule will be
	      added for each possible address combination.

       -D, --delete
	      Delete one or more rules from the	 selected  chain.
	      There  are  two  versions of this command: the rule
	      can be specified as a number in the chain (starting
	      at 1 for the first rule) or a rule to match.

       -R, --replace
	      Replace  a  rule	in  the	 selected  chain.  If the
	      source and/or destination names resolve to multiple
	      addresses,  the  command will fail.  Rules are num­
	      bered starting at 1.

       -I, --insert
	      Insert one or more rules in the selected	chain  as
	      the  given  rule number.	So, if the rule number is
	      1, the rule or rules are inserted at  the	 head  of
	      the chain.

       -L, --list
	      List  all rules in the selected chain.  If no chain
	      is selected, all chains are listed.  It is legal to
	      specify the -Z (zero) option as well, in which case
	      no chain may be specified.   The	exact  output  is
	      affected by the other arguments given.

       -F, --flush
	      Flush  the  selected  chain.  This is equivalent to
	      deleting all the rules one by one.

       -Z, --zero
	      Zero the packet and byte counters	 in  all  chains.
	      It is legal to specify the -L, --list (list) option
	      as well, to see  the  counters  immediately  before
	      they are cleared; if this is done, then no specific
	      chain can be specified (they will all be	displayed
	      and cleared).

       -N, --new-chain
	      Create  a new user-defined chain of the given name.
	      There must be no target of that name already.

       -X, --delete-chain
	      Delete the  specified  user-defined  chain.   There
	      must  be	no  references to the chain (if there are
	      you must delete  or  replace  the	 referring  rules
	      before  the  chain can be deleted).  If no argument
	      is given, it will	 attempt  to  delete  every  non-
	      builtin chain.

       -P, --policy
	      Set  the	policy for the chain to the given target.
	      See the section  TARGETS	for  the  legal	 targets.
	      Only  non-userdefined chains can have policies, and
	      neither built-in nor  user-defined  chains  can  be
	      policy targets.

       -M, --masquerading
	      This  option  allows  viewing of the currently mas­
	      queraded connections (in	conjuction  with  the  -L
	      option)  or  to set the kernel masquerading parame­
	      ters (with the -S option).

       -S, --set tcp tcpfin udp
	      Change the timeout values	 used  for  masquerading.
	      This  command always takes 3 parameters, represent­
	      ing the timeout values (in seconds)  for	TCP  ses­
	      sions,  TCP  sessions after receiving a FIN packet,
	      and UDP packets, respectively.  A timeout	 value	0
	      means  that the current timeout value of the corre­
	      sponding entry is preserved.  This option	 is  only
	      allowed in combination with the -M flag.

       -C, --check
	      Check  the given packet against the selected chain.
	      This is extremely useful for testing, as	the  same
	      kernel  routines used to check "real" network pack­
	      ets are used to check this packet.  It can be  used
	      to check user-defined chains as well as the builtin
	      ones.  The same arguments used to specify	 firewall
	      rules  are  used	to  construct  the  packet  to be
	      tested.  In particular, the -s (source), -d (desti­
	      nation),	-p  (protocol),	 and -i (interface) flags
	      are compulsory.

       -h, --help
	      Give a (currently very brief)  description  of  the
	      command syntax.  If followed by the word icmp, then
	      a list of ICMP names is listed.

       -V, --version
	      Simply output the ipchains version number.

   PARAMETERS
       The following parameters make up a rule specification  (as
       used  in	 the  add, delete, replace, append and check com­
       mands).

       -p, --protocol[!] protocol
	      The protocol of the rule or of the packet to check.
	      The  specified  protocol	can  be	 one of tcp, udp,
	      icmp, or all, or it can be a numeric value,  repre­
	      senting  one of these protocols or a different one.
	      Also  a  protocol	 name  from   /etc/protocols   is
	      allowed.	  A  "!"  argument  before  the	 protocol
	      inverts the test.	 The number zero is equivalent to
	      all.   Protocol  all  will match with all protocols
	      and is taken as default when this option	is  omit­
	      ted.   All  may  not be used in in combination with
	      the check command.

       -s, --source, --src [!] address[/mask] [!] [port[:port]]
	      Source specification.   Address  can  be	either	a
	      hostname,	 a  network  name, or a plain IP address.
	      The mask can be either a network mask  or	 a  plain
	      number,  specifying  the	number of 1's at the left
	      side of the network mask.	 Thus, a mask  of  24  is
	      equivalent to 255.255.255.0.  A "!" argument before
	      the address specification inverts the sense of  the
	      address.
	      The source may include a port specification or ICMP
	      type.  This can either be a service  name,  a  port
	      number,  a  numeric  ICMP	 type, or one of the ICMP
	      type names shown by the command
	       ipchains -h icmp
	      Note that many of these ICMP names refer to both	a
	      type  and code, meaning that an ICMP code after the
	      -d flag is illegal.  In the rest of this paragraph,
	      a port means either a port specification or an ICMP
	      type.  An inclusive range can  also  be  specified,
	      using  the  format port:port.  If the first port is
	      omitted, "0" is assumed; if the  last  is	 omitted,
	      "65535" is assumed.
	      Ports may only be specified in combination with the
	      tcp, udp, or icmp protocols.  A "!" before the port
	      specification  inverts  the  sense.  When the check
	      command is specified, exactly one port is required,
	      and  if  the  -f	(fragment)  flag is specified, no
	      ports are allowed.

       --source-port [!] [port[:port]]
	      This allows separate specification  of  the  source
	      port  or port range.  See the description of the -s
	      flag above for details.The flag --sport is an alias
	      for this option.

       -d, --destination, --dst [!] address[/mask] [!]
       [port[:port]]
	      Destination specification.  See the  desciption  of
	      the  -s (source) flag for a detailed description of
	      the syntax.  For ICMP, which does not have ports, a
	      "destination port" refers to the numeric ICMP code.

       --destination-port [!] [port[:port]]
	      This allows separate specification  of  the  ports.
	      See  the	description  of	 the -s flag for details.
	      The flag --dport is an alias for this option.

       --icmp-type [!] typename
	      This allows specification of the ICMP type (use the
	      -h icmp option to see valid ICMP type names).  This
	      is often more convenient than appending it  to  the
	      destination specification.

       -j, --jump target
	      This  specifies the target of the rule; ie. what to
	      do if the packet matches it.  The target can  be	a
	      user-defined chain (not the one this rule is in) or
	      one of the special targets which decide the fate of
	      the  packet immediately.	If this option is omitted
	      in a rule, then matching	the  rule  will	 have  no
	      effect  on  the  packet's fate, but the counters on
	      the rule will be incremented.

       -i, --interface [!] name
	      Optional name of an interface via which a packet is
	      received (for packets entering the input chain), or
	      via which is packet is going to be sent (for  pack­
	      ets  entering  the forward or output chains).  When
	      this  option  is	omitted,  the  empty  string   is
	      assumed, which has a special meaning and will match
	      with any interface name.	When the "!"  argument is
	      used  before  the	 interface  name,  the	sense  is
	      inverted.	 If the interface name	ends  in  a  "+",
	      then any interface which begins with this name will
	      match.

       [!]  -f, --fragment
	      This means that the rule only refers to second  and
	      further  fragments  of  fragmented  packets.  Since
	      there is no way to tell the source  or  destination
	      ports  of	 such  a  packet  (or  ICMP type), such a
	      packet will not match any rules which specify them.
	      When  the	 "!" argument precedes the "-f" flag, the
	      sense is inverted.

   OTHER OPTIONS
       The following additional options can be specified:

       -b, --bidirectional
	      Bidirectional mode.  The rule will  match	 with  IP
	      packets  in  both	 directions;  this  has	 the same
	      effect as repeating the rule with the source & des­
	      tination	reversed.   Note  that this does NOT mean
	      that if you allow TCP syn packets out, the -b  rule
	      will  allow  non-SYN  packets  back in: the reverse
	      rule is exactly the same as the rule  you	 entered.
	      This means that it's usually better to simply avoid
	      the -b flag and spell the rules out explicitly.

       -v, --verbose
	      Verbose output.  This option makes the list command
	      show  the	 interface  address, the rule options (if
	      any), and the TOS masks.	The packet and byte coun­
	      ters  are	 also listed, with the suffix 'K', 'M' or
	      'G' for 1000, 1,000,000 and 1,000,000,000 multipli­
	      ers  respectively	 (but  see  the -x flag to change
	      this).  When used in combination with -M,	 informa­
	      tion related to delta sequence numbers will also be
	      listed.  For  appending,	insertion,  deletion  and
	      replacement,  this  causes  detailed information on
	      the rule or rules to be printed.

       -n, --numeric
	      Numeric output.  IP addresses and port numbers will
	      be printed in numeric format.  By default, the pro­
	      gram will try to display them as host  names,  net­
	      work names, or services (whenever applicable).

       -l, --log
	      Turn  on	kernel logging of matching packets.  When
	      this option is set for a	rule,  the  Linux  kernel
	      will print some information of all matching packets
	      (like most IP header fields) via printk().

       -o, --output [maxsize]
	      Copy matching  packets  to  the  userspace  device.
	      This is currently mainly for developers who want to
	      play with firewalling effects  in	 userspace.   The
	      optional	maxsize argument can be used to limit the
	      maximum number of bytes from the packet  which  are
	      to  be  copied.	This  option is only valid if the
	      kernel  has  been	 compiled  with	  CONFIG_IP_FIRE­
	      WALL_NETLINK set.


       -m, --mark markvalue
	      Mark  matching packets.  Packets can be marked with
	      a 32-bit unsigned value which may (one day)  change
	      how  they are handled internally.	 If you are not a
	      kernel hacker you are unlikely to care about  this.
	      If  the string markvalue begins with a + or -, then
	      this value will be added	or  subtracted	from  the
	      current marked value of the packet (which starts at
	      zero).

       -t, --TOS andmask xormask
	      Masks used for modifying the TOS field  in  the  IP
	      header.	When  a	 packet	 matches  a rule, its TOS
	      field is first bitwise and'ed with first	mask  and
	      the  result of this will be bitwise xor'ed with the
	      second mask.  The masks should be specified as hex­
	      adecimal 8-bit values.  As the LSB of the TOS field
	      must be unaltered	 (RFC  1349),  TOS  values  which
	      would  cause  it to be altered are rejected, as are
	      any rules which always set more than one	TOS  bit.
	      Rules which might set multiple TOS bits for certain
	      packets result in warnings (sent to  stdout)  which
	      can  be ignored if you know that packets with those
	      TOS values will never reach that rule.   Obviously,
	      manipulating  the	 TOS  is a meaningless gesture if
	      the rule's target is DENY or REJECT.

       -x, --exact
	      Expand numbers.  Display the  exact  value  of  the
	      packet  and  byte	 counters,  instead  of	 only the
	      rounded number in K's (multiples of 1000) M's (mul­
	      tiples of 1000K) or G's (multiples of 1000M).  This
	      option is only relevant for the -L command.

       [!] -y, --syn
	      Only match TCP packets with the SYN bit set and the
	      ACK and FIN bits cleared.	 Such packets are used to
	      request TCP  connection  initiation;  for	 example,
	      blocking	such  packets coming in an interface will
	      prevent incoming TCP connections, but outgoing  TCP
	      connections  will	 be  unaffected.   This option is
	      only meaningful when the protocol type  is  set  to
	      TCP.   If the "!" flag precedes the "-y", the sense
	      of the option is inverted.

       --line-numbers
	      When listing rules, add line numbers to the  begin­
	      ning  of	each  rule,  corresponding to that rule's
	      position in the chain.

       --no-warnings
	      Disable all warnings.

FILES
       /proc/net/ip_fwchains
       /proc/net/ip_masquerade

DIAGNOSTICS
       Various error messages are printed to standard error.  The
       exit  code  is  0  for  correct functioning.  Errors which
       appear to be caused by  invalid	or  abused  command  line
       parameters cause an exit code of 2, and other errors cause
       an exit code of 1.

BUGS
       If input is a terminal, and a  rule  is	inserted  in,  or
       appended to, the forward chain, and IP forwarding does not
       seem to be enabled, and --no-warnings is not specified,	a
       message	is  printed  to	 standard output, warning that no
       forwarding will occur until this is rectified.  This is to
       help users unaware of the requirement (which did not exist
       in the 2.0 kernels).

       There is no way to reset the packet and byte  counters  in
       one chain only.	This is a kernel limitation.

       Loop  detection is not done in ipchains; packets in a loop
       get dropped and logged, but that's the first  you'll  find
       out about it if you inadvertantly create a loop.

       The  explanation	 of  what  effect marking a packet has is
       intentionally vague until documentation describing the new
       2.1 kernel's packet scheduling routines is released.

       There  is no way to zero the policy counters (ie. those on
       the built-in chains).

NOTES
       This ipchains is very different from the	 ipfwadm  by  Jos
       Vos,  as it uses the new IP firewall trees.  Its function­
       ality is a superset of ipfwadm, and there is  generally	a
       1:1  mapping of commands.  I believe the new command names
       are more rational.  There are, however, a few  changes  of
       which you should be aware.

       Fragments  are  handled	differently.  All fragments after
       the first used to be let through (which is usually  safe);
       they  can  now  be  filtered.   This means that you should
       probably add an explicit rule to accept fragments  if  you
       are  converting over.  Also, look for old accounting rules
       which check for source and  destination	ports  of  0xFFFF
       (0xFF  for  ICMP	 packets)  which was the old way of doing
       accounting on fragments.

       Accounting rules are now simply integrated into the  input
       and output chains; you can simulate the old behaviour like
       so:
	ipchains -N acctin
	ipchains -N acctout
	ipchains -N acctio
	ipchains -I input -j acctio
	ipchains -I input -j acctin
	ipchains -I output -j acctio
	ipchains -I output -j acctout
       This creates three user-defined	chains,	 acctin,  acctout
       and  acctio,  which  are	 to  contain any accounting rules
       (these rules should be specified without	 a  -j	flag,  so
       that the packets simply pass through them unscathed).

       A MASQ or REDIRECT target encountered by the kernel out of
       place (ie. not during a	forward	 or  input  rule  respec­
       tively)	will cause a message to the syslog and the packet
       to be dropped.

       The old behaviour of SYN and ACK matching (which was  pre­
       viously	ignored for non-TCP packets) has changed; the SYN
       option is not valid for non-TCP-specific rules.

       The ACK matching option (the -k flag) is	 no  longer  sup­
       ported; the combination of !  and -y will give the equiva­
       lent).

       It is now illegal to specify a TOS mask which will set  or
       alter  the least significant TOS bit; previously TOS masks
       were silently altered by the kernel if they  tried  to  do
       this.

       The -b flag is now handled by simply inserting or deleting
       a pair of rules, one with the source and destination spec­
       ifications reversed.

       There  is  no  way to specify an interface by address: use
       its name.

SEE ALSO
       ipfw(4)

AUTHOR
       Rusty Russell rusty at linuxcare.com.  Thanks also to  Hans
       Persson	for detailed proofreading; I want him to read all
       my future documents!



			 February 8, 1998			1

end_of_manpages;