<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [
<!entity fwbuilder-url    "http://www.fwbuilder.org/">
<!entity tutorial-url     "http://www.fwbuilder.org/pages/Tutorial/index.html">
<!entity requirements-url "http://www.fwbuilder.org/pages/Requirements.html">
<!entity iptables-url     "http://netfilter.filewatcher.org/">
<!entity ipfilter-url     "http://coombs.anu.edu.au/~avalon/">
<!entity gtkmm-url        "http://gtkmm.sourceforge.net/">
<!entity gtkmm-download   "http://www.hvrlab.org/pub/gtkmm/">
]>

<article class="FAQ" id="FAQ">
  <?dbhtml filename="FAQ.html">

  <articleinfo>

    <title>Firewall Builder</title>
    <subtitle> Frequently Asked Questions</subtitle>

    <author>
      <firstname>Vadim</firstname>
      <surname>Kurland</surname>
      <affiliation>
	<address>
	  <email>vadim@fwbuilder.org</email>
	</address>
      </affiliation>
    </author>

    <revhistory>
      <revision>
	<revnumber>0.1</revnumber>
	<date>2001-11-25</date>
	<authorinitials>vk</authorinitials>
	<revremark>
	  Converted to SGML
	</revremark>
      </revision>
      
      <!-- Additional (*earlier*) revision histories go here -->
    </revhistory>

  </articleinfo>

  <sect1 id="intro">
    <title>Introduction</title>

    <para>
      Firewall Builder consists of an object-oriented GUI and a set
      of policy compilers for various firewall platforms. In
      Firewall Builder, a firewall policy is a set of rules; each
      rule consists of abstract objects that represent real network
      objects and services (hosts, routers, firewalls, networks,
      protocols). Firewall Builder helps users maintain a database
      of objects and allows policy editing using simple
      drag-and-drop operations.
    </para>

    <para>
      Preferences and object databases are stored in XML format.
      The GUI and policy compilers are completely independent. The
      GUI requires only minimal changes in order to add support for
      a new firewall platform even though a new policy compiler must
      be written. This provides for a consistent abstract model and
      the same GUI for different firewall platforms. Standardized
      XML data format opens possibility for many user interfaces and
      policy compiler implementations, all interchangeable.
    </para>

    <para>
      We ship a policy compiler for the popular free firewall
      iptables <ulink url="&iptables-url">&iptables-url</ulink> and
      are currently working on support for ip_filter <ulink
							    url="&ipfilter-url">&ipfilter-url</ulink>. Because of the
      modular architecture, Firewall Builder can be used to manage
      firewalls built on a variety of platforms including, but not
      limited to, Linux using iptables or ipfilter on FreeBSD or
      Solaris.
    </para>

    <para>
      The GUI is written using <ulink url="&gtkmm-url">
	GTK--</ulink>. We distribute binary RPM packages for RedHat
      7.1 / 7.2 and Mandrake 8.1. Binary packages for Debian can be
      downloaded from our "contrib" area.
    </para>

    <para>
      An interactive "Druid" facilitates an easy
      kick-start. Basically, to start, one should create objects for
      the firewall and internal network and then use the druid. It
      will ask a few questions and then build a basic skeleton
      policy, which can be edited manually. The same druid can be
      used to add specific "standard" rules later on.
    </para>

    <para>
      We provide a mechanism for automated creation of network
      objects using information either from the /etc/hosts file or
      by importing DNS zones.
    </para>

    <para>
      Solutions to many typical problems and answers to many
      questions can also be found in Firewall Builder Tutorial.
      Many cases people deal with while configuring their firewalls
      are covered in the Tutorial in great details.  Some topics can
      be found both in Tutorial and FAQ, but since FAQ is intended
      just as brief reference document, it provides only short
      answer to the question and refers reader to Tutorial for more
      detailed explanation. Firewall Builder Tutorial can be found
      online: <ulink url="&tutorial-url">&tutorial-url</ulink>
    </para>

  </sect1>

  <!-- ******************** Chapter 1 ************************************************* -->

  <sect1 id="systemreq">
    <title>System requirements, using pre-built packages, compiling from source</title>

    <qandaset>
      <!-- one of (QANDADIV QANDAENTRY) -->
      <qandaentry>
	<question>
	  <para>What are the system requirements for Firewall Builder ?</para>
	</question>

	<answer>
	  <para>
	    These are listed in the file "Requirements" in the docs
	    directory. It is /usr/share/doc/fwbuilder/Requirements or online:
	    <ulink url="&requirements-url">&requirements-url</ulink>
	  </para>
	</answer>

      </qandaentry>




      <qandaentry>
	<question>
	  <para>Where do I get GTK-- packages for RedHat 7.0 and 7.1 ?</para>
	</question>
	<answer>
	  <para> See gtk-- home page at <ulink
					       url="&gtkmm-url">&gtkmm-url</ulink> and follow link
	    "Download" or directly in <ulink
					     url="&gtkmm-download">&gtkmm-download</ulink>
	  </para>
	</answer>

      </qandaentry>




      <qandaentry>
	<question>
	  <para>I want to use pre-built binary package. What do I need to download and
	    install?</para>
	</question>

	<answer>
	  <para>
	    We distribute pre-built binary packages for some Linux distributions. You
	    would need to download and install the following (actual names of the
	    packages vary depending on the naming convention for given distribution):
	  </para>

	  <para>
	    <itemizedlist>
	      <listitem>
		<para>The API: libfwbuilder</para>
	      </listitem>
	      <listitem>
		<para>GUI: fwbuilder</para>
	      </listitem>
	      <listitem>
		<para>Policy compiler for iptables: fwbuilder-iptables</para>
	      </listitem>
	    </itemizedlist>
	  </para>

	  <para>
	    As policy compilers for other firewall platforms become available, they
	    will appear in the download area.
	  </para>
	  <para>
	    You may also want to check what is available under "Contrib" in the
	    download area. There are useful install, boot-time startup and other
	    scripts contributed by users and beta-testers. Pre-built binary packages
	    for Debian and SuSe are also available in "Contrib" area.
	  </para>
	</answer>
      </qandaentry>




      <qandaentry>
	<question>
	  <para>Does Firewall Builder need GNOME?</para>
	</question>

	<answer>
	  <para>
	    As of version 0.9.7 Firewall Builder does not need GNOME
	    anymore. All widgets which are part of libgnomeui library have
	    been rewritten so Firewall Builder now uses only gtk+ and
	    gtk-- libraries. This should simplify porting to other OS and
	    should make it possibly to use Firewall Builder on Linux
	    systems using KDE.
	  </para>
	</answer>
      </qandaentry>





      <qandaentry>
	<question>
	  <para>I am trying to compile Firewall Builder v0.9.6 from
	    source, but configure complains "libfwbuilder not
	    installed"</para>
	</question>

	<answer>
	  <para>
	    As of version 0.9.6 the code has been split into three
	    major parts: API, GUI and policy compilers. You need to
	    download, compile and install API for the rest to
	    compile. The API comes in a separate source archive
	    called libfwbuilder-0.10.0.tar.gz. Compile and install
	    it as usual, using "./configure; make; make install"
	    procedure.
	  </para>
	</answer>
      </qandaentry>






      <qandaentry>
	<question>
	  <para>What firewall platforms are supported ?</para>
	</question>

	<answer>
	  <para>
	    As of version 0.9.3 we support iptables and are working
	    on ipfilter policy compiler. We dropped support for
	    ipchains as obsolete technology and because lack of time
	  </para>
	</answer>
      </qandaentry>




    </qandaset>
  </sect1>


  <!-- ******************** Chapter 2 ************************************************* -->

  <sect1 id="problems">
    <title>Problems, troubleshooting and reporting bugs</title>

    <qandaset>
      <qandaentry>

	<question>
	  <para>fwbuilder binary does not start 1</para>
	</question>

	<answer>
	  <para>If you get this error:
	  </para>
	  
	  <para>
	    <programlisting>
	      fwbuilder: error while loading shared
	      libriaries: libfwbuilder.so.0: cannot load shared object
	      file: no such file or directory.
	    </programlisting>
	  </para>

	  <para>
	    Then the GUI binary (fwbuilder) can not find API library
	    libfwbuilder. If you are using our pre-built binary packages,
	    then make sure you download and install package called
	    libfwbuilder. If you compiled from sources, then perhaps you
	    installed libfwbuilder with default prefix <filename>
	      /usr/local/</filename>, therefore library went to <filename>
	      /usr/local/lib</filename>. Dynamic linker ldd can not find it
	    there.
	  </para>

	  <para>
	    You have the following options:
	  </para>

	  <para>
	    <itemizedlist>
	      <listitem>
		<para>create environment variable LD_LIBRARY_PATH with value
		  <filename>/usr/local/lib</filename> and run fwbuilder
		  from this environment.</para>
	      </listitem>
	      <listitem>
		<para>add <filename>/usr/local/lib</filename> to the file
		  <filename>/etc/ld.so.conf</filename> and run ldconfig so it
		  will rescan dynamic libraries and add them to its
		  cache.</para>
	      </listitem>
	      <listitem>
		<para>recompile libfwbuilder and fwbuilder with prefix
		  <filename> /usr/</filename>, this will install
		  <filename>libfwbuilder.so.0</filename> in
		  <filename>/usr/lib</filename>. <filename>ldd</filename> will
		  find it there without any changes to environment variables
		  or <filename>/etc/ld.so.conf</filename> file.  To change
		  prefix you need to run configure with command line parameter
		  <filename>"--prefix=/usr"</filename>.  Do this both for
		  libfwbuilder and fwbuilder.</para>
	      </listitem>
	    </itemizedlist>
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>fwbuilder binary does not start 2</para>
	</question>

	<answer>
	  <para>If you get this error:
	  </para>

	  <para>
	    <programlisting>
	      fwbuilder: error while loading shared
	      libraries: fwbuilder: undefined symbol: co
	      nnect__Q23Gtk9ProxyNodePQ23Gtk6ObjectPCcPFv_vPQ24SigC8S
	      lotDatab
	    </programlisting>
	  </para>

	  <para>
	    Then usually this error happens when old version of libgtkmm or
	    libsigc++ library is used. Check if you need to upgrade those,
	    you can use our <ulink url="&requirements-url">
	      Requirements</ulink> document to find out what versions you need
	    and where can you get them from.
	  </para>

	  <para>
	    sometimes this error happens even if new rpms have been
	    installed.  In this case you need to check which library
	    gets picked up by fwbuilder when it starts. Sometimes old
	    version gets stuck somewhere on disk after upgrade and then
	    ldd loads it instead of newer one. Try to download script
	    called "check_libs.sh" from "Contribs" area on Sourceforge
	    site of Firewall Builder and then run this script like this:
	  </para>


	  <programlisting>
	    check_libs.sh /usr/bin/fwbuilder
	  </programlisting>

	  <para>
	    it will list all dynamic libraries used by fwbuilder binary
	    and what RPM they are part of. Look for libraries which are not
	    part of any installed rpm, those are causing of the problem.
	  </para>

	</answer>
      </qandaentry>
      
      <qandaentry>

	<question>
	  <para>fwbuilder binary does not start 3</para>
	</question>

	<answer>
	  <para>If you get this error:
	  </para>

	  <para>
	    <programlisting>
	      fwbuilder: /lib/libc.so.6: version `GCC_3.0' not found (required by /usr/lib/libxslt.so.1)
	      fwbuilder: /lib/libc.so.6: version `GCC_3.0' not found (required by /usr/lib/libxsltbreakpoint.so.1)
	      fwbuilder: /lib/libc.so.6: version `GCC_3.0' not found (required by /usr/lib/libxml2.so.2)
	    </programlisting>
	  </para>

	  <para>
	    Most likely you are using libxml2 and libxslt packages
	    from RedHat's distribution RawHide on your RedHat 7.1
	    system. It turns out these packages require new version of
	    glibc, compiled with gcc 3.0. This library is not
	    available for RedHat 7.1, therefore you should not be
	    using libxml2 and libxslt from RawHide on RedHat 7.1.
	  </para>

	  <para>
	    Just follow instructions in our Requirements document and
	    download libxml2 and libxslt from ftp.xmlsoft.org, these
	    work on RedHat 7.1 and 7.2 just fine.
	  </para>

	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>fwbuilder or one of policy compilers crashes. What
	    to do ?</para>
	</question>

	<answer>
	  <para>
	    Please file a bug on Sourceforge. Provide information we might
	    need to fix the problem (in the form of the output of the
	    following commands):
	  </para>

	  <programlisting>
	    cat /etc/issue

	    rpm -qa | grep gnome
	    rpm -qa | grep gtk
	    rpm -qa | grep libxml
	    rpm -qa | grep libsigc++

	    ls -la /usr/share/fwbuilder
	    ls -la /usr/share/pixmaps/fwbuilder

	    ldd /usr/bin/fwbuilder
	    ldd /usr/bin/fwb_ipfilter
	    ldd /usr/bin/fwb_iptables
	  </programlisting>

	  <para>
	    Also send us core file and .xml file with your objects. If
	    program crashes but does not generate core file (it shows
	    "crash" dialog instead), run it as follows:
	  </para>

	  <programlisting>
	    fwbuilder --disable-crash-dialog
	  </programlisting>

	  <para>
	    It will dump core then.
	  </para>
	</answer>
      </qandaentry>



      <qandaentry>
	<question>
	  <para>I get "I/O Error" while compiling policy. There is
	    no other indication of error though.</para>
	</question>

	<answer>
	  <para>
	    Did you install package with corresponding compiler ? We ship compilers in
	    a separate RPMs named like this: fwbuilder-ipchains-0.8.7-2-rh7.i386.rpm
	  </para>

	  <para>
	    Check if compiler dumped core. If you can't find it, you may try to run
	    compiler manually, providing the following command line parameters:
	  </para>


	  <programlisting>
	    $ fwb_iptables  -f path_to_objects.xml   firewall_object_name
	  </programlisting>

	  <para>
	    All policy compilers have the same command line format.
	  </para>
	</answer>
      </qandaentry>



      <qandaentry>
	<question>
	  <para>fwbuilder crashes on my Debian or Mandrake or SuSe
	    system. What do I do ?</para>
	</question>

	<answer>
	  <para>
	    We can not guarantee that Firewall Builder would work flawlessly on Debian
	    or Mandrake or SuSe since we do not have access to these distributions for
	    testing.
	  </para>

	  <para>
	    Sometimes we recieve packages built for these distributions by volunteers.
	    In this case we post these packages in "Contribs" area on the project's
	    page on Sourceforge. We do not verify or even try these packages and
	    completely rely on people who submit them. We usually post information
	    about authors, so if you have questions you can contact them directly.
	  </para>

	  <para>
	    We welcome help from anyone who can test Firewall Builder on these
	    distributions and provide feedback
	  </para>
	</answer>
      </qandaentry>
    </qandaset>
  </sect1>


  
  <!-- ******************** Chapter 3 ************************************************* -->

  <sect1 id="building-policy">
    <title>Building firewall policy</title>

    <qandaset>

      <qandaentry>
	<question>
	  <para>Do I need to add rules for "ACK" packets?</para>
	</question>

	<answer>
	  <para>
	    Firewall Builder uses "stateful inspection" feature of
	    underlying firewall platform. In case of iptables it loads
	    module ip_conntrack which is tracking connections opened
	    through the firewall and by the firewall itself. Since this
	    module "remembers" each connection, there is no need in
	    additional rule for "ACK" or "reply" packets. In fact, this
	    module does lot more than keeping track of opened TCP sessions
	    as it does similar thing to other protocols as well, where
	    possible. Firewall Builder also loads some other modules to
	    keep track of complex protocols, e.g. it loads module
	    ip_nat_ftp to support FTP.
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>Druid seems to multiply rules in the policy</para>
	</question>
	
	<answer>

	  <para>
	    This is how it works now. Interactive Druid does not check for rules in
	    existing policy and simply adds new ones. If you run Druid twice and ask
	    it to generate the same set of rules, you'll get the same rules many times
	    in your policy. This will be improved in subsequent releases.
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>I use iptables (or other) to protect local host. How
	    do I use Firewall Builder to build policy?</para>
	</question>

	<answer>

	  <para>
	    Your host may or may not have its IP address assigned
	    dynamically via PPPoE or DHCP.
	  </para>

	  <para>
	    <itemizedlist>
	      <listitem>
		<para>
		  <emphasis>If address is static:</emphasis>
		</para>

		<para>
		  <itemizedlist>
		    <listitem><para>create firewall object, enter its IP
			address</para></listitem>

		    <listitem><para>create interface for it in "Interfaces" tab,
			mark it as "external"</para></listitem>

		    <listitem><para>add loopback interface named "lo", address
			127.0.0.1/255.0.0.0</para></listitem>

		    <listitem><para>call Druid, chose "Firewall protects local
			host" and then pick rules you want.</para></listitem>

		  </itemizedlist>
		</para>

		<para>
		  See what Druid have created for you. You can edit and add rules now.
		</para>

	      </listitem>

	      <listitem>
		<para>
		  <emphasis>If address is dynamic:</emphasis>
		</para>

		<para>
		  <itemizedlist>
		    <listitem><para>create firewall object, mark its address as
			"dynamic"</para></listitem>

		    <listitem><para>create interface for it in "Interfaces" tab,
			mark it as "external" and "dynamic"</para></listitem>
		    
		    <listitem><para>add loopback interface named "lo", address
			127.0.0.1/255.0.0.0</para></listitem>

		    <listitem><para>call Druid, chose "Firewall protects local
			host" and then pick rules you want.</para></listitem>

		  </itemizedlist>
		</para>
	      </listitem>
	    </itemizedlist>
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>How can I configure NAT to provide access from the
	    Internet to my server behind the firewall ?</para>
	</question>

	<answer>

	  <para>
	    This question is outlined in Firewall Builder Tutorial in
	    great details, what follows is just a brief explanation. You
	    can find Tutorial online: <ulink url="&tutorial-url">
	      &tutorial-url</ulink>
	  </para>

	  <para>
	    There are two possibilities here, depending on what IP address you want to
	    use to access your server - that of your firewall or virtual one. If you
	    use the same address your firewall has, you can arrange access to your
	    internal server from outside, and provide your internal users with access
	    to the Internet using only one address. This scheme may become a
	    limitation though if you have multiple servers inside your network which
	    need to be accessed from outside. In the latter case you may want to use
	    different port numbers or virtual ip addresses for access to different
	    internal servers.
	  </para>

	  <para>
	    <itemizedlist>
	      <listitem>

		<para>
		  <emphasis>Using IP address of the firewall to
		    access your server inside.</emphasis>
		</para>

		<para>
		  This is easy. Just add rule to the "NAT":
		</para>

		<para>
		  <table>
		    <title></title>
		    <tgroup cols="6">
		      <thead>
			<row>
			  <!-- one of (ENTRYTBL ENTRY) -->
			  <entry>Orig.Src</entry>
			  <entry>Orig.Dst</entry>
			  <entry>Orig.Srv</entry>
			  <entry>Transl.Src</entry>
			  <entry>Transl.Dst</entry>
			  <entry>Transl.Srv</entry>
			</row>
		      </thead>
		      <tbody>
			<row>
			  <!-- one of (ENTRYTBL ENTRY) -->
			  <entry>Any</entry>
			  <entry>Firewall</entry>
			  <entry>Any</entry>
			  <entry>Original</entry>
			  <entry>Server</entry>
			  <entry>Original</entry>
			</row>
		      </tbody>
		    </tgroup>
		  </table>
		</para>

		<para>
		  where "firewall" is the object for your firewall
		  and "Server" is the object for your server behind
		  the firewall.  This is it, Firewall Builder will
		  generate iptables code for DNAT translation using
		  firewall's IP address.
		</para>

	      </listitem>

	      <listitem>
		<para>
		  <emphasis>Using virtual IP address for translation</emphasis>
		</para>

		<para>
		  Create a rule in "NAT" in a similar way:
		</para>

		<table>
		  <title></title>
		  <tgroup cols="6">
		    <thead>
		      <row>
			<!-- one of (ENTRYTBL ENTRY) -->
			<entry>Orig.Src</entry>
			<entry>Orig.Dst</entry>
			<entry>Orig.Srv</entry>
			<entry>Transl.Src</entry>
			<entry>Transl.Dst</entry>
			<entry>Transl.Srv</entry>
		      </row>
		    </thead>
		    <tbody>
		      <row>
			<!-- one of (ENTRYTBL ENTRY) -->
			<entry>Any</entry>
			<entry>Server-NAT</entry>
			<entry>Any</entry>
			<entry>Original</entry>
			<entry>Server</entry>
			<entry>Original</entry>
		      </row>
		    </tbody>
		  </tgroup>
		  <!-- one of (GRAPHIC MEDIAOBJECT TGROUP) -->
		</table>

		<para>
		  where "Server-NAT" is special object with address
		  of the translation you want to create, and
		  "Server" is an object for your server behind the
		  firewall.
		</para>

		<para>
		  In addition to the firewall rule, you need to set
		  up static ARP entry and add routing. Asuming
		  external translated address of the server is
		  NN.NN.NN.NN, external firewall's interface is eth1
		  and its internal interface is eth0, the following
		  commands would do the trick:
		</para>

		<programlisting>
		  # arp -Ds NN.NN.NN.NN eth1 pub  
		  # route add NN.NN.NN.NN dev eth0
		</programlisting>

		<para>
		  The first command adds static "published" ARP
		  entry, while the second command routes it through
		  internal interface
		</para>

		<para>
		  As of version 0.9.3 iptables compiler can add
		  these two commands to the generated firewall
		  script if checkbox "Create ARP entries for DNAT
		  translations" is checked in "iptables" tab in
		  firewall object's dialog
		</para>
	      </listitem>

	    </itemizedlist>
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>I see the firewall objects has multiple policies
	    associated with it. How do these policies relate to each
	    other and in what order does policy compiler scan them to
	    generate firewall code?</para>
	</question>


	<answer>

	  <para>
	    Global Policy rules apply to packets crossing the firewall,
	    regardless of the interface they ingress and egress
	    through. In case of iptables this is equivalent to the FORWARD
	    chain, although there may be no such direct correspondence in
	    other firewall platforms. Even when such correspondence does
	    exist, high level Firewall Bulder policy rule may need to be
	    converted into multiple rules going into different groups or
	    chains in the target platform code beause of number of
	    reasons. To explain this, let's consider a situation when
	    Firewall Builder has to generate code for iptables firewall
	    and the rule has "Any" as source. Obviously, if source is
	    "any", then it should cover any object, including the firewall
	    itself.  Therefore policy compiler which generates code for
	    iptables places rule into both FORWARD and OUTPUT
	    chains. However, both final iptables rules won't have
	    interface specified in them since original fwbuilder rule was
	    part of the Global Policy which is not associated with any
	    interface.
	  </para>

	  <para>
	    Interface Policy rules are associated with certain network
	    interface of the firewall. Unlike Global Policy rules,
	    direction can be specified for Interface Policy rules. This
	    provides a mechanism for dealing with situations where knowing
	    both interface and direction is neccessary, for example
	    setting up anti-spoofing rules. Since situations like this are
	    rare, we recommend placing most of the firewall rules in the
	    Global Policy and only those rules which can not be
	    implemented in any other way into Interface Policy.
	  </para>

	  <para>
	    At the same time there are target platforms which require that
	    all rules are always associated with interfaces. In this case
	    using Global Policy rules may not be practical because writing
	    policy compiler capable of guessing correct interface may be
	    too complex. One example of such platform is Cisco routers,
	    where access lists (ACL) are always associated with
	    interfaces.
	  </para>

	  <para>
	    When policy compiler generates code for the target platform,
	    it first scans NAT rules, then Interface Policies, then Global
	    Policy. This determines the order in which lines of the target
	    code are generated.
	  </para>
	</answer>
      </qandaentry>

    </qandaset>

  </sect1>


  <!-- ******************** Chapter 4 ************************************************* -->

  <sect1 id="install">
    <title>Installing policy on the firewall</title>

    <qandaset>

      <qandaentry>
	
	<question>
	  <para>The XML file I save, is it transformed into iptables
	    script and sent to the firewall automatically when I click
	    on "Compile"? Or do I have to restart something to see the
	    changes applied?</para>
	</question>

	<answer>
	  <para>
	    "Compile" only calls compiler, which produces a file called
	    after the name of the firewall object, with ".fw"
	    extension. This file contains iptables sript which needs to be
	    activated. There are two ways to activate it: 1) you can
	    simply run it by hand. 2) you can use custom shell script to
	    copy this file to where it should be and then run it. If you
	    put this script in the "Policy Install Script" field in
	    "Compile/Install" tab of the firewall's object dialog, then
	    menu item "Rules/Install" will be activated. We have examples
	    of the install script in the "Contrib" area on Sourceforge. We
	    do not ship this script with the product because the
	    installation and activation procedure is too different on
	    different installations. We might standardise on one or
	    another version in the future, but for now it is add-on
	    feature and we rely on contributors to send us examples of
	    their install scripts. You do not need to reboot your firewall
	    to activate the new policy. Iptables script generated by
	    Firewall Builder has a code to do a "clean up" job by removing
	    all previous iptables settings, before it loads new ones.
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>I have ipchains installed on my RedHat 7.1
	    system. How do I switch to iptables and start using
	    firewall script generated by Firewall Builder?</para>
	</question>

	<answer>
	  <para>
	    You do not need to uninstall ipchains, but you need to deactivate it.
	  </para>

	  <para>
	    As root, run the following command:
	  </para>

	  <programlisting>
	    # chkconfig --level 2345 ipchains off
	  </programlisting>

	  <para>
	    if you do not want to reboot at this point, run the following to stop and
	    remove ipchains from the memory:
	  </para>

	  <programlisting>
	    # /etc/rc.d/init.d/ipchains stop
	    # rmmod ipchains
	  </programlisting>

	  <para>
	    Now simply run iptables script created by fwbuilder to activate your
	    firewall.
	  </para>
	  
	  <para>
	    RedHat's standard iptables setup depends on their scripts iptables-save
	    and iptables-restore. If you wish to stick with RedHat's standard scripts,
	    simply run these commands:
	  </para>

	  <programlisting>
	    # /etc/rc.d/init.d/iptables save
	    # chkconfig --level 2345 iptables on
	  </programlisting>

	  <para>
	    This will save your configuration to RedHat's standard file
	    /etc/sysconfig/iptables in iptables-save format (which is different!) and
	    then will restart it every time you reboot your firewall.
	  </para>
	  
	  <para>
	    If you do not want to use their scripts, you can use script
	    "firewall-install" available in our Contrib area on SourceForge. This
	    script comes with a README file which describes its usage.
	  </para>
	</answer>
      </qandaentry>
    </qandaset>
  </sect1>

  <!-- ******************** Chapter 5 ************************************************* -->

  <sect1 id="logging">
    <title>Logging</title>

    <qandaset>

      <qandaentry>
	<question>
	  <para>I do not see log records in /var/log/messages, what's wrong?</para>
	</question>

	<answer>
	  <para>
	    RedHat Linux comes with syslog preconfigured to write all log
	    messages with level "info" and higher to /var/log/messages,
	    while iptables script generated by Firewall Builder by default
	    logs everything as "debug". You need either to edit
	    /etc/syslog.conf to make all "debug" messages to be logged, or
	    change log level to "info" in iptables tab in firewall dialog
	  </para>
	</answer>
      </qandaentry>


      <qandaentry>
	<question>
	  <para>I've got logging working, but I think it sends too
	    much information to the log so I can not really find what
	    I am interested in. Is there a way to make it more
	    readable?</para>
	</question>

	<answer>
	  <para>
	    You can use our script logwatcher.pl available in Contrib
	    area. It reads log file /var/log/messages and shows only the
	    following fields from each log line:
	  </para>

	  <para>
	    <itemizedlist>
	      <listitem>
		<para>Date and time</para>
	      </listitem>
	      <listitem>
		<para>rule number (assuming you use default setting for the
		  rule prefix which looks like this: "RULE %N -- %A")</para>
	      </listitem>
	      <listitem>
		<para>rule action (Deny/Reject/Accept)</para>
	      </listitem>
	      <listitem>
		<para>interface</para>
	      </listitem>
	      <listitem>
		<para>protocol</para>
	      </listitem>
	      <listitem>
		<para>source address and source port</para>
	      </listitem>
	      <listitem>
		<para>destination address and destination port</para>
	      </listitem>
	      <listitem>
		<para>ICMP type and code for ICMP packets</para>
	      </listitem>
	    </itemizedlist>
	  </para>

	  <para>
	    Note though that this script drops some data logged by
	    iptables to improve readability. You may miss some important
	    information because of this, so in case of real problem always
	    look in the original log!
	  </para>

	  <para>
	    Another, more elaborate version of the same script is
	    logwatcher2.pl. It is also available in Contrib area.
	  </para>
	</answer>
      </qandaentry>

      <qandaentry>
	<question>
	  <para>How can I get a list of connections opened through the
	    firewall at any given moment of time ?</para>
	</question>

	<answer>
	  <para>
	    You can use our script connwatcher.pl available in Contrib
	    area. It prints the contents of the connections table every
	    second, sort of like top shows processes active in the system.
	  </para>
	</answer>
      </qandaentry>

    </qandaset>
  </sect1>

</article>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:nil
sgml-shorttag:nil
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->