From f3790a541bd8bf205f6b4cce6b12f8f11cb02911 Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 18 Mar 2003 15:16:33 +0000 Subject: [PATCH] Shorwall 1.4.0 git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@507 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- STABLE/INSTALL | 12 +- STABLE/blacklist | 6 +- STABLE/changelog.txt | 70 +- STABLE/common.def | 14 +- STABLE/documentation/Documentation.htm | 5684 ++++++++--------- STABLE/documentation/FAQ.htm | 2240 +++---- STABLE/documentation/IPIP.htm | 408 +- STABLE/documentation/Install.htm | 274 +- STABLE/documentation/MAC_Validation.html | 157 +- STABLE/documentation/News.htm | 4096 ++++++------ .../documentation/Shorewall_Squid_Usage.html | 797 ++- .../documentation/Shorewall_index_frame.htm | 214 +- .../documentation/Shorewall_sfindex_frame.htm | 163 +- .../configuration_file_basics.htm | 487 +- STABLE/documentation/download.htm | 741 ++- STABLE/documentation/errata.htm | 847 +-- STABLE/documentation/errata_3.html | 715 +++ STABLE/documentation/mailing_list.htm | 330 +- STABLE/documentation/myfiles.htm | 289 +- STABLE/documentation/ping.html | 276 +- STABLE/documentation/ports.htm | 9 +- .../documentation/seattlefirewall_index.htm | 853 ++- .../shorewall_extension_scripts.htm | 139 +- .../documentation/shorewall_prerequisites.htm | 84 +- .../shorewall_quickstart_guide.htm | 460 +- .../documentation/shorewall_setup_guide.htm | 4204 ++++++------ STABLE/documentation/sourceforge_index.htm | 592 +- STABLE/documentation/standalone.htm | 690 +- .../starting_and_stopping_shorewall.htm | 469 +- STABLE/documentation/support.htm | 609 +- STABLE/documentation/three-interface.htm | 2209 +++---- STABLE/documentation/traffic_shaping.htm | 542 +- STABLE/documentation/troubleshoot.htm | 332 +- STABLE/documentation/two-interface.htm | 1735 ++--- STABLE/documentation/upgrade_issues.htm | 469 +- .../whitelisting_under_shorewall.htm | 547 +- STABLE/fallback.sh | 26 +- STABLE/firewall | 1293 ++-- STABLE/functions | 29 +- STABLE/hosts | 13 +- STABLE/init | 2 +- STABLE/init.sh | 10 +- STABLE/install.sh | 87 +- STABLE/interfaces | 30 +- STABLE/maclist | 4 +- STABLE/masq | 16 +- STABLE/modules | 7 +- STABLE/nat | 4 +- STABLE/params | 24 +- STABLE/policy | 2 +- STABLE/proxyarp | 4 +- STABLE/releasenotes.txt | 163 +- STABLE/rfc1918 | 8 +- STABLE/routestopped | 6 +- STABLE/rules | 33 +- STABLE/shorewall | 61 +- STABLE/shorewall.conf | 397 +- STABLE/shorewall.spec | 40 +- STABLE/start | 4 +- STABLE/stop | 2 +- STABLE/stopped | 2 +- STABLE/tcrules | 6 +- STABLE/tos | 2 +- STABLE/tunnel | 6 +- STABLE/tunnels | 4 +- STABLE/uninstall.sh | 13 +- STABLE/zones | 6 +- 67 files changed, 16988 insertions(+), 17079 deletions(-) create mode 100644 STABLE/documentation/errata_3.html diff --git a/STABLE/INSTALL b/STABLE/INSTALL index 58e4501ff..c62b8f681 100644 --- a/STABLE/INSTALL +++ b/STABLE/INSTALL @@ -1,4 +1,4 @@ -Shoreline Firewall (Shorewall) Version 1.3 - 6/14/2002 +Shoreline Firewall (Shorewall) Version 1.4 - 3/14/2003 ----- ---- ----------------------------------------------------------------------------- @@ -27,16 +27,16 @@ o If you have an earlier version of Shoreline Firewall installed,see the o Edit the configuration files to fit your environment. To do this, I strongly advise you to follow the instructions at: - - http://shorewall.sf.net/shorewall_quickstart_guide.htm + + http://www.shorewall.net/shorewall_quickstart_guide.htm o If you are using Caldera, Redhat, Mandrake, Corel, Slackware, SuSE or Debian, then type "./install.sh". o For other distributions, determine where your distribution installs init scripts and type "./install.sh " o Start the firewall by typing "shorewall start" -o If the install script was unable to configure Shoreline Firewall to - start audomatically at boot, see the HTML documentation contains in the +o If the install script was unable to configure Shoreline Firewall to + start automatically at boot, see the HTML documentation contains in the "documentation" directory. Upgrade: @@ -44,4 +44,4 @@ Upgrade: o run the install script as described above. o shorewall restart - + diff --git a/STABLE/blacklist b/STABLE/blacklist index 33df1518c..66ca0d9e4 100644 --- a/STABLE/blacklist +++ b/STABLE/blacklist @@ -1,5 +1,5 @@ # -# Shorewall 1.3 -- Blacklist File +# Shorewall 1.4 -- Blacklist File # # /etc/shorewall/blacklist # @@ -9,7 +9,7 @@ # # ADDRESS/SUBNET - Host address, subnetwork or MAC address # -# MAC addresses must be prefixed with "~" and use "-" +# MAC addresses must be prefixed with "~" and use "-" # as a separator. # # Example: ~00-A0-C9-15-39-78 @@ -27,7 +27,7 @@ # /etc/shorewall/shorewall.conf # # If PROTOCOL or PROTOCOL and PORTS are supplied, only packets matching -# the protocol (and one of the ports if PORTS supplied) are blocked. +# the protocol (and one of the ports if PORTS supplied) are blocked. # # Example: # diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index cfeb3947e..64be1589b 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,22 +1,66 @@ -Changes since 1.3.13 +Changes since 1.3.14 -1. Fix 'shorewall add' bug. +1. All versions changed to 1.4. -2. Add OLD_PING_HANDLING option +2. Rework of error message generation to make the 'firewall' script + smaller. -3. Allow adding alias labels under ADD_IP_ALIASES=Yes. +3. Deimplemented MERGE_HOSTS=No. -4. Allow adding alias labels under ADD_SNAT_ALIASES=Yes. +4. Generate error for : name in interfaces file. -5. Use the routing table to generate list of subnets to be masqueraded - when an interface name appears in the SUBNET column of - /etc/shorewall/masq. +5. Deimplement old ping handling. -6. Restore $dev.$vid naming of VLAN interfaces. +6. Deimplement 'routestopped' interface/hosts option. -7. Updated copyrights for 2003. +7. Strip comments from potentially large files while the firewall is + still up and running during 'restart'. -8. Added support for openvpn tunnels on arbitrary ports +8. Disallow the old port forwarding/redirection syntax. -9. Corrected rule number calculation problem in 'shorewall add' command - processing. +9. Reorganize shorewall.conf. + +10. Added support for LOG target. + +11. Move firewall and version (one more time....) + +12. Add late DNS reply rule to the common chain. + +12. Corrected rule number calculation problem in 'shorewall add' command + processing. + +13. Update Documentation for 1.4 + +14. Remove icmp.def file. + +15. Added CONTINUE rule target. + +16. Added Andrew Zhoglo's fix for logunclean. + +17. Removed 'multi' option. + +18. Support 802.11b devices with maclist. + +19. Don't detect loopback simply by name. + +20. Removed trailing white space from all files. + +21. Improved parsing of comma-separated lists. + +22. Add ECN Removal support + +23. Add TCP ports 445 and 139 to the common silent list. + +24. Remove 'check' command support. + +25. Restore 'check' command support. + +26. Remove unused function find_interface_broadcasts() + +27. Remove stale comments in the params file. + +28. Silently drop INVALID state packets + +29. Ignore the 'default' route when detecting masq'd networks. + +30. REALLY process the params file first now (honest). diff --git a/STABLE/common.def b/STABLE/common.def index cde58a555..7cf8676d7 100644 --- a/STABLE/common.def +++ b/STABLE/common.def @@ -1,7 +1,7 @@ ############################################################################ -# Shorewall 1.3 -- /etc/shorewall/common.def +# Shorewall 1.4 -- /etc/shorewall/common.def # -# This file defines the rules that are applied before a policy of +# This file defines the rules that are applied before a policy of # DROP or REJECT is applied. In addition to the rules defined in this file, # the firewall will also define a DROP rule for each subnet broadcast # address defined in /etc/shorewall/interfaces (including "detect"). @@ -14,14 +14,12 @@ # run_iptables -A common -p icmp -j icmpdef ############################################################################ -# Drop invalid state TCP packets -# -run_iptables -A common -m state -p tcp --state INVALID -j DROP -############################################################################ # NETBIOS chatter # run_iptables -A common -p udp --dport 137:139 -j REJECT run_iptables -A common -p udp --dport 445 -j REJECT +run_iptables -A common -p tcp --dport 139 -j REJECT +run_iptables -A common -p tcp --dport 445 -j REJECT run_iptables -A common -p tcp --dport 135 -j reject ############################################################################ # UPnP @@ -36,5 +34,9 @@ run_iptables -A common -d 224.0.0.0/4 -j DROP # AUTH -- Silently reject it so that connections don't get delayed. # run_iptables -A common -p tcp --dport 113 -j reject +############################################################################ +# DNS -- Silenty drop late replies +run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP + diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 6561d1473..357fe5341 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -2,293 +2,306 @@ - + - + - + - Shorewall 1.3 Documentation + Shorewall 1.4 Documentation - - + + + - + + + - + - - - + + - + +

Shorewall 1.4 Reference

+ + - - + +
+
- -

Shorewall 1.3 Reference

-
- + +

This documentation is intended primarily for reference. - Step-by-step instructions for configuring Shorewall in -common setups may be found in the QuickStart Guides.

- +

Components

- +

Shorewall consists of the following components:

- -
    -
  • params -- -a parameter file installed in /etc/shorewall that can be used - to establish the values of shell variables for use in other files.
    • -
  • shorewall.conf - -- a parameter file installed in /etc/shorewall that -is used to set several firewall parameters.
    • -
  • zones - a -parameter file installed in /etc/shorewall that defines - a network partitioning into "zones"
    • -
  • policy -- - a parameter file installed in /etc/shorewall/ that establishes - overall firewall policy.
    • -
  • rules -- -a parameter file installed in /etc/shorewall and used - to express firewall rules that are exceptions to the high-level - policies established in /etc/shorewall/policy.
    • -
  • blacklist -- - a parameter file installed in /etc/shorewall and used - to list blacklisted IP/subnet/MAC addresses.
    • -
  • functions -- a set of shell functions - used by both the firewall and shorewall shell programs. Installed - in /etc/shorewall prior to version 1.3.2, in /var/lib/shorewall -in version s 1.3.2-1.3.8 and in /usr/lib/shorewall in later versions.
    • -
  • modules --- a parameter file installed in /etc/shorewall and that - specifies kernel modules and their parameters. Shorewall will - automatically load the modules specified in this file.
    • -
  • tos -- a parameter - file installed in /etc/shorewall that is used to specify - how the Type of Service (TOS) field in packets is to be set.
    • -
  • icmp.def -- - a parameter file installed in /etc/shorewall and that -specifies the default handling of ICMP packets when the applicable -policy is DROP or REJECT.
    • -
  • common.def --- a parameter file installed in in /etc/shorewall that defines - firewall-wide rules that are applied before a DROP or REJECT - policy is applied.
    • -
  • interfaces - -- a parameter file installed in /etc/shorewall/ - and used to describe the interfaces on the firewall system.
    • -
  • hosts -- a -parameter file installed in /etc/shorewall/ and used - to describe individual hosts or subnetworks in zones.
    • -
  • maclist -- a parameter - file installed in /etc/shorewall and used to verify the MAC address - (and possibly also the IP address(es)) of devices.
    -
    • -
  • masq - This - file also describes IP masquerading under Shorewall and -is installed in /etc/shorewall.
    • -
  • firewall -- a shell - program that reads the configuration files in /etc/shorewall - and configures your firewall. This file is installed in -your init.d directory (/etc/rc.d/init.d ) where it is renamed - shorewall. /etc/shorewall/firewall (/var/lib/shorewall/firewall - in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 -and later) is a symbolic link to this program.
    • -
  • nat -- a parameter - file in /etc/shorewall used to define static - NAT .
    • -
  • proxyarp - -- a parameter file in /etc/shorewall used to define Proxy Arp .
    • -
  • rfc1918 -- -a parameter file in /etc/shorewall used to define the treatment - of packets under the norfc1918 interface - option.
    • -
  • routestopped - -- a parameter file in /etc/shorewall used to define those -hosts that can access the firewall when Shorewall is stopped.
    • -
  • tcrules - -- a parameter file in /etc/shorewall used to define rules - for classifying packets for Traffic Shaping/Control.
    • -
  • tunnels --- a parameter file in /etc/shorewall used to define IPSec - tunnels.
    • -
  • shorewall - -- a shell program (requiring a Bourne shell or - derivative) used to control and monitor the -firewall. This should be placed in /sbin or in /usr/sbin -(the install.sh script and the rpm install this file in -/sbin).
    • -
  • version -- a file created in /etc/shorewall/ - (/var/lib/shorewall in version 1.3.2-1.3.8 and /usr/lib/shorewall - beginning in version 1.3.9) that describes the version of Shorewall - installed on your system.
    • - -
- - -

/etc/shorewall/params

- - -

You may use the file /etc/shorewall/params file to set shell variables - that you can then use in some of the other configuration files.

- - -

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

- - -

Example:

- - -
 	NET_IF=eth0
	NET_BCAST=130.252.100.255
	NET_OPTIONS=blacklist,norfc1918
- -

Example (/etc/shorewall/interfaces record):

- -
	net $NET_IF $NET_BCAST $NET_OPTIONS
- -

The result will be the same as if the record had been written

- -
	net eth0 130.252.100.255 blacklist,norfc1918
- -

Variables may be used anywhere in the other configuration - files.

- - -

/etc/shorewall/zones

- - -

This file is used to define the network zones. There is one entry - in /etc/shorewall/zones for each zone; Columns in an entry -are:

    -
  • ZONE - short name for the zone. -The name should be 5 characters or less in length and consist -of lower-case letters or numbers. Short names must begin with -a letter and the name assigned to the firewall is reserved for - use by Shorewall itself. Note that the output produced by iptables -is much easier to read if you select short names that are three -characters or less in length. The name "all" may not be used as - a zone name nor may the zone name assigned to the firewall itself - via the FW variable in /etc/shorewall/shorewall.conf.
    • -
  • DISPLAY - The name of the zone -as displayed during Shorewall startup.
    • -
  • COMMENTS - Any comments that you - want to make about the zone. Shorewall ignores these comments.
    • - +
  • params + -- a parameter file installed in /etc/shorewall that can + be used to establish the values of shell variables for use +in other files.
    • +
  • shorewall.conf + -- a parameter file installed in /etc/shorewall that + is used to set several firewall parameters.
    • +
  • zones + - a parameter file installed in /etc/shorewall that defines + a network partitioning into "zones"
    • +
  • policy + -- a parameter file installed in /etc/shorewall/ that + establishes overall firewall policy.
    • +
  • rules + -- a parameter file installed in /etc/shorewall and used + to express firewall rules that are exceptions to the high-level + policies established in /etc/shorewall/policy.
    • +
  • blacklist + -- a parameter file installed in /etc/shorewall and used + to list blacklisted IP/subnet/MAC addresses.
    • +
  • ecn -- a parameter file installed in /etc/shorewall +and used to selectively disable Explicit Congestion Notification (ECN - RFC +3168).
    +
    • +
  • functions -- a set of shell + functions used by both the firewall and shorewall shell programs. + Installed in /etc/shorewall prior to version 1.3.2, in /var/lib/shorewall + in version s 1.3.2-1.3.8 and in /usr/lib/shorewall in later versions.
    • +
  • modules + -- a parameter file installed in /etc/shorewall and that + specifies kernel modules and their parameters. Shorewall will + automatically load the modules specified in this file.
    • +
  • tos -- a parameter file installed in + /etc/shorewall that is used to specify how the Type of Service + (TOS) field in packets is to be set.
    +
    • +
  • common.def + -- a parameter file installed in in /etc/shorewall that +defines firewall-wide rules that are applied before a DROP +or REJECT policy is applied.
    • +
  • interfaces + -- a parameter file installed in /etc/shorewall/ + and used to describe the interfaces on the firewall system.
    • +
  • hosts -- + a parameter file installed in /etc/shorewall/ and +used to describe individual hosts or subnetworks in zones.
    • +
  • maclist -- a +parameter file installed in /etc/shorewall and used to verify the +MAC address (and possibly also the IP address(es)) of devices.
    +
    • +
  • masq +- This file also describes IP masquerading under Shorewall + and is installed in /etc/shorewall.
    • +
  • firewall -- a shell + program that reads the configuration files in /etc/shorewall + and configures your firewall. This file is installed +in your init.d directory (/etc/rc.d/init.d ) where it +is renamed shorewall. /etc/shorewall/firewall (/var/lib/shorewall/firewall + in versions 1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 + and later) is a symbolic link to this program.
    • +
  • nat -- + a parameter file in /etc/shorewall used to define static NAT .
    • +
  • proxyarp + -- a parameter file in /etc/shorewall used to define Proxy Arp .
    • +
  • rfc1918 + -- a parameter file in /etc/shorewall used to define the treatment + of packets under the norfc1918 interface + option.
    • +
  • routestopped + -- a parameter file in /etc/shorewall used to define those + hosts that can access the firewall when Shorewall is stopped.
    • +
  • tcrules -- +a parameter file in /etc/shorewall used to define rules for classifying + packets for Traffic Shaping/Control.
    • +
  • tunnels + -- a parameter file in /etc/shorewall used to define + IPSec tunnels.
    • +
  • shorewall + -- a shell program (requiring a Bourne shell or + derivative) used to control and monitor +the firewall. This should be placed in /sbin or in /usr/sbin + (the install.sh script and the rpm install this file +in /sbin).
    • +
  • version -- a file created + in /etc/shorewall/ (/var/lib/shorewall in version + 1.3.2-1.3.8 and /usr/lib/shorewall beginning in version 1.3.9) + that describes the version of Shorewall installed + on your system.
    • +
- -

The /etc/shorewall/zones file released with Shorewall is as follows:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ZONE DISPLAY COMMENTS
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
- -

You may add, delete and modify entries in the /etc/shorewall/zones file - as desired so long as you have at least one zone defined.

+

/etc/shorewall/params

+

You may use the file /etc/shorewall/params file to set shell variables + that you can then use in some of the other configuration + files.

+ + +

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally + within the Shorewall programs

+ + +

Example:

+ + +
 	NET_IF=eth0
	NET_BCAST=130.252.100.255
	NET_OPTIONS=blacklist,norfc1918
+ +

Example (/etc/shorewall/interfaces record):

+ +
	net $NET_IF $NET_BCAST $NET_OPTIONS
+ +

The result will be the same as if the record had been written

+ +
	net eth0 130.252.100.255 blacklist,norfc1918
+ +

Variables may be used anywhere in the other configuration + files.

+ + +

/etc/shorewall/zones

+ + +

This file is used to define the network zones. There is one entry + in /etc/shorewall/zones for each zone; Columns in an entry + are:

+ + +
    +
  • ZONE - short name for the +zone. The name should be 5 characters or less in length and +consist of lower-case letters or numbers. Short names must begin + with a letter and the name assigned to the firewall is reserved +for use by Shorewall itself. Note that the output produced + by iptables is much easier to read if you select short names +that are three characters or less in length. The name "all" +may not be used as a zone name nor may the zone name assigned to + the firewall itself via the FW variable in /etc/shorewall/shorewall.conf.
    • +
  • DISPLAY - The name of the +zone as displayed during Shorewall startup.
    • +
  • COMMENTS - Any comments that + you want to make about the zone. Shorewall ignores these + comments.
    • + +
+ + +

The /etc/shorewall/zones file released with Shorewall is as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZONE DISPLAY COMMENTS
netNetInternet
locLocalLocal networks
dmzDMZDemilitarized zone
+ + +

You may add, delete and modify entries in the /etc/shorewall/zones file + as desired so long as you have at least one zone defined.

+ +

Warning 1: If you rename or delete a zone, you should perform "shorewall - stop; shorewall start" to install the change rather than "shorewall - restart".

- + stop; shorewall start" to install the change rather than + "shorewall restart".

+ +

Warning 2: The order of entries in the /etc/shorewall/zones file is - significant in some cases.

+ significant in some cases.

- +

/etc/shorewall/interfaces

- +

This file is used to tell the firewall which of your firewall's network - interfaces are connected to which zone. There will be one -entry in /etc/shorewall/interfaces for each of your interfaces. -Columns in an entry are:

- -
    -
  • ZONE - A zone defined in the /etc/shorewall/zones file or "-". If you - specify "-", you must use the /etc/shorewall/hosts - file to define the zones accessed via this interface.
    • -
  • INTERFACE - the name of the interface - (examples: eth0, ppp0, ipsec+). Each interface can be listed on - only one record in this file. DO NOT - INCLUDE THE LOOPBACK INTERFACE (lo) IN THIS FILE!!!
    • -
  • BROADCAST - the broadcast address(es) - for the sub-network(s) attached to the interface. This should - be left empty for P-T-P interfaces (ppp*, ippp*); if you need - to specify options for such an interface, enter "-" in this column. - If you supply the special value "detect" in this column, the firewall - will automatically determine the broadcast address. In order to - use "detect": + interfaces are connected to which zone. There will be one + entry in /etc/shorewall/interfaces for each of your interfaces. + Columns in an entry are:

    +
      +
    • ZONE - A zone defined in +the /etc/shorewall/zones file or + "-". If you specify "-", you must use the +/etc/shorewall/hosts file to define the zones + accessed via this interface.
      • +
    • INTERFACE - the name of the + interface (examples: eth0, ppp0, ipsec+). Each interface can + be listed on only one record in this file. DO + NOT INCLUDE THE LOOPBACK INTERFACE (lo) IN THIS FILE!!!
      • +
    • BROADCAST - the broadcast +address(es) for the sub-network(s) attached to the interface. +This should be left empty for P-T-P interfaces (ppp*, ippp*); if + you need to specify options for such an interface, enter "-" +in this column. If you supply the special value "detect" in this +column, the firewall will automatically determine the broadcast + address. In order to use "detect": + +
        -
      • you must have iproute installed
        • -
      • the interface must be up before you start -your firewall
        • -
      • the interface must only be attached to - a single sub-network (i.e., there must have a single broadcast - address).
        • +
      • the +interface must be up before you start your firewall
        • +
      • the interface must only be attached +to a single sub-network (i.e., there must have a single broadcast + address).
        • +
      -
      • -
    • OPTIONS - a comma-separated list - of options. Possible options include: +
      • +
    • OPTIONS - a comma-separated + list of options. Possible options include: - +

      tcpflags (added in version 1.3.11) - This option causes Shorewall to make sanity checks on the header flags in TCP packets arriving on this interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; these @@ -296,1099 +309,1078 @@ flag combinations are typically used for "silent" port scans. Packets failing these checks are logged according to the TCP_FLAGS_LOG_LEVEL option in /etc/shorewall/shorewall.conf and are disposed of according to the TCP_FLAGS_DISPOSITION option.
      -
      - blacklist       - This option causes incoming packets on this - interface to be checked against the
      + blacklist - This option causes incoming packets + on this interface to be checked against the       blacklist.
      -
      - dhcp       - The interface is assigned an IP address - via DHCP or is used by a DHCP server running on the firewall. - The firewall will be configured to allow DHCP traffic to and - from the interface even when the firewall is stopped. You may - also wish to use this option if you have a static IP but you are - on a LAN segment that has a lot of Laptops that use DHCP and you - select the norfc1918 option (see below).

      +
      + dhcp - The interface is assigned an +IP address via DHCP or is used by a DHCP server running +on the firewall. The firewall will be configured to allow +DHCP traffic to and from the interface even when the firewall + is stopped. You may also wish to use this option if you have a static +IP but you are on a LAN segment that has a lot of Laptops that use +DHCP and you select the norfc1918 option (see below).

      - -

      noping - This option is deprecated and is not available - when OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf. ICMP echo-request - (ping) packets addressed to the firewall will be ignored by this - interface.
      -
      - filterping - This option is deprecated - and is not available when OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf. - ICMP echo-request (ping) packets addressed to the firewall -will be handled according to the /etc/shorewall/rules and /etc/shorewall/policy - file. If the applicable policy is DROP or REJECT and you have -supplied your own /etc/shorewall/icmpdef file then these 'ping' requests - will be passed through the rules in that file before being dropped - or rejected. If neither noping nor filterping - is specified then the firewall will automatically ACCEPT these -'ping' requests. If both noping and filterping - are specified, filterping takes precedence.

      - - -

      routestopped - Beginning with Shorewall 1.3.4, this option - is deprecated in favor of the /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from - this interface will be accepted and routing will occur between -this interface and other routestopped interfaces.

      - - - -

      norfc1918 - Packets arriving on this interface and that + +

      norfc1918 - Packets arriving on this interface and that have a source address that is reserved in RFC 1918 or in other - RFCs will be dropped after being optionally logged. If packet mangling is enabled in /etc/shorewall/shorewall.conf - , then packets arriving on this interface that have a destination - address that is reserved by one of these RFCs will also be logged - and dropped.
      -
      - Addresses blocked by the standard +
      + Addresses blocked by the standard       rfc1918 file include those - addresses reserved by RFC1918 plus other ranges reserved by the - IANA or by other RFCs.

      + addresses reserved by RFC1918 plus other ranges reserved by +the IANA or by other RFCs.

      - + +

      Beware that as IPv4 addresses become in increasingly short supply, - ISPs are beginning to use RFC 1918 addresses within their -own infrastructure. Also, many cable and DSL "modems" have -an RFC 1918 address that can be used through a web browser for -management and monitoring functions. If you want to specify norfc1918 - on your external interface but need to allow access to certain -addresses from the above list, see FAQ 14.

      + ISPs are beginning to use RFC 1918 addresses within their + own infrastructure. Also, many cable and DSL "modems" have + an RFC 1918 address that can be used through a web browser for + management and monitoring functions. If you want to specify norfc1918 + on your external interface but need to allow access to certain + addresses from the above list, see FAQ +14.

      - + +

      routefilter - Invoke the Kernel's route filtering - (anti-spoofing) facility on this interface. The kernel - will reject any packets incoming on this interface that have -a source address that would be routed outbound through another - interface on the firewall. Warning: - If you specify this option for an interface then the -interface must be up prior to starting the firewall.

      + (anti-spoofing) facility on this interface. The kernel + will reject any packets incoming on this interface that have + a source address that would be routed outbound through another + interface on the firewall. Warning: + If you specify this option for an interface then the + interface must be up prior to starting the firewall.

      - -

      multi - The interface has multiple addresses and - you want to be able to route between them. Example: you - have two addresses on your single local interface eth1, one - each in subnets 192.168.1.0/24 and 192.168.2.0/24 and you want to - route between these subnets. Because you only have one interface - in the local zone, Shorewall won't normally create a rule to forward - packets from eth1 to eth1. Adding "multi" to the entry for eth1 - will cause Shorewall to create the loc2loc chain and the appropriate - forwarding rule.

      + + +

      dropunclean - Packets from this interface that + are selected by the 'unclean' match target in iptables will + be optionally logged and then dropped. + Warning: This feature + requires that UNCLEAN match support be configured in your + kernel, either in the kernel itself or as a module. UNCLEAN + support is broken in some versions of the kernel + but appears to work ok in 2.4.17-rc1.
      +
      + Update 12/17/2001:       The + unclean match patch from 2.4.17-rc1 is + available + for download. I am currently running + this patch applied to kernel 2.4.16.

      - -

      dropunclean - Packets from this interface that - are selected by the 'unclean' match target in iptables will - be optionally logged and then dropped. - Warning: This feature - requires that UNCLEAN match support be configured in your - kernel, either in the kernel itself or as a module. UNCLEAN - support is broken in some versions of the kernel -but appears to work ok in 2.4.17-rc1.
      -
      - Update 12/17/2001:       The - unclean match patch from 2.4.17-rc1 is available - for download. I am currently running this - patch applied to kernel 2.4.16.

      - - - +

      Update 12/20/2001: I've - seen a number of tcp connection requests with - OPT (020405B40000080A...) being dropped - in the badpkt chain. This appears to be - a bug in the remote TCP stack whereby it is 8-byte aligning - a timestamp (TCP option 8) but rather than padding with 0x01 - it is padding with 0x00. It's a tough call whether -to deny people access to your servers because of this - rather minor bug in their networking software. If - you wish to disable the check that causes these -connections to be dropped, 0000080A...) being + dropped in the badpkt chain. This appears to be + a bug in the remote TCP stack whereby it is 8-byte aligning + a timestamp (TCP option 8) but rather than padding +with 0x01 it is padding with 0x00. It's a tough call +whether to deny people access to your servers because + of this rather minor bug in their networking software. + If you wish to disable the check that causes +these connections to be dropped, here's a kernel patch against 2.4.17-rc2.

      - +

      logunclean - This option works like dropunclean - with the exception that packets selected by - the 'unclean' match target in iptables are logged - but not dropped. The level at which - the packets are logged is determined by the setting - of LOGUNCLEAN and if - LOGUNCLEAN has not been set, "info" is assumed.

      + with the exception that packets selected + by the 'unclean' match target in iptables +are logged but not dropped. The +level at which the packets are logged is determined by + the setting of LOGUNCLEAN +and if LOGUNCLEAN has not been set, "info" is assumed.

      - +

      proxyarp (Added in version 1.3.5) - This option causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp - and is used when implementing Proxy ARP -Sub-netting as described at - - http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do - not set this option if you are implementing Proxy -ARP through entries in - /etc/shorewall/proxyarp.
      -
      - maclist (Added in version 1.3.10) - If this - option is specified, all connection requests from this interface -are subject to MAC Verification. -May only be specified for ethernet interfaces.

      -
      • - + and is used when implementing Proxy ARP + Sub-netting as described at + + http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do + not set this option if you are implementing +Proxy ARP through entries in + /etc/shorewall/proxyarp.
      +
      + maclist (Added in version 1.3.10) - +If this option is specified, all connection requests from this +interface are subject to MAC Verification. + May only be specified for ethernet interfaces.

      + +
    - +

    My recommendations concerning options:
    -

    - +

    +
      -
    • External Interface -- tcpflags,blacklist,norfc1918,routefilter
      • -
    • Internal Interface -- routestopped
      • -
    • Wireless Interface -- maclist,routefilter,tcpflags
      -
      • -
    • Don't use dropunclean -- It's broken in my opinion
      • -
    • Use logunclean only when you are trying to debug - a problem
      • -
    • Use dhcp,multi and proxyarp when - needed.
      -
      • - +
    • External Interface -- tcpflags,blacklist,norfc1918,routefilter
      • +
    • Wireless Interface -- maclist,routefilter,tcpflags
      +
      • +
    • Don't use dropunclean -- It's broken in + my opinion
      • +
    • Use logunclean only when you are trying + to debug a problem
      • +
    • Use dhcp and proxyarp when needed.
      +
      • +
    - +

    - +

    Example 1: You have a conventional firewall setup in which eth0 connects - to a Cable or DSL modem and eth1 connects to your local network - and eth0 gets its IP address via DHCP. You want to check all -packets entering from the internet against the -black list. Your /etc/shorewall/interfaces file - would be as follows:

    + to a Cable or DSL modem and eth1 connects to your local +network and eth0 gets its IP address via DHCP. You want to +check all packets entering from the internet + against the black list. Your /etc/shorewall/interfaces + file would be as follows:

    - +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918,blacklist
    loceth1detect
    -
    -
    - - -

    Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    netppp0
    -
    -
    -
    - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918,blacklist
    loceth1detect
    +
    + + + +

    Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces + file would be:

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE INTERFACE BROADCAST OPTIONS
    netppp0
    +
    +
    +
    + +

    Example 3: You have local interface eth1 with two IP addresses - 192.168.1.1/24 and 192.168.12.1/24

    - +
    - + - - - - - - - - - - + + + + + + + + + + - - - + + + - - + + - +
    ZONE INTERFACE BROADCAST OPTIONS
    loceth1
    ZONE INTERFACE BROADCAST OPTIONS
    loceth1192.168.1.255,192.168.12.255
    -
    192.168.1.255,192.168.12.255
    +
    -
    + - +

    /etc/shorewall/hosts - Configuration

    + Configuration - +

    For most applications, specifying zones entirely in terms of network interfaces is sufficient. There may be times though where you need to define a zone to be a more general collection of hosts. This is the purpose of the /etc/shorewall/hosts file.

    - +

    WARNING: 90% of Shorewall users don't need to put entries in this file and 80% of those who try to add such entries do it wrong. Unless you are ABSOLUTELY SURE that you need entries in this file, don't touch it.

    - +

    Columns in this file are:

    - +
      -
    • ZONE - A zone defined in the /etc/shorewall/zones file.
      • -
    • HOST(S) - The name of a network -interface followed by a colon (":") followed by either:
      • - +
    • ZONE - A zone defined in +the /etc/shorewall/zones file.
      • +
    • HOST(S) - The name of a network + interface followed by a colon (":") followed by either:
      • +
    - +
    - +
      -
    1. An IP address (example - eth1:192.168.1.3)
      2. +
    2. An IP address (example + - eth1:192.168.1.3)
      3. -
    3. A subnet in CIDR notation - (example - eth2:192.168.2.0/24)
      4. +
    4. A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
      5. - +
    - +

    The interface name much match an entry in /etc/shorewall/interfaces.

    -
    + - -
      -
    • OPTIONS - A comma-separated list - of options.
      • - -
    - - -
    - - -

    routestopped - Beginning with Shorewall - 1.3.4, this option is deprecated in favor of the - /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will - occur between this host and other routestopped interfaces - and hosts.
    -
    - maclist - Added in version 1.3.10. If specified, - connection requests from the hosts specified in this entry are subject - to MAC Verification. This option is only - valid for ethernet interfaces.
    -

    -
    - - -

    If you don't define any hosts for a zone, the hosts in the zone default - to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are -the interfaces to the zone.

    - - -

    Note 1: You probably -DON'T want to specify any hosts for your internet zone since the hosts -that you specify will be the only ones that you will be able to access -without adding additional rules.

    - - -

    Note 2: - The setting of the MERGE_HOSTS variable - in /etc/shorewall/shorewall.conf - has an important effect on how the -host file is processed. Please read the -description of that variable carefully.

    - - -

    Example:

    - - -

    Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:

    - - -
      -
    • 192.168.1.0/25
      • -
    • 192.168.1.128/25
      • - -
    - - -

    Your /etc/shorewall/interfaces file might look like:

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    -eth1detect
    -
    -
    - - -

    The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces - to multiple zones.

    - - -

    Your /etc/shorewall/hosts file might look like:

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE HOST(S) OPTIONS
    loc1eth1:192.168.1.0/25
    -
    loc2eth1:192.168.1.128/25routestopped
    -
    - - -

    Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.

    - - -

    Nested and Overlapping -Zones

    - - -

    The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow - you to define nested or overlapping zones. Such overlapping/nested zones - are allowed and Shorewall processes zones in the order that - they appear in the /etc/shorewall/zones file. So if you have nested - zones, you want the sub-zone to appear before the super-zone -and in the case of overlapping zones, the rules that will apply -to hosts that belong to both zones is determined by which zone appears -first in /etc/shorewall/zones.

    - - -

    Hosts that belong to more than one zone may be managed by the rules - of all of those zones. This is done through use of the special - CONTINUE policy described below.

    - - -

    - /etc/shorewall/policy Configuration.

    - - -

    This file is used to describe the firewall policy regarding establishment - of connections. Connection establishment is described in terms - of clients who initiate connections and servers who - receive those connection requests. Policies defined in /etc/shorewall/policy - describe which zones are allowed to establish connections with - other zones.

    - - - -

    Policies established in /etc/shorewall/policy can be viewed as default - policies. If no rule in /etc/shorewall/rules applies to a -particular connection request then the policy from /etc/shorewall/policy - is applied.

    - - - -

    Four policies are defined:

    - -
      -
    • ACCEPT - The connection is allowed.
      • -
    • DROP - The connection request is - ignored.
      • -
    • REJECT - The connection request -is rejected with an RST (TCP) or an ICMP destination-unreachable - packet being returned to the client.
      • -
    • CONTINUE - The connection is neither - ACCEPTed, DROPped nor REJECTed. CONTINUE may be used when one - or both of the zones named in the entry are sub-zones of -or intersect with another zone. For more information, see below. -
      • - +
    • OPTIONS - A comma-separated + list of option
      • +
    -

    For each policy specified in /etc/shorewall/policy, you can indicate - that you want a message sent to your system log each time -that the policy is applied.

    - - -

    Entries in /etc/shorewall/policy have four columns as follows:

    - - -
      - -
    1. SOURCE - - The name of a client zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all").
      2. - -
    2. DEST -- The name of a destination zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all"). Shorewall automatically - allows all traffic from the firewall to itself so the name of the firewall zone cannot appear in both the - SOURCE and DEST columns.
      3. - -
    3. POLICY - - The default policy for connection requests from the SOURCE - zone to the DESTINATION zone.
      4. - -
    4. LOG LEVEL - - Optional. If left empty, no log message is generated when - the policy is applied. Otherwise, this column should contain an -integer or name indicating a syslog level.
      5. - -
    5. LIMIT:BURST - - Optional. If left empty, TCP connection requests from -the SOURCE zone to the DEST zone will not -be rate-limited. Otherwise, this column specifies the maximum rate -at which TCP connection requests will be accepted followed by a -colon (":") followed by the maximum burst size that will be tolerated. -Example: 10/sec:40 specifies that the maximum rate of -TCP connection requests allowed will be 10 per second and a burst -of 40 connections will be tolerated. Connection requests in excess -of these limits will be dropped.
      6. - - -
    - - -

    In the SOURCE and DEST columns, you can enter "all" to indicate all - zones.

    - - -

    The policy file installed by default is as follows:

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    -
    -
    netallDROPinfo
    -
    allallREJECTinfo
    -
    -
    - - - -

    This table may be interpreted as follows:

    - - -
      -
    • All connection requests from the local network - to hosts on the internet are accepted.
      • -
    • All connection requests originating from -the internet are ignored and logged at level KERNEL.INFO.
      • -
    • All other connection requests are rejected - and logged.
      • - -
    - - -

    WARNING:

    - - -

    The firewall script processes the - /etc/shorewall/policy file from top to bottom and uses -the first applicable policy that it finds. For example, -in the following policy file, the policy for (loc, loc) connections -would be ACCEPT as specified in the first entry even though the -third entry in the file specifies REJECT.

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
    -
    +

    maclist - Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to + MAC Verification. This option is only + valid for ethernet interfaces.
    +

    + - -
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    -
    -
    netallDROPinfo
    -
    loclocREJECTinfo
    -
    -
    - -

    - The CONTINUE policy

    + +

    If you don't define any hosts for a zone, the hosts in the zone default + to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are + the interfaces to the zone.

    - -

    Where zones are nested or overlapping , the - CONTINUE policy allows hosts that are within multiple zones to - be managed under the rules of all of these zones. Let's look at -an example:

    - -

    /etc/shorewall/zones:

    + +

    Note: You probably DON'T + want to specify any hosts for your internet zone since the hosts that +you specify will be the only ones that you will be able to access without +adding additional rules.

    + + + + +

    Example:

    + + +

    Your local interface is eth1 and you have two groups of local hosts that + you want to make into separate zones:

    + + +
      +
    • 192.168.1.0/25
      • +
    • 192.168.1.128/25
      • + +
    + + +

    Your /etc/shorewall/interfaces file might look like:

    + -
    - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    -
    - - -

    /etc/shorewall/interfaces:

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ZONE INTERFACE BROADCAST OPTIONS
    -eth0detectdhcp,norfc1918
    loceth1detectroutestopped
    -
    - - -

    /etc/shorewall/hosts:

    - - -
    - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - +
    ZONE HOST(S) OPTIONS
    neteth0:0.0.0.0/0
    -
    sameth0:206.191.149.197routestopped
    ZONE INTERFACE BROADCAST OPTIONS
    neteth0detectdhcp,norfc1918
    -eth1detect
    +
    -
    + - -

    Note that Sam's home system is a member of both the sam zone - and the net zone - and as described above , that means that -sam must be listed before net in /etc/shorewall/zones.

    - -

    /etc/shorewall/policy:

    + +

    The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.

    - -
    - + + +

    Your /etc/shorewall/hosts file might look like:

    + + + +
    + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + +
    SOURCE DEST POLICY LOG LEVEL
    locnetACCEPT
    -
    samallCONTINUE
    -
    netallDROPinfo
    allallREJECTinfo
    ZONE HOST(S) OPTIONS
    loc1eth1:192.168.1.0/25
    +
    loc2eth1:192.168.1.128/25
    +
    -
    +
    - -

    The second entry above says that when Sam is the client, connection - requests should first be process under rules where the source - zone is sam and if there is no match then the connection -request should be treated under rules where the source zone is -net. It is important that this policy be listed BEFORE -the next policy (net to all).

    - -

    Partial /etc/shorewall/rules:

    - -
    - + + +

    Nested and Overlapping +Zones

    + + + +

    The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow + you to define nested or overlapping zones. Such overlapping/nested zones + are allowed and Shorewall processes zones in the order that + they appear in the /etc/shorewall/zones file. So if you have + nested zones, you want the sub-zone to appear before the super-zone + and in the case of overlapping zones, the rules that will apply + to hosts that belong to both zones is determined by which zone +appears first in /etc/shorewall/zones.

    + + + +

    Hosts that belong to more than one zone may be managed by the rules + of all of those zones. This is done through use of the special + CONTINUE policy described below.

    + + + +

    + /etc/shorewall/policy Configuration.

    + + +

    This file is used to describe the firewall policy regarding establishment + of connections. Connection establishment is described in +terms of clients who initiate connections and servers +who receive those connection requests. Policies defined +in /etc/shorewall/policy describe which zones are allowed +to establish connections with other zones.

    + + + +

    Policies established in /etc/shorewall/policy can be viewed as default + policies. If no rule in /etc/shorewall/rules applies to +a particular connection request then the policy from /etc/shorewall/policy + is applied.

    + + + +

    Four policies are defined:

    + + +
      +
    • ACCEPT - The connection is + allowed.
      • +
    • DROP - The connection request + is ignored.
      • +
    • REJECT - The connection request + is rejected with an RST (TCP) or an ICMP destination-unreachable + packet being returned to the client.
      • +
    • CONTINUE - The connection + is neither ACCEPTed, DROPped nor REJECTed. CONTINUE may +be used when one or both of the zones named in the entry are + sub-zones of or intersect with another zone. For more information, + see below.
      • + +
    + + + +

    For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time + that the policy is applied.

    + + + +

    Entries in /etc/shorewall/policy have four columns as follows:

    + + + +
      + +
    1. SOURCE + - The name of a client zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all").
      2. + +
    2. DEST + - The name of a destination zone (a zone defined in the /etc/shorewall/zones file , the name of the firewall zone or "all"). Shorewall automatically + allows all traffic from the firewall to itself so the name of the firewall zone cannot appear in both the + SOURCE and DEST columns.
      3. + +
    3. POLICY + - The default policy for connection requests from the SOURCE + zone to the DESTINATION zone.
      4. + +
    4. LOG + LEVEL - Optional. If left empty, no log message is generated + when the policy is applied. Otherwise, this column should contain + an integer or name indicating a syslog level.
      5. + +
    5. LIMIT:BURST + - Optional. If left empty, TCP connection requests + from the SOURCE zone to the DEST zone will + not be rate-limited. Otherwise, this column specifies the maximum + rate at which TCP connection requests will be accepted followed + by a colon (":") followed by the maximum burst size that will be + tolerated. Example: 10/sec:40 specifies that the maximum + rate of TCP connection requests allowed will be 10 per second and + a burst of 40 connections will be tolerated. Connection requests +in excess of these limits will be dropped.
      6. + + + +
    + + + +

    In the SOURCE and DEST columns, you can enter "all" to indicate all + zones.

    + + + +

    The policy file installed by default is as follows:

    + + + +
    + + - + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - +
    SOURCEDEST POLICY LOG LEVELLIMIT:BURST
    locnetACCEPT
    +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ...
    -
    -
    -
    -
    -
    -
    DNATsamloc:192.168.1.3tcpssh-
    -
    DNATnetloc:192.168.1.5tcpwww-
    -
    ...
    -
    -
    -
    -
    -
    -

    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    +
    + + + +

    This table may be interpreted as follows:

    + + +
      +
    • All connection requests from the local + network to hosts on the internet are accepted.
      • +
    • All connection requests originating +from the internet are ignored and logged at level KERNEL.INFO.
      • +
    • All other connection requests are rejected + and logged.
      • + +
    -

    Given these two rules, Sam can connect to the firewall's internet interface - with ssh and the connection request will be forwarded to 192.168.1.3. - Like all hosts in the net zone, Sam can connect to the -firewall's internet interface on TCP port 80 and the connection -request will be forwarded to 192.168.1.5. The order of the rules -is not significant.

    +

    WARNING:

    - -

    Sometimes it is necessary to suppress port forwarding - for a sub-zone. For example, suppose that all hosts can SSH - to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When - Sam connects to the firewall's external IP, he should be connected - to the firewall itself. Because of the way that Netfilter is constructed, - this requires two rules as follows:

    + +

    The firewall script processes the + /etc/shorewall/policy file from top to bottom and uses + the first applicable policy that it finds. For example, + in the following policy file, the policy for (loc, loc) connections + would be ACCEPT as specified in the first entry even though the + third entry in the file specifies REJECT.

    - -
    - -

    - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
    locallACCEPT
    +
    +
    netallDROPinfo
    +
    loclocREJECTinfo
    +
    +
    + + +

    + The CONTINUE policy

    + + +

    Where zones are nested or overlapping , the + CONTINUE policy allows hosts that are within multiple zones + to be managed under the rules of all of these zones. Let's look + at an example:

    + + +

    /etc/shorewall/zones:

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE DISPLAY COMMENTS
    samSamSam's system at home
    netInternetThe Internet
    locLocLocal Network
    +
    + + +

    /etc/shorewall/interfaces:

    + + +
    + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - + + - + +

    -
    -
    -
    -
    -
    -
    -
    ...
    -
    -
    -
    -
    -
    -
    DNATsamfwtcpssh-
    -
    DNATnet!samloc:192.168.1.3tcpssh-
    -
    ...
    -
    -
    -
    -
    -
    -
    ZONE INTERFACE BROADCAST OPTIONS
    -eth0detectdhcp,norfc1918
    loceth1detect
    +
    -
    + + + +

    /etc/shorewall/hosts:

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZONE HOST(S) OPTIONS
    neteth0:0.0.0.0/0
    +
    sameth0:206.191.149.197
    +
    +
    + + +

    Note that Sam's home system is a member of both the sam zone + and the net + zone and as described above , that means + that sam must be listed before net in /etc/shorewall/zones.

    + + +

    /etc/shorewall/policy:

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SOURCE DEST POLICY LOG LEVEL
    locnetACCEPT
    +
    samallCONTINUE
    +
    netallDROPinfo
    allallREJECTinfo
    +
    + + +

    The second entry above says that when Sam is the client, connection + requests should first be process under rules where the source + zone is sam and if there is no match then the connection + request should be treated under rules where the source zone is + net. It is important that this policy be listed BEFORE +the next policy (net to all).

    + + +

    Partial /etc/shorewall/rules:

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ...
    +
    +
    +
    +
    +
    +
    DNATsamloc:192.168.1.3tcpssh-
    +
    DNATnetloc:192.168.1.5tcpwww-
    +
    ...
    +
    +
    +
    +
    +
    +
    +
    + + +

    Given these two rules, Sam can connect to the firewall's internet interface + with ssh and the connection request will be forwarded to +192.168.1.3. Like all hosts in the net zone, Sam can +connect to the firewall's internet interface on TCP port 80 +and the connection request will be forwarded to 192.168.1.5. The +order of the rules is not significant.

    + + +

    Sometimes it is necessary to suppress port forwarding + for a sub-zone. For example, suppose that all hosts can +SSH to the firewall and be forwarded to 192.168.1.5 EXCEPT +Sam. When Sam connects to the firewall's external IP, he should +be connected to the firewall itself. Because of the way that Netfilter + is constructed, this requires two rules as follows:

    + + +
    + +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST

    +
    +
    +
    +
    +
    +
    +
    ...
    +
    +
    +
    +
    +
    +
    DNATsamfwtcpssh-
    +
    DNATnet!samloc:192.168.1.3tcpssh-
    +
    ...
    +
    +
    +
    +
    +
    +
    +
    + +

    The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the @@ -1397,478 +1389,489 @@ is not significant.

    connection port forwarded to 192.168.1.3. If you need to exclude more than one zone in this way, - you can list the -zones separated by - commas (e.g., net!sam,joe,fred). - This technique also may be used when - the ACTION is REDIRECT.

    + you can list +the zones separated by + commas (e.g., net!sam,joe,fred). + This technique also may be used when + the ACTION is REDIRECT.

    - +

    /etc/shorewall/rules

    - +

    The /etc/shorewall/rules file defines exceptions to the policies established - in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules - for each of these rules.
    -

    - + in the /etc/shorewall/policy file. There is one entry in + /etc/shorewall/rules for each of these rules.
    +

    +

    Shorewall automatically enables firewall->firewall traffic over the - loopback interface (lo) -- that traffic cannot be regulated using -rules and any rule that tries to regulate such traffic will generate -a warning and will be ignored.
    -

    + loopback interface (lo) -- that traffic cannot be regulated using + rules and any rule that tries to regulate such traffic will generate + a warning and will be ignored.
    +

    - +

    Entries in the file have the following columns:

    - +
      -
    • ACTION +
    • ACTION - +
        -
      • ACCEPT, DROP or REJECT. These have the -same meaning here as in the policy file above.
        • -
      • DNAT -- Causes the connection request to - be forwarded to the system specified in the DEST column -(port forwarding). "DNAT" stands for "Destination Network - Address Translation"
        • -
      • DNAT- -- The above ACTION (DNAT) generates two iptables - rules: 1) and header-rewriting rule in the Netfilter 'nat' table and; - 2) an ACCEPT rule in the Netfilter 'filter' table. DNAT- works like DNAT - but only generates the header-rewriting rule.
        -
        • -
      • REDIRECT -- Causes the connection request - to be redirected to a port on the local (firewall) system.
        • +
      • ACCEPT, DROP, REJECT, CONTINUE. These + have the same meaning here as in the policy file above.
        • +
      • DNAT -- Causes the connection request + to be forwarded to the system specified in the DEST column + (port forwarding). "DNAT" stands for "Destination + Network Address Translation"
        • +
      • DNAT- -- The above ACTION (DNAT) generates two + iptables rules: 1) and header-rewriting rule in the Netfilter 'nat' + table and; 2) an ACCEPT rule in the Netfilter 'filter' table. DNAT- + works like DNAT but only generates the header-rewriting rule.
        +
        • +
      • REDIRECT -- Causes the connection +request to be redirected to a port on the local (firewall) +system.
        • +
      • LOG - Log the packet -- requires a syslog level (see below).
        • - +
      - +

      The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info). This causes the packet to be logged at the specified level prior -to being processed according to the specified ACTION.
      -
      - The use of DNAT or REDIRECT requires that you -have NAT enabled.
      -

      -
      • -
    • SOURCE - Describes the source hosts -to which the rule applies.. The contents of this field must begin - with the name of a zone defined in /etc/shorewall/zones, $FW - or "all". If the ACTION is DNAT or REDIRECT, sub-zones may be excluded - from the rule by following the initial zone name with "!' and -a comma-separated list of those sub-zones to be excluded. There - is an example above.
      -
      - If the source is not 'all' then the source may - be further restricted by adding a colon (":") followed by a - comma-separated list of qualifiers. Qualifiers are may include: - - -
        -
      • An interface name - refers to any connection - requests arriving on the specified interface (example - loc:eth4). Beginning with Shorwall 1.3.9, the interface name may optionally - be followed by a colon (":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, - net:eth0:192.0.2.0/24).
        • -
      • An IP address - refers to a connection -request from the host with the specified address (example -net:155.186.235.151). If the ACTION is DNAT, this must not be a -DNS name.
        • -
      • A MAC Address in Shorewall - format.
        • -
      • A subnet - refers to a connection request - from any host in the specified subnet (example net:155.186.235.0/24).
        • - - - -
      -
      • -
    • DEST - Describes the destination host(s) - to which the rule applies. May take any of the forms described - above for SOURCE plus the following two additional forms: - - -
        -
      • An IP address followed by a colon and the - port number that the server is listening - on (service names from /etc/services are not allowed -- example loc:192.168.1.3:80).
        -
        • -
      • A single port number (again, service names - are not allowed) -- this form is only allowed if the ACTION - is REDIRECT and refers to a server running on the firewall itself - and listening on the specified port.
        -
        • - - - -
      -
      • -
    • PROTO - Protocol. Must be a protocol - name from /etc/protocols, a number, "all" or "related". -Specifies the protocol of the connection request. "related" -should be specified only if you have given ALLOWRELATED="no" in /etc/shorewall/shorewall.conf - and you wish to override that setting for related connections - originating with the client(s) and server(s) specified in - this rule. When "related" is given for the protocol, the remainder - of the columns should be left blank.
      • -
    • DEST PORT(S) - Port or port -range (<low port>:<high port>) being connected to. -May only be specified if the protocol is tcp, udp or icmp. -For icmp, this column's contents are interpreted as an icmp -type. If you don't want to specify DEST PORT(S) but need to -include information in one of the columns to the right, enter - "-" in this column. You may give a list of ports and/or port ranges - separated by commas. Port numbers may be either integers or service -names from /etc/services.
      • -
    • SOURCE PORTS(S) - May be - used to restrict the rule to a particular client port or port - range (a port range is specified as <low port number>:<high - port number>). If you don't want to restrict client ports but - want to specify something in the next column, enter "-" in this column. - If you wish to specify a list of port number or ranges, separate - the list elements with commas (with no embedded white space). Port - numbers may be either integers or service names from /etc/services.
      • -
    • ORIGINAL DEST - This column may only - be non-empty if the ACTION is DNAT or REDIRECT.
      -
      - If DNAT or REDIRECT is the ACTION and the ORIGINAL - DEST column is left empty, any connection request arriving -at the firewall from the SOURCE that matches the rule will be -forwarded or redirected. This works fine for connection requests -arriving from the internet where the firewall has only a single - external IP address. When the firewall has multiple external -IP addresses or when the SOURCE is other than the internet, there -will usually be a desire for the rule to only apply to those connection - requests directed to a particular IP address (see Example 2 -below for another usage). That IP address (or a comma-separated - list of such addresses) is specified in the ORIGINAL DEST column.
      -
      - The IP address may be optionally followed by -":" and a second IP address. This latter address, if present, -is used as the source address for packets forwarded to the server -(This is called "Source NAT" or SNAT).
      - -
      - - Note: When using SNAT, it is a good -idea to qualify the source with an IP address or subnet. Otherwise, it -is likely that SNAT will occur on connections other than those described -in the rule. The reason for this is that SNAT occurs in the Netfilter -POSTROUTING hook where it is not possible to restrict the scope of a -rule by incoming interface.
      -
      -       Example: DNAT loc:192.168.1.0/24 - loc:192.168.1.3 tcp www - 206.124.146.179:192.168.1.3
      +to being processed according to the specified ACTION. Note: if the +ACTION is LOG then you MUST specify a syslog level.

      -       If SNAT is not used (no ":" and second - IP address), the original source address is used. If you -want any destination address to match the rule but want to -specify SNAT, simply use a colon followed by the SNAT address.
      • - + The use of DNAT or REDIRECT requires that + you have NAT enabled.
      +

      + +
    • SOURCE - Describes the source +hosts to which the rule applies.. The contents of this field +must begin with the name of a zone defined in /etc/shorewall/zones, + $FW or "all". If the ACTION is DNAT or REDIRECT, sub-zones may + be excluded from the rule by following the initial zone name with + "!' and a comma-separated list of those sub-zones to be excluded. + There is an example above.
      +
      + If the source is not 'all' then the source + may be further restricted by adding a colon (":") followed +by a comma-separated list of qualifiers. Qualifiers are may + include: + + +
        +
      • An interface name - refers to any +connection requests arriving on the specified interface +(example loc:eth4). Beginning with Shorwall 1.3.9, the interface +name may optionally be followed by a colon (":") and an IP address or +subnet (examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).
        • +
      • An IP address - refers to a connection + request from the host with the specified address +(example net:155.186.235.151). If the ACTION is DNAT, this must +not be a DNS name.
        • +
      • A MAC Address in Shorewall + format.
        • +
      • A subnet - refers to a connection +request from any host in the specified subnet (example +net:155.186.235.0/24).
        • + + + +
      +
      • +
    • DEST - Describes the destination + host(s) to which the rule applies. May take most of the forms + described above for SOURCE plus the following two additional + forms: + + +
        +
      • An IP address followed by a colon +and the port number that the server +is listening on (service names from /etc/services are not + allowed - example loc:192.168.1.3:80).
        +
        • +
      • A single port number (again, service + names are not allowed) -- this form is only allowed if + the ACTION is REDIRECT and refers to a server running on the firewall + itself and listening on the specified port.
        • + + + +
      +Restrictions:
      +
        +
      • MAC addresses may not be specified.
        • +
      • In DNAT rules, only an IP address may be given -- DNS names are +not permitted.
        • +
      • You may not specify both an IP address and an interface name in +the DEST column.
        +
        • +
      +
      • +
    • PROTO - Protocol. Must be +a protocol name from /etc/protocols, a number or "all". + Specifies the protocol of the connection request.
      • +
    • DEST PORT(S) - Port or +port range (<low port>:<high port>) being connected +to. May only be specified if the protocol is tcp, udp or +icmp. For icmp, this column's contents are interpreted as +an icmp type. If you don't want to specify DEST PORT(S) but need + to include information in one of the columns to the right, + enter "-" in this column. You may give a list of ports and/or port +ranges separated by commas. Port numbers may be either integers +or service names from /etc/services.
      • +
    • SOURCE PORTS(S) - +May be used to restrict the rule to a particular client port +or port range (a port range is specified as <low port number>:<high + port number>). If you don't want to restrict client ports but + want to specify something in the next column, enter "-" in this column. + If you wish to specify a list of port number or ranges, separate + the list elements with commas (with no embedded white space). +Port numbers may be either integers or service names from /etc/services.
      • +
    • ORIGINAL DEST - This column +may only be non-empty if the ACTION is DNAT or REDIRECT.
      +
      + If DNAT or REDIRECT is the ACTION and the + ORIGINAL DEST column is left empty, any connection request + arriving at the firewall from the SOURCE that matches the rule + will be forwarded or redirected. This works fine for connection + requests arriving from the internet where the firewall has +only a single external IP address. When the firewall has multiple + external IP addresses or when the SOURCE is other than the internet, + there will usually be a desire for the rule to only apply to those + connection requests directed to a particular IP address (see + Example 2 below for another usage). That IP address (or a comma-separated + list of such addresses) is specified in the ORIGINAL DEST column.
      +
      + The IP address may be optionally followed + by ":" and a second IP address. This latter address, if present, + is used as the source address for packets forwarded to the +server (This is called "Source NAT" or SNAT).
      + +
      + + Note: When using SNAT, it +is a good idea to qualify the source with an IP address or subnet. +Otherwise, it is likely that SNAT will occur on connections other than +those described in the rule. The reason for this is that SNAT occurs in + the Netfilter POSTROUTING hook where it is not possible to restrict +the scope of a rule by incoming interface.
      +
      +       Example: DNAT loc:192.168.1.0/24 + loc:192.168.1.3 tcp www - 206.124.146.179:192.168.1.3
      +
      +       If SNAT is not used (no ":" and + second IP address), the original source address is used. + If you want any destination address to match the rule but want + to specify SNAT, simply use a colon followed by the SNAT address.
      • +
    - +

    Example 1. You wish to forward all - ssh connection requests from the internet to local system -192.168.1.3.

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    DNATnetloc:192.168.1.3tcpssh
    -
    -
    -
    - - -

    Example 2. You want to redirect all local www connection requests - EXCEPT those -to your own http server - (206.124.146.177) to a Squid - transparent proxy running on the firewall and -listening on port 3128. Squid will of course require access to -remote web servers. This example shows yet - another use for the ORIGINAL - DEST column; here, connection - requests that were NOT - - (notice the "!") originally - destined to 206.124.146.177 - are redirected to local - port 3128.

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc3128tcpwww -
    -     		!206.124.146.177
    ACCEPTfwnettcpwww
    -
    -
    -
    - - -

    Example 3. You want to run a web server at 155.186.235.222 in -your DMZ and have it accessible remotely and locally. the DMZ is managed - by Proxy ARP or by classical sub-netting.

    + ssh connection requests from the internet to local system + 192.168.1.3.

    -
    - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACCEPTnetdmz:155.186.235.222tcpwww-
    -
    ACCEPTlocdmz:155.186.235.222tcpwww
    -
    -
    -
    - - -

    Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded - DMZ. Your internet interface address is 155.186.235.151 and - you want the FTP server to be accessible from the internet in -addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24 -subnetworks. Note that since the server is in the 192.168.2.0/24 subnetwork, - we can assume that access to the server from that subnet will not -involve the firewall (but see FAQ 2). -Note that unless you - have more than one external - IP address, you can leave - the ORIGINAL DEST column - blank in the first rule. You - cannot leave it blank in the - second rule though because - then all ftp connections - originating in the -local subnet 192.168.1.0/24 - would be sent to 192.168.2.2 - regardless of -the site that the -user was trying to - connect to. That is - clearly not what you want - - .

    - - -
    - - - + - - - - - - - + + + + + + + - - - - - - - - - - - - - - - - - - + + + + + + + + + - +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST    		ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    DNATnetdmz:192.168.2.2tcpftp
    -
    -
    DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
    DNATnetloc:192.168.1.3tcpssh
    +
    +
    -
    + + + +

    Example 2. You want to redirect all local www connection requests + EXCEPT those + to your own http server + (206.124.146.177) to a Squid + transparent proxy running on the firewall +and listening on port 3128. Squid will of course require access +to remote web servers. This example shows yet + another use for the ORIGINAL + DEST column; here, connection + requests that were NOT + +(notice the "!") originally + destined to 206.124.146.177 are + redirected to local port 3128.

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - -

    If you are running wu-ftpd, you should restrict the range of passive - in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions - so I use port range 65500-65535. In /etc/ftpaccess, this entry - is appropriate:

    - -
    + +
    + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    REDIRECTloc3128tcpwww -
    +     		!206.124.146.177
    ACCEPTfwnettcpwww
    +
    +
    +
    + + +

    Example 3. You want to run a web server at 155.186.235.222 in +your DMZ and have it accessible remotely and locally. the DMZ is managed + by Proxy ARP or by classical sub-netting.

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -

    passive ports 0.0.0.0/0 65500 65534

    +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTnetdmz:155.186.235.222tcpwww-
    +
    ACCEPTlocdmz:155.186.235.222tcpwww
    +
    +
    +
    + + +

    Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded + DMZ. Your internet interface address is 155.186.235.151 + and you want the FTP server to be accessible from the internet + in addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24 + subnetworks. Note that since the server is in the 192.168.2.0/24 + subnetwork, we can assume that access to the server from that subnet + will not involve the firewall (but see FAQ + 2). Note that unless you + have more than one external + IP address, you can leave + the ORIGINAL DEST column + blank in the first rule. You + cannot leave it blank +in the second rule though + because then all +ftp connections + originating in the local + subnet 192.168.1.0/24 would + be sent to 192.168.2.2 + regardless of the site that + the user was trying to + connect to. That is + clearly not what you +want + .

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    DNATnetdmz:192.168.2.2tcpftp
    +
    +
    DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
    - + +

    If you are running wu-ftpd, you should restrict the range of passive + in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions + so I use port range 65500-65535. In /etc/ftpaccess, this + entry is appropriate:

    + + + + +
    + + + +

    passive ports 0.0.0.0/0 65500 65534

    +
    + + + +

    If you are running pure-ftpd, you would include "-p 65500:65534" on - the pure-ftpd runline.

    + the pure-ftpd runline.

    - +

    The important point here is to ensure that the port range used for FTP - passive connections is unique and will not overlap with any -usage on the firewall system.

    + passive connections is unique and will not overlap with +any usage on the firewall system.

    - +

    Example 5. You wish to allow unlimited DMZ access to the host @@ -1877,54 +1880,110 @@ usage on the firewall system.

    - +
    - + - - - - - - - - - + + + + + + + + + - - - - - - - - - - + + + + + + + + + + - + - +
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    ACCEPTloc:~02-00-08-E3-FA-55dmzall
    -
    -
    -
    ACCEPTloc:~02-00-08-E3-FA-55dmzall
    +
    +
    +
    -
    + - Example -6. You wish to allow access to the SMTP server in your DMZ from -all zones.
    - -
    + Example + 6. You wish to allow access to the SMTP server in your DMZ +from all zones.
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(S)
    +     		SOURCE
    + PORT(S)
    +     		ORIGINAL
    + DEST
    +
    ACCEPT
    +     		all
    +     		dmz
    +     		tcp
    +     		25
    +
    +
    +
    +
    + Note: When 'all' is used as a source or destination, + intra-zone traffic is not affected. In this example, if there were + two DMZ interfaces then the above rule would NOT enable SMTP traffic + between hosts on these interfaces.
    +
    + Example 7 (For advanced users running Shorewall version + 1.3.13 or later). From the internet, you with to forward tcp +port 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 +in your DMZ. You also want to allow access from the internet directly +to tcp port 25 on 192.0.2.177.
    + +
    @@ -1937,21 +1996,53 @@ all zones.
    + + + + + + + + + + + + + + + + + + - - @@ -1963,111 +2054,25 @@ all zones.
    - - + +
    PROTO
    		 DEST
    - PORT(S)
    + PORT(S)
    		 SOURCE
    - PORT(S)
    + PORT(S)
    		 ORIGINAL
    - DEST
    + DEST
    DNAT-
    +     		net
    +     		dmz:192.0.2.177
    +     		tcp
    +     		25
    +     		0
    +     		192.0.2.178
    +
    DNAT-
    +     		net
    +     		dmz:192.0.2.177
    +     		tcp
    +     		25
    +     		0
    +     		192.0.2.179
    +
    ACCEPT
    		all
    +     		net
    		dmz
    +     		dmz:192.0.2.177
    		 tcp
    -
    - Note: When 'all' is used as a source or destination, intra-zone - traffic is not affected. In this example, if there were two DMZ interfaces - then the above rule would NOT enable SMTP traffic between hosts on -these interfaces.
    -
    - Example 7 (For advanced users running Shorewall version 1.3.13 - or later). From the internet, you with to forward tcp port 25 directed - to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You -also want to allow access from the internet directly to tcp port 25 on -192.0.2.177.
    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DEST
    -     		PROTO
    -     		DEST
    - PORT(S)
    -     		SOURCE
    - PORT(S)
    -     		ORIGINAL
    - DEST
    -
    DNAT-
    -     		net
    -     		dmz:192.0.2.177
    -     		tcp
    -     		25
    -     		0
    -     		192.0.2.178
    -
    DNAT-
    -     		net
    -     		dmz:192.0.2.177
    -     		tcp
    -     		25
    -     		0
    -     		192.0.2.179
    -
    ACCEPT
    -     		net
    -     		dmz:192.0.2.177
    -     		tcp
    -     		25
    -
    -
    -
    -
    - Using "DNAT-" rather than "DNAT" avoids two extra copies of the - third rule from being generated.
    - +
    + Using "DNAT-" rather than "DNAT" avoids two extra copies + of the third rule from being generated.
    +

    Look here for information on other services.

    - +

    /etc/shorewall/common

    - +

    Shorewall allows definition of rules that apply between all zones. @@ -2077,198 +2082,209 @@ also want to allow access from the internet directly to tcp port 25 on but may be modified to suit individual requirements. Rather - than -modify /etc/shorewall/common.def, - you -should copy that - file to - /etc/shorewall/common - and modify that file.

    + than + modify +/etc/shorewall/common.def, + you should copy that + file to + /etc/shorewall/common + and modify that + file.

    - +

    The /etc/shorewall/common - file -is expected to - contain iptables - commands; rather than - running iptables - directly, you should run - it indirectly using the - Shorewall function - 'run_iptables'. - That way, if iptables - encounters an error, the - firewall will be safely - stopped.

    + file + is expected to + contain iptables + commands; rather than + running iptables + directly, you should run + it indirectly using the + Shorewall function + 'run_iptables'. + That way, if iptables + encounters an error, the + firewall will be safely + stopped.

    - +

    /etc/shorewall/masq

    - +

    The /etc/shorewall/masq file is used to define classical IP Masquerading - and Source Network Address Translation (SNAT). There is one -entry in the file for each subnet that you want to masquerade. -In order to make use of this feature, you must have NAT enabled .

    - +

    Columns are:

    - +
      -
    • INTERFACE - The interface that -will masquerade the subnet; this is normally your internet -interface. This interface name can be optionally qualified -by adding ":" and a subnet or host IP. When this qualification - is added, only packets addressed to that host or subnet will - be masqueraded. Beginning with Shorewall version 1.3.14, if you have set -ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf, -you can cause Shorewall to create an alias label of the form interfacename:digit - (e.g., eth0:0) by placing that label in this column. See example -5 below. Alias labels created in this way allow the alias to be visible to -the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL IS GOOD -FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.
      • -
    • SUBNET - The subnet that you want - to have masqueraded through the INTERFACE. This may be expressed - as a single IP address, a subnet or an interface name. In the - latter instance, the interface must be configured and started -before Shorewall is started as Shorewall will determine the subnet - based on information obtained from the 'ip' utility. When using Shorewall 1.3.13 or earlier, when an interface - name is specified, Shorewall will only masquerade traffic from the first -subnetwork on the named interface; if the interface interfaces to more that -one subnetwork, you will need to add additional entries to this file for each -of those other subnetworks. Beginning with Shorewall 1.3.14, shorewall will -masquerade/SNAT traffic from any host that is routed through the named interface.
      -
      - The subnet may be optionally followed by "!' - and a comma-separated list of addresses and/or subnets that -are to be excluded from masquerading.
      • -
    • ADDRESS - The source address to be -used for outgoing packets. This column is optional and if left -blank, the current primary IP address of the interface in the -first column is used. If you have a static IP on that interface, listing - it here makes processing of output packets a little less expensive - for the firewall. If you specify an address in this column, it must be -an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES - enabled in /etc/shorewall/shorewall.conf.
      • - +
    • INTERFACE - The interface +that will masquerade the subnet; this is normally your +internet interface. This interface name can be optionally + qualified by adding ":" and a subnet or host IP. When this + qualification is added, only packets addressed to that host or subnet + will be masqueraded. Beginning with Shorewall version 1.3.14, if +you have set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf, + you can cause Shorewall to create an alias label of the form interfacename:digit + (e.g., eth0:0) by placing that label in this column. See example + 5 below. Alias labels created in this way allow the alias to be visible + to the ipconfig utility. THAT IS THE ONLY THING THAT THIS LABEL +IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.
      • +
    • SUBNET - The subnet that +you want to have masqueraded through the INTERFACE. This +may be expressed as a single IP address, a subnet or an interface + name. In the latter instance, the interface must be configured and + started before Shorewall is started as Shorewall will determine + the subnet based on information obtained from the 'ip' utility. + When using Shorewall 1.3.13 or earlier, when + an interface name is specified, Shorewall will only masquerade traffic +from the first subnetwork on the named interface; if the interface interfaces + to more that one subnetwork, you will need to add additional entries to + this file for each of those other subnetworks. Beginning with Shorewall +1.3.14, shorewall will masquerade/SNAT traffic from any host that is routed +through the named interface.
      +
      + The subnet may be optionally followed by + "!' and a comma-separated list of addresses and/or subnets + that are to be excluded from masquerading.
      • +
    • ADDRESS - The source address +to be used for outgoing packets. This column is optional and +if left blank, the current primary IP address of the interface + in the first column is used. If you have a static IP on that interface, + listing it here makes processing of output packets a little less + expensive for the firewall. If you specify an address in this column, +it must be an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES + enabled in /etc/shorewall/shorewall.conf.
      • +
    - +

    Example 1: You have eth0 connected to a cable modem and eth1 - connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq - file would look like:

    + connected to your local subnetwork 192.168.9.0/24. Your +/etc/shorewall/masq file would look like:

    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    INTERFACE SUBNETADDRESS
    eth0192.168.9.0/24
    -
    -
    - - -

    Example 2: You have a number of IPSEC tunnels through ipsec0 - and you want to masquerade traffic from your 192.168.9.0/24 - subnet to the remote subnet 10.1.0.0/16 only.

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    INTERFACE SUBNETADDRESS
    ipsec0:10.1.0.0/16192.168.9.0/24
    -
    -
    - - -

    Example 3: You have a DSL line connected on eth0 and a local - network - (192.168.10.0/24) - connected to eth1. You - want all local->net - connections to use - source address - 206.124.146.176.

    - -
    + + - - - - - - - - - - - + + + + + + + + + + - + + - -
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24206.124.146.176
    INTERFACE SUBNETADDRESS
    eth0192.168.9.0/24
    +
    -
    - + + + + + + + +

    Example 2: You have a number of IPSEC tunnels through ipsec0 + and you want to masquerade traffic from your 192.168.9.0/24 + subnet to the remote subnet 10.1.0.0/16 only.

    + + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    ipsec0:10.1.0.0/16192.168.9.0/24
    +
    +
    + + + +

    Example 3: You have a DSL line connected on eth0 and a local + network + (192.168.10.0/24) + connected to eth1. You + want all local->net + connections to use + source address + 206.124.146.176.

    + + +
    + + + + + + + + + + + + + + + + + + + + + + +
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24206.124.146.176
    +
    + + +

    Example 4: Same as example 3 except that you wish @@ -2279,70 +2295,72 @@ an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES - +

    - + - - - - - - - - - - - + + + + + + + + + + + - + + - +
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
    INTERFACE SUBNETADDRESS
    eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
    -
    + - Example - 5 (Shorewall version >= 1.3.14): You have a second IP address (206.124.146.177) - assigned to you and wish to use it for SNAT of the subnet 192.168.12.0/24. - You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes - in /etc/shorewall/shorewall.conf.
    - + +Example 5 (Shorewall version >= 1.3.14): You have a second +IP address (206.124.146.177) assigned to you and wish to use it for SNAT +of the subnet 192.168.12.0/24. You want to give that address the name +eth0:0. You must have ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
    +
    - + - - - - - - - - - - - + + + + + + + + + + + - + + - +
    INTERFACE SUBNETADDRESS
    eth0:0192.168.12.0/24206.124.146.177
    INTERFACE SUBNETADDRESS
    eth0:0192.168.12.0/24206.124.146.177
    -
    - + +

    /etc/shorewall/proxyarp

    - +

    If you want to use proxy ARP on an entire sub-network, @@ -2352,30 +2370,30 @@ an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/"> http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. -If you decide to use - the technique - described in that - HOWTO, you can set - the proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by -including the - proxyarp option - in the interface's - record in - - /etc/shorewall/interfaces. - When using Proxy -ARP sub-netting, - you do NOT - include any - entries in - /etc/shorewall/proxyarp.

    + If you decide to use + the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + +by including the + proxyarp option + in the interface's + record in + + /etc/shorewall/interfaces. + When using +Proxy ARP + sub-netting, you do + NOT include + any entries in + /etc/shorewall/proxyarp.

    - +

    The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for @@ -2383,51 +2401,52 @@ ARP sub-netting, on a small set of systems since you need one entry - in - this file for each - system using proxy - ARP. Columns are:

    - + in + this file for each + system using proxy + ARP. Columns are:

    +
      -
    • ADDRESS - address of the system.
      • -
    • INTERFACE - the interface that -connects to the system. If the interface is obvious from -the subnetting, you may enter "-" in this column.
      • -
    • EXTERNAL - the external interface - that you want to honor ARP requests for the ADDRESS specified - in the first column.
      • -
    • HAVEROUTE - If - you already have - a route through - INTERFACE to - ADDRESS, -this column -should - contain - "Yes" or - "yes". - If you want - Shorewall -to add the -route, the - column should - contain - "No" - or - "no".
      • - +
    • ADDRESS - address of the +system.
      • +
    • INTERFACE - the interface +that connects to the system. If the interface is obvious +from the subnetting, you may enter "-" in this column.
      • +
    • EXTERNAL - the external interface + that you want to honor ARP requests for the ADDRESS specified + in the first column.
      • +
    • HAVEROUTE - If + you already have + a route through + INTERFACE + to ADDRESS, + this +column should + contain + "Yes" + or + "yes". + If you want + Shorewall to add + the route, the + column should + contain + "No" + or + "no".
      • +
    - +

    Note: After you have made a change to the /etc/shorewall/proxyarp - file, you may need to flush the ARP cache of all routers on -the LAN segment connected to the interface specified in the EXTERNAL - column of the change/added entry(s). If you are having problems communicating - between an individual host (A) on that segment and a system whose - entry has changed, you may need to flush the ARP cache on host -A as well.

    + file, you may need to flush the ARP cache of all routers +on the LAN segment connected to the interface specified in the +EXTERNAL column of the change/added entry(s). If you are having +problems communicating between an individual host (A) on that +segment and a system whose entry has changed, you may need to +flush the ARP cache on host A as well.

    - +

    ISPs typically have ARP configured with long TTL (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump -nei <external interface> host <IP addr>"), it may @@ -2437,106 +2456,106 @@ order after changing my proxy ARP settings.

    - +

    Example: You have public IP addresses 155.182.235.0/28. You configure your - firewall as follows:

    - + firewall as follows:

    +
      -
    • eth0 - 155.186.235.1 (internet connection)
      • -
    • eth1 - 192.168.9.0/24 (masqueraded local -systems)
      • -
    • eth2 - 192.168.10.1 (interface to your DMZ)
      • - +
    • eth0 - 155.186.235.1 (internet connection)
      • +
    • eth1 - 192.168.9.0/24 (masqueraded +local systems)
      • +
    • eth2 - 192.168.10.1 (interface to your + DMZ)
      • +
    - +

    In your DMZ, you want to install a Web/FTP server with public address - 155.186.235.4. On the Web server, you subnet just like the -firewall's eth0 and you configure 155.186.235.1 as the default -gateway. In your /etc/shorewall/proxyarp file, you will have:

    + 155.186.235.4. On the Web server, you subnet just like the + firewall's eth0 and you configure 155.186.235.1 as the default + gateway. In your /etc/shorewall/proxyarp file, you will have:

    - + +
    - + - + - - - - - - - - - - - + + + + + + + + + + + - + + - +
    ADDRESS INTERFACE EXTERNALHAVEROUTE
    155.186.235.4eth2eth0No
    ADDRESS INTERFACE EXTERNALHAVEROUTE
    155.186.235.4eth2eth0No
    -
    + - +

    Note: You may want to configure the servers in your DMZ with a subnet - that is smaller than the subnet of your internet interface. -See the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) - for details. In this case you will want to place "Yes" in the - HAVEROUTE column.

    + for details. In this case you will want to place "Yes" in + the HAVEROUTE column.

    - -

    To learn how I use Proxy ARP in my DMZ, see my -configuration files.

    - +

    Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. - If you start or restart Shorewall with an IPSEC tunnel active, - the proxied IP addresses are mistakenly assigned to the IPSEC tunnel - device (ipsecX) rather than to the interface that you specify -in the INTERFACE column of /etc/shorewall/proxyarp. I haven't had -the time to debug this problem so I can't say if it is a bug in the -Kernel or in FreeS/Wan.

    - + If you start or restart Shorewall with an IPSEC tunnel active, + the proxied IP addresses are mistakenly assigned to the IPSEC + tunnel device (ipsecX) rather than to the interface that you +specify in the INTERFACE column of /etc/shorewall/proxyarp. I haven't +had the time to debug this problem so I can't say if it is a bug +in the Kernel or in FreeS/Wan.

    +

    You might be able to work around this problem using the following - (I haven't tried it):

    - + (I haven't tried it):

    +

    In /etc/shorewall/init, include:

    - +

    qt service ipsec stop

    - +

    In /etc/shorewall/start, include:

    - +

    qt service ipsec start

    - +

    /etc/shorewall/nat

    - +

    The /etc/shorewall/nat file is used to define static NAT. There is one - entry in the file for each static NAT relationship that you - wish to define. In order to make use of this feature, you must - have NAT enabled .

    + entry in the file for each static NAT relationship that +you wish to define. In order to make use of this feature, you +must have NAT enabled .

    - +

    IMPORTANT: If @@ -2548,498 +2567,394 @@ Kernel or in FreeS/Wan.

    static NAT. Port forwarding can be accomplished - with - simple entries in - the - - rules file. - Also, in most - cases - - Proxy ARP - provides a - superior solution - to static NAT - because the - internal systems - are accessed -using -the same IP - address internally - and externally.

    + with + simple entries in + the + + rules file. + Also, in most + cases + + Proxy ARP + provides a + superior solution + to static NAT + because the + internal systems + are accessed + using + the same IP + address internally + and externally.

    - +

    Columns in an entry are:

    - +
      -
    • EXTERNAL - External IP address -- This should NOT be the primary IP address of the -interface named in the next column.
      • -
    • INTERFACE - Interface that you -want the EXTERNAL IP address to appear on. Beginning with -Shorewall version 1.3.14, if you have set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf,  you can specify an alias -label of the form interfacename:digit (e.g., eth0:0) and Shorewall -will create the alias with that label. Alias labels created in this way -allow the alias to be visible to the ipconfig utility. THAT IS THE -ONLY THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE -IN YOUR SHOREWALL CONFIGURATION. 
      • -
    • INTERNAL - Internal IP address.
      • -
    • ALL - INTERFACES - - If Yes - or yes (or - left - empty), - NAT -will - be - effective - from all - hosts. If - No or no - then NAT - will be - effective - only - through - the - interface - named -in - the - INTERFACE - column. Note: If two or more NATed -systems are connected to the same firewall interface and you -want them to be able to communicate using their EXTERNAL IP addresses, - then you will want to specify the multi option in the - /etc/shorewall/interface entry for that -interface.
      • -
    • LOCAL - If Yes or yes and the ALL -INTERFACES column contains Yes or yes, NAT will be effective -from the firewall system. Note: For this to work, -you must be running kernel 2.4.19 or later and iptables 1.2.6a or - later and you must have enabled CONFIG_IP_NF_NAT_LOCAL - in your kernel.
      • - +
    • EXTERNAL - External IP address + - This should NOT be the primary IP address of the + interface named in the next column.
      • +
    • INTERFACE - Interface that + you want the EXTERNAL IP address to appear on. Beginning + with Shorewall version 1.3.14, if you have set ADD_IP_ALIASES=Yes in + /etc/shorewall/shorewall.conf,  you can specify +an alias label of the form interfacename:digit (e.g., eth0:0) +and Shorewall will create the alias with that label. Alias labels created +in this way allow the alias to be visible to the ipconfig utility. + THAT IS THE ONLY THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR +ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION. 
      • +
    • INTERNAL - Internal IP address.
      • +
    • ALL + INTERFACES + - If Yes + or yes (or + left + empty), + NAT + will + be + effective + from all + hosts. If + No or no + then NAT + will be + effective + only + through + +the + interface + named in + the + INTERFACE + column.
      • +
    • LOCAL - If Yes or yes and the + ALL INTERFACES column contains Yes or yes, NAT will be +effective from the firewall system. Note: For +this to work, you must be running kernel 2.4.19 or later and +iptables 1.2.6a or later and you must have enabled CONFIG_IP_NF_NAT_LOCAL + in your kernel.
      • +
    - +

    Look here for additional information and an example. -

    +

    - +

    /etc/shorewall/tunnels

    - + +

    The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, -OpenVPN and PPTP tunnels - with end-points on your firewall. To use ipsec, you must install -version 1.9, 1.91 or the current OpenVPN and PPTP + tunnels with end-points on your firewall. To use ipsec, you must + install version 1.9, 1.91 or the current FreeS/WAN development snapshot.

    - -

    Note: For kernels 2.4.4 and above, you will need to use version 1.91 - or a development snapshot as patching with version 1.9 results - in kernel compilation errors.

    - + +

    Note: For kernels 2.4.4 and above, you will need to use version 1.91 + or a development snapshot as patching with version 1.9 +results in kernel compilation errors.

    + + +

    Instructions for setting up IPSEC tunnels may - be found here, instructions for - IPIP and GRE tunnels are here, instructions + for IPIP and GRE tunnels are here, instructions for OpenVPN tunnels are here, and -instructions for PPTP tunnels are here.

    - + instructions for PPTP tunnels are here.

    +

    /etc/shorewall/shorewall.conf

    - + +

    This file is used to set the following firewall parameters:

    - +
      -
    • OLD_PING_HANDLING - Added at version - 1.3.14.
      - If this option is set to 'Yes' then the old and confusing ICMP echo-request - (Ping) handling is enabled. This includes the 'noping' and 'filterping' -interface options and the FORWARDPING option below. If this option is set -to "No" then ping requests are handled using rules and policies just like -any other connection request. For upward compatibility with only configurations, -if this option is omitted OLD_PING_HANDLING=Yes is assumed. New Shorewall -users should leave this option set to "No".
      -
      - For a complete description of how ping handling works under Shorewall, - see ping.html.
      -
      -
      • -
    • CLEAR_TC - Added at version 1.3.13
      - If this option is set to 'No' then Shorewall won't clear the current - traffic control rules during [re]start. This setting is intended for use - by people that prefer to configure traffic shaping when the network interfaces - come up rather than when the firewall is started. If that is what you want - to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart - file. That way, your traffic shaping rules can still use the 'fwmark' classifier - based on packet marking defined in /etc/shorewall/tcrules. If not specified, - CLEAR_TC=Yes is assumed.
      -
      • -
    • MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
      - If your kernel has a FORWARD chain in the mangle table, you -may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in -the tcrules file to occur in -that chain rather than in the PREROUTING chain. This permits you to -mark inbound traffic based on its destination address when SNAT or Masquerading -are in use. To determine if your kernel has a FORWARD chain in the mangle - table, use the "/sbin/shorewall show mangle" command; if a FORWARD chain - is displayed then your kernel will support this option. If this option - is not specified or if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") - then MARK_IN_FORWARD_CHAIN=No is assumed.
      -
      • -
    • RFC1918_LOG_LEVEL - Added at version 1.3.12
      - This parameter determines the level at which packets logged -under the 'norfc1918' mechanism - are logged. The value must be a valid CLEAR_TC - Added at version + 1.3.13
      + If this option is set to 'No' then Shorewall won't clear the +current traffic control rules during [re]start. This setting is intended +for use by people that prefer to configure traffic shaping when the network +interfaces come up rather than when the firewall is started. If that +is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply +an /etc/shorewall/tcstart file. That way, your traffic shaping rules +can still use the 'fwmark' classifier based on packet marking defined +in /etc/shorewall/tcrules. If not specified, CLEAR_TC=Yes is assumed.
      +
      • +
    • MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
      + If your kernel has a FORWARD chain in the mangle table, + you may set MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified + in the       tcrules file to occur + in that chain rather than in the PREROUTING chain. This permits you + to mark inbound traffic based on its destination address when SNAT +or Masquerading are in use. To determine if your kernel has a FORWARD +chain in the mangle table, use the "/sbin/shorewall show mangle" command; +if a FORWARD chain is displayed then your kernel will support this +option. If this option is not specified or if it is given the empty +value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No + is assumed.
      +
      • +
    • RFC1918_LOG_LEVEL - Added at version 1.3.12
      + This parameter determines the level at which packets +logged under the 'norfc1918' + mechanism are logged. The value must be a valid syslog level and if no level is given, - then info is assumed. Prior to Shorewall version 1.3.12, these packets - are always logged at the info level.
      • -
    • TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
      - Determines the disposition of TCP packets that fail the checks - enabled by the tcpflags interface option - and must have a value of ACCEPT (accept the packet), REJECT (send an - RST response) or DROP (ignore the packet). If not set or if set to the - empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP - is assumed.
      • -
    • TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
      - Determines the syslog -level for logging packets that fail the checks enabled by the - tcpflags interface option.The value must be - a valid syslogd log level. If you don't want to log these packets, - set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
      -
      • -
    • MACLIST_DISPOSITION - Added in Version 1.3.10
      - Determines the disposition of connections requests that - fail MAC Verification and must have - the value ACCEPT (accept the connection request anyway), REJECT (reject -the connection request) or DROP (ignore the connection request). If not -set or if set to the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT + then info is assumed. Prior to Shorewall version 1.3.12, these packets + are always logged at the info level.
      • +
    • TCP_FLAGS_DISPOSITION - Added in Version +1.3.11
      + Determines the disposition of TCP packets that fail the + checks enabled by the tcpflags interface + option and must have a value of ACCEPT (accept the packet), REJECT + (send an RST response) or DROP (ignore the packet). If not set or +if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.
      • -
    • MACLIST_LOG_LEVEL - Added in Version 1.3.10
      - Determines the syslog - level for logging connection requests that fail MAC Verification. The value must be a valid - syslogd log level. If you don't want to log these connection requests, - set to the empty value (e.g., MACLIST_LOG_LEVEL="").
      -
      • -
    • NEWNOTSYN - Added in Version 1.3.8
      - When set to "Yes" or "yes", Shorewall will filter -TCP packets that are not part of an established connention and -that are not SYN packets (SYN flag on - ACK flag off). If set to "No", -Shorewall will silently drop such packets. If not set or set to -the empty value (e.g., "NEWNOTSYN="), NEWNOTSYN=No is assumed.
      -
      - If you have a HA setup with failover to another firewall, - you should have NEWNOTSYN=Yes on both firewalls. You should also - select NEWNOTSYN=Yes if you have asymmetric routing.
      +
    • TCP_FLAGS_LOG_LEVEL - Added in Version + 1.3.11
      + Determines the syslog + level for logging packets that fail the checks enabled by the + tcpflags interface option.The value must + be a valid syslogd log level. If you don't want to log these packets, + set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
      • -
    • FORWARDPING - Added in Version 1.3.7 -- This option is deprecated and is not available when OLD_PING_HANDLING=No - (see above).
      - When set to "Yes" or "yes", ICMP echo-request -(ping) packets from interfaces that specify "filterping" are -ACCEPTed by the firewall. When set to "No" or "no", such ping -requests are silently dropped unless they are handled by an explicit -entry in the rules file. If not specified, "No" - is assumed. 
      • -
    • LOGNEWNOTSYN - Added in Version 1.3.6
      - Beginning with version 1.3.6, Shorewall drops -non-SYN TCP packets that are not part of an existing connection. -If you would like to log these packets, set LOGNEWNOTSYN to the - syslog level at which you want - the packets logged. Example: LOGNEWNOTSYN=ULOG|
      -
      - Note: Packets logged under this option -are usually the result of broken remote IP stacks rather than -the result of any sort of attempt to breach your firewall.
      -
      • -
    • MERGE_HOSTS - Added in Version 1.3.5
      - Prior to 1.3.5, when the /etc/shorewall/hosts - file included an entry for a zone then the entire zone had - to be defined in the /etc/shorewall/hosts file and any associations - between the zone and interfaces in the /etc/shorewall/interfaces file were -ignored. This behavior is preserved if MERGE_HOSTS=No or if MERGE_HOSTS - is not set or is set to the empty value.
      -
      - Beginning with version 1.3.5, if MERGE_HOSTS=Yes, - then zone assignments in the /etc/shorewall/hosts file are ADDED - to those in the /etc/shorewall/interfaces file.
      -
      - Example:
      -
      - Interfaces File:
      - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ZONEHOSTSBROADCASTOPTIONS
      loceth1-dhcp
      -ppp+
      -
      -
      - - - -


      - Hosts File:
      -

      - - - - - - - - - - - - - - - - - - -
      ZONEHOSTS
      locppp+:192.168.12.0/24
      - - - -


      -       With MERGE_HOSTS=No, the loc zone - consists of only ppp+:192.168.12.0/24; with MERGE_HOSTS=Yes, - it includes eth1:0.0.0.0/0 and ppp+:192.168.12.0/24.
      -

      -
      • -
    • DETECT_DNAT_ADDRS - Added in Version -1.3.4
      - If set to "Yes" or "yes", Shorewall will detect the - IP address(es) of the interface(es) to the source zone and will -include this (these) address(es) in DNAT rules as the original destination - IP address. If set to "No" or "no", Shorewall will not detect this - (these) address(es) and any destination IP address will match the -DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" is +
    • MACLIST_DISPOSITION - Added in Version + 1.3.10
      + Determines the disposition of connections requests + that fail MAC Verification and + must have the value ACCEPT (accept the connection request anyway), REJECT + (reject the connection request) or DROP (ignore the connection request). + If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") + then MACLIST_DISPOSITION=REJECT is assumed.
      • +
    • MACLIST_LOG_LEVEL - Added in Version + 1.3.10
      + Determines the syslog level for logging connection +requests that fail MAC Verification. +The value must be a valid syslogd log level. If you don't want +to log these connection requests, set to the empty value (e.g., +MACLIST_LOG_LEVEL="").
      +
      • +
    • NEWNOTSYN - Added in Version 1.3.8
      + When set to "Yes" or "yes", Shorewall will filter + TCP packets that are not part of an established connention +and that are not SYN packets (SYN flag on - ACK flag off). If set +to "No", Shorewall will silently drop such packets. If not set +or set to the empty value (e.g., "NEWNOTSYN="), NEWNOTSYN=No is assumed.
      -
      • -
    • MULTIPORT - Added in Version 1.3.2
      - If set to "Yes" or "yes", Shorewall will use -the Netfilter multiport facility. In order to use this facility, - your kernel must have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). - When this support is used, Shorewall will generate a single -rule from each record in the /etc/shorewall/rules file that -meets these criteria:
      +
      + If you have a HA setup with failover to another + firewall, you should have NEWNOTSYN=Yes on both firewalls. +You should also select NEWNOTSYN=Yes if you have asymmetric routing.
      +
      • +
    • LOGNEWNOTSYN - Added in Version +1.3.6
      + Beginning with version 1.3.6, Shorewall +drops non-SYN TCP packets that are not part of an existing +connection. If you would like to log these packets, set LOGNEWNOTSYN +to the syslog level at which +you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
      +
      + Note: Packets logged under this +option are usually the result of broken remote IP stacks +rather than the result of any sort of attempt to breach your +firewall.
      • +
    • DETECT_DNAT_ADDRS + - Added in Version 1.3.4
      + If set to "Yes" or "yes", Shorewall will detect the IP address(es) + of the interface(es) to the source zone and will include this +(these) address(es) in DNAT rules as the original destination + IP address. If set to "No" or "no", Shorewall will not detect this + (these) address(es) and any destination IP address will match the +DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" is +assumed.
      +
      • +
    • MULTIPORT - Added in Version + 1.3.2
      + If set to "Yes" or "yes", Shorewall will + use the Netfilter multiport facility. In order to use +this facility, your kernel must have multiport support +(CONFIG_IP_NF_MATCH_MULTIPORT). When this support is used, Shorewall + will generate a single rule from each record in the /etc/shorewall/rules + file that meets these criteria:
      +
        -
      • No port range(s) specified
        • -
      • Specifies 15 or fewer ports
        • +
      • No port range(s) specified
        • +
      • Specifies 15 or fewer ports
        • - +
      - +

      Rules not meeting those criteria will continue to generate an individual - rule for each listed port or port range.

      -
      • -
    • NAT_BEFORE_RULES
      - If set to "No" or "no", port forwarding rules -can override the contents of the /etc/shorewall/nat - file. If set to "Yes" or "yes", port forwarding rules cannot -override static NAT. If not set or set to an empty value, "Yes" -is assumed.
      • -
    • FW
      + rule for each listed port or port range.

      +
      • +
    • NAT_BEFORE_RULES
      + If set to "No" or "no", port forwarding +rules can override the contents of the /etc/shorewall/nat + file. If set to "Yes" or "yes", port forwarding rules cannot + override static NAT. If not set or set to an empty value, "Yes" + is assumed.
      • +
    • FW
      -       This - parameter - specifies the - name of the - firewall zone. - If not set or - if set -to an - empty string, - the value - "fw" - is assumed.
      • -
    • SUBSYSLOCK
      - This parameter should be set to the name - of a file that the firewall should create if it starts -successfully and remove when it stops. Creating and removing -this file allows Shorewall to work with your distribution's - initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall. - For Debian, the value is /var/state/shorewall and in LEAF it -is /var/run/shorwall. - Example: - SUBSYSLOCK=/var/lock/subsys/shorewall.
      • -
    • STATEDIR
      - This parameter specifies the name of a -directory where Shorewall stores state information. If -the directory doesn't exist when Shorewall starts, it will -create the directory. Example: STATEDIR=/tmp/shorewall.
      -
      - NOTE: If you change the STATEDIR variable - while the firewall is running, create the new directory if -necessary then copy the contents of the old directory to the -new directory.
      • -
    • ALLOWRELATED
      - This parameter must be assigned the value - "Yes" ("yes") or "No" ("no") and specifies whether Shorewall - allows connection requests that are related to an already -allowed connection. If you say "No" ("no"), you can still override -this setting by including "related" rules in /etc/shorewall/rules -("related" given as the protocol). If you specify ALLOWRELATED=No, -you will need to include rules in /etc/shorewall/icmpdef to - handle common ICMP packet types.
      • -
    • MODULESDIR
      - This parameter specifies the directory -where your kernel netfilter modules may be found. If you -leave the variable empty, Shorewall will supply the value -"/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
      • -
    • LOGRATE and LOGBURST
      - These parameters set the match rate and -initial burst size for logged packets. Please see the iptables -man page for a description of the behavior of these parameters -(the iptables option --limit is set by LOGRATE and --limit-burst -is set by LOGBURST). If both parameters are set empty, no rate-limiting -will occur.
      -
      - Example:
      - LOGRATE=10/minute
      - LOGBURST=5
      -
      • -
    • LOGFILE
      +       This + parameter + specifies the + name of the + firewall zone. + If not set + or if +set to an + empty string, + the value + "fw" + is assumed.
      • +
    • SUBSYSLOCK
      + This parameter should be set to the + name of a file that the firewall should create if it starts + successfully and remove when it stops. Creating and removing + this file allows Shorewall to work with your distribution's + initscripts. For RedHat, this should be set to /var/lock/subsys/shorewall. + For Debian, the value is /var/state/shorewall and in LEAF it + is /var/run/shorwall. - This parameter - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when - processing - the "show - log", - "monitor", - "status" - and - "hits" - commands. - If not - assigned - or if assigned - an empty - value, - /var/log/messages - is assumed.
      • -
    • NAT_ENABLED
      + Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
      • +
    • STATEDIR
      + This parameter specifies the name +of a directory where Shorewall stores state information. + If the directory doesn't exist when Shorewall starts, + it will create the directory. Example: STATEDIR=/tmp/shorewall.
      +
      + NOTE: If you change the STATEDIR +variable while the firewall is running, create the new directory + if necessary then copy the contents of the old directory +to the new directory.
      • +
    • MODULESDIR
      + This parameter specifies the directory + where your kernel netfilter modules may be found. If +you leave the variable empty, Shorewall will supply the + value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
      • +
    • LOGRATE and LOGBURST
      + These parameters set the match rate + and initial burst size for logged packets. Please see the + iptables man page for a description of the behavior of these + parameters (the iptables option --limit is set by LOGRATE and + --limit-burst is set by LOGBURST). If both parameters are set + empty, no rate-limiting will occur.
      +
      + Example:
      + LOGRATE=10/minute
      + LOGBURST=5
      +
      • +
    • LOGFILE
      + + This parameter + tells the + /sbin/shorewall + program where + to look for + Shorewall + messages +when +processing the + "show + log", + "monitor", + "status" + and + "hits" + commands. If + not assigned + or if assigned + an empty + value, + /var/log/messages + is assumed.
      • +
    • NAT_ENABLED
      + This parameter determines whether +Shorewall supports NAT operations. NAT operations include:
      +
      + Static NAT
      + Port Forwarding
      + Port Redirection
      + Masquerading
      +
      + If the parameter has no value or +has a value of "Yes" or "yes" then NAT is enabled. If the +parameter has a value of "no" or "No" then NAT is disabled.
      +
      • +
    • MANGLE_ENABLED
      + This parameter determines if packet + mangling is enabled. If the parameter has no value or +has a value of "Yes" or "yes" than packet mangling is enabled. + If the parameter has a value of "no" or "No" then packet mangling + is disabled. If packet mangling is disabled, the /etc/shorewall/tos + file is ignored.
      +
      • +
    • IP_FORWARDING
      + This parameter determines whether +Shorewall enables or disables IPV4 Packet Forwarding +(/proc/sys/net/ipv4/ip_forward). Possible values are:
      +
      + On or on - packet forwarding +will be enabled.
      + Off or off - packet forwarding + will be disabled.
      + Keep or keep - Shorewall will +neither enable nor disable packet forwarding.
      +
      + If this variable is not set or is +given an empty value (IP_FORWARD="") then IP_FORWARD=On +is assumed.
      +
      • +
    • ADD_IP_ALIASES
      + This parameter determines whether +Shorewall automatically adds the + external address(es) +in /etc/shorewall/nat . If the variable + is set to "Yes" or "yes" then Shorewall automatically + adds these aliases. If it is set to "No" or "no", you must + add these aliases yourself using your distribution's network +configuration tools.
      +
      + If this variable is not set or is +given an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes + is assumed.
      • +
    • ADD_SNAT_ALIASES
      This parameter determines whether Shorewall - supports NAT operations. NAT operations include:
      -
      - Static NAT
      - Port Forwarding
      - Port Redirection
      - Masquerading
      -
      - If the parameter has no value or has a -value of "Yes" or "yes" then NAT is enabled. If the parameter -has a value of "no" or "No" then NAT is disabled.
      -
      • -
    • MANGLE_ENABLED
      - This parameter determines if packet mangling - is enabled. If the parameter has no value or has a value - of "Yes" or "yes" than packet mangling is enabled. If the parameter - has a value of "no" or "No" then packet mangling is disabled. - If packet mangling is disabled, the /etc/shorewall/tos file -is ignored.
      -
      • -
    • IP_FORWARDING
      - This parameter determines whether Shorewall - enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). - Possible values are:
      -
      - On or on - packet forwarding will be - enabled.
      - Off or off - packet forwarding will -be disabled.
      - Keep or keep - Shorewall will neither - enable nor disable packet forwarding.
      -
      - If this variable is not set or is given -an empty value (IP_FORWARD="") then IP_FORWARD=On is assumed.
      -
      • -
    • ADD_IP_ALIASES
      - This parameter determines whether Shorewall - automatically adds the - external address(es) in - /etc/shorewall/nat . If the variable - is set to "Yes" or "yes" then Shorewall automatically adds -these aliases. If it is set to "No" or "no", you must add these -aliases yourself using your distribution's network configuration - tools.
      -
      - If this variable is not set or is given -an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes - is assumed.
      • -
    • ADD_SNAT_ALIASES
      - This parameter determines whether Shorewall automatically - adds the SNAT ADDRESS in /etc/shorewall/masq. - If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these addresses. If it is set to "No" or "no", you must - add these addresses yourself using your distribution's network - configuration tools.
      -
      - If this variable is not set or is given -an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No - is assumed.
      -
      • -
    • LOGUNCLEAN
      + automatically adds the SNAT ADDRESS in /etc/shorewall/masq. If the variable is set +to "Yes" or "yes" then Shorewall automatically adds these addresses. +If it is set to "No" or "no", you must add these addresses yourself +using your distribution's network configuration tools.
      +
      + If this variable is not set or is +given an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No + is assumed.
      +
      • +
    • LOGUNCLEAN
      - This parameter - determines the - logging level - of - mangled/invalid - packets - controlled by - the 'dropunclean and logunclean' interface @@ -3066,214 +2981,220 @@ empty level (Example: LOGUNCLEAN=debug).
      • -
    • BLACKLIST_DISPOSITION
      +
    • BLACKLIST_DISPOSITION
      - This parameter - determines the - disposition of - packets from - blacklisted - hosts. It may - have the -value - DROP if the - packets are to - be dropped or - REJECT if the - packets are to - be replied - with an ICMP - port - unreachable - reply or -a TCP RST -(tcp only). -If you -do not assign - a value or if - you assign an - empty value - then DROP is - assumed.
      • -
    • BLACKLIST_LOGLEVEL
      + This parameter + determines the + disposition of + packets from + blacklisted + hosts. It +may have +the value + DROP if the + packets are to + be dropped or + REJECT if the + packets are to + be replied + with an ICMP + port + unreachable + reply or + a TCP +RST (tcp + only). If you + do not assign + a value or if + you assign an + empty value + then DROP is + assumed.
      • +
    • BLACKLIST_LOGLEVEL
      - This paremter - determines if - packets from - blacklisted - hosts are - logged and it - determines the - syslog -level - that they are - to be logged - at. Its value - is a syslog - level - (Example: - BLACKLIST_LOGLEVEL=debug). - If you do not - assign a value - or if you - assign -an empty -value then -packets - from - blacklisted - hosts are not - logged.
      • -
    • CLAMPMSS
      + This paremter + determines if + packets from + blacklisted + hosts are + logged and it + determines + the +syslog level + that they are + to be logged + at. Its value + is a syslog level + (Example: + BLACKLIST_LOGLEVEL=debug). - This parameter - enables the - TCP Clamp MSS - to PMTU - feature of - Netfilter and - is usually - required when - your internet - connection - is -through PPPoE - or PPTP. If - set to - "Yes" - or - "yes", - the feature is - enabled. If - left blank or - set to - "No" - or - "no", - the feature is - not enabled. - Note: This - option - requires - CONFIG_IP_NF_TARGET_TCPMSS - - in - your kernel.
      • -
    • ROUTE_FILTER
      - If this parameter is given the value "Yes" or -"yes" then route filtering (anti-spoofing) is enabled on -all network interfaces. The default value is "no".
      • - +If you do not + assign a value + or if you + assign an + empty value + then packets + from + blacklisted + hosts are not + logged. +
    • CLAMPMSS
      + + This parameter + enables the + TCP Clamp MSS + to PMTU + feature of + Netfilter and + is usually + required when + your +internet + connection is + through PPPoE + or PPTP. If + set to + "Yes" + or + "yes", + the feature is + enabled. If + left blank +or set +to "No" + or + "no", + the feature + is not + enabled. + Note: This + option + requires + CONFIG_IP_NF_TARGET_TCPMSS + in + your kernel.
      • +
    • ROUTE_FILTER
      + If this parameter is given the value "Yes" + or "yes" then route filtering (anti-spoofing) is enabled + on all network interfaces. The default value is "no".
      • +
    - +

    /etc/shorewall/modules Configuration

    - +

    The file /etc/shorewall/modules contains commands for loading the kernel - modules required by Shorewall-defined firewall rules. Shorewall - will source this file during start/restart provided that it -exists and that the directory specified by the MODULESDIR parameter -exists (see /etc/shorewall/shorewall.conf -above).

    + modules required by Shorewall-defined firewall rules. Shorewall + will source this file during start/restart provided that +it exists and that the directory specified by the MODULESDIR +parameter exists (see /etc/shorewall/shorewall.conf + above).

    - +

    The file that is released with Shorewall calls the Shorewall function - "loadmodule" for the set of modules that I load.

    + "loadmodule" for the set of modules that I load.

    - +

    The loadmodule function is called as follows:

    - +
    - + +

    loadmodule <modulename> [ <module parameters> ]

    -
    + - +

    where

    - +
    +

    <modulename>

    - +
    - + +

    is the name of the modules without the trailing ".o" (example ip_conntrack).

    -
    +
    - +

    <module parameters>

    - +
    - + +

    Optional parameters to the insmod utility.

    -
    - + + - +

    The function determines if the module named by <modulename> - is already loaded and if not then the function determines - if the ".o" file corresponding to the module exists in the moduledirectory; - if so, then the following command is executed:

    + is already loaded and if not then the function determines + if the ".o" file corresponding to the module exists in the + moduledirectory; if so, then the following command +is executed:

    - +
    - +

    insmod moduledirectory/<modulename>.o <module - parameters>

    -
    + parameters>

    + - +

    If the file doesn't exist, the function determines of the ".o.gz" file corresponding to the module exists in the moduledirectory. If it does, the function assumes that the running configuration supports @@ -3281,436 +3202,431 @@ compressed modules and execute the following command:

    - +
    - +

    insmod moduledirectory/<modulename>.o.gz <module - parameters>

    -
    + parameters>

    + - +

    /etc/shorewall/tos Configuration

    - +

    The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet destination, - protocol, source port and destination port. In order for this - file to be processed by Shorewall, you must have mangle support enabled .

    - +

    Entries in the file have the following columns:

    - +
      -
    • SOURCE -- The source zone. May -be qualified by following the zone name with a colon (":") -and either an IP address, an IP subnet, a MAC address in Shorewall Format or the name of an interface. - This column may also contain the name of - the firewall - zone to - indicate packets originating on the firewall itself or "all" to - indicate any source.
      • -
    • DEST -- The destination zone. May - be qualified by following the zone name with a colon (":") - and either an IP address or an IP subnet. Because packets are - marked prior to routing, you may not specify the name of an - interface. This column may also contain "all" to indicate any - destination.
      • -
    • PROTOCOL -- The name of a protocol - in /etc/protocols or the protocol's number.
      • -
    • SOURCE PORT(S) -- The source port - or a port range. For all ports, place a hyphen ("-") in this - column.
      • -
    • DEST PORT(S) -- The destination - port or a port range. To indicate all ports, place a hyphen - ("-") in this column.
      • -
    • TOS -- The type of service. Must - be one of the following:
      • - +
    • SOURCE -- The source zone. + May be qualified by following the zone name with a colon + (":") and either an IP address, an IP subnet, a MAC address + in Shorewall Format or the name of an +interface. This column may also contain the name of + the firewall + zone +to indicate packets originating on the firewall itself or "all" +to indicate any source.
      • +
    • DEST -- The destination zone. + May be qualified by following the zone name with a colon + (":") and either an IP address or an IP subnet. Because packets + are marked prior to routing, you may not specify the name + of an interface. This column may also contain "all" to indicate + any destination.
      • +
    • PROTOCOL -- The name of a +protocol in /etc/protocols or the protocol's number.
      • +
    • SOURCE PORT(S) -- The source + port or a port range. For all ports, place a hyphen ("-") + in this column.
      • +
    • DEST PORT(S) -- The destination + port or a port range. To indicate all ports, place a hyphen + ("-") in this column.
      • +
    • TOS -- The type of service. + Must be one of the following:
      • +
    - +
    - +
    - + +

    Minimize-Delay (16)
    - Maximize-Throughput (8)
    - Maximize-Reliability (4)
    - Minimize-Cost (2)
    - Normal-Service (0)

    -
    -
    + Maximize-Throughput (8)
    + Maximize-Reliability (4)
    + Minimize-Cost (2)
    + Normal-Service (0)

    + + - +

    The /etc/shorewall/tos file that is included with Shorewall contains - the following entries.

    + the following entries.

    - +
    - + - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - +
    SOURCEDESTPROTOCOLSOURCE
    + PORT(S)    		DEST PORT(S)TOS
    SOURCEDESTPROTOCOLSOURCE
    - PORT(S)    		DEST PORT(S)TOS
    allalltcp-ssh16
    allalltcpssh-16
    allalltcp-ftp16
    allalltcpftp-16
    allalltcp-ftp-data8
    allalltcpftp-data-8
    allalltcp-ssh16
    allalltcpssh-16
    allalltcp-ftp16
    allalltcpftp-16
    allalltcp-ftp-data8
    allalltcpftp-data-8
    -
    + - +

    WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos file. -

    + adding the ESP and AH protocols to the /etc/shorewall/tos +file.

    - +

    /etc/shorewall/blacklist

    - +

    Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall Format or subnet address. - Example:

    + Example:

    - + 
          130.252.100.69
          206.124.146.0/24
    - +

    Packets from hosts listed in - the - blacklist - file - will - be + the + blacklist + file + will - disposed - of - according - to - the +be + disposed + of + according + to + the - value - assigned - to - the BLACKLIST_DISPOSITION - - and BLACKLIST_LOGLEVEL variables + value + assigned + to + the BLACKLIST_DISPOSITION - in - /etc/shorewall/shorewall.conf. - Only - packets - - arriving - on - interfaces - that - have - - the - 'blacklist' - option + and BLACKLIST_LOGLEVEL variables in - /etc/shorewall/interfaces - are - checked + /etc/shorewall/shorewall.conf. + Only + packets - against - the - blacklist. The black list is designed to prevent - listed hosts/subnets from accessing services on your - network.
    -

    - + arriving + on + interfaces + that + have + + the + 'blacklist' + option + + in + /etc/shorewall/interfaces + are + checked + + against + the + blacklist. The black list is designed to +prevent listed hosts/subnets from accessing services on your + network.
    +

    +

    Beginning with Shorewall 1.3.8, the blacklist file has three columns:
    -

    - +

    +
      -
    • ADDRESS/SUBNET - As described above.
      • -
    • PROTOCOL - Optional. If specified, only - packets specifying this protocol will be blocked.
      • -
    • PORTS - Optional; may only be given if - PROTOCOL is tcp, udp or icmp. Expressed as a comma-separated list - of port numbers or service names (from /etc/services). If present, - only packets destined for the specified protocol and one of the -listed ports are blocked. When the PROTOCOL is icmp, the PORTS column -contains a comma-separated list of ICMP type numbers or names (see -"iptables -h icmp").
      -
      • - +
    • ADDRESS/SUBNET - As described above.
      • +
    • PROTOCOL - Optional. If specified, + only packets specifying this protocol will be blocked.
      • +
    • PORTS - Optional; may only be given + if PROTOCOL is tcp, udp or icmp. Expressed as a comma-separated + list of port numbers or service names (from /etc/services). If present, + only packets destined for the specified protocol and one of the + listed ports are blocked. When the PROTOCOL is icmp, the PORTS column + contains a comma-separated list of ICMP type numbers or names (see + "iptables -h icmp").
      +
      • +
    - +

    Shorewall also has a dynamic blacklist - capability.

    + capability.

    - +

    IMPORTANT: The Shorewall blacklist file is NOT - designed to police your users' web browsing -- to do that, I -suggest that you install and configure Squid (http://www.squid-cache.org).

    - +

    /etc/shorewall/rfc1918 (Added in Version 1.3.1)

    - +

    This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:

    + interface option. Columns in the file are:

    - +
      -
    • SUBNET - The subnet using VLSM - notation (e.g., 192.168.0.0/16).
      • +
    • SUBNET - The subnet using + VLSM notation (e.g., 192.168.0.0/16).
      • -
    • TARGET - What to do with - packets to/from the SUBNET: +
    • TARGET - What to + do with packets to/from the SUBNET: - +
        -
      • RETURN - Process the packet - normally thru the rules and policies.
        • +
      • RETURN - Process the +packet normally thru the rules and policies.
        • -
      • DROP - Silently drop the packet.
        • +
      • DROP - Silently drop +the packet.
        • -
      • logdrop - Log then drop the - packet -- see the RFC1918_LOG_LEVEL parameter above.
        • +
      • logdrop - Log then drop + the packet -- see the RFC1918_LOG_LEVEL parameter + above.
        • - +
      -
      • - + +
    - +

    /etc/shorewall/routestopped (Added in Version - 1.3.4)

    + 1.3.4) - +

    This file defines the hosts that are accessible from the firewall when - the firewall is stopped. Columns in the file are:

    + the firewall is stopped. Columns in the file are:

    - +
      -
    • INTERFACE - The firewall interface - through which the host(s) comminicate with the firewall.
      • +
    • INTERFACE - The firewall + interface through which the host(s) comminicate with the firewall.
      • -
    • HOST(S) - (Optional) - A comma-separated - list of IP/Subnet addresses. If not supplied or supplied as "-" -then 0.0.0.0/0 is assumed.
      • - +
    • HOST(S) - (Optional) - +A comma-separated list of IP/Subnet addresses. If not supplied +or supplied as "-" then 0.0.0.0/0 is assumed.
      • +
    - +

    Example: When your firewall is stopped, you want firewall accessibility - from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces - through eth1 and your local hosts through eth2.

    + from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ + interfaces through eth1 and your local hosts through eth2.

    - +
    - + - - - - - - - - - + - + - + - + - + - + - + - + + + + + + + + + - + - +
    INTERFACEHOST(S)
    eth2INTERFACE192.168.1.0/24HOST(S)
    eth1eth2-192.168.1.0/24
    eth1-
    -
    + - +

    /etc/shorewall/maclist (Added in Version 1.3.10)

    - This file is described in the MAC Validation Documentation.
    -
    - -

    Updated 3/4/2003 - Tom Eastep -

    + +

    /etc/shorewall/ecn (Added in Version 1.4.0)

    + This file is described in the ECN Control Documentation.
    +
    + +

    Updated 3/6/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    -
    -

    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    +

    diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 0b8e1ab08..93634625a 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -3,1270 +3,1328 @@ - + - + - + - + Shorewall FAQ - + + - + - - - + + - + + + + + + +
    +
    - + +

    Shorewall FAQs

    -
    + + +

    1. I want to forward UDP + port 7777 to my my personal PC with IP address + 192.168.1.5. I've looked everywhere and can't find how + to do it.

    + + +

    1a. Ok -- I followed those instructions + but it doesn't work.
    +

    + + +

    1b. I'm still having problems with + port forwarding

    + + +

    2. I port forward www requests + to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 + in my local network. External clients can browse + http://www.mydomain.com but internal clients can't.

    + + +

    2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 + addresses to hosts in Z. Hosts in Z cannot communicate + with each other using their external (non-RFC1918 addresses) + so they can't access each other using their DNS names.

    + + +

    3. I want to use Netmeeting + or MSN Instant Messenger with Shorewall. What + do I do?

    + + +

    4. I just used an online port scanner + to check my firewall and it shows some ports as + 'closed' rather than 'blocked'. Why?

    + + +

    4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as open!!!!

    + + +

    5. I've installed Shorewall and now + I can't ping through the firewall

    + + +

    6. Where are the log messages + written and how do I change the destination?

    - - - - -

    1. I want to forward UDP - port 7777 to my my personal PC with IP address 192.168.1.5. - I've looked everywhere and can't find how to do it.

    - - -

    1a. Ok -- I followed those instructions - but it doesn't work.
    -

    - - -

    1b. I'm still having problems with - port forwarding

    - -

    2. I port forward www requests - to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5 - in my local network. External clients can browse -http://www.mydomain.com but internal clients can't.

    - - -

    2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 - addresses to hosts in Z. Hosts in Z cannot communicate -with each other using their external (non-RFC1918 addresses) -so they can't access each other using their DNS names.

    - - -

    3. I want to use Netmeeting - or MSN Instant Messenger with Shorewall. What -do I do?

    - - -

    4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' - rather than 'blocked'. Why?

    - - -

    4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports as open!!!!

    - - -

    5. I've installed Shorewall and now - I can't ping through the firewall

    - - -

    6. Where are the log messages - written and how do I change the destination?

    - - -

    6a. Are there any log parsers - that work with Shorewall?

    - +

    6a. Are there any log parsers + that work with Shorewall?

    +

    6b. DROP messages on port 10619 are flooding the logs with their connect - requests. Can i exclude these error messages for this port temporarily - from logging in Shorewall?
    -

    - -

    6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered port.  - They get dropped, but what the heck are they?
    -

    - -

    6d. Why is the MAC address - in Shorewall log messages so long? I thought MAC addresses were only - 6 bytes in length.
    -

    - -

    7. When I stop Shorewall using - 'shorewall stop', I can't connect to anything. Why doesn't that command - work?

    + href="#faq6b"> on port 10619 are flooding the logs with their connect + requests. Can i exclude these error messages for this port temporarily + from logging in Shorewall?
    +

    + +

    6c. All day long I get a steady flow + of these DROP messages from port 53 to some high numbered + port. They get dropped, but what the heck are they?
    +

    + +

    6d. Why is the MAC address + in Shorewall log messages so long? I thought MAC addresses were + only 6 bytes in length.
    +

    + +

    7. When I stop Shorewall using +'shorewall stop', I can't connect to anything. Why doesn't that command + work?

    - -

    8. When I try to start Shorewall - on RedHat I get messages about insmod failing -- -what's wrong?

    + +

    8. When I try to start Shorewall + on RedHat I get messages about insmod failing -- + what's wrong?
    +

    - -

    9. Why can't Shorewall detect - my interfaces properly?

    + +

    8a. When I try to start Shorewall +on RedHat I get a message referring me to FAQ #8
    +

    + +

    9. Why can't Shorewall detect + my interfaces properly?

    - -

    10. What distributions does - it work with?

    + +

    10. What distributions does + it work with?

    - -

    11. What features does it - support?

    + +

    11. What features does it +support?

    - +

    12. Is there a GUI?

    - +

    13. Why do you call it "Shorewall"?

    - -

    14. I'm connected via a cable modem - and it has an internel web server that allows me to -configure/monitor it but as expected if I enable rfc1918 -blocking for my eth0 interface, it also blocks the cable -modems web server.

    + +

    14. I'm connected via a cable modem + and it has an internel web server that allows me to + configure/monitor it but as expected if I enable +rfc1918 blocking for my eth0 interface, it also blocks +the cable modems web server.

    - -

    14a. Even though it assigns public - IP addresses, my ISP's DHCP server has an RFC 1918 address. - If I enable RFC 1918 filtering on my external interface, -my DHCP client cannot renew its lease.

    + +

    14a. Even though it assigns public + IP addresses, my ISP's DHCP server has an RFC 1918 + address. If I enable RFC 1918 filtering on my external +interface, my DHCP client cannot renew its lease.

    - -

    15. My local systems can't see - out to the net

    + +

    15. My local systems can't see + out to the net

    - -

    16. Shorewall is writing log messages - all over my console making it unusable!
    -

    - 17. How do I find out why this traffic is getting - logged?
    -
    - 18. Is there any -way to use aliased ip addresses with Shorewall, and -maintain separate rulesets for different IPs?
    -
    - 19. I have added entries - to /etc/shorewall/tcrules but they don't seem to do - anything. Why?
    -
    - 20. I have just set up - a server. Do I have to change Shorewall to allow access to my - server from the internet?
    -
    -     21. I see these strange - log entries occasionally; what are they?
    -
    - 22. I have some iptables commands - that I want to run when Shorewall starts. Which file do -I put them in?
    -
    - 23. Why do you use such ugly fonts - on your web site?
    -
    - 24. How can I allow conections -to let's say the ssh port only from specific IP Addresses on the -internet?
    -
    - 25. How to I tell which version of Shorewall - I am running?
    -
    - -
    -

    1. I want to forward UDP port 7777 to - my my personal PC with IP address 192.168.1.5. I've looked - everywhere and can't find how to do it.

    + +

    16. Shorewall is writing log messages + all over my console making it unusable!
    +

    + 17. How do I find out why this traffic is +getting logged?
    +
    + 18. Is there + any way to use aliased ip addresses with Shorewall, + and maintain separate rulesets for different IPs?
    +
    + 19. I have added + entries to /etc/shorewall/tcrules but they don't +seem to do anything. Why?
    +
    + 20. I have just +set up a server. Do I have to change Shorewall to allow access + to my server from the internet?
    +
    +     21. I see these strange + log entries occasionally; what are they?
    +
    + 22. I have some iptables + commands that I want to run when Shorewall starts. Which + file do I put them in?
    +
    + 23. Why do you use such ugly + fonts on your web site?
    +
    + 24. How can I allow conections + to let's say the ssh port only from specific IP Addresses +on the internet?
    +
    + 25. How to I tell which version of Shorewall + I am running?
    +
    + +
    +

    1. I want to forward UDP port 7777 to + my my personal PC with IP address 192.168.1.5. I've + looked everywhere and can't find how to do it.

    - +

    Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format of a port-forwarding - rule to a local system is as follows:

    + href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a + port-forwarding rule to a local system is as follows:

    - -
    - - - - - - - - - - - - - - - - - - - - - + +
    - - - -
    - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>
    -
    -
    -
    - - -

    So to forward UDP port 7777 to internal system 192.168.1.5, - the rule is:

    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:192.168.1.5udp7777
    -
    -
    -
    - - -
    If - you want to forward requests directed to a particular address ( <external - IP> ) on your firewall to an internal system:
    - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:<local IP address>[:<local - port>]<protocol><port #>-<external IP>
    -
    - - Finally, if you need to forward a range of ports, in the PORT column -specify the range as low-port:high-port.
    -

    1a. Ok -- I followed those instructions - but it doesn't work

    + + + + + + + + + + + + + + + + + + + + - + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:<local + IP address>[:<local port>]<protocol><port #>
    +
    +
    + + + +

    So to forward UDP port 7777 to internal system 192.168.1.5, + the rule is:

    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:192.168.1.5udp7777
    +
    +
    +
    + + +
    If + you want to forward requests directed to a particular address + ( <external IP> ) on your firewall to an internal +system:
    + + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATnetloc:<local + IP address>[:<local port>]<protocol><port #>-<external +IP>
    +
    + + Finally, if you need to forward a range of ports, in the PORT +column specify the range as low-port:high-port.
    + +

    1a. Ok -- I followed those instructions + but it doesn't work

    + +

    Answer: That is usually the result of one of two things:

    - +
      -
    • You are trying to test from - inside your firewall (no, that won't work -- see FAQ #2).
      • -
    • You have a more basic problem - with your local system such as an incorrect default gateway - configured (it should be set to the IP address of your firewall's - internal interface).
      • +
    • You are trying to test + from inside your firewall (no, that won't work -- see + FAQ #2).
      • +
    • You have a more basic + problem with your local system such as an incorrect default + gateway configured (it should be set to the IP address +of your firewall's internal interface).
      • - +
    - -

    1b. I'm still having problems with port - forwarding

    - Answer: To further diagnose this problem:
    - -
      -
    • As root, type "iptables -t nat -Z". -This clears the NetFilter counters in the nat table.
      • -
    • Try to connect to the redirected port - from an external host.
      • -
    • As root type "shorewall show nat"
      • -
    • Locate the appropriate DNAT rule. It -will be in a chain called <source zone>_dnat ('net_dnat' - in the above examples).
      • -
    • Is the packet count in the first column - non-zero? If so, the connection request is reaching the firewall - and is being redirected to the server. In this case, the problem - is usually a missing or incorrect default gateway setting on -the server (the server's default gateway should be the IP address - of the firewall's interface to the server).
      • -
    • If the packet count is zero:
      • + +

      1b. I'm still having problems with port + forwarding

      + Answer: To further diagnose +this problem:
      - + +
        +
      • As root, type "iptables -t nat + -Z". This clears the NetFilter counters in the nat table.
        • +
      • Try to connect to the redirected + port from an external host.
        • +
      • As root type "shorewall show +nat"
        • +
      • Locate the appropriate DNAT rule. + It will be in a chain called <source zone>_dnat + ('net_dnat' in the above examples).
        • +
      • Is the packet count in the first + column non-zero? If so, the connection request is reaching + the firewall and is being redirected to the server. In this + case, the problem is usually a missing or incorrect default +gateway setting on the server (the server's default gateway should + be the IP address of the firewall's interface to the server).
        • +
      • If the packet count is zero:
        • + + +
          -
        • the connection request is not reaching - your server (possibly it is being blocked by your ISP); or
          • -
        • you are trying to connect to a secondary - IP address on your firewall and your rule is only redirecting - the primary IP address (You need to specify the secondary IP address - in the "ORIG. DEST." column in your DNAT rule); or
          • -
        • your DNAT rule doesn't match the connection - request in some other way. In that case, you may have to use - a packet sniffer such as tcpdump or ethereal to further diagnose - the problem.
          -
          • +
        • the connection request is not + reaching your server (possibly it is being blocked by your + ISP); or
          • +
        • you are trying to connect to + a secondary IP address on your firewall and your rule is +only redirecting the primary IP address (You need to specify + the secondary IP address in the "ORIG. DEST." column in your +DNAT rule); or
          • +
        • your DNAT rule doesn't match + the connection request in some other way. In that case, +you may have to use a packet sniffer such as tcpdump or ethereal +to further diagnose the problem.
          +
          • - + +
        - -
      - -

      2. I port forward www requests to www.mydomain.com - (IP 130.151.100.69) to system 192.168.1.5 in my local -network. External clients can browse http://www.mydomain.com -but internal clients can't.

      - + +
    + + +

    2. I port forward www requests to www.mydomain.com + (IP 130.151.100.69) to system 192.168.1.5 in my local + network. External clients can browse http://www.mydomain.com + but internal clients can't.

    + +

    Answer: I have two objections to this setup.

    - +
      -
    • Having an internet-accessible - server in your local network is like raising foxes in -the corner of your hen house. If the server is compromised, -there's nothing between that server and your other internal - systems. For the cost of another NIC and a cross-over cable, - you can put your server in a DMZ such that it is isolated from -your local systems - assuming that the Server can be located -near the Firewall, of course :-)
      • -
    • The accessibility problem -is best solved using Bind Version 9 "views" - (or using a separate DNS server for local clients) such that www.mydomain.com - resolves to 130.141.100.69 externally and 192.168.1.5 internally. -That's what I do here at shorewall.net for my local systems that -use static NAT.
      • +
    • Having an internet-accessible + server in your local network is like raising foxes +in the corner of your hen house. If the server is compromised, + there's nothing between that server and your other internal + systems. For the cost of another NIC and a cross-over cable, + you can put your server in a DMZ such that it is isolated from + your local systems - assuming that the Server can be located + near the Firewall, of course :-)
      • +
    • The accessibility problem + is best solved using Bind Version 9 "views" + (or using a separate DNS server for local clients) such that www.mydomain.com + resolves to 130.141.100.69 externally and 192.168.1.5 internally. + That's what I do here at shorewall.net for my local systems + that use static NAT.
      • - +
    - -

    If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that your -external interface is eth0 and your internal interface -is eth1 and that eth1 has IP address 192.168.1.254 with subnet -192.168.1.0/24, do the following:

    - -

    a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1 (No longer required as of Shorewall version -1.3.9).

    + +

    If you insist on an IP solution to the accessibility problem + rather than a DNS solution, then assuming that your + external interface is eth0 and your internal interface + is eth1 and that eth1 has IP address 192.168.1.254 with subnet + 192.168.1.0/24, in /etc/shorewall/rules, add:

    - -
    -

    b) In /etc/shorewall/rules, add:

    -
    + +
    +
    - -
    -
    - + +
    +
    + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - - + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-130.151.100.69:192.168.1.254
    -
    -
    +
    +
    - -
    -

    That rule only works of course if you have a static external - IP address. If you have a dynamic IP address and are - running Shorewall 1.3.4 or later then include this in /etc/shorewall/params:

    -
    + +
    +

    That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and +are running Shorewall 1.3.4 or later then include this +in /etc/shorewall/init:

    +
    - -
    + +
         ETH0_IP=`find_interface_address eth0`
    -
    +
    - -
    + +

    and make your DNAT rule:

    -
    +
    - -
    -
    - + +
    +
    + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - - + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
    DNATloc:192.168.1.0/24loc:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
    -
    -
    +
    +
    - -
    -

    Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each time -that you get a new IP address.

    -
    + +
    +

    Using this technique, you will want to configure your DHCP/PPPoE + client to automatically restart Shorewall each time + that you get a new IP address.

    +
    - -

    2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 addresses - to hosts in Z. Hosts in Z cannot communicate with each other - using their external (non-RFC1918 addresses) so they can't - access each other using their DNS names.

    + +

    2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 addresses + to hosts in Z. Hosts in Z cannot communicate with each +other using their external (non-RFC1918 addresses) so they +can't access each other using their DNS names.

    - -

    Answer: This is another problem that is best solved - using Bind Version 9 "views". It allows both external -and internal clients to access a NATed host using the host's - DNS name.

    + +

    Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both external + and internal clients to access a NATed host using the +host's DNS name.

    - -

    Another good way to approach this problem is to switch from - static NAT to Proxy ARP. That way, the hosts in Z have - non-RFC1918 addresses and can be accessed externally and -internally using the same address.

    + +

    Another good way to approach this problem is to switch from + static NAT to Proxy ARP. That way, the hosts in Z +have non-RFC1918 addresses and can be accessed externally +and internally using the same address.

    - -

    If you don't like those solutions and prefer routing all -Z->Z traffic through your firewall then:

    + +

    If you don't like those solutions and prefer routing all Z->Z +traffic through your firewall then:

    - -

    a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces - (If you are running a Shorewall version earlier than 1.3.9).
    - b) Set the Z->Z policy to ACCEPT.
    - c) Masquerade Z to itself.
    -
    - Example:

    + +

    a) Set the Z->Z policy to ACCEPT.
    + b) Masquerade Z to itself.
    +
    + Example:

    - +

    Zone: dmz
    - Interface: eth2
    - Subnet: 192.168.2.0/24

    + Interface: eth2
    + Subnet: 192.168.2.0/24

    - +

    In /etc/shorewall/interfaces:

    - -
    - + +
    + + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    dmzeth2192.168.2.255multi
    ZONEINTERFACEBROADCASTOPTIONS
    dmzeth2192.168.2.255
    +
    -
    +
    - +

    In /etc/shorewall/policy:

    - -
    - + +
    + + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - + + + +
    SOURCE DESTINATIONPOLICYLIMIT:BURST
    dmzdmzACCEPT
    -
    SOURCE DESTINATIONPOLICYLIMIT:BURST
    dmzdmzACCEPT
    +
    -
    +
    - + +

    In /etc/shorewall/masq:

    - -
    - + +
    + + - - - - - - - - - - - + + + + + + + + + + + + + + + +
    INTERFACE - SUBNETADDRESS
    eth2192.168.2.0/24
    -
    INTERFACE + SUBNETADDRESS
    eth2192.168.2.0/24
    +
    +
    + + +

    3. I want to use Netmeeting or MSN Instant + Messenger with Shorewall. What do I do?

    + + +

    Answer: There is an H.323 connection + tracking/NAT module that may help with Netmeeting. + Look here for a solution + for MSN IM but be aware that there are significant security risks involved + with this solution. Also check the Netfilter mailing list + archives at http://www.netfilter.org. +

    + + +

    4. I just used an online port scanner + to check my firewall and it shows some ports as +'closed' rather than 'blocked'. Why?

    + + +

    Answer: The common.def included with version 1.3.x + always rejects connection requests on TCP port 113 + rather than dropping them. This is necessary to prevent + outgoing connection problems to services that use the + 'Auth' mechanism for identifying requesting users. Shorewall + also rejects TCP ports 135, 137 and 139 as well as UDP ports + 137-139. These are ports that are used by Windows (Windows can + be configured to use the DCE cell locator on port 135). Rejecting + these connection requests rather than dropping them cuts down + slightly on the amount of Windows chatter on LAN segments connected + to the Firewall.

    + + +

    If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web server + in violation of your Service Agreement.

    + + +

    4a. I just ran an nmap UDP scan of my + firewall and it showed 100s of ports as open!!!!

    + + +

    Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing + back from your firewall then it reports the port as +open. If you want to see which UDP ports are really open, + temporarily change your net->all policy to REJECT, restart + Shorewall and do the nmap UDP scan again.

    + - - - -
    +

    5. I've installed Shorewall and now I + can't ping through the firewall

    - -

    3. I want to use Netmeeting or MSN Instant - Messenger with Shorewall. What do I do?

    + +

    Answer: If you want your firewall to be totally open + for "ping",

    - -

    Answer: There is an H.323 connection - tracking/NAT module that may help with Netmeeting. - Look here for a solution - for MSN IM but be aware that there are significant security risks involved - with this solution. Also check the Netfilter mailing list -archives at http://www.netfilter.org. -

    + +

    a) Create /etc/shorewall/common if it doesn't already exist. +
    + b) Be sure that the first +command in the file is ". /etc/shorewall/common.def"
    + c) Add the following to /etc/shorewall/common +

    - -

    4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' - rather than 'blocked'. Why?

    + +
    - -

    Answer: The common.def included with version 1.3.x - always rejects connection requests on TCP port 113 -rather than dropping them. This is necessary to prevent -outgoing connection problems to services that use the 'Auth' -mechanism for identifying requesting users. Shorewall also -rejects TCP ports 135, 137 and 139 as well as UDP ports 137-139. - These are ports that are used by Windows (Windows can -be configured to use the DCE cell locator on port 135). Rejecting -these connection requests rather than dropping them cuts down -slightly on the amount of Windows chatter on LAN segments connected - to the Firewall.

    + +

    run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
    +

    +
    + For a complete description of Shorewall 'ping' management, + see this page. + +

    6. Where are the log messages written + and how do I change the destination?

    - -

    If you are seeing port 80 being 'closed', that's probably - your ISP preventing you from running a web server -in violation of your Service Agreement.

    + +

    Answer: NetFilter uses the kernel's equivalent of syslog +(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility +(see "man openlog") and you get to choose the log level (again, see "man +syslog") in your policies and rules. The destination for messaged +logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). + When you have changed /etc/syslog.conf, be sure to restart + syslogd (on a RedHat system, "service syslog restart"). +

    - -

    4a. I just ran an nmap UDP scan of my - firewall and it showed 100s of ports as open!!!!

    + +

    By default, older versions of Shorewall ratelimited log messages + through settings + in /etc/shorewall/shorewall.conf -- If you want to log + all messages, set:

    - -

    Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing - back from your firewall then it reports the port as open. - If you want to see which UDP ports are really open, temporarily - change your net->all policy to REJECT, restart Shorewall -and do the nmap UDP scan again.

    + +
    +
         LOGLIMIT=""
         LOGBURST=""
    +Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages +to a separate file.
    +
    - -

    5. I've installed Shorewall and now I - can't ping through the firewall

    + +

    6a. Are there any log parsers that work + with Shorewall?

    - -

    Answer: If you want your firewall to be totally open - for "ping":

    + +

    Answer: Here are several links that may be helpful: +

    - -

    a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
    - b) Copy /etc/shorewall/icmp.def -to /etc/shorewall/icmpdef
    - c) Add the following to /etc/shorewall/icmpdef: -

    + +
    - -
    - -

    run_iptables -A icmpdef -p ICMP --icmp-type echo-request - -j ACCEPT
    -

    -
    - For a complete description of Shorewall 'ping' management, - see this page. - -

    6. Where are the log messages written - and how do I change the destination?

    - - -

    Answer: NetFilter uses the kernel's equivalent of -syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern) -facility (see "man openlog") and you get to choose the log level (again, -see "man syslog") in your policies - and rules. The destination for messaged - logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). - When you have changed /etc/syslog.conf, be sure to restart - syslogd (on a RedHat system, "service syslog restart").

    - - -

    By default, older versions of Shorewall ratelimited log messages - through settings -in /etc/shorewall/shorewall.conf -- If you want to log -all messages, set:

    - - -
    -
         LOGLIMIT=""
         LOGBURST=""

    Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.
    -
    - - -

    6a. Are there any log parsers that work - with Shorewall?

    - - -

    Answer: Here are several links that may be helpful: -

    - - -
    - +

    http://www.shorewall.net/pub/shorewall/parsefw/
    - http://www.fireparse.com
    - http://cert.uni-stuttgart.de/projects/fwlogwatch
    - http://www.logwatch.org
    - http://gege.org/iptables
    -

    -
    - I personnaly use Logwatch. It emails me a report each - day from my various systems with each report summarizing the logged - activity on the corresponding system. - -

    6b. DROP messages on port 10619 - are flooding the logs with their connect requests. Can i exclude - these error messages for this port temporarily from logging in Shorewall?

    - Temporarily add the following rule:
    - -
    	DROP    net    fw    udp    10619
    - -

    6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered port.  They -get dropped, but what the heck are they?

    - -
    Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
                                                            SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
                                                            TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
    - Answer: There are two possibilities:
    - + http://www.logwatch.org
    + http://gege.org/iptables
    +

    +
    + I personnaly use Logwatch. It emails me a report + each day from my various systems with each report summarizing +the logged activity on the corresponding system. + +

    6b. DROP messages on port 10619 + are flooding the logs with their connect requests. Can i exclude + these error messages for this port temporarily from logging in Shorewall?

    + Temporarily add the following rule:
    + +
    	DROP    net    fw    udp    10619
    + +

    6c. All day long I get a steady flow + of these DROP messages from port 53 to some high numbered port. +They get dropped, but what the heck are they?

    + +
    Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
                                                            SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
                                                            TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
    + Answer: There are two possibilities:
    +
      -
    1. They are late-arriving replies to DNS queries.
      2. -
    2. They are corrupted reply packets.
      3. - +
    3. They are late-arriving replies to DNS queries.
      4. +
    4. They are corrupted reply packets.
      5. +
    - You can distinguish the difference by setting the logunclean - option (/etc/shorewall/interfaces) - on your external interface (eth0 in the above example). If they get logged - twice, they are corrupted. I solve this problem by using an /etc/shorewall/common - file like this:
    - -
    + You can distinguish the difference by setting the logunclean + option (/etc/shorewall/interfaces) + on your external interface (eth0 in the above example). If they get + logged twice, they are corrupted. I solve this problem by using an +/etc/shorewall/common file like this:
    + +
    #
    # Include the standard common.def file
    #
    . /etc/shorewall/common.def
    #
    # The following rule is non-standard and compensates for tardy
    # DNS replies
    #
    run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
    -
    - The above file is also include in all of my sample configurations - available in the Quick Start -Guides.
    - -

    6d. Why is the MAC address in - Shorewall log messages so long? I thought MAC addresses were only 6 bytes - in length.

    -What is labeled as the MAC address in a Shorewall log message is actually -the Ethernet frame header. It contains:
    - +
    + The above file is also include in all of my sample configurations + available in the Quick Start + Guides and in the common.def file in Shorewall 1.4.0 and later.
    + +

    6d. Why is the MAC address in + Shorewall log messages so long? I thought MAC addresses were only 6 +bytes in length.

    + What is labeled as the MAC address in a Shorewall log message is actually + the Ethernet frame header. IT contains:
    +
      -
    • the destination MAC address (6 bytes)
      • -
    • the source MAC address (6 bytes)
      • -
    • the ethernet frame type (2 bytes)
      • - +
    • the destination MAC address (6 bytes)
      • +
    • the source MAC address (6 bytes)
      • +
    • the ethernet frame type (2 bytes)
      • +
    - Example:
    -
    - MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
    - + Example:
    +
    + MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
    +
      -
    • Destination MAC address = 00:04:4c:dc:e2:28
      • -
    • Source MAC address = 00:b0:8e:cf:3c:4c
      • -
    • Ethernet Frame Type = 08:00 (IP Version 4)
      • - +
    • Destination MAC address = 00:04:4c:dc:e2:28
      • +
    • Source MAC address = 00:b0:8e:cf:3c:4c
      • +
    • Ethernet Frame Type = 08:00 (IP Version 4)
      • +
    - -

    7. When I stop Shorewall using 'shorewall - stop', I can't connect to anything. Why doesn't that command - work?

    + +

    7. When I stop Shorewall using 'shorewall + stop', I can't connect to anything. Why doesn't that + command work?

    - -

    The 'stop' command is intended to place your firewall into - a safe state whereby only those hosts listed in /etc/shorewall/routestopped' - are activated. If you want to totally open up your firewall, - you must use the 'shorewall clear' command.

    + +

    The 'stop' command is intended to place your firewall into + a safe state whereby only those hosts listed in /etc/shorewall/routestopped' + are activated. If you want to totally open up your firewall, + you must use the 'shorewall clear' command.

    - -

    8. When I try to start Shorewall on RedHat, - I get messages about insmod failing -- what's wrong?

    + +

    8. When I try to start Shorewall on RedHat, + I get messages about insmod failing -- what's wrong?

    - -

    Answer: The output you will see looks something like - this:

    + +

    Answer: The output you will see looks something like + this:

    - + 
         /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
         Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
         /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
         /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
         /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
         iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
         Perhaps iptables or your kernel needs to be upgraded.
    - -

    This is usually cured by the following sequence of commands: -

    + +

    This is usually cured by the following sequence of commands: +

    - -
    -
         service ipchains stop
         chkconfig --delete ipchains
         rmmod ipchains
    -
    + +
    +
         service ipchains stop
         chkconfig --delete ipchains
         rmmod ipchains
    +
    - -
    -

    Also, be sure to check the errata - for problems concerning the version of iptables (v1.2.3) - shipped with RH7.2.

    -
    + +
    +

    Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) + shipped with RH7.2.
    +

    + +

    8a. When I try to start Shorewall on RedHat +I get a message referring me to FAQ #8

    + Answer: This is usually cured by the sequence of commands shown above +in FAQ #8 + +

    +
    - +

    - -

    9. Why can't Shorewall detect my interfaces - properly?

    + +

    9. Why can't Shorewall detect my interfaces + properly?

    - -

    I just installed Shorewall and when I issue the start command, - I see the following:

    + +

    I just installed Shorewall and when I issue the start command, + I see the following:

    - -
    + +
         Processing /etc/shorewall/shorewall.conf ...
         Processing /etc/shorewall/params ...
         Starting Shorewall...
         Loading Modules...
         Initializing...
         Determining Zones...
         Zones: net loc
         Validating interfaces file...
         Validating hosts file...
         Determining Hosts in Zones...
         Net Zone: eth0:0.0.0.0/0
         Local Zone: eth1:0.0.0.0/0
         Deleting user chains...
         Creating input Chains...
         ...
    -
    +
    - -
    + +

    Why can't Shorewall detect my interfaces properly?

    -
    - - -
    -

    Answer: The above output is perfectly normal. The -Net zone is defined as all hosts that are connected through eth0 and the -local zone is defined as all hosts connected through eth1

    -
    - - -

    10. What Distributions does it work - with?

    - - -

    Shorewall works with any GNU/Linux distribution that includes - the proper -prerequisites.

    - - -

    11. What Features does it have?

    - - -

    Answer: See the Shorewall - Feature List.

    - - -

    12. Is there a GUI?

    - - -

    Answer: Yes. Shorewall support is included in Webmin - 1.060 and later versions. See http://www.webmin.com -

    - - -

    13. Why do you call it "Shorewall"?

    - - -

    Answer: Shorewall is a concatenation of "Shoreline" - (the city - where I live) and "Firewall". The full name of - the product is actually "Shoreline Firewall" but "Shorewall" is must - more commonly used.

    - - -

    14. I'm connected via a cable modem - and it has an internal web server that allows me to -configure/monitor it but as expected if I enable rfc1918 -blocking for my eth0 interface (the internet one), it also -blocks the cable modems web server.

    - - -

    Is there any way it can add a rule before the rfc1918 blocking - that will let all traffic to and from the 192.168.100.1 - address of the modem in/out but still block all other rfc1918 - addresses?

    - - -

    Answer: If you are running a version of Shorewall -earlier than 1.3.1, create /etc/shorewall/start and in it, place the -following:

    - - -
    -
         run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
    -
    - - -
    -

    If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:

    -
    - - -
    -
    - - - - - - - - - - - - + + +
    +

    Answer: The above output is perfectly normal. The Net + zone is defined as all hosts that are connected through eth0 and the local + zone is defined as all hosts connected through eth1

    +
    - - -
    SUBNET TARGET
    192.168.100.1RETURN
    -
    -
    +

    10. What Distributions does it work + with?

    - -
    -

    Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
    -

    + +

    Shorewall works with any GNU/Linux distribution that includes + the proper + prerequisites.

    - -

    Note: If you add a second IP address to your external firewall - interface to correspond to the modem address, you must -also make an entry in /etc/shorewall/rfc1918 for that address. -For example, if you configure the address 192.168.100.2 on your -firewall, then you would add two entries to /etc/shorewall/rfc1918: -
    -

    + +

    11. What Features does it have?

    - + +

    Answer: See the Shorewall + Feature List.

    + + +

    12. Is there a GUI?

    + + +

    Answer: Yes. Shorewall support is included in Webmin + 1.060 and later versions. See http://www.webmin.com +

    + + +

    13. Why do you call it "Shorewall"?

    + + +

    Answer: Shorewall is a concatenation of "Shoreline" + (the +city where I live) and "Firewall". The full +name of the product is actually "Shoreline Firewall" but "Shorewall" +is must more commonly used.

    + + +

    14. I'm connected via a cable modem + and it has an internal web server that allows me to + configure/monitor it but as expected if I enable rfc1918 + blocking for my eth0 interface (the internet one), it also + blocks the cable modems web server.

    + + +

    Is there any way it can add a rule before the rfc1918 blocking + that will let all traffic to and from the 192.168.100.1 + address of the modem in/out but still block all other rfc1918 + addresses?

    + + +

    Answer: If you are running a version of Shorewall earlier +than 1.3.1, create /etc/shorewall/start and in it, place the following:

    + + +
    +
         run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
    +
    + + +
    +

    If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:

    +
    + + +
    - - - - - - - - - - - - - - - - - - - - - -
    SUBNET
    -     		TARGET
    -
    192.168.100.1
    -     		RETURN
    -
    192.168.100.2
    -     		RETURN
    -
    -
    -
    - - -
    -

    14a. Even though it assigns public -IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable -RFC 1918 filtering on my external interface, my DHCP client cannot renew -its lease.

    -
    - - -
    -

    The solution is the same as FAQ 14 above. Simply substitute - the IP address of your ISPs DHCP server.

    -
    - - -

    15. My local systems can't see out to - the net

    - - -

    Answer: Every time I read "systems can't see out to - the net", I wonder where the poster bought computers -with eyes and what those computers will "see" when things -are working properly. That aside, the most common causes of -this problem are:

    - - -
      -
    1. - - - -

      The default gateway on each local system isn't set to - the IP address of the local firewall interface.

      -
      2. -
    2. - - - -

      The entry for the local network in the /etc/shorewall/masq - file is wrong or missing.

      -
      3. -
    3. - - - -

      The DNS settings on the local systems are wrong or the - user is running a DNS server on the firewall and hasn't - enabled UDP and TCP port 53 from the firewall to the -internet.

      -
      4. - - -
    - - -

    16. Shorewall is writing log messages - all over my console making it unusable!

    -

    Answer: "man dmesg" -- add a suitable 'dmesg' command - to your startup scripts or place it in /etc/shorewall/start. - Under RedHat, the max log level that is sent to the -console is specified in /etc/sysconfig/init in the LOGLEVEL -variable.
    -

    - -

    17. How do I find out why this traffic is getting - logged?

    - Answer: Logging occurs out of -a number of chains (as indicated in the log message) in Shorewall:
    - -
      -
    1. man1918 - The destination - address is listed in /etc/shorewall/rfc1918 with a logdrop - target -- see /etc/shorewall/rfc1918.
      2. -
    2. rfc1918 - The source address - is listed in /etc/shorewall/rfc1918 with a logdrop target - -- see /etc/shorewall/rfc1918.
      3. -
    3. all2<zone>, <zone>2all - or all2all - You have a policy that specifies a log level - and this packet is being logged under that policy. If you intend - to ACCEPT this traffic then you need a rule to that effect.
      -
      4. -
    4. <zone1>2<zone2> - - Either you have a -policy for <zone1> to <zone2> -that specifies a log level and this packet is being logged -under that policy or this packet matches a rule that includes a log level.
      5. -
    5. <interface>_mac - The packet - is being logged under the maclist interface option.
      -
      6. -
    6. logpkt - The packet is being - logged under the logunclean interface option.
      7. -
    7. badpkt - The packet is being - logged under the dropunclean interface option as specified - in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      8. -
    8. blacklst - The packet is -being logged because the source IP is blacklisted in the /etc/shorewall/blacklist file.
      9. -
    9. newnotsyn - The packet is - being logged because it is a TCP packet that is not part -of any current connection yet it is not a syn packet. Options -affecting the logging of such packets include NEWNOTSYN - and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
      10. -
    10. INPUT or FORWARD - -The packet has a source IP address that isn't in any of your -defined zones ("shorewall check" and look at the printed zone -definitions) or the chain is FORWARD and the destination IP isn't -in any of your defined zones.
      11. -
    11. logflags - The packet is being logged - because it failed the checks implemented by the tcpflags interface option.
      -
      12. - -
    - -

    18. Is there any way to use aliased ip addresses - with Shorewall, and maintain separate rulesets for different - IPs?

    - Answer: Yes. See Shorewall and Aliased Interfaces. - -

    19. I have added entries to /etc/shorewall/tcrules - but they don't seem to do anything. Why?

    - You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf - so the contents of the tcrules file are simply being ignored.
    - -

    20. I have just set up a server. Do I have - to change Shorewall to allow access to my server from the internet?
    -

    - Yes. Consult the QuickStart guide that you -used during your initial setup for information about how to set up -rules for your server.
    - -

    21. I see these strange log entries occasionally; - what are they?
    -

    - -
    - - 
    Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00
         SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 
         [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
    -
    - 192.0.2.3 is external on my firewall... 172.16.0.0/24 - is my internal LAN
    -
    - Answer: While most people associate the Internet - Control Message Protocol (ICMP) with 'ping', ICMP is a key piece - of the internet. ICMP is used to report problems back to the sender - of a packet; this is what is happening here. Unfortunately, where -NAT is involved (including SNAT, DNAT and Masquerade), there are -a lot of broken implementations. That is what you are seeing with these -messages.
    -
    - Here is my interpretation of what is happening -- -to confirm this analysis, one would have to have packet sniffers -placed a both ends of the connection.
    -
    - Host 172.16.1.10 behind NAT gateway 206.124.146.179 - sent a UDP DNS query to 192.0.2.3 and your DNS server tried to -send a response (the response information is in the brackets -- note -source port 53 which marks this as a DNS reply). When the response was -returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 - and forwarded the packet to 172.16.1.10 who no longer had a connection - on UDP port 2857. This causes a port unreachable (type 3, code 3) -to be generated back to 192.0.2.3. As this packet is sent back through - 206.124.146.179, that box correctly changes the source address in -the packet to 206.124.146.179 but doesn't reset the DST IP in the original - DNS response similarly. When the ICMP reaches your firewall (192.0.2.3), - your firewall has no record of having sent a DNS reply to 172.16.1.10 -so this ICMP doesn't appear to be related to anything that was sent. -The final result is that the packet gets logged and dropped in the -all2all chain. I have also seen cases where the source IP in the ICMP -itself isn't set back to the external IP of the remote NAT gateway; that -causes your firewall to log and drop the packet out of the rfc1918 chain -because the source IP is reserved by RFC 1918.
    - -

    22. I have some iptables commands that - I want to run when Shorewall starts. Which file do I put them - in?

    - You can place these commands in one of the Shorewall Extension Scripts. Be -sure that you look at the contents of the chain(s) that you will be modifying - with your commands to be sure that the commands will do what they -are intended. Many iptables commands published in HOWTOs and other instructional - material use the -A command which adds the rules to the end of the -chain. Most chains that Shorewall constructs end with an unconditional -DROP, ACCEPT or REJECT rule and any rules that you add after that will -be ignored. Check "man iptables" and look at the -I (--insert) command.
    - -

    23. Why do you use such ugly fonts on your - web site?

    - The Shorewall web site is almost font neutral (it doesn't -explicitly specify fonts except on a few pages) so the fonts you see -are largely the default fonts configured in your browser. If you don't -like them then reconfigure your browser.
    - -

    24. How can I allow conections to let's say - the ssh port only from specific IP Addresses on the internet?

    - In the SOURCE column of the rule, follow "net" by a colon and -a list of the host/subnet addresses as a comma-separated list.
    - -
        net:<ip1>,<ip2>,...
    - Example:
    - -
        ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
    + + + + + + + + + + + + + + + + -

    +
    SUBNET + TARGET
    192.168.100.1RETURN
    + +
    - -
    - -

    25. How to I tell which version of Shorewall - I am running?
    -

    - At the shell prompt, type:
    + +
    +

    Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
    +

    + + +

    Note: If you add a second IP address to your external firewall + interface to correspond to the modem address, you must + also make an entry in /etc/shorewall/rfc1918 for that address. + For example, if you configure the address 192.168.100.2 on + your firewall, then you would add two entries to /etc/shorewall/rfc1918:
    -     /sbin/shorewall version
    -
    - Last updated 3/5/2003 - Tom Eastep - -

    Copyright © -2001, 2002, 2003 Thomas M. Eastep.
    -

    -
    -
    +

    + + +
    + + + + + + + + + + + + + + + + + + + + + +
    SUBNET
    +     		TARGET
    +
    192.168.100.1
    +     		RETURN
    +
    192.168.100.2
    +     		RETURN
    +
    +
    +
    + + +
    +

    14a. Even though it assigns public IP + addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC +1918 filtering on my external interface, my DHCP client cannot renew its +lease.

    +
    + + +
    +

    The solution is the same as FAQ 14 above. Simply substitute + the IP address of your ISPs DHCP server.

    +
    + + +

    15. My local systems can't see out to + the net

    + + +

    Answer: Every time I read "systems can't see out to + the net", I wonder where the poster bought computers + with eyes and what those computers will "see" when things + are working properly. That aside, the most common causes + of this problem are:

    + + +
      +
    1. + + + +

      The default gateway on each local system isn't set to + the IP address of the local firewall interface.

      +
      2. +
    2. + + + +

      The entry for the local network in the /etc/shorewall/masq + file is wrong or missing.

      +
      3. +
    3. + + + +

      The DNS settings on the local systems are wrong or the + user is running a DNS server on the firewall and + hasn't enabled UDP and TCP port 53 from the firewall + to the internet.

      +
      4. + + +
    + + +

    16. Shorewall is writing log messages + all over my console making it unusable!

    + + +

    Answer: "man dmesg" -- add a suitable 'dmesg' command + to your startup scripts or place it in /etc/shorewall/start. + Under RedHat, the max log level that is sent to the + console is specified in /etc/sysconfig/init in the LOGLEVEL + variable.
    +

    + + +

    17. How do I find out why this traffic is getting + logged?

    + Answer: Logging occurs +out of a number of chains (as indicated in the log message) + in Shorewall:
    + + +
      +
    1. man1918 - The destination + address is listed in /etc/shorewall/rfc1918 with a logdrop + target -- see /etc/shorewall/rfc1918.
      2. +
    2. rfc1918 - The source + address is listed in /etc/shorewall/rfc1918 with a logdrop + target -- see /etc/shorewall/rfc1918.
      3. +
    3. all2<zone>, + <zone>2all or all2all - + You have a policy that specifies +a log level and this packet is being logged under that policy. + If you intend to ACCEPT this traffic then you need a rule to that effect.
      +
      4. +
    4. <zone1>2<zone2> + - Either you have a policy for <zone1> + to <zone2> that specifies a log level and +this packet is being logged under that policy or this packet + matches a rule that includes + a log level.
      5. +
    5. <interface>_mac - +The packet is being logged under the maclist interface option.
      +
      6. +
    6. logpkt - The packet + is being logged under the logunclean interface option.
      7. +
    7. badpkt - The packet + is being logged under the dropunclean + interface option as specified + in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
      8. +
    8. blacklst - The packet + is being logged because the source IP is blacklisted in + the /etc/shorewall/blacklist + file.
      9. +
    9. newnotsyn - The packet + is being logged because it is a TCP packet that is not +part of any current connection yet it is not a syn packet. + Options affecting the logging of such packets include NEWNOTSYN + and LOGNEWNOTSYN in /etc/shorewall/shorewall.conf.
      10. +
    10. INPUT or FORWARD + - The packet has a source IP address that isn't in any +of your defined zones ("shorewall check" and look at the + printed zone definitions) or the chain is FORWARD and the destination + IP isn't in any of your defined zones.
      11. +
    11. logflags - The packet is being + logged because it failed the checks implemented by the tcpflags + interface option.
      +
      12. + + +
    + + +

    18. Is there any way to use aliased ip addresses + with Shorewall, and maintain separate rulesets for different + IPs?

    + Answer: Yes. See Shorewall and Aliased Interfaces. + +

    19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?

    + You probably haven't set TC_ENABLED=Yes + in /etc/shorewall/shorewall.conf so the contents of the +tcrules file are simply being ignored.
    + +

    20. I have just set up a server. Do I have + to change Shorewall to allow access to my server from the + internet?
    +

    + Yes. Consult the QuickStart guide that +you used during your initial setup for information about how to set + up rules for your server.
    + +

    21. I see these strange log entries occasionally; + what are they?
    +

    + +
    + + 
    Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00
         SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 
         [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
    +
    + 192.0.2.3 is external on my firewall... 172.16.0.0/24 + is my internal LAN
    +
    + Answer: While most people associate + the Internet Control Message Protocol (ICMP) with 'ping', +ICMP is a key piece of the internet. ICMP is used to report +problems back to the sender of a packet; this is what is happening + here. Unfortunately, where NAT is involved (including SNAT, DNAT +and Masquerade), there are a lot of broken implementations. That is + what you are seeing with these messages.
    +
    + Here is my interpretation of what is happening + -- to confirm this analysis, one would have to have packet sniffers + placed a both ends of the connection.
    +
    + Host 172.16.1.10 behind NAT gateway 206.124.146.179 + sent a UDP DNS query to 192.0.2.3 and your DNS server tried + to send a response (the response information is in the brackets +-- note source port 53 which marks this as a DNS reply). When the +response was returned to to 206.124.146.179, it rewrote the destination + IP TO 172.16.1.10 and forwarded the packet to 172.16.1.10 who no longer + had a connection on UDP port 2857. This causes a port unreachable + (type 3, code 3) to be generated back to 192.0.2.3. As this packet +is sent back through 206.124.146.179, that box correctly changes the +source address in the packet to 206.124.146.179 but doesn't reset +the DST IP in the original DNS response similarly. When the ICMP +reaches your firewall (192.0.2.3), your firewall has no record of having + sent a DNS reply to 172.16.1.10 so this ICMP doesn't appear to be +related to anything that was sent. The final result is that the packet +gets logged and dropped in the all2all chain. I have also seen cases +where the source IP in the ICMP itself isn't set back to the external +IP of the remote NAT gateway; that causes your firewall to log and drop +the packet out of the rfc1918 chain because the source IP is reserved +by RFC 1918.
    + +

    22. I have some iptables commands that + I want to run when Shorewall starts. Which file do I put + them in?

    + You can place these commands in one of the + Shorewall Extension Scripts. + Be sure that you look at the contents of the chain(s) that you will be modifying + with your commands to be sure that the commands will do what +they are intended. Many iptables commands published in HOWTOs and +other instructional material use the -A command which adds the rules +to the end of the chain. Most chains that Shorewall constructs end +with an unconditional DROP, ACCEPT or REJECT rule and any rules that +you add after that will be ignored. Check "man iptables" and look at +the -I (--insert) command.
    + +

    23. Why do you use such ugly fonts on your + web site?

    + The Shorewall web site is almost font neutral (it doesn't + explicitly specify fonts except on a few pages) so the fonts you +see are largely the default fonts configured in your browser. If you +don't like them then reconfigure your browser.
    + +

    24. How can I allow conections to let's say + the ssh port only from specific IP Addresses on the internet?

    + In the SOURCE column of the rule, follow "net" by a colon + and a list of the host/subnet addresses as a comma-separated list.
    + +
        net:<ip1>,<ip2>,...
    + Example:
    + +
        ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
    + + +
    + +

    25. How to I tell which version of Shorewall + I am running?
    +

    + At the shell prompt, type:
    +
    +     /sbin/shorewall version
    +
    + Last updated 3/11/2003 - Tom + Eastep + +

    Copyright +© 2001, 2002, 2003 Thomas M. Eastep.
    +


    diff --git a/STABLE/documentation/IPIP.htm b/STABLE/documentation/IPIP.htm index 0813f4ff6..b64f475fb 100644 --- a/STABLE/documentation/IPIP.htm +++ b/STABLE/documentation/IPIP.htm @@ -1,196 +1,248 @@ + - - -GRE/IPIP Tunnels - - + + + GRE/IPIP Tunnels + + + + - - - - - - + + +
    -

    GRE and IPIP Tunnels

    -
    + + + + + +
    +

    GRE and IPIP Tunnels

    +
    -

    Warning: GRE and IPIP Tunnels are insecure when used -over the internet; use them at your own risk

    -

    GRE and IPIP tunneling with Shorewall requires iproute2 and can be used to bridge two masqueraded networks. GRE -tunnels were introduced in shorewall version 1.2.0_Beta2.

    -

    The simple scripts described in the Linux Advanced Routing -and Shaping HOWTO work fine with Shorewall. Shorewall also includes a tunnel -script for automating tunnel configuration. If you have installed the RPM, the -tunnel script may be found in the Shorewall documentation directory (usually -/usr/share/doc/shorewall-<version>/).

    + +

    Warning: GRE and IPIP Tunnels are insecure +when used over the internet; use them at your own risk

    + +

    GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded +networks.

    + +

    The simple scripts described in the Linux +Advanced Routing and Shaping HOWTO work fine with Shorewall. Shorewall +also includes a tunnel script for automating tunnel configuration. If you +have installed the RPM, the tunnel script may be found in the Shorewall documentation +directory (usually /usr/share/doc/shorewall-<version>/).

    +

    Bridging two Masqueraded Networks

    +

    Suppose that we have the following situation:

    -

    -

    -

    We want systems in the 192.168.1.0/24 subnetwork to be able to -communicate with the systems in the 10.0.0.0/8 network. This is accomplished -through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy file -and the /etc/shorewall/tunnel script that is included with Shorewall.

    -

    The 'tunnel' script is not installed in /etc/shorewall by -default -- If you install using the tarball, the script is included in the -tarball; if you install using the RPM, the file is in your Shorewall -documentation directory (normally /usr/share/doc/shorewall-<version>).

    -

    In the /etc/shorewall/tunnel script, set the 'tunnel_type' + +

    +

    + +

    We want systems in the 192.168.1.0/24 subnetwork to be able +to communicate with the systems in the 10.0.0.0/8 network. This is accomplished +through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy +file and the /etc/shorewall/tunnel script that is included with Shorewall.

    + +

    The 'tunnel' script is not installed in /etc/shorewall by +default -- If you install using the tarball, the script is included in the +tarball; if you install using the RPM, the file is in your Shorewall documentation +directory (normally /usr/share/doc/shorewall-<version>).

    + +

    In the /etc/shorewall/tunnel script, set the 'tunnel_type' parameter to the type of tunnel that you want to create.

    +

    Example:

    -
    -

    tunnel_type=gre

    -
    -

    On each firewall, you will need to declare a zone to represent -the remote subnet. We'll assume that this zone is called 'vpn' and declare it in -/etc/shorewall/zones on both systems as follows.

    -
    - - - - - - - - - - - - -
    ZONEDISPLAYCOMMENTS
    vpnVPNRemote Subnet
    + +
    +

    tunnel_type=gre

    -

    On system A, the 10.0.0.0/8 will comprise the vpn zone. In -/etc/shorewall/interfaces:

    -
    - - - - - - - - - - - - - + +

    On each firewall, you will need to declare a zone to represent + the remote subnet. We'll assume that this zone is called 'vpn' and declare +it in /etc/shorewall/zones on both systems as follows.

    + +
    +
    ZONEINTERFACEBROADCASTOPTIONS
    vpntosysb10.255.255.255 
    + + + + + + + + + + + + +
    ZONEDISPLAYCOMMENTS
    vpnVPNRemote Subnet
    -
    -

    In /etc/shorewall/tunnels on system A, we need the following:

    -
    - - - - - - - - - - - - - -
    TYPEZONEGATEWAYGATEWAY ZONE
    ipipnet134.28.54.2 
    -
    -

    This entry in /etc/shorewall/tunnels, opens the firewall so that the IP -encapsulation protocol (4) will be accepted to/from the remote gateway.

    -

    In the tunnel script on system A:

    -
    -

    tunnel=tosysb
    - myrealip=206.161.148.9 (for GRE tunnel only)
    - myip=192.168.1.1
    - hisip=10.0.0.1
    - gateway=134.28.54.2
    - subnet=10.0.0.0/8

    -
    -

    Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn +

    + +

    On system A, the 10.0.0.0/8 will comprise the vpn zone. In /etc/shorewall/interfaces:

    -
    - - - - - - - - - - - - - + +
    +
    ZONEINTERFACEBROADCASTOPTIONS
    vpntosysa192.168.1.255 
    + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    vpntosysb10.255.255.255 
    -
    + + +

    In /etc/shorewall/tunnels on system A, we need the following:

    + +
    + + + + + + + + + + + + + + + + +
    TYPEZONEGATEWAYGATEWAY ZONE
    ipipnet134.28.54.2 
    +
    + +

    This entry in /etc/shorewall/tunnels, opens the firewall so that the IP + encapsulation protocol (4) will be accepted to/from the remote gateway.

    + +

    In the tunnel script on system A:

    + +
    +

    tunnel=tosysb
    + myrealip=206.161.148.9 (for GRE tunnel only)
    + myip=192.168.1.1
    + hisip=10.0.0.1
    + gateway=134.28.54.2
    + subnet=10.0.0.0/8

    +
    + +

    Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn +zone. In /etc/shorewall/interfaces:

    + +
    + + + + + + + + + + + + + + + + +
    ZONEINTERFACEBROADCASTOPTIONS
    vpntosysa192.168.1.255 
    +
    +

    In /etc/shorewall/tunnels on system B, we have:

    -
    - - - - - - - - - - - - - + +
    +
    TYPEZONEGATEWAYGATEWAY ZONE
    ipipnet206.191.148.9 
    + + + + + + + + + + + + + + +
    TYPEZONEGATEWAYGATEWAY ZONE
    ipipnet206.191.148.9 
    -
    + +

    And in the tunnel script on system B:

    -
    + +

    tunnel=tosysa
    - myrealip=134.28.54.2 (for GRE tunnel only)
    - myip=10.0.0.1
    - hisip=192.168.1.1
    - gateway=206.191.148.9
    - subnet=192.168.1.0/24

    -
    -

    You can rename the modified tunnel scripts if you like; be sure that they are -secured so that root can execute them.

    - -

    You will need to allow traffic between the "vpn" zone and - the "loc" zone on both systems -- if you simply want to admit all traffic - in both directions, you can use the policy file:

    - - -
    - - - - - - - - - - - - - - - - - - - - - -
    SOURCEDESTPOLICYLOG LEVEL
    locvpnACCEPT 
    vpnlocACCEPT 
    -
    -

    On both systems, restart Shorewall and -run the modified tunnel script with the "start" argument on each -system. The systems in the two masqueraded subnetworks can now talk to each -other

    -

    Updated 8/22/2002 - Tom -Eastep

    -

    Copyright -© 2001, 2002 Thomas M. Eastep.

    - + myrealip=134.28.54.2 (for GRE tunnel only)
    + myip=10.0.0.1
    + hisip=192.168.1.1
    + gateway=206.191.148.9
    + subnet=192.168.1.0/24

    +
    + +

    You can rename the modified tunnel scripts if you like; be sure that they +are secured so that root can execute them.

    + +

    You will need to allow traffic between the "vpn" zone and + the "loc" zone on both systems -- if you simply want to admit all +traffic in both directions, you can use the policy file:

    + +
    + + + + + + + + + + + + + + + + + + + + + + +
    SOURCEDESTPOLICYLOG LEVEL
    locvpnACCEPT 
    vpnlocACCEPT 
    +
    + +

    On both systems, restart Shorewall and run the modified tunnel script +with the "start" argument on each system. The systems in the two masqueraded +subnetworks can now talk to each other

    + +

    Updated 2/22/2003 - Tom Eastep +

    + +

    Copyright © 2001, 2002, 2003Thomas M. Eastep.

    +
    - diff --git a/STABLE/documentation/Install.htm b/STABLE/documentation/Install.htm index 9438668ed..d636696ca 100644 --- a/STABLE/documentation/Install.htm +++ b/STABLE/documentation/Install.htm @@ -1,220 +1,192 @@ - + Shorewall Installation - + - + - + - - - + + - - - + Upgrade + + + +
    +

    Shorewall Installation and - Upgrade

    -
    - +

    Before upgrading, be sure to review the Upgrade Issues

    - +

    Install using RPM
    - Install using tarball
    -    Install the .lrp
    - Upgrade using RPM
    - Upgrade using tarball
    -    Upgrade the .lrp
    - Configuring Shorewall
    - Uninstall/Fallback

    - + Install using tarball
    +     Install the .lrp
    + Upgrade using RPM
    + Upgrade using tarball
    +     Upgrade the .lrp
    + Configuring Shorewall
    + Uninstall/Fallback

    +

    To install Shorewall using the RPM:

    - +

    If you have RedHat 7.2 and are running iptables version 1.2.3 (at a - shell prompt, type "/sbin/iptables --version"), you must upgrade to version - 1.2.4 either from the RedHat update - site or from the Shorewall Errata page before - attempting to start Shorewall.

    - + site or from the Shorewall Errata page before + attempting to start Shorewall.

    +
      -
    • Install the RPM (rpm -ivh <shorewall rpm>).
      -
      - Note: Some SuSE users have encountered a problem whereby rpm -reports a conflict with kernel <= 2.2 even though a 2.4 kernel is +
    • Install the RPM (rpm -ivh <shorewall rpm>).
      +
      + Note: Some SuSE users have encountered a problem whereby rpm + reports a conflict with kernel <= 2.2 even though a 2.4 kernel is installed. If this happens, simply use the --nodeps option to rpm (rpm -ivh --nodeps <shorewall rpm>).
      • -
    • Edit the configuration files to match - your configuration. WARNING - YOU CAN NOT - SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION - IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU ISSUE A "start" COMMAND - AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL NO LONGER ACCEPT ANY +
    • Edit the configuration files to match + your configuration. WARNING - YOU CAN NOT + SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION + IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU ISSUE A "start" COMMAND + AND THE FIREWALL FAILS TO START, YOUR SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE A "shorewall clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.
      • -
    • Start the firewall by typing "shorewall start"
      • - -
    +
  • Start the firewall by typing "shorewall start"
    • +
+

To install Shorewall using the tarball - and install script:

- + and install script:

+ - +

To install my version of Shorewall on a fresh Bering -disk, simply replace the "shorwall.lrp" file on the image with the file that -you downloaded. See the two-interface QuickStart -Guide for information about further steps required.

+ disk, simply replace the "shorwall.lrp" file on the image with the file +that you downloaded. See the two-interface QuickStart + Guide for information about further steps required.

+

If you already have the Shorewall RPM installed - and are upgrading to a new version:

- -

If you are upgrading from a 1.2 version of Shorewall to a 1.3 version + and are upgrading to a new version:

+ +

If you are upgrading from a 1.2 version of Shorewall to a 1.4 version or and you have entries in the /etc/shorewall/hosts file then please check -your /etc/shorewall/interfaces file to be sure that it contains an entry -for each interface mentioned in the hosts file. Also, there are certain -1.2 rule forms that are no longer supported under 1.3 (you must use the -new 1.3 syntax). See the upgrade issues for -details. You can check your rules and host file for 1.3 compatibility using -the "shorewall check" command after installing the latest version of 1.3.

- + your /etc/shorewall/interfaces file to be sure that it contains an entry + for each interface mentioned in the hosts file. Also, there are certain +1.2 rule forms that are no longer supported under 1.4 (you must use the +new 1.4 syntax). See the upgrade issues for +details.

+
    -
  • Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: If - you are installing version 1.2.0 and have one of the 1.2.0 Beta RPMs -installed, you must use the "--oldpackage" option to rpm (e.g., "rpm - -Uvh --oldpackage shorewall-1.2-0.noarch.rpm"). +
  • Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: + If you are installing version 1.2.0 and have one of the 1.2.0 +Beta RPMs installed, you must use the "--oldpackage" option to rpm (e.g., +"rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm"). +

    Note: Some SuSE users have encountered a problem whereby - rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel -is installed. If this happens, simply use the --nodeps option to rpm (rpm - -Uvh --nodeps <shorewall rpm>).
    -  

    -
    • -
  • See if there are any incompatibilities between your configuration + rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel + is installed. If this happens, simply use the --nodeps option to rpm +(rpm -Uvh --nodeps <shorewall rpm>).
    +  

    +
    • +
  • See if there are any incompatibilities between your configuration and the new Shorewall version (type "shorewall check") and correct as necessary.
    • -
  • Restart the firewall (shorewall restart).
    • - +
  • Restart the firewall (shorewall restart).
    • +
- +

If you already have Shorewall installed and are upgrading to a new version using the tarball:

- -

If you are upgrading from a 1.2 version of Shorewall to a 1.3 version + +

If you are upgrading from a 1.2 version of Shorewall to a 1.4 version and you have entries in the /etc/shorewall/hosts file then please check your /etc/shorewall/interfaces file to be sure that it contains an entry for each interface mentioned in the hosts file.  Also, there are certain -1.2 rule forms that are no longer supported under 1.3 (you must use the -new 1.3 syntax). See the upgrade issues -for details. You can check your rules and host file for 1.3 compatibility -using the "shorewall check" command after installing the latest version -of 1.3.

- +1.2 rule forms that are no longer supported under 1.4 (you must use the +new 1.4 syntax). See the upgrade issues +for details.

+
    -
  • unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
    • -
  • cd to the shorewall directory (the version is encoded in the - directory name as in "shorewall-3.0.1").
    • -
  • If you are using unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
    • +
  • cd to the shorewall directory (the version is encoded in the + directory name as in "shorewall-3.0.1").
    • +
  • If you are using Caldera, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
    • -
  • If you are using SuSe then type - "./install.sh /etc/init.d"
    • -
  • If your distribution has directory /etc/rc.d/init.d -or /etc/init.d then type "./install.sh"
    • -
  • For other distributions, determine where your distribution - installs init scripts and type "./install.sh <init script -directory>
    • -
  • See if there are any incompatibilities between your configuration - and the new Shorewall version (type "shorewall check") and correct as -necessary.
    • -
  • Restart the firewall by typing "shorewall restart"
    • - +
  • If you are using SuSe then type + "./install.sh /etc/init.d"
    • +
  • If your distribution has directory /etc/rc.d/init.d + or /etc/init.d then type "./install.sh"
    • +
  • For other distributions, determine where your distribution + installs init scripts and type "./install.sh <init script + directory>
    • +
  • See if there are any incompatibilities between your configuration +and the new Shorewall version (type "shorewall check") and correct as necessary.
    • +
  • Restart the firewall by typing "shorewall restart"
    • +
- If you already have a running Bering installation -and wish to upgrade to a later version of Shorewall:
-
-    UNDER CONSTRUCTION...
+ If you already have a running Bering +installation and wish to upgrade to a later version of Shorewall:
+
+     UNDER CONSTRUCTION...
+

Configuring Shorewall

- -

You will need to edit some or all of these configuration files to match + +

You will need to edit some or all of the configuration files to match your setup. In most cases, the Shorewall QuickStart Guides contain all of the information you need.

- +
    -
  • /etc/shorewall/shorewall.conf - used to set several firewall - parameters.
    • -
  • /etc/shorewall/params - use this file to set shell variables that - you will expand in other files.
    • -
  • /etc/shorewall/zones - partition the firewall's view of the world - into zones.
    • -
  • /etc/shorewall/policy - establishes firewall high-level policy.
    • -
  • /etc/shorewall/interfaces - describes the interfaces on the - firewall system.
    • -
  • /etc/shorewall/hosts - allows defining zones in terms of individual - hosts and subnetworks.
    • -
  • /etc/shorewall/maclist - verification of the MAC addresses of devices.
    -
    • -
  • /etc/shorewall/masq - directs the firewall where to use many-to-one - (dynamic) NAT a.k.a. Masquerading.
    • -
  • /etc/shorewall/modules - directs the firewall to load kernel modules.
    • -
  • /etc/shorewall/rules - defines rules that are exceptions to the - overall policies established in /etc/shorewall/policy.
    • -
  • /etc/shorewall/nat - defines static NAT rules.
    • -
  • /etc/shorewall/proxyarp - defines use of Proxy ARP.
    • -
  • /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines - hosts accessible when Shorewall is stopped.
    • -
  • /etc/shorewall/tcrules - defines marking of packets for later use - by traffic control/shaping.
    • -
  • /etc/shorewall/tos - defines rules for setting the TOS field in -packet headers.
    • -
  • /etc/shorewall/tunnels - defines IPSEC tunnels with end-points on - the firewall system.
    • -
  • /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
    • - +
- -

Updated 1/30/2003 - Tom Eastep -

- + +

Updated 2/27/2003 - Tom Eastep +

+

Copyright © 2001, 2002, 2003 Thomas M. Eastep.

+

+


diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html index c4770f15b..f0ea5b7b7 100644 --- a/STABLE/documentation/MAC_Validation.html +++ b/STABLE/documentation/MAC_Validation.html @@ -2,110 +2,111 @@ MAC Verification - + - + - + - - - + + - - - + +
+ + + +
- +
+

MAC Verification
-

-
-
-
- Beginning with Shorewall version 1.3.10, all traffic from an interface - or from a subnet on an interface can be verified to originate from a defined - set of MAC addresses. Furthermore, each MAC address may be optionally -associated with one or more IP addresses.
-
- You must have the iproute package (ip utility) installed to use MAC -Verification and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC -- module name ipt_mac.o).
-
- There are four components to this facility.
- +
+ All traffic from an interface or from a subnet on an interface +can be verified to originate from a defined set of MAC addresses. Furthermore, +each MAC address may be optionally associated with one or more IP addresses. +
+
+ Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC + - module name ipt_mac.o).
+
+ There are four components to this facility.
+
    -
  1. The maclist interface option in The maclist interface option in /etc/shorewall/interfaces. When this option is specified, all traffic arriving on the interface is subjet to MAC verification.
    2. -
  2. The maclist option in The maclist option in /etc/shorewall/hosts. When this option -is specified for a subnet, all traffic from that subnet is subject to MAC -verification.
    3. -
  3. The /etc/shorewall/maclist file. This file is used to associate - MAC addresses with interfaces and to optionally associate IP addresses with - MAC addresses.
    4. -
  4. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables - in /etc/shorewall/shorewall.conf. -The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and -determines the disposition of connection requests that fail MAC verification. -The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection -requests that fail verification are to be logged. If set the the empty value -(e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.
    -
    5. - + is specified for a subnet, all traffic from that subnet is subject to MAC + verification. +
  5. The /etc/shorewall/maclist file. This file is used to associate + MAC addresses with interfaces and to optionally associate IP addresses +with MAC addresses.
    6. +
  6. The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables + in /etc/shorewall/shorewall.conf. + The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT +and determines the disposition of connection requests that fail MAC verification. + The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection + requests that fail verification are to be logged. If set the the empty +value (e.g., MACLIST_LOG_LEVEL="") then failing connection requests are +not logged.
    +
    7. +
- The columns in /etc/shorewall/maclist are:
- + The columns in /etc/shorewall/maclist are:
+
    -
  • INTERFACE - The name of an ethernet interface on the Shorewall - system.
    • -
  • MAC - The MAC address of a device on the ethernet segment connected - by INTERFACE. It is not necessary to use the Shorewall MAC format in this - column although you may use that format if you so choose.
    • -
  • IP Address - An optional comma-separated list of IP addresses -for the device whose MAC is listed in the MAC column.
    • - +
  • INTERFACE - The name of an ethernet interface on the Shorewall + system.
    • +
  • MAC - The MAC address of a device on the ethernet segment connected + by INTERFACE. It is not necessary to use the Shorewall MAC format in +this column although you may use that format if you so choose.
    • +
  • IP Address - An optional comma-separated list of IP addresses + for the device whose MAC is listed in the MAC column.
    • +
- +

Example 1: Here are my files:

- /etc/shorewall/shorewall.conf:
- + /etc/shorewall/shorewall.conf:
+ 
     MACLIST_DISPOSITION=REJECT
     MACLIST_LOG_LEVEL=info
- /etc/shorewall/interfaces:
- -
     #ZONE           INTERFACE       BROADCAST       OPTIONS
     net             eth0            206.124.146.255 norfc1918,filterping,dhcp,blacklist
     loc             eth2            192.168.1.255   dhcp,filterping,maclist
     dmz             eth1            192.168.2.255   filterping
     net             eth3            206.124.146.255 filterping,blacklist
     -               texas           192.168.9.255   filterping
     loc             ppp+            -               filterping
- /etc/shorewall/maclist:
- + /etc/shorewall/interfaces:
+ +
     #ZONE           INTERFACE       BROADCAST       OPTIONS
     net             eth0            206.124.146.255 norfc1918,dhcp,blacklist
     loc             eth2            192.168.1.255   dhcp,maclist
     dmz             eth1            192.168.2.255
     net             eth3            206.124.146.255 blacklist
     -               texas           192.168.9.255
     loc             ppp+
+ /etc/shorewall/maclist:
+ 
     #INTERFACE              MAC                     IP ADDRESSES (Optional)
     eth2                    00:A0:CC:63:66:89       192.168.1.3      #Wookie
     eth2                    00:10:B5:EC:FD:0B       192.168.1.4      #Tarry
     eth2                    00:A0:CC:DB:31:C4       192.168.1.5      #Ursa
     eth2                    00:A0:CC:DB:31:C4       192.168.1.128/26 #PPTP Clients to server on Ursa
     eth2                    00:06:25:aa:a8:0f       192.168.1.7      #Eastept1 (Wireless)
     eth2                    00:04:5A:0E:85:B9       192.168.1.250    #Wap
- As shown above, I use MAC Verification on my -local zone.
- + As shown above, I use MAC Verification on my local zone.
+

Example 2: Router in Local Zone

- Suppose now that I add a second ethernet segment to my local zone and - gateway that segment via a router with MAC address 00:06:43:45:C6:15 and - IP address 192.168.1.253. Hosts in the second segment have IP addresses -in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist - file:
- + Suppose now that I add a second ethernet segment to my local zone +and gateway that segment via a router with MAC address 00:06:43:45:C6:15 +and IP address 192.168.1.253. Hosts in the second segment have IP addresses + in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist + file:
+ 
     eth2                     00:06:43:45:C6:15       192.168.1.253,192.168.2.0/24
- This entry accomodates traffic from the router itself (192.168.1.253) - and from the second LAN segment (192.168.2.0/24). Remember that all traffic - being sent to my firewall from the 192.168.2.0/24 segment will be forwarded - by the router so that traffic's MAC address will be that of the router + This entry accomodates traffic from the router itself (192.168.1.253) + and from the second LAN segment (192.168.2.0/24). Remember that all traffic + being sent to my firewall from the 192.168.2.0/24 segment will be forwarded + by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15) and not that of the host sending the traffic. - -

Updated 1/7/2002 - Tom Eastep -

+ +

Updated 2/21/2002 - Tom Eastep +

- +

Copyright © -2001, 2002, 2003 Thomas M. Eastep.
-

+ 2001, 2002, 2003 Thomas M. Eastep.
+

+
+
diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 4f0b5e007..9e62e68e9 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -3,7 +3,7 @@ - + Shorewall News @@ -11,2853 +11,2621 @@ - + - + - + - - - + + - + + - - + +
+
- +

Shorewall News Archive

-
- -

3/7/2003 - Shorewall 1.4.0 RC2 

- Shorewall 1.4 represents -the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall + +

3/17/2003 - Shorewall 1.4.0

+ Shorewall 1.4 represents +the next step in the evolution of Shorewall. The main thrust of the initial + release is simply to remove the cruft that has accumulated in Shorewall over time.
-
- IMPORTANT: Shorewall 1.4.0 requires the iproute package -('ip' utility).
-
- Function from 1.3 that has been omitted from this version include:
- +
+ IMPORTANT: Shorewall 1.4.0 requires the iproute package ('ip' + utility).
+
+ Function from 1.3 that has been omitted from this version include:
+
    -
  1. The MERGE_HOSTS variable in shorewall.conf is no longer supported. -Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
    -
    -
    2. -
  2. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
    -
    -
    3. -
  3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
    -
    -
    4. -
  4. The 'routestopped' option in the /etc/shorewall/interfaces and /etc/shorewall/hosts - files is no longer supported and will generate an error at startup if -specified.
    -
    -
    5. -
  5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer -accepted.
    -
    -
    6. -
  6. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    -
    -
    7. -
  7. The icmp.def file has been removed.
    -
    8. -
- Changes for 1.4 include:
- -
    -
  1. The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
    -
    -
    2. -
  2. LOG is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    3. -
  3. The firewall script and version file are now installed in /usr/share/shorewall.
    -
    -
    4. -
  4. Late arriving DNS replies are now silently dropped in the common chain - by default.
    -
    -
    5. -
  5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no - longer unconditionally accepts outbound ICMP packets. So if you want to -'ping' from the firewall, you will need the appropriate rule or policy.
    -
    -
    6. -
  6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    7. -
  7. 802.11b devices with names of the form wlan<n> - now support the 'maclist' option.
    +
  8. The MERGE_HOSTS variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.

    9. -
  9. Explicit Congestion Notification (ECN - RFC 3168) may now -be turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
    -
    -    a) You must be running kernel 2.4.20
    -    b) You must have applied the patch in
    -    http://www.shorewall/net/pub/shorewall/ecn/patch.
    -    c) You must have iptables 1.2.7a installed.
    -
    -
    10. -
  10. The /etc/shorewall/params file is now processed first so that variables -may be used in the /etc/shorewall/shorewall.conf file.
    11. -
- -

2/27/2003 - Shorewall 1.4.0 Beta 2 

- Shorewall 1.4 represents -the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall -over time.
-
- IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package - ('ip' utility).
-
- Function from 1.3 that has been omitted from this version include:
- -
    -
  1. The 'check' command is no longer supported.
    -
    -
    2. -
  2. The MERGE_HOSTS variable in shorewall.conf is no longer supported. -Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
    -
    -
    3. -
  3. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
    -
    -
    4. -
  4. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification +
  5. Interface names of the form <device>:<integer> in + /etc/shorewall/interfaces now generate an error.
    +
    +
    6. +
  6. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification of the 'noping' or 'filterping' interface options.
    -
    -
    7. -
  7. The 'routestopped' option in the /etc/shorewall/interfaces and /etc/shorewall/hosts - files is no longer supported and will generate an error at startup if -specified.
    -
    -
    8. -
  8. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer -accepted.
    -
    -
    9. -
  9. The ALLOWRELATED variable in shorewall.conf is no longer supported. +
    +
    10. +
  10. The 'routestopped' option in the /etc/shorewall/interfaces and + /etc/shorewall/hosts files is no longer supported and will generate an +error at startup if specified.
    +
    +
    11. +
  11. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
    +
    +
    12. +
  12. The ALLOWRELATED variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    -
    -
    13. -
  13. The icmp.def file has been removed.
    -
    14. +
    + +
  14. The icmp.def file has been removed.
    +
    15. +
- Changes for 1.4 include:
- + Changes for 1.4 include:
+
    -
  1. The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
    -
    -
    2. -
  2. LOG is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
    3. -
  3. The firewall script and version file are now installed in /usr/share/shorewall.
    -
    -
    4. -
  4. Late arriving DNS replies are now silently dropped in the common chain - by default.
    -
    -
    5. -
  5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no - longer unconditionally accepts outbound ICMP packets. So if you want to -'ping' from the firewall, you will need the appropriate rule or policy.
    -
    -
    6. -
  6. You may now disable ECN on a host or network basis.
    -
    7. -
- -

3/5/2003 - Shorewall 1.4.0 RC1 

- Shorewall 1.4 represents -the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall -over time.
+
  • The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
    +
    +
    • +
  • LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    • +
  • The firewall script and version file are now installed in /usr/share/shorewall.
    +
    +
    • +
  • Late arriving DNS replies are now silently dropped in the common + chain by default.
    +
    +
    • +
  • In addition to behaving like OLD_PING_HANDLING=No, Shorewall +1.4 no longer unconditionally accepts outbound ICMP packets. So if you +want to 'ping' from the firewall, you will need the appropriate rule or +policy.

    - IMPORTANT: Shorewall 1.4.0 requires the iproute package -('ip' utility).
    -
    - Function from 1.3 that has been omitted from this version include:
    - -
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      2. -
    2. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
      -
      -
      3. -
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      4. -
    4. The 'routestopped' option in the /etc/shorewall/interfaces and /etc/shorewall/hosts - files is no longer supported and will generate an error at startup if -specified.
      -
      -
      5. -
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer - accepted.
      -
      -
      6. -
    6. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
      7. -
    7. The icmp.def file has been removed.
      -
      8. - -
    - Changes for 1.4 include:
    - -
      -
    1. The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
      -
      -
      2. -
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      3. -
    3. The firewall script and version file are now installed in /usr/share/shorewall.
      -
      -
      4. -
    4. Late arriving DNS replies are now silently dropped in the common -chain by default.
      -
      -
      5. -
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 -no longer unconditionally accepts outbound ICMP packets. So if you want -to 'ping' from the firewall, you will need the appropriate rule or policy.
      -
      -
      6. +
    6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).

      7. -
    7. 802.11b devices with names of the form wlan<n> - now support the 'maclist' option.
      -
      -
      8. -
    8. Explicit Congestion Notification (ECN - RFC 3168) may now -be turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
      -
      -    a) You must be running kernel 2.4.20
      -    b) You must have applied the patch in
      -    http://www.shorewall/net/pub/shorewall/ecn/patch.
      -    c) You must have iptables 1.2.7a installed.
      -
      -
      9. +
    9. 802.11b devices with names of the form wlan<n> now support the +'maclist' option.
      +
      +
      10. +
    10. Explicit Congestion Notification (ECN - RFC 3168) may now be turned +off on a host or network basis using the new /etc/shorewall/ecn file. To use +this facility:
      +
      +    a) You must be running kernel 2.4.20
      +    b) You must have applied the patch in
      +    http://www.shorewall/net/pub/shorewall/ecn/patch.
      +    c) You must have iptables 1.2.7a installed.
      +
      +
    11. The /etc/shorewall/params file is now processed first so that variables -may be used in the /etc/shorewall/shorewall.conf file.
      12. - -
    - -

    2/27/2003 - Shorewall 1.4.0 Beta 2 

    - Shorewall 1.4 represents -the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall -over time.
    -
    - IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package - ('ip' utility).
    -
    - Function from 1.3 that has been omitted from this version include:
    - -
      -
    1. The 'check' command is no longer supported.
      -
      -
      2. -
    2. The MERGE_HOSTS variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      3. -
    3. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
      -
      -
      4. -
    4. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      5. -
    5. The 'routestopped' option in the /etc/shorewall/interfaces and /etc/shorewall/hosts - files is no longer supported and will generate an error at startup if -specified.
      -
      -
      6. -
    6. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer - accepted.
      -
      -
      7. -
    7. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
      8. -
    8. The icmp.def file has been removed.
      -
      9. - -
    - Changes for 1.4 include:
    - -
      -
    1. The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
      -
      -
      2. -
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      3. -
    3. The firewall script and version file are now installed in /usr/share/shorewall.
      -
      -
      4. -
    4. Late arriving DNS replies are now silently dropped in the common - chain by default.
      -
      -
      5. -
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 - no longer unconditionally accepts outbound ICMP packets. So if you want -to 'ping' from the firewall, you will need the appropriate rule or policy.
      -
      -
      6. -
    6. You may now disable ECN on a host or network basis.
      -
      7. - -
    - -

    2/21/2003 - Shorewall 1.4.0 Beta 1 

    - Shorewall 1.4 represents -the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall -over time.
    -
    - IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package - ('ip' utility).
    -
    - Function from 1.3 that has been omitted from this version include:
    - -
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      2. -
    2. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
      -
      -
      3. -
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      4. -
    4. The 'routestopped' option in the /etc/shorewall/interfaces and -/etc/shorewall/hosts files is no longer supported and will generate an -error at startup if specified.
      -
      -
      5. -
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer - accepted.
      -
      -
      6. -
    6. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
      7. -
    7. The icmp.def file has been removed.
      -
      8. - -
    - Changes for 1.4 include:
    - -
      -
    1. The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
      -
      -
      2. -
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      3. -
    3. The firewall script and version file are now installed in /usr/share/shorewall.
      -
      -
      4. -
    4. Late arriving DNS replies are now silently dropped in the common - chain by default.
      -
      -
      5. -
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 - no longer unconditionally accepts outbound ICMP packets. So if you want - to 'ping' from the firewall, you will need the appropriate rule or policy. -
      6. - -
    - -

    2/8/2003 - Shoreawall 1.3.14

    - -

    New features include

    - -
      -
    1. An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been (see - http://www.shorewall.net/ping.html).
      -
      - When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules - and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options in - /etc/shorewall/interfaces will all generate an error.
      -
      -
      2. -
    2. It is now possible to direct Shorewall to create a "label" -such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
      -  
      -    a) In the INTERFACE column of /etc/shorewall/masq
      -    b) In the INTERFACE column of /etc/shorewall/nat
      -  
      3. -
    3. Support for OpenVPN Tunnels.
      -
      -
      4. -
    4. Support for VLAN devices with names of the form $DEV.$VID (e.g., - eth0.0)
      +may be used in the /etc/shorewall/shorewall.conf file.
      +
      +
      5. +
    5. Shorewall now gives a more helpful diagnostic when the +'ipchains' compatibility kernel module is loaded and a 'shorewall start' + command is issued.

      6. -
    6. In /etc/shorewall/tcrules, the MARK value may be optionally followed - by ":" and either 'F' or 'P' to designate that the marking will occur -in the FORWARD or PREROUTING chains respectively. If this additional specification - is omitted, the chain used to mark packets will be determined by the setting - of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      -
      -
      7. -
    7. When an interface name is entered in the SUBNET column of the - /etc/shorewall/masq file, Shorewall previously masqueraded traffic from - only the first subnet defined on that interface. It did not masquerade - traffic from:
      -  
      -    a) The subnets associated with other addresses on the interface.
      -    b) Subnets accessed through local routers.
      -  
      - Beginning with Shorewall 1.3.14, if you enter an interface name - in the SUBNET column, shorewall will use the firewall's routing table - to construct the masquerading/SNAT rules.
      -  
      - Example 1 -- This is how it works in 1.3.14.
      -   
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      - - - 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      -  
      - When upgrading to Shorewall 1.3.14, if you have multiple local - subnets connected to an interface that is specified in the SUBNET column - of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will need - changing. In most cases, you will simply be able to remove redundant entries. - In some cases though, you might want to change from using the interface - name to listing specific subnetworks if the change described above will -cause masquerading to occur on subnetworks that you don't wish to masquerade.
      -  
      - Example 2 -- Suppose that your current config is as follows:
      -   
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, the second entry in /etc/shorewall/masq is -no longer required.
      -  
      - Example 3 -- What if your current configuration is like this?
      -  
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, you would want to change the entry in  /etc/shorewall/masq - to:
      - - - 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      -
      8. - +
    8. The SHARED_DIR variable has been removed from shorewall.conf. This +variable was for use by package maintainers and was not documented for general +use.
      +
      +
      9. +
    9. Shorewall now ignores 'default' routes when detecting masq'd networks.
      10. +
    - -


    - 2/5/2003 - Shorewall Support included in Webmin 1.060

    - -

    Webmin version 1.060 now has Shorewall support included as standard. See - http://www.webmin.com.
    -
    - 2/4/2003 - Shorewall 1.3.14-RC1

    - -

    Includes the Beta 2 content plus support for OpenVPN tunnels.

    - -

    1/28/2003 - Shorewall 1.3.14-Beta2

    - -

    Includes the Beta 1 content plus restores VLAN device names of the form - $dev.$vid (e.g., eth0.1)

    - -

    1/25/2003 - Shorewall 1.3.14-Beta1
    -

    - -

    The Beta includes the following changes:
    -

    - + +

    2/8/2003 - Shoreawall 1.3.14

    + +

    New features include

    +
      -
    1. An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been (see - http://www.shorewall.net/ping.html).
      -
      - When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules - and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options in - /etc/shorewall/interfaces will all generate an error.
      -
      -
      2. -
    2. It is now possible to direct Shorewall to create a "label" - such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
      -  
      -    a) In the INTERFACE column of /etc/shorewall/masq
      -    b) In the INTERFACE column of /etc/shorewall/nat
      -  
      3. -
    3. When an interface name is entered in the SUBNET column -of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic - from only the first subnet defined on that interface. It did not masquerade +
    4. An OLD_PING_HANDLING option has been added to shorewall.conf. + When set to Yes, Shorewall ping handling is as it has always been +(see http://www.shorewall.net/ping.html).
      +
      + When OLD_PING_HANDLING=No, icmp echo (ping) is handled via + rules and policies just like any other connection request. The FORWARDPING=Yes + option in shorewall.conf and the 'noping' and 'filterping' options + in /etc/shorewall/interfaces will all generate an error.
      +
      +
      5. +
    5. It is now possible to direct Shorewall to create a "label" + such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes + and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead + of just the interface name:
      +  
      +    a) In the INTERFACE column of /etc/shorewall/masq
      +    b) In the INTERFACE column of /etc/shorewall/nat
      +  
      6. +
    6. Support for OpenVPN Tunnels.
      +
      +
      7. +
    7. Support for VLAN devices with names of the form $DEV.$VID + (e.g., eth0.0)
      +
      +
      8. +
    8. In /etc/shorewall/tcrules, the MARK value may be optionally + followed by ":" and either 'F' or 'P' to designate that the marking will + occur in the FORWARD or PREROUTING chains respectively. If this additional + specification is omitted, the chain used to mark packets will be determined + by the setting of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      +
      +
      9. +
    9. When an interface name is entered in the SUBNET column of + the /etc/shorewall/masq file, Shorewall previously masqueraded traffic + from only the first subnet defined on that interface. It did not masquerade traffic from:
      -  
      -    a) The subnets associated with other addresses on the interface.
      -    b) Subnets accessed through local routers.
      -  
      - Beginning with Shorewall 1.3.14, if you enter an interface name - in the SUBNET column, shorewall will use the firewall's routing table - to construct the masquerading/SNAT rules.
      -  
      - Example 1 -- This is how it works in 1.3.14.
      -   
      - - +  
      +    a) The subnets associated with other addresses on the +interface.
      +    b) Subnets accessed through local routers.
      +  
      + Beginning with Shorewall 1.3.14, if you enter an interface + name in the SUBNET column, shorewall will use the firewall's routing + table to construct the masquerading/SNAT rules.
      +  
      + Example 1 -- This is how it works in 1.3.14.
      +   
      + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      - - + + 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      -  
      - When upgrading to Shorewall 1.3.14, if you have multiple local - subnets connected to an interface that is specified in the SUBNET column - of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will need - changing. In most cases, you will simply be able to remove redundant entries. - In some cases though, you might want to change from using the interface - name to listing specific subnetworks if the change described above will -cause masquerading to occur on subnetworks that you don't wish to masquerade.
      -  
      - Example 2 -- Suppose that your current config is as follows:
      -   
      - - +  
      + When upgrading to Shorewall 1.3.14, if you have multiple +local subnets connected to an interface that is specified in the +SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq +file will need changing. In most cases, you will simply be able to remove +redundant entries. In some cases though, you might want to change from +using the interface name to listing specific subnetworks if the change +described above will cause masquerading to occur on subnetworks that you +don't wish to masquerade.
      +  
      + Example 2 -- Suppose that your current config is as follows:
      +   
      + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, the second entry in /etc/shorewall/masq is -no longer required.
      -  
      - Example 3 -- What if your current configuration is like this?
      -  
      - - +  
      +    In this case, the second entry in /etc/shorewall/masq +is no longer required.
      +  
      + Example 3 -- What if your current configuration is like this?
      +  
      + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, you would want to change the entry in  /etc/shorewall/masq - to:
      - - +  
      +    In this case, you would want to change the entry in  /etc/shorewall/masq + to:
      + + 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      -
      10. - + +
    + +


    + 2/5/2003 - Shorewall Support included in Webmin 1.060

    + +

    Webmin version 1.060 now has Shorewall support included as standard. See + http://www.webmin.com.
    +
    + 2/4/2003 - Shorewall 1.3.14-RC1

    +

    Includes the Beta 2 content plus support for OpenVPN tunnels.

    + +

    1/28/2003 - Shorewall 1.3.14-Beta2

    + +

    Includes the Beta 1 content plus restores VLAN device names of the form + $dev.$vid (e.g., eth0.1)

    + +

    1/25/2003 - Shorewall 1.3.14-Beta1
    +

    + +

    The Beta includes the following changes:
    +

    + +
      +
    1. An OLD_PING_HANDLING option has been added to shorewall.conf. + When set to Yes, Shorewall ping handling is as it has always been (see + http://www.shorewall.net/ping.html).
      +
      + When OLD_PING_HANDLING=No, icmp echo (ping) is handled via + rules and policies just like any other connection request. The FORWARDPING=Yes + option in shorewall.conf and the 'noping' and 'filterping' options + in /etc/shorewall/interfaces will all generate an error.
      +
      +
      2. +
    2. It is now possible to direct Shorewall to create a +"label" such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes + and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead + of just the interface name:
      +  
      +    a) In the INTERFACE column of /etc/shorewall/masq
      +    b) In the INTERFACE column of /etc/shorewall/nat
      +  
      3. +
    3. When an interface name is entered in the SUBNET column + of the /etc/shorewall/masq file, Shorewall previously masqueraded +traffic from only the first subnet defined on that interface. It did +not masquerade traffic from:
      +  
      +    a) The subnets associated with other addresses on the +interface.
      +    b) Subnets accessed through local routers.
      +  
      + Beginning with Shorewall 1.3.14, if you enter an interface + name in the SUBNET column, shorewall will use the firewall's routing + table to construct the masquerading/SNAT rules.
      +  
      + Example 1 -- This is how it works in 1.3.14.
      +   
      + + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      + + + 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      +  
      + When upgrading to Shorewall 1.3.14, if you have multiple +local subnets connected to an interface that is specified in the +SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq +file will need changing. In most cases, you will simply be able to remove +redundant entries. In some cases though, you might want to change from +using the interface name to listing specific subnetworks if the change +described above will cause masquerading to occur on subnetworks that you +don't wish to masquerade.
      +  
      + Example 2 -- Suppose that your current config is as follows:
      +   
      + + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      +  
      +    In this case, the second entry in /etc/shorewall/masq +is no longer required.
      +  
      + Example 3 -- What if your current configuration is like this?
      +  
      + + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      +  
      +    In this case, you would want to change the entry in  /etc/shorewall/masq + to:
      + + + 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      +
      4. + +
    +

    1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format

    - -

    Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation. - the PDF may be downloaded from

    -     Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation. + the PDF may be downloaded from

    +         ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
    -     http://slovakia.shorewall.net/pub/shorewall/pdf/ - +     http://slovakia.shorewall.net/pub/shorewall/pdf/ +

    1/17/2003 - shorewall.net has MOVED 

    - +

    Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and -ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A -big thanks to Alex for making this happen.
    -

    - + href="http://www.rettc.com">Rett Consulting, www.shorewall.net and ftp.shorewall.net +are now hosted on a system in Bellevue, Washington. A big thanks to Alex +for making this happen.
    +

    +

    1/13/2003 - Shorewall 1.3.13
    -

    - +

    +

    Just includes a few things that I had on the burner:
    -

    - +

    +
      -
    1. A new 'DNAT-' action has been added for entries in -the /etc/shorewall/rules file. DNAT- is intended for advanced users -who wish to minimize the number of rules that connection requests must -traverse.
      -
      - A Shorewall DNAT rule actually generates two iptables rules: - a header rewriting rule in the 'nat' table and an ACCEPT rule in the - 'filter' table. A DNAT- rule only generates the first of these rules. - This is handy when you have several DNAT rules that would generate the - same ACCEPT rule.
      -
      -    Here are three rules from my previous rules file:
      -
      -         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
      -         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
      -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
      -
      -    These three rules ended up generating _three_ copies -of
      -
      -          ACCEPT net  dmz:206.124.146.177 tcp smtp
      -
      -    By writing the rules this way, I end up with only one -copy of the ACCEPT rule.
      -
      -         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
      -         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
      -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
      -
      -
      2. -
    2. The 'shorewall check' command now prints out the applicable - policy between each pair of zones.
      -
      -
      3. -
    3. A new CLEAR_TC option has been added to shorewall.conf. - If this option is set to 'No' then Shorewall won't clear the current - traffic control rules during [re]start. This setting is intended for - use by people that prefer to configure traffic shaping when the network - interfaces come up rather than when the firewall is started. If that -is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not -supply an /etc/shorewall/tcstart file. That way, your traffic shaping -rules can still use the 'fwmark' classifier based on packet marking defined +
    4. A new 'DNAT-' action has been added for entries +in the /etc/shorewall/rules file. DNAT- is intended for advanced +users who wish to minimize the number of rules that connection requests + must traverse.
      +
      + A Shorewall DNAT rule actually generates two iptables +rules: a header rewriting rule in the 'nat' table and an ACCEPT rule +in the 'filter' table. A DNAT- rule only generates the first of these + rules. This is handy when you have several DNAT rules that would +generate the same ACCEPT rule.
      +
      +    Here are three rules from my previous rules file:
      +
      +         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
      +         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
      +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
      +
      +    These three rules ended up generating _three_ copies + of
      +
      +          ACCEPT net  dmz:206.124.146.177 tcp smtp
      +
      +    By writing the rules this way, I end up with only +one copy of the ACCEPT rule.
      +
      +         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
      +         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
      +         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
      +
      +
      5. +
    5. The 'shorewall check' command now prints out the + applicable policy between each pair of zones.
      +
      +
      6. +
    6. A new CLEAR_TC option has been added to shorewall.conf. + If this option is set to 'No' then Shorewall won't clear the current + traffic control rules during [re]start. This setting is intended for + use by people that prefer to configure traffic shaping when the network + interfaces come up rather than when the firewall is started. If that +is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not +supply an /etc/shorewall/tcstart file. That way, your traffic shaping +rules can still use the 'fwmark' classifier based on packet marking defined in /etc/shorewall/tcrules.
      -
      -
      7. -
    7. A new SHARED_DIR variable has been added that allows - distribution packagers to easily move the shared directory (default - /usr/lib/shorewall). Users should never have a need to change the value - of this shorewall.conf setting.
      -
      8. - -
    - -

    1/6/2003 - BURNOUT -

    - -

    Until further notice, I will not be involved in either Shorewall Development - or Shorewall Support

    - -

    -Tom Eastep
    -

    - -

    12/30/2002 - Shorewall Documentation in PDF Format

    - -

    Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. - the PDF may be downloaded from

    - -

        ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
    -     http://slovakia.shorewall.net/pub/shorewall/pdf/
    -

    - -

    12/27/2002 - Shorewall 1.3.12 Released

    - -

    Features include:
    -

    - -
      -
    1. "shorewall refresh" now reloads the traffic shaping - rules (tcrules and tcstart).
      2. -
    2. "shorewall debug [re]start" now turns off debugging - after an error occurs. This places the point of the failure near - the end of the trace rather than up in the middle of it.
      3. -
    3. "shorewall [re]start" has been speeded up by more - than 40% with my configuration. Your milage may vary.
      4. -
    4. A "shorewall show classifiers" command has been -added which shows the current packet classification filters. The -output from this command is also added as a separate page in "shorewall - monitor"
      5. -
    5. ULOG (must be all caps) is now accepted as a valid - syslog level and causes the subject packets to be logged using -the ULOG target rather than the LOG target. This allows you to run -ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages to a separate log file.
      6. -
    6. If you are running a kernel that has a FORWARD -chain in the mangle table ("shorewall show mangle" will show you -the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes -in shorewall.conf. This allows for - marking input packets based on their destination even when you -are using Masquerading or SNAT.
      7. -
    7. I have cluttered up the /etc/shorewall directory - with empty 'init', 'start', 'stop' and 'stopped' files. If you - already have a file with one of these names, don't worry -- the upgrade - process won't overwrite your file.
      8. -
    8. I have added a new RFC1918_LOG_LEVEL variable to - shorewall.conf. This variable specifies - the syslog level at which packets are logged as a result of entries - in the /etc/shorewall/rfc1918 file. Previously, these packets were - always logged at the 'info' level.
      +
      +
      9. +
    9. A new SHARED_DIR variable has been added that allows + distribution packagers to easily move the shared directory (default + /usr/lib/shorewall). Users should never have a need to change the + value of this shorewall.conf setting.
    -

    12/20/2002 - Shorewall 1.3.12 Beta 3
    -

    - This version corrects a problem with Blacklist logging. - In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the - firewall would fail to start and "shorewall refresh" would also fail.
    - -

    12/20/2002 - Shorewall 1.3.12 Beta 2

    - -

    The first public Beta version of Shorewall 1.3.12 is now available (Beta - 1 was made available only to a limited audience).
    -

    - Features include:
    - +

    1/6/2003 - BURNOUT +

    + +

    Until further notice, I will not be involved in either Shorewall Development + or Shorewall Support

    + +

    -Tom Eastep
    +

    + +

    12/30/2002 - Shorewall Documentation in PDF Format

    + +

    Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. + the PDF may be downloaded from

    + +

        ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
    +     http://slovakia.shorewall.net/pub/shorewall/pdf/
    +

    + +

    12/27/2002 - Shorewall 1.3.12 Released

    + +

    Features include:
    +

    +
      -
    1. "shorewall refresh" now reloads the traffic - shaping rules (tcrules and tcstart).
      2. -
    2. "shorewall debug [re]start" now turns off -debugging after an error occurs. This places the point of the -failure near the end of the trace rather than up in the middle of -it.
      3. -
    3. "shorewall [re]start" has been speeded up -by more than 40% with my configuration. Your milage may vary.
      4. -
    4. A "shorewall show classifiers" command has -been added which shows the current packet classification filters. -The output from this command is also added as a separate page in "shorewall - monitor"
      5. -
    5. ULOG (must be all caps) is now accepted as -a valid syslog level and causes the subject packets to be logged -using the ULOG target rather than the LOG target. This allows you -to run ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages "shorewall refresh" now reloads the traffic +shaping rules (tcrules and tcstart).
      6. +
    6. "shorewall debug [re]start" now turns off debugging + after an error occurs. This places the point of the failure near + the end of the trace rather than up in the middle of it.
      7. +
    7. "shorewall [re]start" has been speeded up by +more than 40% with my configuration. Your milage may vary.
      8. +
    8. A "shorewall show classifiers" command has been + added which shows the current packet classification filters. +The output from this command is also added as a separate page +in "shorewall monitor"
      9. +
    9. ULOG (must be all caps) is now accepted as a +valid syslog level and causes the subject packets to be logged +using the ULOG target rather than the LOG target. This allows you +to run ulogd (available from http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
      10. -
    10. If you are running a kernel that has a FORWARD - chain in the mangle table ("shorewall show mangle" will show you - the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes - in shorewall.conf. This allows for marking input packets based on - their destination even when you are using Masquerading or SNAT.
      11. -
    11. I have cluttered up the /etc/shorewall directory - with empty 'init', 'start', 'stop' and 'stopped' files. If you -already have a file with one of these names, don't worry -- the upgrade -process won't overwrite your file.
      12. - +
    12. If you are running a kernel that has a FORWARD + chain in the mangle table ("shorewall show mangle" will show you + the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes + in shorewall.conf. This allows for + marking input packets based on their destination even when you + are using Masquerading or SNAT.
      13. +
    13. I have cluttered up the /etc/shorewall directory + with empty 'init', 'start', 'stop' and 'stopped' files. If you + already have a file with one of these names, don't worry -- the upgrade + process won't overwrite your file.
      14. +
    14. I have added a new RFC1918_LOG_LEVEL variable + to shorewall.conf. This variable + specifies the syslog level at which packets are logged as a result + of entries in the /etc/shorewall/rfc1918 file. Previously, these +packets were always logged at the 'info' level.
      +
      15. +
    - You may download the Beta from:
    - + +

    12/20/2002 - Shorewall 1.3.12 Beta 3
    +

    + This version corrects a problem with Blacklist logging. + In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the + firewall would fail to start and "shorewall refresh" would also fail.
    + +

    12/20/2002 - Shorewall 1.3.12 Beta 2

    + +

    The first public Beta version of Shorewall 1.3.12 is now available (Beta + 1 was made available only to a limited audience).
    +

    + Features include:
    + +
      +
    1. "shorewall refresh" now reloads the traffic + shaping rules (tcrules and tcstart).
      2. +
    2. "shorewall debug [re]start" now turns off + debugging after an error occurs. This places the point of the + failure near the end of the trace rather than up in the middle of + it.
      3. +
    3. "shorewall [re]start" has been speeded +up by more than 40% with my configuration. Your milage may vary.
      4. +
    4. A "shorewall show classifiers" command +has been added which shows the current packet classification +filters. The output from this command is also added as a separate +page in "shorewall monitor"
      5. +
    5. ULOG (must be all caps) is now accepted +as a valid syslog level and causes the subject packets to be logged + using the ULOG target rather than the LOG target. This allows +you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
      6. +
    6. If you are running a kernel that has a +FORWARD chain in the mangle table ("shorewall show mangle" will +show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes + in shorewall.conf. This allows for marking input packets based +on their destination even when you are using Masquerading or SNAT.
      7. +
    7. I have cluttered up the /etc/shorewall +directory with empty 'init', 'start', 'stop' and 'stopped' files. +If you already have a file with one of these names, don't worry +-- the upgrade process won't overwrite your file.
      8. + +
    + You may download the Beta from:
    +
    http://www.shorewall.net/pub/shorewall/Beta
    - ftp://ftp.shorewall.net/pub/shorewall/Beta
    -
    - + +

    12/12/2002 - Mandrake Multi Network Firewall Powered by Mandrake Linux -

    - Shorewall is at the center of MandrakeSoft's -recently-announced Multi - Network Firewall (MNF) product. Here is the press - release.
    - +

    + Shorewall is at the center of MandrakeSoft's + recently-announced Multi + Network Firewall (MNF) product. Here is the press + release.
    +

    12/7/2002 - Shorewall Support for Mandrake 9.0

    - -

    Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. - I have installed 9.0 on one of my systems and I am now in a -position to support Shorewall users who run Mandrake 9.0.

    - + +

    Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. + I have installed 9.0 on one of my systems and I am now in +a position to support Shorewall users who run Mandrake 9.0.

    +

    12/6/2002 - Debian 1.3.11a Packages Available
    -

    - - -

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - -

    12/3/2002 - Shorewall 1.3.11a

    - -

    This is a bug-fix roll up which includes Roger Aich's fix for DNAT with - excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 - users who don't need rules of this type need not upgrade to 1.3.11.

    - -

    11/24/2002 - Shorewall 1.3.11

    - -

    In this version:

    - -
      -
    • A 'tcpflags' option has been added -to entries in /etc/shorewall/interfaces. - This option causes Shorewall to make a set of sanity check on TCP -packet header flags.
      • -
    • It is now allowed to use 'all' in the - SOURCE or DEST column in a rule. When used, 'all' must appear - by itself (in may not be qualified) and it does not enable intra-zone - traffic. For example, the rule
      -
      -     ACCEPT loc all tcp 80
      -
      - does not enable http traffic from 'loc' to - 'loc'.
      • -
    • Shorewall's use of the 'echo' command - is now compatible with bash clones such as ash and dash.
      • -
    • fw->fw policies now generate a startup - error. fw->fw rules generate a warning and are ignored
      • - -
    - -

    11/14/2002 - Shorewall Documentation in PDF Format

    - -

    Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. - the PDF may be downloaded from

    - -

        ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
    -     http://slovakia.shorewall.net/pub/shorewall/pdf/
    -

    - -

    11/09/2002 - Shorewall is Back at SourceForge -

    - - -

    The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
    -

    +

    -

    11/09/2002 - Shorewall 1.3.10

    +

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    + + +

    12/3/2002 - Shorewall 1.3.11a

    + +

    This is a bug-fix roll up which includes Roger Aich's fix for DNAT with + excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 + users who don't need rules of this type need not upgrade to +1.3.11.

    + +

    11/24/2002 - Shorewall 1.3.11

    In this version:

      -
    • You may now define the contents of a zone dynamically - with the "shorewall add" - and "shorewall delete" commands. These commands are expected - to be used primarily within FreeS/Wan updown -scripts.
      • -
    • Shorewall can now do MAC verification on ethernet segments. -You can specify the set of allowed MAC addresses on the segment -and you can optionally tie each MAC address to one or more IP addresses.
      • -
    • PPTP Servers and Clients running -on the firewall system may now be defined in the /etc/shorewall/tunnels file.
      • -
    • A new 'ipsecnat' tunnel type is -supported for use when the remote -IPSEC endpoint is behind a NAT gateway.
      • -
    • The PATH used by Shorewall may now - be specified in /etc/shorewall/shorewall.conf.
      • -
    • The main firewall script is now -/usr/lib/shorewall/firewall. The script in /etc/init.d/shorewall -is very small and uses /sbin/shorewall to do the real work. -This change makes custom distributions such as for Debian and - for Gentoo easier to manage since it is /etc/init.d/shorewall - that tends to have distribution-dependent code
      • +
    • A 'tcpflags' option has been added + to entries in /etc/shorewall/interfaces. + This option causes Shorewall to make a set of sanity check on TCP +packet header flags.
      • +
    • It is now allowed to use 'all' in + the SOURCE or DEST column in a rule. When used, 'all' must +appear by itself (in may not be qualified) and it does not enable + intra-zone traffic. For example, the rule
      +
      +     ACCEPT loc all tcp 80
      +
      + does not enable http traffic from 'loc' + to 'loc'.
      • +
    • Shorewall's use of the 'echo' command + is now compatible with bash clones such as ash and dash.
      • +
    • fw->fw policies now generate +a startup error. fw->fw rules generate a warning and +are ignored
    +

    11/14/2002 - Shorewall Documentation in PDF Format

    + +

    Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. + the PDF may be downloaded from

    + +

        ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
    +     http://slovakia.shorewall.net/pub/shorewall/pdf/
    +

    + +

    11/09/2002 - Shorewall is Back at SourceForge +

    + + +

    The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
    +

    + + +

    11/09/2002 - Shorewall 1.3.10

    + + +

    In this version:

    + + + + +

    10/24/2002 - Shorewall is now in Gentoo Linux
    -

    - Alexandru Hartmann reports that his -Shorewall package is now a part of the Gentoo Linux distribution. - Thanks Alex!
    +

    + Alexandru Hartmann reports that his + Shorewall package is now a part of the Gentoo Linux distribution. + Thanks Alex!
    + + +

    10/23/2002 - Shorewall 1.3.10 Beta 1

    + In this version:
    + + + + You may download the Beta from:
    + + + + + +

    10/10/2002 -  Debian 1.3.9b Packages Available
    +

    + + +

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    -

    10/23/2002 - Shorewall 1.3.10 Beta 1

    - In this version:
    +

    10/9/2002 - Shorewall 1.3.9b

    + This release rolls up fixes to the + installer and to the firewall script.
    + + +

    10/6/2002 - Shorewall.net now running on RH8.0
    +
    + The firewall and server here at + shorewall.net are now running RedHat release 8.0.
    +
    + 9/30/2002 - Shorewall 1.3.9a

    + Roles up the fix for broken tunnels.
    + + +

    9/30/2002 - TUNNELS Broken in 1.3.9!!!

    + There is an updated firewall script + at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall.
    + + +

    9/28/2002 - Shorewall 1.3.9

    + + +

    In this version:
    +

    - You may download the Beta from:
    +
  • DNS Names are +now allowed in Shorewall config files (although I recommend against + using them).
    • +
  • The connection SOURCE + may now be qualified by both interface and IP address + in a Shorewall rule.
    • +
  • Shorewall startup is + now disabled after initial installation until the +file /etc/shorewall/startup_disabled is removed. This avoids + nasty surprises during reboot for users who install Shorewall + but don't configure it.
    • +
  • The 'functions' and 'version' + files and the 'firewall' symbolic link have been moved + from /var/lib/shorewall to /usr/lib/shorewall to appease + the LFS police at Debian.
    +
    • - - - -

    10/10/2002 -  Debian 1.3.9b Packages Available
    -

    - - -

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - -

    10/9/2002 - Shorewall 1.3.9b

    - This release rolls up fixes to the -installer and to the firewall script.
    - - -

    10/6/2002 - Shorewall.net now running on RH8.0
    -
    - The firewall and server here at shorewall.net - are now running RedHat release 8.0.
    -
    - 9/30/2002 - Shorewall 1.3.9a

    - Roles up the fix for broken tunnels.
    - - -

    9/30/2002 - TUNNELS Broken in 1.3.9!!!

    - There is an updated firewall script - at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.
    - - -

    9/28/2002 - Shorewall 1.3.9

    - - -

    In this version:
    -

    - - -
      -
    • DNS Names are - now allowed in Shorewall config files (although I recommend against - using them).
      • -
    • The connection SOURCE -may now be qualified by both interface and IP address -in a Shorewall rule.
      • -
    • Shorewall startup is now - disabled after initial installation until the file /etc/shorewall/startup_disabled - is removed. This avoids nasty surprises during reboot -for users who install Shorewall but don't configure it.
      • -
    • The 'functions' and 'version' - files and the 'firewall' symbolic link have been moved - from /var/lib/shorewall to /usr/lib/shorewall to appease - the LFS police at Debian.
      -
      • - - +
    - -

    9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
    -

    - 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
    +

    + Brown Paper Bag - A couple of recent configuration - changes at www.shorewall.net broke the Search facility:
    + A couple of recent configuration + changes at www.shorewall.net broke the Search facility:
    - -
    + +
    - +
      -
    1. Mailing List Archive -Search was not available.
      2. -
    2. The Site Search index - was incomplete
      3. -
    3. Only one page of matches - was presented.
      4. - - - -
    -
    - Hopefully these problems -are now corrected. -

    9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability - Restored
    -

    - A couple of recent configuration - changes at www.shorewall.net had the negative effect - of breaking the Search facility:
    - - -
      -
    1. Mailing List Archive -Search was not available.
      2. -
    2. The Site Search index -was incomplete
      3. -
    3. Only one page of matches - was presented.
      4. - - -
    - Hopefully these problems are - now corrected.
    - - -

    9/18/2002 -  Debian 1.3.8 Packages Available
    -

    - - -

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - - -

    9/16/2002 - Shorewall 1.3.8

    - - -

    In this version:
    -

    - - -
      -
    • A NEWNOTSYN option has been - added to shorewall.conf. This option determines whether Shorewall - accepts TCP packets which are not part of an established - connection and that are not 'SYN' packets (SYN flag on and - ACK flag off).
      • -
    • The need for the 'multi' - option to communicate between zones za and zb on the - same interface is removed in the case where the chain 'za2zb' - and/or 'zb2za' exists. 'za2zb' will exist if:
      • - - - -
        -
      • There is -a policy for za to zb; or
        • -
      • There is at least - one rule for za to zb.
        • +
      • Mailing List Archive + Search was not available.
        • +
      • The Site Search index + was incomplete
        • +
      • Only one page of +matches was presented.
        • + +
    + Hopefully these problems + are now corrected. + +

    9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
    +

    + A couple of recent configuration + changes at www.shorewall.net had the negative effect + of breaking the Search facility:
    + + +
      +
    1. Mailing List Archive + Search was not available.
      2. +
    2. The Site Search index + was incomplete
      3. +
    3. Only one page of matches + was presented.
      4. + + +
    + Hopefully these problems +are now corrected.
    + + +

    9/18/2002 -  Debian 1.3.8 Packages Available
    +

    + + +

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    + + +

    9/16/2002 - Shorewall 1.3.8

    + + +

    In this version:
    +

    + + +
      +
    • A NEWNOTSYN option has been + added to shorewall.conf. This option determines whether Shorewall + accepts TCP packets which are not part of an established + connection and that are not 'SYN' packets (SYN flag on and + ACK flag off).
      • +
    • The need for the + 'multi' option to communicate between zones za and + zb on the same interface is removed in the case where the +chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will exist if:
      • + + + +
        +
      • There +is a policy for za to zb; or
        • +
      • There is at + least one rule for za to zb.
        • + + +
      - +
    - +
      -
    • The /etc/shorewall/blacklist - file now contains three columns. In addition to the -SUBNET/ADDRESS column, there are optional PROTOCOL and PORT - columns to block only certain applications from the blacklisted - addresses.
      -
      • +
    • The /etc/shorewall/blacklist + file now contains three columns. In addition to the + SUBNET/ADDRESS column, there are optional PROTOCOL and + PORT columns to block only certain applications from the + blacklisted addresses.
      +
      • - +
    - +

    9/11/2002 - Debian 1.3.7c Packages Available

    - +

    Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    9/2/2002 - Shorewall 1.3.7c

    - -

    This is a role up of a fix for "DNAT" rules where the source zone is $FW - (fw).

    + +

    This is a role up of a fix for "DNAT" rules where the source zone is $FW + (fw).

    - +

    8/31/2002 - I'm not available

    - -

    I'm currently on vacation  -- please respect my need for a couple of - weeks free of Shorewall problem reports.

    + +

    I'm currently on vacation  -- please respect my need for a couple of +weeks free of Shorewall problem reports.

    - +

    -Tom

    - +

    8/26/2002 - Shorewall 1.3.7b

    - -

    This is a role up of the "shorewall refresh" bug fix and the change which - reverses the order of "dhcp" and "norfc1918" checking.

    + +

    This is a role up of the "shorewall refresh" bug fix and the change which + reverses the order of "dhcp" and "norfc1918" +checking.

    - +

    8/26/2002 - French FTP Mirror is Operational

    - +

    ftp://france.shorewall.net/pub/mirrors/shorewall - is now available.

    + href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall + is now available.

    - +

    8/25/2002 - Shorewall Mirror in France

    - -

    Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored - at Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored + at http://france.shorewall.net.

    - +

    8/25/2002 - Shorewall 1.3.7a Debian Packages Available

    - -

    Lorenzo Martignoni reports that the packages for version 1.3.7a are available - at Lorenzo Martignoni reports that the packages for version 1.3.7a are available + at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - -

    8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author - -- Shorewall 1.3.7a released8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author + -- Shorewall 1.3.7a released -

    +

    - -

    1.3.7a corrects problems occurring in rules file processing when starting - Shorewall 1.3.7.

    + +

    1.3.7a corrects problems occurring in rules file processing when starting + Shorewall 1.3.7.

    - +

    8/22/2002 - Shorewall 1.3.7 Released 8/13/2002

    - +

    Features in this release include:

    - +
      -
    • The 'icmp.def' file - is now empty! The rules in that file were required in - ipchains firewalls but are not required in Shorewall. - Users who have ALLOWRELATED=No in shorewall.conf should see the - Upgrade Issues.
      • -
    • A 'FORWARDPING' -option has been added to - shorewall.conf. The effect of setting this -variable to Yes is the same as the effect of adding an ACCEPT - rule for ICMP echo-request in /etc/shorewall/icmpdef. - Users who have such a rule in icmpdef are encouraged - to switch to FORWARDPING=Yes.
      • -
    • The loopback CLASS - A Network (127.0.0.0/8) has been added to the rfc1918 - file.
      • -
    • Shorewall now works - with iptables 1.2.7
      • -
    • The documentation - and web site no longer uses FrontPage themes.
      • +
    • The 'icmp.def' + file is now empty! The rules in that file were required + in ipchains firewalls but are not required in Shorewall. + Users who have ALLOWRELATED=No in shorewall.conf should see +the Upgrade Issues.
      • +
    • A 'FORWARDPING' + option has been added to shorewall.conf. The effect + of setting this variable to Yes is the same as +the effect of adding an ACCEPT rule for ICMP echo-request + in /etc/shorewall/icmpdef. + Users who have such a rule in icmpdef are encouraged + to switch to FORWARDPING=Yes.
      • +
    • The loopback +CLASS A Network (127.0.0.0/8) has been added to the + rfc1918 file.
      • +
    • Shorewall now +works with iptables 1.2.7
      • +
    • The documentation + and web site no longer uses FrontPage themes.
      • - +
    - -

    I would like to thank John Distler for his valuable input regarding TCP - SYN and ICMP treatment in Shorewall. That input -has led to marked improvement in Shorewall in the last -two releases.

    + +

    I would like to thank John Distler for his valuable input regarding TCP + SYN and ICMP treatment in Shorewall. That input + has led to marked improvement in Shorewall in the +last two releases.

    - +

    8/13/2002 - Documentation in the CVS Repository

    - -

    The Shorewall-docs project now contains just the HTML and image files - -the Frontpage files have been removed.

    + +

    The Shorewall-docs project now contains just the HTML and image files +- the Frontpage files have been removed.

    - +

    8/7/2002 - STABLE branch added to CVS Repository

    - -

    This branch will only be updated after I release a new version of Shorewall - so you can always update from this branch to get - the latest stable tree.

    + +

    This branch will only be updated after I release a new version of Shorewall + so you can always update from this branch to +get the latest stable tree.

    - -

    8/7/2002 - Upgrade Issues section added - to the Errata Page

    + +

    8/7/2002 - Upgrade Issues section +added to the Errata Page

    - -

    Now there is one place to go to look for issues involved with upgrading - to recent versions of Shorewall.

    + +

    Now there is one place to go to look for issues involved with upgrading + to recent versions of Shorewall.

    - +

    8/7/2002 - Shorewall 1.3.6

    - +

    This is primarily a bug-fix rollup with a couple of new features:

    - + - +

    7/30/2002 - Shorewall 1.3.5b Released

    - +

    This interim release:

    - + - +

    7/29/2002 - New Shorewall Setup Guide Available

    - +

    The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. - The guide is intended for use by people who are -setting up Shorewall to manage multiple public IP addresses - and by people who want to learn more about Shorewall than - is described in the single-address guides. Feedback on the - new guide is welcome.

    + href="http://www.shorewall.net/shorewall_setup_guide.htm"> http://www.shorewall.net/shorewall_setup_guide.htm. + The guide is intended for use by people who are + setting up Shorewall to manage multiple public IP + addresses and by people who want to learn more about Shorewall +than is described in the single-address guides. Feedback + on the new guide is welcome.

    - +

    7/28/2002 - Shorewall 1.3.5 Debian Package Available

    - -

    Lorenzo Martignoni reports that the packages are version 1.3.5a and are - available at Lorenzo Martignoni reports that the packages are version 1.3.5a and are + available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    7/27/2002 - Shorewall 1.3.5a Released

    - +

    This interim release restores correct handling of REDIRECT rules.

    - +

    7/26/2002 - Shorewall 1.3.5 Released

    - -

    This will be the last Shorewall release for a while. I'm going to be - focusing on rewriting a lot of the documentation.

    + +

    This will be the last Shorewall release for a while. I'm going to be +focusing on rewriting a lot of the documentation.

    - +

     In this version:

    - +
      -
    • Empty and invalid - source and destination qualifiers are now detected - in the rules file. It is a good idea to use the 'shorewall - check' command before you issue a 'shorewall restart' - command be be sure that you don't have any configuration problems - that will prevent a successful restart.
      • -
    • Added MERGE_HOSTS - variable in shorewall.conf - to provide saner behavior of the /etc/shorewall/hosts - file.
      • -
    • The time that the - counters were last reset is now displayed in the - heading of the 'status' and 'show' commands.
      • -
    • A proxyarp option - has been added for entries in /etc/shorewall/interfaces. - This option facilitates Proxy ARP sub-netting as described in - the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). - Specifying the proxyarp option for an interface - causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
      • -
    • The Samples have -been updated to reflect the new capabilities in this - release.
      • +
    • Empty and invalid + source and destination qualifiers are now detected + in the rules file. It is a good idea to use the 'shorewall + check' command before you issue a 'shorewall restart' + command be be sure that you don't have any configuration problems + that will prevent a successful restart.
      • +
    • Added MERGE_HOSTS + variable in shorewall.conf + to provide saner behavior of the /etc/shorewall/hosts + file.
      • +
    • The time that +the counters were last reset is now displayed in the + heading of the 'status' and 'show' commands.
      • +
    • A proxyarp + option has been added for entries in /etc/shorewall/interfaces. + This option facilitates Proxy ARP sub-netting as described in + the Proxy ARP subnetting mini-HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). + Specifying the proxyarp option for an interface + causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp.
      • +
    • The Samples have + been updated to reflect the new capabilities in this + release.
      • - +
    - +

    7/16/2002 - New Mirror in Argentina

    - -

    Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in - Argentina. Thanks Buanzo!!!

    + +

    Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in + Argentina. Thanks Buanzo!!!

    - +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

    - +
      -
    • A new /etc/shorewall/routestopped - file has been added. This file is intended to -eventually replace the routestopped option - in the /etc/shorewall/interface and /etc/shorewall/hosts - files. This new file makes remote firewall administration -easier by allowing any IP or subnet to be enabled while - Shorewall is stopped.
      • -
    • An /etc/shorewall/stopped - extension script has - been added. This script is invoked after Shorewall has - stopped.
      • -
    • A DETECT_DNAT_ADDRS - option has been added to /etc/shoreall/shorewall.conf. - When this option is selected, DNAT rules only apply when - the destination address is the external interface's - primary IP address.
      • -
    • The QuickStart Guide has - been broken into three guides and has been almost entirely - rewritten.
      • -
    • The Samples have -been updated to reflect the new capabilities in this - release.
      • +
    • A new /etc/shorewall/routestopped + file has been added. This file is intended to +eventually replace the routestopped option + in the /etc/shorewall/interface and /etc/shorewall/hosts + files. This new file makes remote firewall administration +easier by allowing any IP or subnet to be enabled while +Shorewall is stopped.
      • +
    • An /etc/shorewall/stopped + extension script has + been added. This script is invoked after Shorewall has + stopped.
      • +
    • A DETECT_DNAT_ADDRS + option has been added to /etc/shoreall/shorewall.conf. + When this option is selected, DNAT rules only apply when + the destination address is the external interface's + primary IP address.
      • +
    • The QuickStart Guide has + been broken into three guides and has been almost entirely + rewritten.
      • +
    • The Samples have + been updated to reflect the new capabilities in this + release.
      • - +
    - +

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

    Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

    - +
      -
    • Entries in /etc/shorewall/interface - that use the wildcard character ("+") now have -the "multi" option assumed.
      • -
    • The 'rfc1918' chain - in the mangle table has been renamed 'man1918' to - make log messages generated from that chain distinguishable - from those generated by the 'rfc1918' chain in the -filter table.
      • -
    • Interface names -appearing in the hosts file are now validated against - the interfaces file.
      • -
    • The TARGET column - in the rfc1918 file is now checked for correctness.
      • -
    • The chain structure - in the nat table has been changed to reduce the - number of rules that a packet must traverse and to correct - problems with NAT_BEFORE_RULES=No
      • -
    • The "hits" command - has been enhanced.
      • +
    • Entries in /etc/shorewall/interface + that use the wildcard character ("+") now have + the "multi" option assumed.
      • +
    • The 'rfc1918' +chain in the mangle table has been renamed 'man1918' + to make log messages generated from that chain distinguishable + from those generated by the 'rfc1918' chain in the + filter table.
      • +
    • Interface names + appearing in the hosts file are now validated against + the interfaces file.
      • +
    • The TARGET column + in the rfc1918 file is now checked for correctness.
      • +
    • The chain structure + in the nat table has been changed to reduce the + number of rules that a packet must traverse and to correct +problems with NAT_BEFORE_RULES=No
      • +
    • The "hits" command + has been enhanced.
      • - +
    - +

    6/25/2002 - Samples Updated for 1.3.2

    - -

    The comments in the sample configuration files have been updated to reflect - new features introduced in Shorewall 1.3.2.

    + +

    The comments in the sample configuration files have been updated to reflect + new features introduced in Shorewall 1.3.2.

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

    Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

    Thanks to Mike Martinez, the Shorewall Documentation is now available for - download in Adobe - PDF format.

    + +

    Thanks to Mike Martinez, the Shorewall Documentation is now available +for download in Adobe PDF format.

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + - +

    6/6/2002 - Why CVS Web access is Password Protected

    - -

    Last weekend, I installed the CVS Web package to provide brower-based access - to the Shorewall CVS repository. Since then, I have had several instances -where my server was almost unusable due to the high load generated by website -copying tools like HTTrack and WebStripper. These mindless tools:

    + +

    Last weekend, I installed the CVS Web package to provide brower-based +access to the Shorewall CVS repository. Since then, I have had several +instances where my server was almost unusable due to the high load generated +by website copying tools like HTTrack and WebStripper. These mindless tools:

    - +
      -
    • Ignore robot.txt -files.
      • -
    • Recursively copy -everything that they find.
      • -
    • Should be classified - as weapons rather than tools.
      • +
    • Ignore robot.txt + files.
      • +
    • Recursively copy + everything that they find.
      • +
    • Should be classified + as weapons rather than tools.
      • - +
    - -

    These tools/weapons are particularly damaging when combined with CVS Web - because they doggedly follow every link in the cgi-generated - HTML resulting in 1000s of executions of the cvsweb.cgi - script. Yesterday, I spend several hours implementing - measures to block these tools but unfortunately, these measures - resulted in my server OOM-ing under even moderate load.

    + +

    These tools/weapons are particularly damaging when combined with CVS Web + because they doggedly follow every link in the + cgi-generated HTML resulting in 1000s of executions + of the cvsweb.cgi script. Yesterday, I spend several + hours implementing measures to block these tools but unfortunately, + these measures resulted in my server OOM-ing under even + moderate load.

    - -

    Until I have the time to understand the cause of the OOM (or until I buy - more RAM if that is what is required), CVS Web access - will remain Password Protected.

    + +

    Until I have the time to understand the cause of the OOM (or until I buy + more RAM if that is what is required), CVS Web + access will remain Password Protected.

    - +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

    Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    6/2/2002 - Samples Corrected

    - -

    The 1.3.0 samples configurations had several serious problems that prevented - DNS and SSH from working properly. These problems - have been corrected in the The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These problems + have been corrected in the 1.3.1 samples.

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

    In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 - includes:

    + +

    In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 + includes:

    - +
      -
    • A 'filterping' interface - option that allows ICMP echo-request (ping) requests - addressed to the firewall to be handled by entries in - /etc/shorewall/rules and /etc/shorewall/policy.
      • +
    • A 'filterping' + interface option that allows ICMP echo-request (ping) + requests addressed to the firewall to be handled by entries + in /etc/shorewall/rules and /etc/shorewall/policy.
      • - +
    - +

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

    In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) - incorporates the following:

    + +

    In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) + incorporates the following:

    - +
      -
    • Support for the -/etc/shorewall/whitelist file has been withdrawn. +
    • Support for the + /etc/shorewall/whitelist file has been withdrawn. If you need whitelisting, see these instructions.
      • - +
    - +

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

    In addition to the changes in Beta 1, this release which carries the - designation 1.2.91 adds:

    + +

    In addition to the changes in Beta 1, this release which carries the +designation 1.2.91 adds:

    - +
      -
    • The structure of -the firewall is changed markedly. There is now an INPUT - and a FORWARD chain for each interface; this reduces the - number of rules that a packet must traverse, especially in - complicated setups.
      • -
    • Sub-zones may now be excluded - from DNAT and REDIRECT rules.
      • -
    • The names of the -columns in a number of the configuration files have -been changed to be more consistent and self-explanatory - and the documentation has been updated accordingly.
      • -
    • The sample configurations - have been updated for 1.3.
      • +
    • The structure +of the firewall is changed markedly. There is now an +INPUT and a FORWARD chain for each interface; this reduces + the number of rules that a packet must traverse, especially + in complicated setups.
      • +
    • Sub-zones may now be excluded + from DNAT and REDIRECT rules.
      • +
    • The names of +the columns in a number of the configuration files + have been changed to be more consistent and self-explanatory + and the documentation has been updated accordingly.
      • +
    • The sample configurations + have been updated for 1.3.
      • - +
    - +

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

    Beta 1 carries the version designation 1.2.90 and implements the following - features:

    + +

    Beta 1 carries the version designation 1.2.90 and implements the following + features:

    - +
      -
    • Simplified rule -syntax which makes the intent of each rule clearer +
    • Simplified rule + syntax which makes the intent of each rule clearer and hopefully makes Shorewall easier to learn.
      • -
    • Upward compatibility - with 1.2 configuration files has been maintained so - that current users can migrate to the new syntax at their - convenience.
      • -
    • WARNING:  Compatibility with the old - parameterized sample configurations has NOT been maintained. - Users still running those configurations should migrate - to the new sample configurations before upgrading to +
    • Upward compatibility + with 1.2 configuration files has been maintained + so that current users can migrate to the new syntax + at their convenience.
      • +
    • WARNING:  Compatibility with the old + parameterized sample configurations has NOT been maintained. + Users still running those configurations should migrate + to the new sample configurations before upgrading to 1.3 Beta 1.
      • - +
    - +

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + - +

    4/30/2002 - Shorewall Debian News

    - -

    Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the Debian -Testing Branch and the Debian -Unstable Branch.

    + +

    Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the +Debian + Testing Branch and the Debian + Unstable Branch.

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

    - +
      -
    • The 'try' command - works again
      • -
    • There is now a single - RPM that also works with SuSE.
      • +
    • The 'try' command + works again
      • +
    • There is now +a single RPM that also works with SuSE.
      • - +
    - +

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - + - +

    Thanks, Lorenzo!

    - +

    4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE

    - -

    Thanks to Stefan Mohr, there - is now a Shorewall 1.2.11 - SuSE RPM available.

    + +

    Thanks to Stefan Mohr, there + is now a Shorewall 1.2.11 + SuSE RPM available.

    - +

    4/13/2002 - Shorewall 1.2.11 Available

    - +

    In this version:

    - +
      -
    • The 'try' command - now accepts an optional timeout. If the timeout is - given in the command, the standard configuration will -automatically be restarted after the new configuration -has been running for that length of time. This prevents - a remote admin from being locked out of the firewall in the -case where the new configuration starts but prevents access.
      • -
    • Kernel route filtering - may now be enabled globally using the new ROUTE_FILTER - parameter in /etc/shorewall/shorewall.conf.
      • -
    • Individual IP source - addresses and/or subnets may now be excluded from - masquerading/SNAT.
      • -
    • Simple "Yes/No" -and "On/Off" values are now case-insensitive in +
    • The 'try' command + now accepts an optional timeout. If the timeout is + given in the command, the standard configuration will automatically + be restarted after the new configuration has been running + for that length of time. This prevents a remote admin from + being locked out of the firewall in the case where the new configuration + starts but prevents access.
      • +
    • Kernel route +filtering may now be enabled globally using the new + ROUTE_FILTER parameter in /etc/shorewall/shorewall.conf.
      • +
    • Individual IP +source addresses and/or subnets may now be excluded + from masquerading/SNAT.
      • +
    • Simple "Yes/No" + and "On/Off" values are now case-insensitive in /etc/shorewall/shorewall.conf.
      • - +
    - +

    4/13/2002 - Hamburg Mirror now has FTP

    - +

    Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  - Thanks Stefan!

    + href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall.  + Thanks Stefan!

    - +

    4/12/2002 - New Mirror in Hamburg

    - -

    Thanks to Stefan Mohr, there - is now a mirror of the Shorewall website at http://germany.shorewall.net. -

    + +

    Thanks to Stefan Mohr, there + is now a mirror of the Shorewall website at + http://germany.shorewall.net. +

    - +

    4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available

    - -

    Version 1.1 of the QuickStart - Guide is now available. Thanks to those who -have read version 1.0 and offered their suggestions. -Corrections have also been made to the sample scripts.

    + +

    Version 1.1 of the QuickStart + Guide is now available. Thanks to those who + have read version 1.0 and offered their suggestions. + Corrections have also been made to the sample scripts.

    - +

    4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available

    - -

    Version 1.0 of the QuickStart - Guide is now available. This Guide and its accompanying - sample configurations are expected to provide a replacement - for the recently withdrawn parameterized samples. -

    + +

    Version 1.0 of the QuickStart + Guide is now available. This Guide and its + accompanying sample configurations are expected +to provide a replacement for the recently withdrawn parameterized + samples.

    - +

    4/8/2002 - Parameterized Samples Withdrawn

    - +

    Although the parameterized - samples have allowed people to get a firewall - up and running quickly, they have unfortunately set -the wrong level of expectation among those who have used - them. I am therefore withdrawing support for the samples - and I am recommending that they not be used in new Shorewall installations.

    + href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized + samples have allowed people to get a firewall + up and running quickly, they have unfortunately set + the wrong level of expectation among those who have used + them. I am therefore withdrawing support for the samples + and I am recommending that they not be used in new Shorewall + installations.

    - +

    4/2/2002 - Updated Log Parser

    - -

    John Lodge has provided an updated - version of his CGI-based log parser - with corrected date handling.

    + +

    John Lodge has provided an updated + version of his CGI-based log parser + with corrected date handling.

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - -

    The quick search on the home page now excludes the mailing list archives. - The Extended Search - allows excluding the archives or restricting the search - to just the archives. An archive search form is also available - on the mailing - list information page.

    + +

    The quick search on the home page now excludes the mailing list archives. + The Extended Search + allows excluding the archives or restricting the +search to just the archives. An archive search form +is also available on the mailing list information + page.

    - +

    3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)

    - + - +

    3/25/2002 - Log Parser Available

    - +

    John Lodge has provided a CGI-based log parser for Shorewall. Thanks - John.

    + href="pub/shorewall/parsefw/">CGI-based log parser for Shorewall. Thanks + John.

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

    - +
      -
    • A "shorewall try" - command has been added (syntax: shorewall try - <configuration directory>). This command -attempts "shorewall -c <configuration directory> - start" and if that results in the firewall being stopped -due to an error, a "shorewall start" command is executed. The - 'try' command allows you to create a new configuration and attempt - to start it; if there is an error that leaves your firewall - in the stopped state, it will automatically be restarted using +
    • A "shorewall +try" command has been added (syntax: shorewall try + <configuration directory>). This + command attempts "shorewall -c <configuration directory> + start" and if that results in the firewall being stopped + due to an error, a "shorewall start" command is executed. The + 'try' command allows you to create a new configuration and attempt + to start it; if there is an error that leaves your firewall + in the stopped state, it will automatically be restarted using the default configuration (in /etc/shorewall).
      • -
    • A new variable ADD_SNAT_ALIASES - has been added to /etc/shorewall/shorewall.conf. - If this variable is set to "Yes", Shorewall will -automatically add IP addresses listed in the third - column of the /etc/shorewall/masq - file.
      • -
    • Copyright notices - have been added to the documenation.
      • +
    • A new variable + ADD_SNAT_ALIASES has been added to /etc/shorewall/shorewall.conf. + If this variable is set to "Yes", Shorewall will automatically + add IP addresses listed in the third column of +the /etc/shorewall/masq +file.
      • +
    • Copyright notices + have been added to the documenation.
      • - +
    - +

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - + - +

    3/1/2002 - 1.2.8 Debian Package is Available

    - +

    See http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    2/25/2002 - New Two-interface Sample

    - -

    I've enhanced the two interface sample to allow access from the firewall - to servers in the local zone - - http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

    + +

    I've enhanced the two interface sample to allow access from the firewall + to servers in the local zone - + http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz

    - +

    2/23/2002 - Shorewall 1.2.8 Released

    - -

    Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects - problems associated with the lock file used to prevent multiple state-changing - operations from occuring simultaneously. My apologies - for any inconvenience my carelessness may have caused.

    + +

    Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects + problems associated with the lock file used to prevent multiple state-changing + operations from occuring simultaneously. My apologies + for any inconvenience my carelessness may have caused.

    - +

    2/22/2002 - Shorewall 1.2.7 Released

    - +

    In this version:

    - +
      -
    • UPnP probes (UDP -destination port 1900) are now silently dropped in -the common chain
      • -
    • RFC 1918 checking - in the mangle table has been streamlined to no longer - require packet marking. RFC 1918 checking in the filter +
    • UPnP probes (UDP + destination port 1900) are now silently dropped +in the common chain
      • +
    • RFC 1918 checking + in the mangle table has been streamlined to no longer + require packet marking. RFC 1918 checking in the filter table has been changed to require half as many rules as previously.
      • -
    • A 'shorewall check' - command has been added that does a cursory validation - of the zones, interfaces, hosts, rules and policy files.
      • +
    • A 'shorewall +check' command has been added that does a cursory +validation of the zones, interfaces, hosts, rules and + policy files.
      • - +
    - +

    2/18/2002 - 1.2.6 Debian Package is Available

    - +

    See http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    2/8/2002 - Shorewall 1.2.6 Released

    - +

    In this version:

    - +
      -
    • $-variables may -now be used anywhere in the configuration files except - /etc/shorewall/zones.
      • -
    • The interfaces and - hosts files now have their contents validated before - any changes are made to the existing Netfilter configuration. - The appearance of a zone name that isn't defined in /etc/shorewall/zones - causes "shorewall start" and "shorewall restart" to abort - without changing the Shorewall state. Unknown options in either - file cause a warning to be issued.
      • -
    • A problem occurring - when BLACKLIST_LOGLEVEL was not set has been corrected.
      • +
    • $-variables may + now be used anywhere in the configuration files except + /etc/shorewall/zones.
      • +
    • The interfaces + and hosts files now have their contents validated + before any changes are made to the existing Netfilter + configuration. The appearance of a zone name that isn't + defined in /etc/shorewall/zones causes "shorewall start" + and "shorewall restart" to abort without changing the Shorewall + state. Unknown options in either file cause a warning to be + issued.
      • +
    • A problem occurring + when BLACKLIST_LOGLEVEL was not set has been corrected.
      • - +
    - +

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - +

    see http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    2/1/2002 - Shorewall 1.2.5 Released

    - -

    Due to installation problems with Shorewall 1.2.4, I have released Shorewall - 1.2.5. Sorry for the rapid-fire development.

    + +

    Due to installation problems with Shorewall 1.2.4, I have released Shorewall + 1.2.5. Sorry for the rapid-fire development.

    - +

    In version 1.2.5:

    - +
      -
    • The installation -problems have been corrected.
      • -
    • The installation + problems have been corrected.
      • +
    • SNAT is now supported.
      • -
    • A "shorewall version" - command has been added
      • -
    • The default value -of the STATEDIR variable in /etc/shorewall/shorewall.conf - has been changed to /var/lib/shorewall in order to -conform to the GNU/Linux File Hierarchy Standard, Version - 2.2.
      • +
    • A "shorewall version" + command has been added
      • +
    • The default value + of the STATEDIR variable in /etc/shorewall/shorewall.conf + has been changed to /var/lib/shorewall in order + to conform to the GNU/Linux File Hierarchy Standard, Version + 2.2.
      • - +
    - +

    1/28/2002 - Shorewall 1.2.4 Released

    - +
      -
    • The "fw" zone may now be given a different name.
      • -
    • You may now place -end-of-line comments (preceded by '#') in any of the - configuration files
      • -
    • There is now protection - against against two state changing operations -occuring concurrently. This is implemented using the 'lockfile' - utility if it is available (lockfile is part of procmail); - otherwise, a less robust technique is used. The lockfile - is created in the STATEDIR defined in /etc/shorewall/shorewall.conf - and has the name "lock".
      • -
    • "shorewall start" -no longer fails if "detect" is specified in /etc/shorewall/interfaces - for an interface with subnet mask 255.255.255.255.
      • +
    • The "fw" zone + may now be given a different +name.
      • +
    • You may now place + end-of-line comments (preceded by '#') in any of +the configuration files
      • +
    • There is now protection + against against two state changing operations + occuring concurrently. This is implemented using the 'lockfile' + utility if it is available (lockfile is part of procmail); + otherwise, a less robust technique is used. The lockfile + is created in the STATEDIR defined in /etc/shorewall/shorewall.conf + and has the name "lock".
      • +
    • "shorewall start" + no longer fails if "detect" is specified in + /etc/shorewall/interfaces + for an interface with subnet mask 255.255.255.255.
      • - +
    - +

    1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html

    - +

    1/20/2002 - Corrected firewall script available 

    - -

    Corrects a problem with BLACKLIST_LOGLEVEL. See the - errata for details.

    + +

    Corrects a problem with BLACKLIST_LOGLEVEL. See the + errata for details.

    - +

    1/19/2002 - Shorewall 1.2.3 Released

    - +

    This is a minor feature and bugfix release. The single new feature is:

    - +
      -
    • Support for TCP MSS - Clamp to PMTU -- This support is usually required when - the internet connection is via PPPoE or PPTP and may -be enabled using the CLAMPMSS - option in /etc/shorewall/shorewall.conf.
      • +
    • Support for TCP + MSS Clamp to PMTU -- This support is usually required + when the internet connection is via PPPoE or PPTP and + may be enabled using the CLAMPMSS option in /etc/shorewall/shorewall.conf.
      • - +
    - +

    The following problems were corrected:

    - +
      -
    • The "shorewall status" - command no longer hangs.
      • -
    • The "shorewall monitor" - command now displays the icmpdef chain
      • -
    • The CLIENT PORT(S) - column in tcrules is no longer ignored
      • +
    • The "shorewall +status" command no longer hangs.
      • +
    • The "shorewall +monitor" command now displays the icmpdef chain
      • +
    • The CLIENT PORT(S) + column in tcrules is no longer ignored
      • - +
    - +

    1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release

    - -

    Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution - that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo - for details.

    + +

    Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution + that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo + for details.

    - +

    1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2 - Shorewall Debian package is now available. There is - a link to Lorenzo's site from the Lorenzo Martignoni, a 1.2.2 + Shorewall Debian package is now available. There + is a link to Lorenzo's site from the Shorewall download page.

    - +

    1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores - the "shorewall status" command to health.

    + href="/pub/shorewall/errata/1.2.2/shorewall">This corrected version restores + the "shorewall status" command to health.

    - +

    1/8/2002 - Shorewall 1.2.2 Released

    - +

    In version 1.2.2

    - +
      -
    • Support for IP blacklisting - has been added +
    • Support for IP +blacklisting has been added - + +
        -
      • You specify whether - you want packets from blacklisted hosts dropped or - rejected using the BLACKLIST_DISPOSITION - setting in /etc/shorewall/shorewall.conf
        • -
      • You specify whether - you want packets from blacklisted hosts logged and - at what syslog level using the BLACKLIST_LOGLEVEL -setting in /etc/shorewall/shorewall.conf
        • -
      • You list the IP -addresses/subnets that you wish to blacklist in - /etc/shorewall/blacklist
        • -
      • You specify the -interfaces you want checked against the blacklist - using the new "blacklist" - option in /etc/shorewall/interfaces.
        • -
      • The black list -is refreshed from /etc/shorewall/blacklist by the +
      • You specify +whether you want packets from blacklisted hosts dropped + or rejected using the BLACKLIST_DISPOSITION + setting in /etc/shorewall/shorewall.conf
        • +
      • You specify +whether you want packets from blacklisted hosts logged + and at what syslog level using the BLACKLIST_LOGLEVEL + setting in /etc/shorewall/shorewall.conf
        • +
      • You list the +IP addresses/subnets that you wish to blacklist in + /etc/shorewall/blacklist
        • +
      • You specify +the interfaces you want checked against the blacklist + using the new "blacklist" + option in /etc/shorewall/interfaces.
        • +
      • The black list + is refreshed from /etc/shorewall/blacklist by the "shorewall refresh" command.
        • - - + +
      -
      • -
    • Use of TCP RST replies - has been expanded  +
      • +
    • Use of TCP RST +replies has been expanded  - + +
        -
      • TCP connection -requests rejected because of a REJECT policy are now - replied with a TCP RST packet.
        • -
      • TCP connection -requests rejected because of a protocol=all rule in - /etc/shorewall/rules are now replied with a TCP RST +
      • TCP connection + requests rejected because of a REJECT policy are now + replied with a TCP RST packet.
        • +
      • TCP connection + requests rejected because of a protocol=all rule in + /etc/shorewall/rules are now replied with a TCP RST packet.
        • - - -
      -
      • -
    • A LOGFILE specification -has been added to /etc/shorewall/shorewall.conf. LOGFILE is used - to tell the /sbin/shorewall program where to look for Shorewall - messages.
      • - + +
    + +
  • A LOGFILE specification has + been added to /etc/shorewall/shorewall.conf. LOGFILE is used + to tell the /sbin/shorewall program where to look for Shorewall + messages.
    • + + - +

    1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates - to the previously-released samples. There are two -new rules added:

    + target="_blank">version 1.2.0) released.     These are minor updates + to the previously-released samples. There are two + new rules added:

    - +
      -
    • Unless you have explicitly - enabled Auth connections (tcp port 113) to your - firewall, these connections will be REJECTED rather than - DROPPED. This speeds up connection establishment to some -servers.
      • -
    • Orphan DNS replies - are now silently dropped.
      • +
    • Unless you have + explicitly enabled Auth connections (tcp port 113) + to your firewall, these connections will be REJECTED +rather than DROPPED. This speeds up connection establishment + to some servers.
      • +
    • Orphan DNS replies + are now silently dropped.
      • - +
    - +

    See the README file for upgrade instructions.

    - +

    1/1/2002 - Shorewall Mailing List Moving

    - -

    The Shorewall mailing list hosted at - Sourceforge is moving to Shorewall.net. If you - are a current subscriber to the list at Sourceforge, please - see these instructions. - If you would like to subscribe to the new list, visit - http://www.shorewall.net/mailman/listinfo/shorewall-users.

    + +

    The Shorewall mailing list hosted at + Sourceforge is moving to Shorewall.net. If +you are a current subscriber to the list at Sourceforge, + please see these instructions. + If you would like to subscribe to the new list, +visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

    - +

    12/31/2001 - Shorewall 1.2.1 Released

    - +

    In version 1.2.1:

    - + - -

    12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing -1.2 on 12/21/2001

    + +

    12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist +releasing 1.2 on 12/21/2001

    - +

    Version 1.2 contains the following new features:

    - + - -

    For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current version 1.1.x - users will not be forced into a quick upgrade to 1.2.0 - just to have access to bug fixes.

    + +

    For the next month or so, I will continue to provide corrections to version + 1.1.18 as necessary so that current version 1.1.x + users will not be forced into a quick upgrade to 1.2.0 + just to have access to bug fixes.

    - -

    For those of you who have installed one of the Beta RPMS, you will need - to use the "--oldpackage" option when upgrading to - 1.2.0:

    + +

    For those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading + to 1.2.0:

    - -
    + +
    - +

    rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

    -
    +
    - -

    12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror in Texas. - This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at 12/19/2001 - Thanks to Steve + Cowles, there is now a Shorewall mirror in Texas. + This web site is mirrored at http://www.infohiiway.com/shorewall + and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

    - +

    11/30/2001 - A new set of the parameterized Sample -Configurations has been released. In this version:

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample + Configurations has been released. In this version:

    - +
      -
    • Ping is now allowed - between the zones.
      • -
    • In the three-interface - configuration, it is now possible to configure the - internet services that are to be available to servers in -the DMZ. 
      • +
    • Ping is now allowed + between the zones.
      • +
    • In the three-interface + configuration, it is now possible to configure the + internet services that are to be available to servers in + the DMZ. 
      • - +
    - +

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    - +

    In this version:

    - +
      -
    • The spelling of ADD_IP_ALIASES - has been corrected in the shorewall.conf file
      • -
    • The logic for deleting - user-defined chains has been simplified so that it - avoids a bug in the LRP version of the 'cut' utility.
      • -
    • The /var/lib/lrpkg/shorwall.conf - file has been corrected to properly display the - NAT entry in that file.
      • +
    • The spelling of + ADD_IP_ALIASES has been corrected in the shorewall.conf + file
      • +
    • The logic for +deleting user-defined chains has been simplified so + that it avoids a bug in the LRP version of the 'cut' utility.
      • +
    • The /var/lib/lrpkg/shorwall.conf + file has been corrected to properly display the + NAT entry in that file.
      • - +
    - -

    11/19/2001 - Thanks to Juraj - Ontkanin, there is now a Shorewall mirror - in the Slovak Republic. The website is now mirrored - at http://www.nrg.sk/mirror/shorewall - and the FTP site is mirrored at 11/19/2001 - Thanks to Juraj + Ontkanin, there is now a Shorewall mirror + in the Slovak Republic. The website is now mirrored + at http://www.nrg.sk/mirror/shorewall + and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

    + +

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. + There are three sample configurations:

    + -

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. - There are three sample configurations:

    - -
      -
    • One Interface -- -for a standalone system.
      • -
    • Two Interfaces -- -A masquerading firewall.
      • -
    • Three Interfaces --- A masquerading firewall with DMZ.
      • +
    • One Interface +-- for a standalone system.
      • +
    • Two Interfaces +-- A masquerading firewall.
      • +
    • Three Interfaces + -- A masquerading firewall with DMZ.
      • - +
    - +

    Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 - . See the README file for instructions.

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17"> ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 + . See the README file for instructions.

    - -

    11/1/2001 - The current version of Shorewall is 1.1.17.  I intend - this to be the last of the 1.1 Shorewall -releases.

    + +

    11/1/2001 - The current version of Shorewall is 1.1.17.  I intend + this to be the last of the 1.1 Shorewall + releases.

    - +

    In this version:

    - + - -

    10/22/2001 - The current version of Shorewall is 1.1.16. In this - version:

    + +

    10/22/2001 - The current version of Shorewall is 1.1.16. In this + version:

    - +
      -
    • A new "shorewall -show connections" command has been added.
      • -
    • In the "shorewall -monitor" output, the currently tracked connections - are now shown on a separate page.
      • -
    • Prior to this release, - Shorewall unconditionally added the external IP - adddress(es) specified in /etc/shorewall/nat. Beginning - with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be - set to "no" (or "No") to inhibit this behavior. +
    • A new "shorewall + show connections" command has been added.
      • +
    • In the "shorewall + monitor" output, the currently tracked connections + are now shown on a separate page.
      • +
    • Prior to this +release, Shorewall unconditionally added the external + IP adddress(es) specified in /etc/shorewall/nat. Beginning + with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be + set to "no" (or "No") to inhibit this behavior. This allows IP aliases created using your distribution's - network configuration tools to be used in static + network configuration tools to be used in static NAT. 
      • - + +
    + + +

    10/15/2001 - The current version of Shorewall is 1.1.15. In this + version:

    + + +
      +
    • Support for nested + zones has been improved. See the documentation for details
      • +
    • Shorewall now +correctly checks the alternate configuration directory + for the 'zones' file.
      • + +
    -

    10/15/2001 - The current version of Shorewall is 1.1.15. In this - version:

    +

    10/4/2001 - The current version of Shorewall is 1.1.14. In this + version

    - +
      -
    • Support for nested - zones has been improved. See the documentation for -details
      • -
    • Shorewall now correctly - checks the alternate configuration directory for - the 'zones' file.
      • +
    • Shorewall now +supports alternate configuration directories. When + an alternate directory is specified when starting or +restarting Shorewall (e.g., "shorewall -c /etc/testconf + restart"), Shorewall will first look for configuration files + in the alternate directory then in /etc/shorewall. To +create an alternate configuration simply:
      + 1. Create a New +Directory
      + 2. Copy to that +directory any of your configuration files that you + want to change.
      + 3. Modify the copied + files as needed.
      + 4. Restart Shorewall + specifying the new directory.
      • +
    • The rules for +allowing/disallowing icmp echo-requests (pings) are + now moved after rules created when processing the rules + file. This allows you to add rules that selectively allow/deny + ping based on source or destination address.
      • +
    • Rules that specify + multiple client ip addresses or subnets no longer cause + startup failures.
      • +
    • Zone names in +the policy file are now validated against the zones + file.
      • +
    • If you have packet mangling support + enabled, the "norfc1918" + interface option now logs and drops any incoming packets + on the interface that have an RFC 1918 destination + address.
      • - +
    - -

    10/4/2001 - The current version of Shorewall is 1.1.14. In this - version

    + +

    9/12/2001 - The current version of Shorewall is 1.1.13. In this + version

    - +
      -
    • Shorewall now supports - alternate configuration directories. When an -alternate directory is specified when starting or restarting - Shorewall (e.g., "shorewall -c /etc/testconf restart"), - Shorewall will first look for configuration files in the alternate - directory then in /etc/shorewall. To create an alternate -configuration simply:
      - 1. Create a New Directory
      - 2. Copy to that directory - any of your configuration files that you want to - change.
      - 3. Modify the copied - files as needed.
      - 4. Restart Shorewall - specifying the new directory.
      • -
    • The rules for allowing/disallowing - icmp echo-requests (pings) are now moved after - rules created when processing the rules file. This allows - you to add rules that selectively allow/deny ping based -on source or destination address.
      • -
    • Rules that specify - multiple client ip addresses or subnets no longer cause - startup failures.
      • -
    • Zone names in the -policy file are now validated against the zones file.
      • -
    • If you have packet mangling support - enabled, the "norfc1918" - interface option now logs and drops any incoming packets - on the interface that have an RFC 1918 destination - address.
      • +
    • Shell variables + can now be used to parameterize Shorewall rules.
      • +
    • The second column + in the hosts file may now contain a comma-separated + list.
      +
      + Example:
      +     sea    eth0:130.252.100.0/24,206.191.149.0/24
      • +
    • Handling of multi-zone + interfaces has been improved. See the documentation for the /etc/shorewall/interfaces + file.
      • - +
    - -

    9/12/2001 - The current version of Shorewall is 1.1.13. In this - version

    + +

    8/28/2001 - The current version of Shorewall is 1.1.12. In this + version

    - +
      -
    • Shell variables can - now be used to parameterize Shorewall rules.
      • -
    • The second column -in the hosts file may now contain a comma-separated - list.
      -
      - Example:
      -     sea    eth0:130.252.100.0/24,206.191.149.0/24
      • -
    • Handling of multi-zone - interfaces has been improved. See the documentation for the /etc/shorewall/interfaces - file.
      • +
    • Several columns + in the rules file may now contain comma-separated + lists.
      • +
    • Shorewall is now + more rigorous in parsing the options in /etc/shorewall/interfaces.
      • +
    • Complementation + using "!" is now supported in rules.
      • - +
    - -

    8/28/2001 - The current version of Shorewall is 1.1.12. In this - version

    + +

    7/28/2001 - The current version of Shorewall is 1.1.11. In this + version

    - +
      -
    • Several columns in - the rules file may now contain comma-separated lists.
      • -
    • Shorewall is now -more rigorous in parsing the options in /etc/shorewall/interfaces.
      • -
    • Complementation using - "!" is now supported in rules.
      • +
    • A "shorewall refresh" + command has been added to allow for refreshing + the rules associated with the broadcast address on a dynamic + interface. This command should be used in place of "shorewall + restart" when the internet interface's IP address changes.
      • +
    • The /etc/shorewall/start + file (if any) is now processed after all temporary + rules have been deleted. This change prevents the accidental + removal of rules added during the processing of that + file.
      • +
    • The "dhcp" interface + option is now applicable to firewall interfaces used + by a DHCP server running on the firewall.
      • +
    • The RPM can now + be built from the .tgz file using "rpm -tb" 
      • - +
    - -

    7/28/2001 - The current version of Shorewall is 1.1.11. In this - version

    + +

    7/6/2001 - The current version of Shorewall is 1.1.10. In this +version

    - +
      -
    • A "shorewall refresh" - command has been added to allow for refreshing the - rules associated with the broadcast address on a dynamic - interface. This command should be used in place of "shorewall - restart" when the internet interface's IP address changes.
      • -
    • The /etc/shorewall/start - file (if any) is now processed after all temporary - rules have been deleted. This change prevents the accidental - removal of rules added during the processing of that - file.
      • -
    • The "dhcp" interface - option is now applicable to firewall interfaces used - by a DHCP server running on the firewall.
      • -
    • The RPM can now be - built from the .tgz file using "rpm -tb" 
      • - - -
    - - -

    7/6/2001 - The current version of Shorewall is 1.1.10. In this version

    - - -
      -
    • Shorewall now enables - Ipv4 Packet Forwarding by default. Packet forwarding - may be disabled by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf. - If you don't want Shorewall to enable or disable packet - forwarding, add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf - file.
      • -
    • The "shorewall hits" - command no longer lists extraneous service names - in its last report.
      • -
    • Erroneous instructions - in the comments at the head of the firewall script +
    • Shorewall now +enables Ipv4 Packet Forwarding by default. Packet forwarding + may be disabled by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf. + If you don't want Shorewall to enable or disable + packet forwarding, add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf + file.
      • +
    • The "shorewall +hits" command no longer lists extraneous service + names in its last report.
      • +
    • Erroneous instructions + in the comments at the head of the firewall script have been corrected.
      • - +
    - -

    6/23/2001 - The current version of Shorewall is 1.1.9. In this version

    + +

    6/23/2001 - The current version of Shorewall is 1.1.9. In this +version

    - + - -

    6/18/2001 - The current version of Shorewall is 1.1.8. In this version

    + +

    6/18/2001 - The current version of Shorewall is 1.1.8. In this +version

    - + - +

    6/2/2001 - The current version of Shorewall is 1.1.7. In this version

    - +
      -
    • The TOS rules are -now deleted when the firewall is stopped.
      • -
    • The .rpm will now -install regardless of which version of iptables is - installed.
      • -
    • The .rpm will now -install without iproute2 being installed.
      • -
    • The documentation -has been cleaned up.
      • -
    • The sample configuration - files included in Shorewall have been formatted +
    • The TOS rules +are now deleted when the firewall is stopped.
      • +
    • The .rpm will +now install regardless of which version of iptables + is installed.
      • +
    • The .rpm will +now install without iproute2 being installed.
      • +
    • The documentation + has been cleaned up.
      • +
    • The sample configuration + files included in Shorewall have been formatted to 80 columns for ease of editing on a VGA console.
      • - +
    - -

    5/25/2001 - The current version of Shorewall is 1.1.6. In this version

    + +

    5/25/2001 - The current version of Shorewall is 1.1.6. In this +version

    - +
      -
    • You may now rate-limit the - packet log.
      • -
    • Previous versions - of Shorewall have an implementation of Static NAT which - violates the principle of least surprise.  NAT only -occurs for packets arriving at (DNAT) or send from (SNAT) -the interface named in the INTERFACE column of /etc/shorewall/nat. -Beginning with version 1.1.6, NAT effective regardless of -which interface packets come from or are destined to. To get -compatibility with prior versions, I have added a new "ALL "ALL INTERFACES"  column to /etc/shorewall/nat. - By placing "no" or "No" in the new column, the NAT behavior - of prior versions may be retained. 
      • -
    • The treatment of - IPSEC Tunnels where the remote - gateway is a standalone system has been improved. Previously, - it was necessary to include an additional rule allowing UDP port -500 traffic to pass through the tunnel. Shorewall will now create - this rule automatically when you place the name of the remote peer's - zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
      • +
    • You may now rate-limit the +packet log.
      • +
    • Previous + versions of Shorewall have an implementation of Static NAT + which violates the principle of least surprise.  +NAT only occurs for packets arriving at (DNAT) or send +from (SNAT) the interface named in the INTERFACE column of + /etc/shorewall/nat. Beginning with version 1.1.6, NAT effective + regardless of which interface packets come from or are destined +to. To get compatibility with prior versions, I have added + a new "ALL "ALL INTERFACES"  column + to /etc/shorewall/nat. By placing "no" or "No" in +the new column, the NAT behavior of prior versions may be +retained. 
      • +
    • The treatment +of IPSEC Tunnels where the remote + gateway is a standalone system has been improved. Previously, + it was necessary to include an additional rule allowing UDP +port 500 traffic to pass through the tunnel. Shorewall will now + create this rule automatically when you place the name of the +remote peer's zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
      • - +
    - -

    5/20/2001 - The current version of Shorewall is 1.1.5. In this version

    + +

    5/20/2001 - The current version of Shorewall is 1.1.5. In this +version

    - + - -

    5/10/2001 - The current version of Shorewall is 1.1.4. In this version

    + +

    5/10/2001 - The current version of Shorewall is 1.1.4. In this +version

    - +
      -
    • Accepting RELATED connections - is now optional.
      • -
    • Corrected problem -where if "shorewall start" aborted early (due to -kernel configuration errors for example), superfluous 'sed' - error messages were reported.
      • -
    • Corrected rules generated - for port redirection.
      • -
    • The order in which - iptables kernel modules are loaded has been corrected - (Thanks to Mark Pavlidis). 
      • +
    • Accepting RELATED connections + is now optional.
      • +
    • Corrected problem + where if "shorewall start" aborted early (due +to kernel configuration errors for example), superfluous +'sed' error messages were reported.
      • +
    • Corrected rules + generated for port redirection.
      • +
    • The order in which + iptables kernel modules are loaded has been corrected + (Thanks to Mark Pavlidis). 
      • - +
    - -

    4/28/2001 - The current version of Shorewall is 1.1.3. In this version

    + +

    4/28/2001 - The current version of Shorewall is 1.1.3. In this +version

    - +
      -
    • Correct message issued - when Proxy ARP address added (Thanks to Jason Kirtland).
      • -
    • /tmp/shorewallpolicy-$$ - is now removed if there is an error while starting - the firewall.
      • -
    • /etc/shorewall/icmp.def - and /etc/shorewall/common.def are now used to define - the icmpdef and common chains unless overridden by the - presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
      • -
    • In the .lrp, the -file /var/lib/lrpkg/shorwall.conf has been corrected. - An extra space after "/etc/shorwall/policy" has been +
    • Correct message + issued when Proxy ARP address added (Thanks to Jason + Kirtland).
      • +
    • /tmp/shorewallpolicy-$$ + is now removed if there is an error while starting + the firewall.
      • +
    • /etc/shorewall/icmp.def + and /etc/shorewall/common.def are now used to +define the icmpdef and common chains unless overridden +by the presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
      • +
    • In the .lrp, the + file /var/lib/lrpkg/shorwall.conf has been corrected. + An extra space after "/etc/shorwall/policy" has been removed and "/etc/shorwall/rules" has been added.
      • -
    • When a sub-shell -encounters a fatal error and has stopped the firewall, - it now kills the main shell so that the main shell will +
    • When a sub-shell + encounters a fatal error and has stopped the firewall, + it now kills the main shell so that the main shell will not continue.
      • -
    • A problem has been - corrected where a sub-shell stopped the firewall - and main shell continued resulting in a perplexing error - message referring to "common.so" resulted.
      • -
    • Previously, placing - "-" in the PORT(S) column in /etc/shorewall/rules resulted - in an error message during start. This has been corrected.
      • -
    • The first line of -"install.sh" has been corrected -- I had inadvertently - deleted the initial "#".
      • +
    • A problem has +been corrected where a sub-shell stopped the firewall + and main shell continued resulting in a perplexing error + message referring to "common.so" resulted.
      • +
    • Previously, placing + "-" in the PORT(S) column in /etc/shorewall/rules + resulted in an error message during start. This has been +corrected.
      • +
    • The first line +of "install.sh" has been corrected -- I had inadvertently + deleted the initial "#".
      • - +
    - -

    4/12/2001 - The current version of Shorewall is 1.1.2. In this version

    + +

    4/12/2001 - The current version of Shorewall is 1.1.2. In this +version

    - +
      -
    • Port redirection -now works again.
      • -
    • The icmpdef and common - chains may now be user-defined.
      • -
    • The firewall no longer - fails to start if "routefilter" is specified for - an interface that isn't started. A warning message is now - issued in this case.
      • -
    • The LRP Version is - renamed "shorwall" for 8,3 MSDOS file system compatibility.
      • -
    • A couple of LRP-specific - problems were corrected.
      • +
    • Port redirection + now works again.
      • +
    • The icmpdef and + common chains may now + be user-defined.
      • +
    • The firewall no + longer fails to start if "routefilter" is specified + for an interface that isn't started. A warning message +is now issued in this case.
      • +
    • The LRP Version + is renamed "shorwall" for 8,3 MSDOS file system + compatibility.
      • +
    • A couple of LRP-specific + problems were corrected.
      • - +
    - +

    4/8/2001 - Shorewall is now affiliated with the Leaf Project -

    +

    - +

    4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

    - +
      -
    • The common chain -is traversed from INPUT, OUTPUT and FORWARD before +
    • The common chain + is traversed from INPUT, OUTPUT and FORWARD before logging occurs
      • -
    • The source has been - cleaned up dramatically
      • -
    • DHCP DISCOVER packets - with RFC1918 source addresses no longer generate - log messages. Linux DHCP clients generate such packets and - it's annoying to see them logged. 
      • +
    • The source has +been cleaned up dramatically
      • +
    • DHCP DISCOVER +packets with RFC1918 source addresses no longer + generate log messages. Linux DHCP clients generate such + packets and it's annoying to see them logged. 
      • - +
    - +

    3/25/2001 - The current version of Shorewall is 1.1.0. In this version:

    - +
      -
    • Log messages now -indicate the packet disposition.
      • -
    • Error messages have - been improved.
      • -
    • The ability to define - zones consisting of an enumerated set of hosts - and/or subnetworks has been added.
      • -
    • The zone-to-zone -chain matrix is now sparse so that only those chains +
    • Log messages now + indicate the packet disposition.
      • +
    • Error messages +have been improved.
      • +
    • The ability to +define zones consisting of an enumerated set of hosts + and/or subnetworks has been added.
      • +
    • The zone-to-zone + chain matrix is now sparse so that only those chains that contain meaningful rules are defined.
      • -
    • 240.0.0.0/4 and 169.254.0.0/16 - have been added to the source subnetworks whose -packets are dropped under the norfc1918 interface - option.
      • -
    • Exits are now provided - for executing an user-defined script when a -chain is defined, when the firewall is initialized, when - the firewall is started, when the firewall is stopped - and when the firewall is cleared.
      • -
    • The Linux kernel's - route filtering facility can now be specified +
    • 240.0.0.0/4 and + 169.254.0.0/16 have been added to the source subnetworks + whose packets are dropped under the norfc1918 +interface option.
      • +
    • Exits are now +provided for executing an user-defined script when + a chain is defined, when the firewall is initialized, + when the firewall is started, when the firewall is +stopped and when the firewall is cleared.
      • +
    • The Linux kernel's + route filtering facility can now be specified selectively on network interfaces.
      • - +
    - +

    3/19/2001 - The current version of Shorewall is 1.0.4. This version:

    - +
      -
    • Allows user-defined - zones. Shorewall now has only one pre-defined -zone (fw) with the remaining zones being defined in the new -configuration file /etc/shorewall/zones. The /etc/shorewall/zones - file released in this version provides behavior that - is compatible with Shorewall 1.0.3. 
      • -
    • Adds the ability -to specify logging in entries in the /etc/shorewall/rules - file.
      • -
    • Correct handling -of the icmp-def chain so that only ICMP packets are +
    • Allows user-defined + zones. Shorewall now has only one pre-defined + zone (fw) with the remaining zones being defined in the +new configuration file /etc/shorewall/zones. The +/etc/shorewall/zones file released in this version provides + behavior that is compatible with Shorewall 1.0.3. 
      • +
    • Adds the ability + to specify logging in entries in the /etc/shorewall/rules + file.
      • +
    • Correct handling + of the icmp-def chain so that only ICMP packets are sent through the chain.
      • -
    • Compresses the output - of "shorewall monitor" if awk is installed. Allows - the command to work if awk isn't installed (although it's - not pretty).
      • +
    • Compresses the +output of "shorewall monitor" if awk is installed. + Allows the command to work if awk isn't installed (although + it's not pretty).
      • - +
    - -

    3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix - release with no new features.

    + +

    3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix + release with no new features.

    - +
      -
    • The PATH variable -in the firewall script now includes /usr/local/bin - and /usr/local/sbin.
      • -
    • DMZ-related chains - are now correctly deleted if the DMZ is deleted.
      • -
    • The interface OPTIONS - for "gw" interfaces are no longer ignored.
      • +
    • The PATH variable + in the firewall script now includes /usr/local/bin + and /usr/local/sbin.
      • +
    • DMZ-related chains + are now correctly deleted if the DMZ is deleted.
      • +
    • The interface +OPTIONS for "gw" interfaces are no longer ignored.
      • - +
    - -

    3/8/2001 - The current version of Shorewall is 1.0.2. It supports an - additional "gw" (gateway) zone for tunnels and -it supports IPSEC tunnels with end-points on the firewall. - There is also a .lrp available now.

    + +

    3/8/2001 - The current version of Shorewall is 1.0.2. It supports an + additional "gw" (gateway) zone for tunnels and + it supports IPSEC tunnels with end-points on the firewall. + There is also a .lrp available now.

    - -

    Updated 3/7/2003 - Tom Eastep -

    + +

    Updated 3/17/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index 6444873e3..803a46e5b 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -2,374 +2,331 @@ Shorewall Squid Usage - + - + - + - - - + - + - - - - +
    + + + +
    +
    -
    -
    +     		Using Shorewall with Squid
    -     		+ -
    -
    -
    - This page covers Shorewall configuration to use with Squid running as a Transparent - Proxy. 
    -
    - + This page covers Shorewall configuration to use with Squid running as a Transparent + Proxy. 
    +
    + Caution -     Please observe the following general requirements:
    -
    - -     In all cases, Squid should be configured to run - as a transparent proxy as described at +
    + +     In all cases, Squid should be configured to +run as a transparent proxy as described at     http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
    -
    -
    +     -     The following instructions mention the files -/etc/shorewall/start and /etc/shorewall/init -- if you don't have those +     The following instructions mention the files +/etc/shorewall/start and /etc/shorewall/init -- if you don't have those files, siimply create them.
    -
    - -     When the Squid server is in the DMZ zone or -in the local zone, that zone must be defined ONLY by its interface -- no -/etc/shorewall/hosts file entries. That is because the packets being routed +
    + +     When the Squid server is in the DMZ zone or +in the local zone, that zone must be defined ONLY by its interface -- no +/etc/shorewall/hosts file entries. That is because the packets being routed to the Squid server still have their original destination IP addresses.
    -
    - -     You must have iproute2 (ip utility) installed - on your firewall.
    -
    - -     You must have iptables installed on your Squid - server.
    -
    - -     You must have NAT and MANGLE enabled in your -/etc/shorewall/conf file
    -
    -         NAT_ENABLED=Yes
    -             + +     You must have iptables installed on your Squid + server.
    +
    + +     You must have NAT and MANGLE enabled in your + /etc/shorewall/conf file
    +
    +         NAT_ENABLED=Yes
    +             MANGLE_ENABLED=Yes
    -
    - Three different configurations are covered:
    - +
    + Three different configurations are covered:
    +
      -
    1. Squid running on -the Firewall.
      2. -
    2. Squid running in the +
    3. Squid running on + the Firewall.
      4. +
    4. Squid running in the local network
      5. -
    5. Squid running in the +
    6. Squid running in the DMZ
      7. - +
    - +

    Squid Running on the Firewall

    - You want to redirect all local www connection requests EXCEPT - those to your own - http server (206.124.146.177) - to a Squid transparent - proxy running on the firewall and listening on port 3128. Squid + You want to redirect all local www connection requests +EXCEPT those to your + own http server (206.124.146.177) + to a Squid transparent + proxy running on the firewall and listening on port 3128. Squid will of course require access to remote web servers.
    -
    - In /etc/shorewall/rules:
    -
    +
    + In /etc/shorewall/rules:
    +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    REDIRECTloc3128tcpwww -
    +     		!206.124.146.177
    ACCEPTfwnettcpwww
    +
    +
    +
    +
    + +

    Squid Running in the local network

    + You want to redirect all local www connection requests to a Squid + transparent proxy + running in your local zone at 192.168.1.3 and listening on port 3128. + Your local interface is eth1. There may also be a web server running on + 192.168.1.3. It is assumed that web access is already enabled from the local + zone to the internet.
    + +

    WARNING: This setup may conflict with + other aspects of your gateway including but not limited to traffic shaping + and route redirection. For that reason, I don't recommend it.
    +

    + +
      +
    • On your firewall system, issue the following command
      +
      • + +
    + +
    + 
    echo 202 www.out >> /etc/iproute2/rt_tables
    +
    + +
      +
    • In /etc/shorewall/init, put:
      +
      • + +
    + +
    + 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.168.1.3 dev eth1 table www.out
    	ip route flush cache
    	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    fi
    +
    + +
      +
    • In /etc/shorewall/rules:
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      ACCEPT
      +       		locloc
      +       		tcpwww
      +
      +
      +
      +
      • +
    • Alternativfely, you can have the following policy:
      +
      + + + + + + + + + + + + + + + + + + + +
      SOURCE
      +       		DESTINATION
      +       		POLICY
      +       		LOG LEVEL
      +       		BURST PARAMETERS
      +
      loc
      +       		loc
      +       		ACCEPT
      +
      +
      +
      +
      +
      • +
    • In /etc/shorewall/start add:
      +
      • + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc3128tcpwww -
    -     		!206.124.146.177
    ACCEPTfwnettcpwww
    -
    -
    -
    + 
    iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
    -

    Squid Running in the local network

    - You want to redirect all local www connection requests to a Squid - transparent proxy - running in your local zone at 192.168.1.3 and listening on port 3128. - Your local interface is eth1. There may also be a web server running on -192.168.1.3. It is assumed that web access is already enabled from the local -zone to the internet.
    - -

    WARNING: This setup may conflict with - other aspects of your gateway including but not limited to traffic shaping - and route redirection. For that reason, I don't recommend it.
    -

    -
      -
    • On your firewall system, issue the following command
      -
      • - -
    - -
    - 
    echo 202 www.out >> /etc/iproute2/rt_tables
    -
    - -
      -
    • In /etc/shorewall/init, put:
      -
      • - -
    - -
    - 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.168.1.3 dev eth1 table www.out
    	ip route flush cache
    	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    fi
    -
    - -
      -
    • In /etc/shorewall/rules:
      -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ACCEPT
      -       		locloc
      -       		tcpwww
      -
      -
      -
      -
      • -
    • Alternativfely, you can have the following policy:
      -
      - - - - - - - - - - - - - - - - - - - -
      SOURCE
      -       		DESTINATION
      -       		POLICY
      -       		LOG LEVEL
      -       		BURST PARAMETERS
      -
      loc
      -       		loc
      -       		ACCEPT
      -
      -
      -
      -
      -
      • -
    • In /etc/shorewall/start add:
      -
      • - -
    - -
    - 
    iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
    -
    - -
      -
    • On 192.168.1.3, arrange for the following command to be executed +
    • On 192.168.1.3, arrange for the following command to be executed after networking has come up
      - + 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      -
      • - + +
    - -
    If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
    -
    -
    +
    If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
    +
    + +
    - + 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables start
    -
    - +
    +
    - +

    Squid Running in the DMZ (This is what I do)

    - You have a single Linux system in your DMZ with IP address 192.0.2.177. - You want to run both a web server and Squid on that system. Your DMZ interface + You have a single Linux system in your DMZ with IP address 192.0.2.177. + You want to run both a web server and Squid on that system. Your DMZ interface is eth1 and your local interface is eth2.
    - -
      -
    • On your firewall system, issue the following command
      -
      • - -
    - -
    - 
    echo 202 www.out >> /etc/iproute2/rt_tables
    -
    - -
      -
    • In /etc/shorewall/init, put:
      -
      • - -
    - -
    - 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.0.2.177 dev eth1 table www.out
    	ip route flush cache
    fi
    -
    - -
      -
    •  Do one of the following:
      -
      - A) In /etc/shorewall/start add
      -
      • - -
    - -
    - 
    	iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
    -
    - -
    B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf - and add the following entry in /etc/shorewall/tcrules:
    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - -
    MARK
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT
    -     		CLIENT PORT
    -
    202
    -     		eth2
    -     		0.0.0.0/0
    -     		tcp
    -     		80
    -     		-
    -
    -
    - C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
    -
    - +
      +
    • On your firewall system, issue the following command
      +
      • + +
    + +
    + 
    echo 202 www.out >> /etc/iproute2/rt_tables
    +
    + +
      +
    • In /etc/shorewall/init, put:
      +
      • + +
    + +
    + 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.0.2.177 dev eth1 table www.out
    	ip route flush cache
    fi
    +
    + +
      +
    •  Do one of the following:
      +
      + A) In /etc/shorewall/start add
      +
      • + +
    + +
    + 
    	iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
    +
    + +
    B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf + and add the following entry in /etc/shorewall/tcrules:
    +
    +
    @@ -389,7 +346,7 @@ zone to the internet.
    - @@ -406,90 +363,130 @@ zone to the internet.
    202:P
    +     		202
    		 eth2
    -
    -
    - + C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
    + + +
    +
    + + + + + + + + + + + + + + + + + + + + +
    MARK
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT
    +     		CLIENT PORT
    +
    202:P
    +     		eth2
    +     		0.0.0.0/0
    +     		tcp
    +     		80
    +     		-
    +
    +
    +
    +
    +
      -
    • In /etc/shorewall/rules, you will need:
      • - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DEST
    -     		PROTO
    -     		DEST
    - PORT(S)
    -     		CLIENT
    - PORT(2)
    -     		ORIGINAL
    - DEST
    -
    ACCEPT
    -     		dmz
    -     		net
    -     		tcp
    -     		80
    -
    -
    -
    -
    -
    - -
      -
    • On 192.0.2.177 (your Web/Squid server), arrange for the following - command to be executed after networking has come up
      - - 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      -
      • +
    • In /etc/shorewall/rules, you will need:
    - -
    If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
    -
    - +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(S)
    +     		CLIENT
    + PORT(2)
    +     		ORIGINAL
    + DEST
    +
    ACCEPT
    +     		dmz
    +     		net
    +     		tcp
    +     		80
    +
    +
    +
    +
    +
    + +
      +
    • On 192.0.2.177 (your Web/Squid server), arrange for the following + command to be executed after networking has come up
      + + 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      +
      • + +
    + +
    If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
    +
    + +
    - + 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables start
    -
    - + +
    - -

    Updated 2/22/2003 - Tom Eastep -

    + +

    Updated 2/22/2003 - Tom Eastep +

    - Copyright © 2003 Thomas M. Eastep.
    -
    -
    -
    +
    +
    +
    +



    diff --git a/STABLE/documentation/Shorewall_index_frame.htm b/STABLE/documentation/Shorewall_index_frame.htm index 11e470a5c..ddb2bd735 100644 --- a/STABLE/documentation/Shorewall_index_frame.htm +++ b/STABLE/documentation/Shorewall_index_frame.htm @@ -2,166 +2,162 @@ - + - + - + - + Shorewall Index - - + + - + - - - + + - - - + + + - + + - - + +
    +
    - +

    Shorewall

    -
    - - - -
    + - + -
    - -
    -
    - Note:     Search is unavailable + + +
    + Note:     Search is unavailable Daily 0200-0330 GMT.
    - - + +

    Quick Search
    -

    -
    - +

    Extended Search

    - +

    Copyright © 2001-2003 Thomas M. Eastep.

    - -

    -
    -

    -
    -
    -
    -
    -
    + size="2">2001-2003 Thomas M. Eastep.

    + diff --git a/STABLE/documentation/Shorewall_sfindex_frame.htm b/STABLE/documentation/Shorewall_sfindex_frame.htm index e583fbd4e..c3693715a 100644 --- a/STABLE/documentation/Shorewall_sfindex_frame.htm +++ b/STABLE/documentation/Shorewall_sfindex_frame.htm @@ -2,163 +2,166 @@ - + - + - + - + Shorewall Index - - + + + - + - - - + + - - - + + + - - - + + + + + + +
    +
    - +

    Shorewall

    -
    +
    - + - + + -
    -
    -
    - Note:     Search is unavailable - Daily 0200-0330 GMT.
    - - + + +
    + Note:     Search is unavailable + Daily 0200-0330 GMT.
    + +

    Quick Search
    - + +

    -
    - +

    Extended Search

    +

    Copyright © 2001-2003 Thomas M. Eastep.

    -
    -
    -
    -
    -
    + size="2">2001-2003 Thomas M. Eastep.
    +

    diff --git a/STABLE/documentation/configuration_file_basics.htm b/STABLE/documentation/configuration_file_basics.htm index 2e6379b18..ad30e3e78 100644 --- a/STABLE/documentation/configuration_file_basics.htm +++ b/STABLE/documentation/configuration_file_basics.htm @@ -1,343 +1,348 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
    +
    - +

    Configuration Files

    -
    - +

    Warning: If you copy or edit your configuration files on a system running Microsoft Windows, you must - run them through dos2unix - before you use them with Shorewall.

    - + before you use them with Shorewall.

    +

    Files

    - +

    Shorewall's configuration files are in the directory /etc/shorewall.

    - +
      -
    • /etc/shorewall/shorewall.conf - used to set several - firewall parameters.
      • -
    • /etc/shorewall/params - use this file to set -shell variables that you will expand in other files.
      • -
    • /etc/shorewall/zones - partition the firewall's - view of the world into zones.
      • -
    • /etc/shorewall/policy - establishes firewall -high-level policy.
      • -
    • /etc/shorewall/interfaces - describes the interfaces - on the firewall system.
      • -
    • /etc/shorewall/hosts - allows defining zones -in terms of individual hosts and subnetworks.
      • -
    • /etc/shorewall/masq - directs the firewall where - to use many-to-one (dynamic) Network Address Translation +
    • /etc/shorewall/shorewall.conf - used to set +several firewall parameters.
      • +
    • /etc/shorewall/params - use this file to set + shell variables that you will expand in other files.
      • +
    • /etc/shorewall/zones - partition the firewall's + view of the world into zones.
      • +
    • /etc/shorewall/policy - establishes firewall + high-level policy.
      • +
    • /etc/shorewall/interfaces - describes the interfaces + on the firewall system.
      • +
    • /etc/shorewall/hosts - allows defining zones + in terms of individual hosts and subnetworks.
      • +
    • /etc/shorewall/masq - directs the firewall +where to use many-to-one (dynamic) Network Address Translation (a.k.a. Masquerading) and Source Network Address Translation (SNAT).
      • -
    • /etc/shorewall/modules - directs the firewall -to load kernel modules.
      • -
    • /etc/shorewall/rules - defines rules that are -exceptions to the overall policies established in /etc/shorewall/policy.
      • -
    • /etc/shorewall/nat - defines static NAT rules.
      • -
    • /etc/shorewall/proxyarp - defines use of Proxy - ARP.
      • -
    • /etc/shorewall/routestopped (Shorewall 1.3.4 -and later) - defines hosts accessible when Shorewall is stopped.
      • -
    • /etc/shorewall/tcrules - defines marking of packets - for later use by traffic control/shaping or policy routing.
      • -
    • /etc/shorewall/tos - defines rules for setting - the TOS field in packet headers.
      • -
    • /etc/shorewall/tunnels - defines IPSEC, GRE and - IPIP tunnels with end-points on the firewall system.
      • -
    • /etc/shorewall/blacklist - lists blacklisted -IP/subnet/MAC addresses.
      • -
    • /etc/shorewall/init - commands that you wish to execute at the beginning - of a "shorewall start" or "shorewall restart".
      • -
    • /etc/shorewall/start - commands that you wish to execute at the -completion of a "shorewall start" or "shorewall restart"
      • -
    • /etc/shorewall/stop - commands that you wish to execute at the beginning - of a "shorewall stop".
      • -
    • /etc/shorewall/stopped - commands that you wish to execute at the - completion of a "shorewall stop".
      -
      • - +
    • /etc/shorewall/modules - directs the firewall + to load kernel modules.
      • +
    • /etc/shorewall/rules - defines rules that are + exceptions to the overall policies established in /etc/shorewall/policy.
      • +
    • /etc/shorewall/nat - defines static NAT rules.
      • +
    • /etc/shorewall/proxyarp - defines use of Proxy + ARP.
      • +
    • /etc/shorewall/routestopped (Shorewall 1.3.4 + and later) - defines hosts accessible when Shorewall is stopped.
      • +
    • /etc/shorewall/tcrules - defines marking of +packets for later use by traffic control/shaping or policy routing.
      • +
    • /etc/shorewall/tos - defines rules for setting + the TOS field in packet headers.
      • +
    • /etc/shorewall/tunnels - defines IPSEC, GRE +and IPIP tunnels with end-points on the firewall system.
      • +
    • /etc/shorewall/blacklist - lists blacklisted + IP/subnet/MAC addresses.
      • +
    • /etc/shorewall/init - commands that you wish to execute at the +beginning of a "shorewall start" or "shorewall restart".
      • +
    • /etc/shorewall/start - commands that you wish to execute at the + completion of a "shorewall start" or "shorewall restart"
      • +
    • /etc/shorewall/stop - commands that you wish to execute at the +beginning of a "shorewall stop".
      • +
    • /etc/shorewall/stopped - commands that you wish to execute at +the completion of a "shorewall stop".
      • +
    • /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN +- RFC 3168) to remote hosts or networks.
      +
      • +
    - +

    Comments

    - +

    You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at - the end of any line, again by delimiting the comment from the -rest of the line with a pound sign.

    - + character a pound sign ("#"). You may also place comments +at the end of any line, again by delimiting the comment from +the rest of the line with a pound sign.

    +

    Examples:

    - + 
    # This is a comment
    - + 
    ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
    - +

    Line Continuation

    - +

    You may continue lines in the configuration files using the usual backslash - ("\") followed immediately by a new line character.

    - + ("\") followed immediately by a new line character.

    +

    Example:

    - + 
    ACCEPT	net	fw	tcp \
    smtp,www,pop3,imap  #Services running on the firewall
    - +

    Using DNS Names

    - +

    - +

    WARNING: I personally recommend strongly against - using DNS names in Shorewall configuration files. If you use DNS + using DNS names in Shorewall configuration files. If you use DNS names and you are called out of bed at 2:00AM because Shorewall won't start as a result of DNS problems then don't say that you were not forewarned. -
    -

    - +
    +

    +

        -Tom
    -

    - +

    +

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall - configuration files may be specified as either IP addresses or DNS - Names.
    -
    - DNS names in iptables rules aren't nearly as useful as they - first appear. When a DNS name appears in a rule, the iptables utility - resolves the name to one or more IP addresses and inserts those addresses - into the rule. So changes in the DNS->IP address relationship that - occur after the firewall has started have absolutely no effect on the - firewall's ruleset.

    - + configuration files may be specified as either IP addresses or DNS + Names.
    +
    + DNS names in iptables rules aren't nearly as useful as +they first appear. When a DNS name appears in a rule, the iptables +utility resolves the name to one or more IP addresses and inserts + those addresses into the rule. So changes in the DNS->IP address +relationship that occur after the firewall has started have absolutely +no effect on the firewall's ruleset.

    +

    If your firewall rules include DNS names then:

    - +
      -
    • If your /etc/resolv.conf is wrong then your firewall -won't start.
      • -
    • If your /etc/nsswitch.conf is wrong then your firewall +
    • If your /etc/resolv.conf is wrong then your firewall won't start.
      • -
    • If your Name Server(s) is(are) down then your firewall - won't start.
      • -
    • If your startup scripts try to start your firewall before - starting your DNS server then your firewall won't start.
      -
      • -
    • Factors totally outside your control (your ISP's router - is down for example), can prevent your firewall from starting.
      • -
    • You must bring up your network interfaces prior to starting - your firewall.
      -
      • - +
    • If your /etc/nsswitch.conf is wrong then your firewall + won't start.
      • +
    • If your Name Server(s) is(are) down then your firewall + won't start.
      • +
    • If your startup scripts try to start your firewall +before starting your DNS server then your firewall won't start.
      +
      • +
    • Factors totally outside your control (your ISP's router + is down for example), can prevent your firewall from starting.
      • +
    • You must bring up your network interfaces prior to +starting your firewall.
      +
      • +
    - +

    Each DNS name much be fully qualified and include a minumum - of two periods (although one may be trailing). This restriction is -imposed by Shorewall to insure backward compatibility with existing -configuration files.
    -
    - Examples of valid DNS names:
    -

    - + of two periods (although one may be trailing). This restriction is + imposed by Shorewall to insure backward compatibility with existing + configuration files.
    +
    + Examples of valid DNS names:
    +

    +
      -
    • mail.shorewall.net
      • -
    • shorewall.net. (note the trailing period).
      • - +
    • mail.shorewall.net
      • +
    • shorewall.net. (note the trailing period).
      • +
    - Examples of invalid DNS names:
    - + Examples of invalid DNS names:
    +
      -
    • mail (not fully qualified)
      • -
    • shorewall.net (only one period)
      • - +
    • mail (not fully qualified)
      • +
    • shorewall.net (only one period)
      • +
    - DNS names may not be used as:
    - + DNS names may not be used as:
    +
      -
    • The server address in a DNAT rule (/etc/shorewall/rules - file)
      • -
    • In the ADDRESS column of an entry in /etc/shorewall/masq.
      • -
    • In the /etc/shorewall/nat file.
      • - +
    • The server address in a DNAT rule (/etc/shorewall/rules + file)
      • +
    • In the ADDRESS column of an entry in /etc/shorewall/masq.
      • +
    • In the /etc/shorewall/nat file.
      • +
    - These restrictions are not imposed by Shorewall simply for - your inconvenience but are rather limitations of iptables.
    - + These restrictions are not imposed by Shorewall simply +for your inconvenience but are rather limitations of iptables.
    +

    Complementing an Address or Subnet

    - +

    Where specifying an IP address, a subnet or an interface, you can precede the item with "!" to specify the complement of the item. For example, !192.168.1.4 means "any host but 192.168.1.4". There must be no white space following the "!".

    - +

    Comma-separated Lists

    - +

    Comma-separated lists are allowed in a number of contexts within the configuration files. A comma separated list:

    - +
      -
    • Must not have any embedded white space.
      - Valid: routestopped,dhcp,norfc1918
      - Invalid: routestopped,     dhcp,     norfc1818
      • -
    • If you use line continuation to break a comma-separated - list, the continuation line(s) must begin in column 1 (or -there would be embedded white space)
      • -
    • Entries in a comma-separated list may appear -in any order.
      • - +
    • Must not have any embedded white space.
      + Valid: routefilter,dhcp,norfc1918
      + Invalid: routefilter,     dhcp,     norfc1818
      • +
    • If you use line continuation to break a comma-separated + list, the continuation line(s) must begin in column 1 (or + there would be embedded white space)
      • +
    • Entries in a comma-separated list may appear + in any order.
      • +
    - +

    Port Numbers/Service Names

    - +

    Unless otherwise specified, when giving a port number you can use either an integer or a service name from /etc/services.

    - +

    Port Ranges

    - +

    If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. For example, - if you want to forward the range of tcp ports 4000 through 4100 to local - host 192.168.1.3, the entry in /etc/shorewall/rules is:
    -

    - + port number>:<high port number>. For example, + if you want to forward the range of tcp ports 4000 through 4100 to +local host 192.168.1.3, the entry in /etc/shorewall/rules is:
    +

    + 
         DNAT	net	loc:192.168.1.3	tcp	4000:4100
    -If you omit the low port number, a value of zero is assumed; if you omit -the high port number, a value of 65535 is assumed.
    - + If you omit the low port number, a value of zero is assumed; if you omit + the high port number, a value of 65535 is assumed.
    +

    Using Shell Variables

    - +

    You may use the /etc/shorewall/params file to set shell variables that you can then use in some of the other configuration files.

    - +

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs

    - + within the Shorewall programs

    +

    Example:

    - -
    - - 
    NET_IF=eth0
    NET_BCAST=130.252.100.255
    NET_OPTIONS=noping,norfc1918
    -
    - -


    - Example (/etc/shorewall/interfaces record):

    - - +
    - 
    net $NET_IF $NET_BCAST $NET_OPTIONS
    -
    -     - -

    The result will be the same as if the record had been written

    - NET_IF=eth0
    NET_BCAST=130.252.100.255
    NET_OPTIONS=routefilter,norfc1918 + + +


    + Example (/etc/shorewall/interfaces record):

    +
    - 
    net eth0 130.252.100.255 noping,norfc1918
    -
    -     + 
    net $NET_IF $NET_BCAST $NET_OPTIONS
    + +     + +

    The result will be the same as if the record had been written

    + + +
    + + 
    net eth0 130.252.100.255 routefilter,norfc1918
    +
    +     +

    Variables may be used anywhere in the other configuration - files.

    - + files.

    +

    Using MAC Addresses

    - +

    Media Access Control (MAC) addresses can be used to specify packet - source in several of the configuration files. To use this feature, - your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) - included.

    - + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + included.

    +

    MAC addresses are 48 bits wide and each Ethernet Controller has a unique MAC address.
    -
    - In GNU/Linux, MAC addresses are usually written as -a series of 6 hex numbers separated by colons. Example:
    -
    -      [root@gateway root]# ifconfig eth0
    -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    -      inet addr:206.124.146.176 Bcast:206.124.146.255 - Mask:255.255.255.0
    -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    -      RX packets:2398102 errors:0 dropped:0 overruns:0 - frame:0
    -      TX packets:3044698 errors:0 dropped:0 overruns:0 - carrier:0
    -      collisions:30394 txqueuelen:100
    -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 - (1582.8 Mb)
    -      Interrupt:11 Base address:0x1800
    -
    - Because Shorewall uses colons as a separator for address - fields, Shorewall requires MAC addresses to be written in another - way. In Shorewall, MAC addresses begin with a tilde ("~") and -consist of 6 hex numbers separated by hyphens. In Shorewall, the -MAC address in the example above would be written "~02-00-08-E3-FA-55".
    -

    - +
    + In GNU/Linux, MAC addresses are usually written as + a series of 6 hex numbers separated by colons. Example:
    +
    +      [root@gateway root]# ifconfig eth0
    +      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    +      inet addr:206.124.146.176 Bcast:206.124.146.255 + Mask:255.255.255.0
    +      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    +      RX packets:2398102 errors:0 dropped:0 overruns:0 + frame:0
    +      TX packets:3044698 errors:0 dropped:0 overruns:0 + carrier:0
    +      collisions:30394 txqueuelen:100
    +      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 + (1582.8 Mb)
    +      Interrupt:11 Base address:0x1800
    +
    + Because Shorewall uses colons as a separator for +address fields, Shorewall requires MAC addresses to be written +in another way. In Shorewall, MAC addresses begin with a tilde +("~") and consist of 6 hex numbers separated by hyphens. In Shorewall, +the MAC address in the example above would be written "~02-00-08-E3-FA-55".
    +

    +

    Note: It is not necessary to use the special Shorewall notation - in the /etc/shorewall/maclist file.
    -

    - + in the /etc/shorewall/maclist file.
    +

    +

    Shorewall Configurations

    - +

    Shorewall allows you to have configuration directories other than /etc/shorewall. - The shorewall start and - restart commands allow you to specify an alternate configuration - directory and Shorewall will use the files in the alternate directory - rather than the corresponding files in /etc/shorewall. The alternate directory - need not contain a complete configuration; those files not in the alternate - directory will be read from /etc/shorewall.

    - + The shorewall start +and restart commands allow you to specify an alternate configuration + directory and Shorewall will use the files in the alternate directory + rather than the corresponding files in /etc/shorewall. The alternate +directory need not contain a complete configuration; those files not in +the alternate directory will be read from /etc/shorewall.

    +

    This facility permits you to easily create a test or temporary configuration - by:

    - + by:

    +
      -
    1. copying the files that need modification from - /etc/shorewall to a separate directory;
      2. -
    2. modify those files in the separate directory; - and
      3. -
    3. specifying the separate directory in a shorewall - start or shorewall restart command (e.g., shorewall -c /etc/testconfig - restart ).
      4. - +
    4. copying the files that need modification +from /etc/shorewall to a separate directory;
      5. +
    5. modify those files in the separate directory; + and
      6. +
    6. specifying the separate directory in a shorewall + start or shorewall restart command (e.g., shorewall -c +/etc/testconfig restart ).
      7. +
    - -

    Updated 2/7/2003 - Tom Eastep -

    + +

    Updated 2/24/2003 - Tom Eastep +

    - +

    Copyright - © 2001, 2002, 2003 Thomas M. Eastep.
    -

    + © 2001, 2002, 2003 Thomas M. Eastep.
    +

    +
    +



    diff --git a/STABLE/documentation/download.htm b/STABLE/documentation/download.htm index 482971210..cd2cee24c 100644 --- a/STABLE/documentation/download.htm +++ b/STABLE/documentation/download.htm @@ -1,457 +1,456 @@ - + - + - + - + Download - + - - - + + - - - + + + +
    +
    - +

    Shorewall Download

    -
    - +

    I strongly urge you to read and print a copy of the Shorewall QuickStart Guide - for the configuration that most closely matches your own.
    -

    - -

    The entire set of Shorewall documentation is available in PDF format at:

    - + href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide + for the configuration that most closely matches your own.
    +

    + +

    The entire set of Shorewall documentation is available in PDF format +at:

    +

        ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
    -     http://slovakia.shorewall.net/pub/shorewall/pdf/
    -     rsync://slovakia.shorewall.net/shorewall/pdf/ +     http://slovakia.shorewall.net/pub/shorewall/pdf/
    +     rsync://slovakia.shorewall.net/shorewall/pdf/

    - -

    The documentation in HTML format is included in the .rpm and in the .tgz -packages below.

    - -

    Once you've printed the appropriate QuickStart Guide, download - one of the modules:

    - + +

    The documentation in HTML format is included in the .rpm and in the +.tgz packages below.

    + +

    Once you've printed the appropriate QuickStart Guide, download + one of the modules:

    +
      -
    • If you run a RedHat, SuSE, Mandrake, - Linux PPC or TurboLinux distribution - with a 2.4 kernel, you can use the RPM version (note: the - RPM should also work with other distributions that - store init scripts in /etc/init.d and that include chkconfig +
    • If you run a RedHat, SuSE, Mandrake, + Linux PPC or TurboLinux distribution + with a 2.4 kernel, you can use the RPM version (note: the + RPM should also work with other distributions that + store init scripts in /etc/init.d and that include chkconfig or insserv). If you find that it works in other cases, let me know so that - I can mention them here. See the Installation - Instructions if you have problems installing the RPM.
      • -
    • If you are running LRP, download the .lrp file (you - might also want to download the .tgz so you will have a copy of - the documentation).
      • -
    • If you run Debian - and would like a .deb package, Shorewall is included in both -the Debian - Testing Branch and the Debian -Unstable Branch.
      • -
    • Otherwise, download the shorewall - module (.tgz)
      • - + href="mailto:teastep@shorewall.net"> me know so that + I can mention them here. See the Installation + Instructions if you have problems installing the RPM. +
    • If you are running LRP, download the .lrp file (you + might also want to download the .tgz so you will have a copy +of the documentation).
      • +
    • If you run Debian + and would like a .deb package, Shorewall is included in both +the Debian + Testing Branch and the Debian + Unstable Branch.
      • +
    • Otherwise, download the shorewall + module (.tgz)
      • +
    - -

    The documentation in HTML format is included in the .tgz and .rpm files - and there is an documentation .deb that also contains the documentation.  The -.rpm will install the documentation in your default document directory which -can be obtained using the following command:
    -

    - -
    + +

    The documentation in HTML format is included in the .tgz and .rpm files + and there is an documentation .deb that also contains the documentation.  The + .rpm will install the documentation in your default document directory which + can be obtained using the following command:
    +

    + +

    rpm --eval '%{defaultdocdir}'

    -
    - -

    Please verify the version that you have downloaded -- during the - release of a new version of Shorewall, the links below may - point to a newer or an older version than is shown below.

    - +
    + +

    Please verify the version that you have downloaded -- during the + release of a new version of Shorewall, the links below may + point to a newer or an older version than is shown below.

    +
      -
    • RPM - "rpm -qip LATEST.rpm"
      • -
    • TARBALL - "tar -ztf LATEST.tgz" (the directory - name will contain the version)
      • -
    • LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar - -zxf <downloaded .lrp>; cat var/lib/lrpkg/shorwall.version" -
      • - +
    • RPM - "rpm -qip LATEST.rpm"
      • +
    • TARBALL - "tar -ztf LATEST.tgz" (the directory + name will contain the version)
      • +
    • LRP - "mkdir Shorewall.lrp; cd Shorewall.lrp; tar + -zxf <downloaded .lrp>; cat var/lib/lrpkg/shorwall.version" +
      • +
    - +

    Once you have verified the version, check the errata to see - if there are updates that apply to the version that you have - downloaded.

    - -

    WARNING - YOU CAN NOT SIMPLY INSTALL - THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION - IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration - of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.

    - -

    Download Latest Version (1.3.14): Remember that updates - to the mirrors occur 1-12 hours after an update to the Washington + color="#ff0000"> errata to see + if there are updates that apply to the version that you have + downloaded.

    + +

    WARNING - YOU CAN NOT SIMPLY INSTALL + THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION + IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed + configuration of your firewall, you can enable startup by removing the + file /etc/shorewall/startup_disabled.

    + +

    Download Latest Version (1.4.0): Remember that updates + to the mirrors occur 1-12 hours after an update to the Washington State site.

    - -
    + +
    - + + + + + + + - - - - - - - - - + + - - - - - - + + + + + - + - - - - - + + + + + - + - - - - - + + + + + - + - - - - - + + + + + - + - - - - - + + + + + - + - - - - - - + + + + + + - + + - - + +
    SERVER LOCATIONDOMAINHTTPFTP
    SERVER LOCATIONDOMAINHTTPFTP
    SourceForge
    -     		sf.net
    -     		SourceForge
    +     		sf.net
    +     		Download
    -
    -
    Slovak RepublicShorewall.net +
    +
    Slovak RepublicShorewall.netDownload .rpm
    - Download - .tgz 
    - Download - .lrp
    - - Download.md5sums
    -     Download + Download + .tgz 
    + Download + .lrp
    + + Download.md5sums
    +     Download .samples
    -     		Download - .rpm  
    - Download +     		Download + .rpm  
    + Download .tgz 
    - Download + Download .lrp
    - - Download.md5sums
    -     Download + + Download.md5sums
    +     Download .samples
    -
    Texas, USAInfohiiway.comDownload - .rpm
    - Download +
    Texas, USAInfohiiway.comDownload + .rpm
    + Download .tgz 
    - Download + Download .lrp
    - - Download.md5sums
    -     Download + + Download.md5sums
    +     Download .samples
    -     		Download .rpm  
    - Download - .tgz 
    - Download - .lrp
    - - Download.md5sums
    -     Download - .samplesDownload + .tgz 
    + Download + .lrp
    + + Download.md5sums
    +     Download + .samples
    -
    Hamburg, GermanyShorewall.net Download - .rpm
    - Download - .tgz
    - Download - .lrp
    - - Download.md5sums
    -     Download +
    Hamburg, GermanyShorewall.net Download + .rpm
    + Download + .tgz
    + Download + .lrp
    + + Download.md5sums
    +     Download .samples
    -     		Download - .rpm  
    - Download - .tgz 
    - Download - .lrp
    - Download +     		Download + .rpm  
    + Download + .tgz 
    + Download + .lrp
    + Download .md5sums
    -     Download + Download .samples
    -
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download - .rpm  
    - Download +
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.ar Download + .rpm  
    + Download .tgz 
    - + Download .lrp
    - Download + Download .md5sums
    -     + Download .samples
    -     		Download - .rpm  
    - Download +     		Download + .rpm  
    + Download .tgz 
    - + Download .lrp
    - Download + Download .md5sums
    -     + Download .samples
    -
    Paris, FranceShorewall.net
    Paris, FranceShorewall.netDownload .rpm
    - Download .tgz 
    - Download .lrp
    - Download - .md5sums
    -     Download + Download +.tgz 
    + Download +.lrp
    + Download + .md5sums
    +     Download .samples
    -     		Download - .rpm  
    - Download +     		Download + .rpm  
    + Download .tgz 
    - Download - .lrp
    - Download - .md5sums
    -     Download - .samples
    -
    Washington State, USA
    -     		Shorewall.net
    -     		Download .rpm
    - Download - .tgz 
    - Download - .lrp
    - Download + Download + .lrp
    + Download .md5sums
    -     Download - .samples
    -     		- Download .rpm 
    - Download - .tgz 
    - Download - .lrp
    - Download - .md5sums
    -     Download + .samples
    +
    Washington State, USA
    +     		Shorewall.net
    +     		Download .rpm
    + Download + .tgz 
    + Download + .lrp
    + Download + .md5sums
    +     Download + .samples
    +     		+ Download .rpm 
    + Download + .tgz 
    + Download + .lrp
    + Download + .md5sums
    +     Download .samples
    -
    -
    - +
    +

    Browse Download Sites:

    - -
    + +
    - - - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    SERVER LOCATIONDOMAINHTTPFTP
    SourceForge
    -     		sf.net +
    SERVER LOCATIONDOMAINHTTPFTP
    SourceForge
    +     		sf.netBrowseN/A
    Slovak RepublicShorewall.netBrowse Browse
    Texas, USAInfohiiway.comBrowseBrowse
    Hamburg, GermanyShorewall.netBrowseBrowse
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
    FranceShorewall.netBrowse Browse
    N/A
    Washington State, USAShorewall.netBrowseBrowseSlovak RepublicShorewall.netBrowse Browse
    Texas, USAInfohiiway.comBrowseBrowse
    Hamburg, GermanyShorewall.netBrowseBrowse
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
    FranceShorewall.netBrowse Browse
    Washington State, USAShorewall.netBrowseBrowse
    -
    - +
    +

    CVS:

    - -
    + +

    The CVS repository - at cvs.shorewall.net contains the latest snapshots of the each - Shorewall component. There's no guarantee that what you find there + href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS repository + at cvs.shorewall.net contains the latest snapshots of the each + Shorewall component. There's no guarantee that what you find there will work at all.
    -

    -
    - +

    +
    +

    Last Updated 3/6/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    -

    -
    -
    -
    -
    -
    +

    diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index 31086545c..628748a58 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -2,728 +2,241 @@ - + - Shorewall 1.3 Errata + Shorewall 1.4 Errata - + - + - + + + - + - - - + + - - - - -
    +
    - -

    Shorewall Errata/Upgrade Issues

    -
    - -

    IMPORTANT

    - -
      -
    1. - - -

      If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved - it to your Linux system.

      -
      2. -
    2. - - -

      If you are installing Shorewall for the first -time and plan to use the .tgz and install.sh script, you can untar -the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

      -
      3. -
    3. - - -

      If you are running a Shorewall version earlier - than 1.3.11, when the instructions say to install a corrected firewall - script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to -overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD -/etc/shorewall/firewall or /var/lib/shorewall/firewall before -you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall - are symbolic links that point to the 'shorewall' file used by your - system initialization scripts to start Shorewall during boot. -It is that file that must be overwritten with the corrected -script. Beginning with Shorewall 1.3.11, you may rename the existing file -before copying in the new file.

      -
      4. -
    4. - -

      DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. - For example, do NOT install the 1.3.9a firewall script if you are running - 1.3.7c.
      -

      -
      5. - -
    - - - -
    -

    Problems in Version 1.3

    - - -

    Version 1.3.14

    - -
      -
    • There is an updated - rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and -223.0.0.0/8.
      • - -
    - -
      -
    • The documentation for the routestopped file claimed that a comma-separated - list could appear in the second column while the code only supported a -single host or network address.
      • -
    • Log messages produced by 'logunclean' and 'dropunclean' were not -rate-limited.
      • -
    • 802.11b devices with names of the form wlan<n> don't -support the 'maclist' interface option.
      • -
    • Log messages generated by RFC 1918 filtering are not rate limited.
      -
      • - -
    - These four problems have been corrected in this - firewall script which may be installed in /usr/lib/shorewall as described - above.
    - -

    Version 1.3.13

    - -
      -
    • The 'shorewall add' command produces an error message referring - to 'find_interfaces_by_maclist'.
      • -
    • The 'shorewall delete' command can leave behind undeleted rules.
      • -
    • The 'shorewall add' command can fail with "iptables: Index of -insertion too big".
      -
      • - -
    - All three problems are corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
    - -
      -
    • VLAN interface names of the form "ethn.m" (e.g., - eth0.1) are not supported in this version or in 1.3.12. If you need such - support, post on the users list and I can provide you with a patched version.
      -
      • - -
    - -

    Version 1.3.12

    - -
      -
    • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect - is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem - is corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
      • -
    • VLAN interface names of the form "ethn.m" (e.g., - eth0.1) are not supported in this version or in 1.3.13. If you need such - support, post on the users list and I can provide you with a patched version.
      -
      • - -
    - -

    Version 1.3.12 LRP

    - -
      -
    • The .lrp was missing the /etc/shorewall/routestopped file --- a new lrp (shorwall-1.3.12a.lrp) has been released which corrects this - problem.
      -
      • - -
    - -

    Version 1.3.11a

    - - - -

    Version 1.3.11

    - -
      -
    • When installing/upgrading using the .rpm, you may receive - the following warnings:
      -
      -      user teastep does not exist - using root
      -      group teastep does not exist - using root
      -
      - These warnings are harmless and may be ignored. Users downloading - the .rpm from shorewall.net or mirrors should no longer see these warnings - as the .rpm you will get from there has been corrected.
      • -
    • DNAT rules that exclude a source subzone (SOURCE column - contains ! followed by a sub-zone list) result in an error message -and Shorewall fails to start.
      -
      - Install this - corrected script in /usr/lib/shorewall/firewall to correct this -problem. Thanks go to Roger Aich who analyzed this problem and provided -a fix.
      -
      - This problem is corrected in version 1.3.11a.
      -
      • - -
    - -

    Version 1.3.10

    - -
      -
    • If you experience problems connecting to a PPTP server - running on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, - this - version of the firewall script may help. Please report any cases - where installing this script in /usr/lib/shorewall/firewall solved your - connection problems. Beginning with version 1.3.10, it is safe to save - the old version of /usr/lib/shorewall/firewall before copying in the - new one since /usr/lib/shorewall/firewall is the real script now and -not just a symbolic link to the real script.
      -
      • - -
    - -

    Version 1.3.9a

    - -
      -
    • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No - then the following message appears during "shorewall [re]start":
      • - -
    - -
              recalculate_interfacess: command not found
    - -
    The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall - as described above.
    -
    - -
    Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
    -
    - -
      -
    • The installer (install.sh) issues a misleading message - "Common functions installed in /var/lib/shorewall/functions" whereas - the file is installed in /usr/lib/shorewall/functions. The installer - also performs incorrectly when updating old configurations that had the - file /etc/shorewall/functions. Here - is an updated version that corrects these problems.
      -
      • - -
    - -

    Version 1.3.9

    - TUNNELS Broken in 1.3.9!!! There is an updated -firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall as described above.
    -
    - Version 1.3.8 -
      -
    • Use of shell variables in the LOG LEVEL or SYNPARMS - columns of the policy file doesn't work.
      • -
    • A DNAT rule with the same original and new IP -addresses but with different port numbers doesn't work (e.g., "DNAT -loc dmz:10.1.1.1:24 tcp 25 - 10.1.1.1")
      -
      • -
    - Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these - problems. -

    Version 1.3.7b

    +

    Shorewall Errata/Upgrade Issues

    + + - -

    DNAT rules where the source zone is 'fw' ($FW) - result in an error message. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this - problem.

    - - -

    Version 1.3.7a

    - - -

    "shorewall refresh" is not creating the proper - rule for FORWARDPING=Yes. Consequently, after - "shorewall refresh", the firewall will not forward - icmp echo-request (ping) packets. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this - problem.

    - - -

    Version <= 1.3.7a

    - - -

    If "norfc1918" and "dhcp" are both specified as - options on a given interface then RFC 1918 - checking is occurring before DHCP checking. This - means that if a DHCP client broadcasts using an - RFC 1918 source address, then the firewall will - reject the broadcast (usually logging it). This - has two problems:

    - - + + + + +

    IMPORTANT

    +
      -
    1. If the firewall - is running a DHCP server, the client - won't be able to obtain an IP address - lease from that server.
      2. -
    2. With this order - of checking, the "dhcp" option -cannot be used as a noise-reduction - measure where there are both dynamic and static - clients on a LAN segment.
      3. - +
    3. + +

      If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved + it to your Linux system.

      +
      4. +
    4. + +

      If you are installing Shorewall for the +first time and plan to use the .tgz and install.sh script, you can +untar the archive, replace the 'firewall' script in the untarred directory + with the one you downloaded below, and then run install.sh.

      +
      5. +
    5. + +

      When the instructions say to install a corrected + firewall script in /usr/share/shorewall/firewall, you may +rename the existing file before copying in the new file.

      +
      6. +
    6. + +

      DO NOT INSTALL CORRECTED COMPONENTS + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. + For example, do NOT install the 1.3.9a firewall script if you are running + 1.3.7c.
      +

      +
      7. +
    - - -

    - This version of the 1.3.7a firewall script - corrects the problem. It must be - installed in /var/lib/shorewall -as described above.

    - - -

    Version 1.3.7

    - - -

    Version 1.3.7 dead on arrival -- please use - version 1.3.7a and check your version against - these md5sums -- if there's a difference, please - download again.

    - - -
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    - -

    In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

    - -

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

    - - -

    Version 1.3.6

    - - + + +
    +

    Problems in Version 1.4

    - -

    These problems are fixed in - this correct firewall script which must be installed in - /var/lib/shorewall/ as described above. These problems are also - corrected in version 1.3.7.

    - - -

    Two-interface Samples 1.3.6 (file two-interfaces.tgz)

    - - -

    A line was inadvertently deleted from the "interfaces - file" -- this line should be added back in if the version that you - downloaded is missing it:

    - - -

    net    eth0    detect    routefilter,dhcp,norfc1918

    - - -

    If you downloaded two-interfaces-a.tgz then the above - line should already be in the file.

    - - -

    Version 1.3.5-1.3.5b

    - - -

    The new 'proxyarp' interface option doesn't work :-( - This is fixed in - this corrected firewall script which must be installed in - /var/lib/shorewall/ as described above.

    - - -

    Versions 1.3.4-1.3.5a

    - - -

    Prior to version 1.3.4, host file entries such as the - following were allowed:

    - - -
    -
    	adm	eth0:1.2.4.5,eth0:5.6.7.8
    -
    - -
    -

    That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. - This problem is corrected by this - modified 1.3.5a firewall script. Install the script in -/var/lib/pub/shorewall/firewall as instructed above.

    -
    - -
    -

    This problem is corrected in version 1.3.5b.

    -
    - - -

    Version 1.3.5

    - - -

    REDIRECT rules are broken in this version. Install - - this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version - 1.3.5a.

    - - -

    Version 1.3.n, n < 4

    - - -

    The "shorewall start" and "shorewall restart" commands - to not verify that the zones named in the /etc/shorewall/policy file - have been previously defined in the /etc/shorewall/zones file. -The "shorewall check" command does perform this verification so -it's a good idea to run that command after you have made configuration - changes.

    - - -

    Version 1.3.n, n < 3

    - - -

    If you have upgraded from Shorewall 1.2 and after - "Activating rules..." you see the message: "iptables: No chains/target/match - by that name" then you probably have an entry in /etc/shorewall/hosts - that specifies an interface that you didn't include -in /etc/shorewall/interfaces. To correct this problem, you - must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 - and later versions produce a clearer error message in this - case.

    - - -

    Version 1.3.2

    - - -

    Until approximately 2130 GMT on 17 June 2002, the - download sites contained an incorrect version of the .lrp file. That - file can be identified by its size (56284 bytes). The correct version - has a size of 38126 bytes.

    - - -
      -
    • The code to detect a duplicate interface - entry in /etc/shorewall/interfaces contained a typo that - prevented it from working correctly.
      • -
    • "NAT_BEFORE_RULES=No" was broken; -it behaved just like "NAT_BEFORE_RULES=Yes".
      • - -
    - - -

    Both problems are corrected in - this script which should be installed in /var/lib/shorewall - as described above.

    - - -
      -
    • - - -

      The IANA have just announced the allocation of subnet - 221.0.0.0/8. This - updated rfc1918 file reflects that allocation.

      -
      • - -
    - - -

    Version 1.3.1

    - - -
      -
    • TCP SYN packets may be double counted - when LIMIT:BURST is included in a CONTINUE or ACCEPT policy - (i.e., each packet is sent through the limit chain twice).
      • -
    • An unnecessary jump to the policy -chain is sometimes generated for a CONTINUE policy.
      • -
    • When an option is given for more -than one interface in /etc/shorewall/interfaces then -depending on the option, Shorewall may ignore all but -the first appearence of the option. For example:
      -
      - net    eth0    dhcp
      - loc    eth1    dhcp
      -
      - Shorewall will ignore the 'dhcp' on eth1.
      • -
    • Update 17 June 2002 - The bug described - in the prior bullet affects the following options: -dhcp, dropunclean, logunclean, norfc1918, routefilter, -multi, filterping and noping. An additional bug has been -found that affects only the 'routestopped' option.
      -
      - Users who downloaded the corrected script - prior to 1850 GMT today should download and install - the corrected script again to ensure that this second - problem is corrected.
      • - -
    - - -

    These problems are corrected in - this firewall script which should be installed in /etc/shorewall/firewall - as described above.

    - - -

    Version 1.3.0

    - - -
      -
    • Folks who downloaded 1.3.0 from the - links on the download page before 23:40 GMT, 29 May - 2002 may have downloaded 1.2.13 rather than 1.3.0. -The "shorewall version" command will tell you which version - that you have installed.
      • -
    • The documentation NAT.htm file uses - non-existent wallpaper and bullet graphic files. The - - corrected version is here.
      • - -
    - -
    + +

    + None. +

    Upgrade Issues

    - - +

    The upgrade issues have moved to a separate page.

    - -
    -

    Problem with - iptables version 1.2.3

    - -
    - -

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, - RedHat released this buggy iptables in RedHat 7.2. 

    + +
    +

    Problem with + iptables version 1.2.3

    + +
    + +

    There are a couple of serious bugs in iptables 1.2.3 that + prevent it from working with Shorewall. Regrettably, RedHat + released this buggy iptables in RedHat 7.2. 

    - +

    I have built a - corrected 1.2.3 rpm which you can download here  and I have - also built an - iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm"> + corrected 1.2.3 rpm which you can download here  and I have + also built an +iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs before you upgrade to RedHat 7.2.

    - -

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can - download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works - fine.

    + +

    Update 11/9/2001: RedHat + has released an iptables-1.2.4 RPM of their own which you can +download from http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it works + fine.

    - -

    If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level -specification while this patch - corrects a problem in handling the  TOS target.

    + +

    If you would like to patch iptables 1.2.3 yourself, + the patches are available for download. This patch + which corrects a problem with parsing of the --log-level specification + while this patch + corrects a problem in handling the  TOS target.

    - +

    To install one of the above patches:

    - +
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • - +
    -
    +
    - -

    Problems with kernels >= 2.4.18 - and RedHat iptables

    - -
    -

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

    +

    Problems with kernels >= 2.4.18 + and RedHat iptables

    + +
    + +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 + may experience the following:

    - -
    - + +
    + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    -
    +
    - -

    The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by - installing - this iptables RPM. If you are already running a 1.2.5 -version of iptables, you will need to specify the --oldpackage -option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    + +

    The RedHat iptables RPM is compiled with debugging enabled but the + user-space debugging code was not updated to reflect recent changes in + the Netfilter 'mangle' table. You can correct the problem by + installing + this iptables RPM. If you are already running a 1.2.5 version + of iptables, you will need to specify the --oldpackage option to + rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    - -

    Problems installing/upgrading - RPM on SuSE

    + +

    Problems installing/upgrading + RPM on SuSE

    - -

    If you find that rpm complains about a conflict - with kernel <= 2.2 yet you have a 2.4 kernel - installed, simply use the "--nodeps" option to - rpm.

    +

    If you find that rpm complains about a conflict + with kernel <= 2.2 yet you have a 2.4 kernel + installed, simply use the "--nodeps" option to + rpm.

    -

    Installing: rpm -ivh --nodeps <shorewall rpm>

    -

    Upgrading: rpm -Uvh --nodeps <shorewall rpm>

    - -

    Problems with - iptables version 1.2.7 and MULTIPORT=Yes

    +

    Problems with + iptables version 1.2.7 and MULTIPORT=Yes

    - -

    The iptables 1.2.7 release of iptables has made - an incompatible change to the syntax used to - specify multiport match rules; as a consequence, - if you install iptables 1.2.7 you must be running - Shorewall 1.3.7a or later or:

    +

    The iptables 1.2.7 release of iptables has made + an incompatible change to the syntax used to + specify multiport match rules; as a consequence, + if you install iptables 1.2.7 you must be running + Shorewall 1.3.7a or later or:

    -
      -
    • set MULTIPORT=No - in /etc/shorewall/shorewall.conf; or -
      • -
    • if you are running - Shorewall 1.3.6 you may install - - this firewall script in /var/lib/shorewall/firewall - as described above.
      • - +
    • set MULTIPORT=No +in /etc/shorewall/shorewall.conf; or
      • +
    • if you are running + Shorewall 1.3.6 you may install + + this firewall script in /var/lib/shorewall/firewall + as described above.
      • +
    - +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

    - /etc/shorewall/nat entries of the following form will -result in Shorewall being unable to start:
    -
    - + + /etc/shorewall/nat entries of the following form will result + in Shorewall being unable to start:
    +
    + 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    192.0.2.22      eth0            192.168.9.22    yes                     yes
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - Error message is:
    - + Error message is:
    + 
    Setting up NAT...
    iptables: Invalid argument
    Terminated

    - The solution is to put "no" in the LOCAL column. Kernel - support for LOCAL=yes has never worked properly and 2.4.18-10 has - disabled it. The 2.4.19 kernel contains corrected support under a -new kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
    - -

    Last updated 3/8/2003 - -Tom Eastep

    - + The solution is to put "no" in the LOCAL column. Kernel support + for LOCAL=yes has never worked properly and 2.4.18-10 has disabled +it. The 2.4.19 kernel contains corrected support under a new kernel configuraiton + option; see http://www.shorewall.net/Documentation.htm#NAT
    + +

    Last updated 2/8/2003 - + Tom Eastep

    +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.

    diff --git a/STABLE/documentation/errata_3.html b/STABLE/documentation/errata_3.html new file mode 100644 index 000000000..92b98f31d --- /dev/null +++ b/STABLE/documentation/errata_3.html @@ -0,0 +1,715 @@ + + + + + + + Shorewall 1.3 Errata + + + + + + + + + + + + + + + + + + + + + +
    + + +

    Shorewall Errata/Upgrade Issues

    +
    + +

    IMPORTANT

    + +
      +
    1. + + +

      If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved + it to your Linux system.

      +
      2. +
    2. + + +

      If you are installing Shorewall for the +first time and plan to use the .tgz and install.sh script, you can +untar the archive, replace the 'firewall' script in the untarred directory + with the one you downloaded below, and then run install.sh.

      +
      3. +
    3. + + +

      If you are running a Shorewall version earlier + than 1.3.11, when the instructions say to install a corrected +firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall + or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to +overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD +/etc/shorewall/firewall or /var/lib/shorewall/firewall before +you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall + are symbolic links that point to the 'shorewall' file used by +your system initialization scripts to start Shorewall during +boot. It is that file that must be overwritten with the corrected +script. Beginning with Shorewall 1.3.11, you may rename the existing file +before copying in the new file.

      +
      4. +
    4. + +

      DO NOT INSTALL CORRECTED COMPONENTS + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. + For example, do NOT install the 1.3.9a firewall script if you are running + 1.3.7c.
      +

      +
      5. + +
    + + + +
    +

    Problems in Version 1.3

    + + +

    Version 1.3.14

    + +
      +
    • There is an updated + rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and +223.0.0.0/8.
      • + +
    + +
      +
    • The documentation for the routestopped file claimed that a comma-separated + list could appear in the second column while the code only supported a single + host or network address.
      • +
    • Log messages produced by 'logunclean' and 'dropunclean' were not rate-limited.
      • +
    • 802.11b devices with names of the form wlan<n> don't +support the 'maclist' interface option.
      • +
    • Log messages generated by RFC 1918 filtering are not rate limited.
      • +
    • The firewall fails to start in the case where you have "eth0 eth1" +in /etc/shorewall/masq and the default route is through eth1.
      +
      • + +
    + These problems have been corrected in this + firewall script which may be installed in /usr/lib/shorewall as described + above.
    + +

    Version 1.3.13

    + +
      +
    • The 'shorewall add' command produces an error message referring + to 'find_interfaces_by_maclist'.
      • +
    • The 'shorewall delete' command can leave behind undeleted rules.
      • +
    • The 'shorewall add' command can fail with "iptables: Index of insertion + too big".
      +
      • + +
    + All three problems are corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
    + +
      +
    • VLAN interface names of the form "ethn.m" (e.g., +eth0.1) are not supported in this version or in 1.3.12. If you need such +support, post on the users list and I can provide you with a patched version.
      +
      • + +
    + +

    Version 1.3.12

    + +
      +
    • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect + is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem + is corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
      • +
    • VLAN interface names of the form "ethn.m" (e.g., +eth0.1) are not supported in this version or in 1.3.13. If you need such +support, post on the users list and I can provide you with a patched version.
      +
      • + +
    + +

    Version 1.3.12 LRP

    + +
      +
    • The .lrp was missing the /etc/shorewall/routestopped file +-- a new lrp (shorwall-1.3.12a.lrp) has been released which corrects +this problem.
      +
      • + +
    + +

    Version 1.3.11a

    + + + +

    Version 1.3.11

    + +
      +
    • When installing/upgrading using the .rpm, you may receive + the following warnings:
      +
      +      user teastep does not exist - using root
      +      group teastep does not exist - using root
      +
      + These warnings are harmless and may be ignored. Users downloading + the .rpm from shorewall.net or mirrors should no longer see these warnings + as the .rpm you will get from there has been corrected.
      • +
    • DNAT rules that exclude a source subzone (SOURCE column +contains ! followed by a sub-zone list) result in an error message and +Shorewall fails to start.
      +
      + Install this + corrected script in /usr/lib/shorewall/firewall to correct this +problem. Thanks go to Roger Aich who analyzed this problem and provided +a fix.
      +
      + This problem is corrected in version 1.3.11a.
      +
      • + +
    + +

    Version 1.3.10

    + +
      +
    • If you experience problems connecting to a PPTP server + running on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, + this + version of the firewall script may help. Please report any cases + where installing this script in /usr/lib/shorewall/firewall solved +your connection problems. Beginning with version 1.3.10, it is safe +to save the old version of /usr/lib/shorewall/firewall before copying +in the new one since /usr/lib/shorewall/firewall is the real script +now and not just a symbolic link to the real script.
      +
      • + +
    + +

    Version 1.3.9a

    + +
      +
    • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No + then the following message appears during "shorewall [re]start":
      • + +
    + +
              recalculate_interfacess: command not found
    + +
    The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + corrects this problem.Copy the script to /usr/lib/shorewall/firewall + as described above.
    +
    + +
    Alternatively, edit /usr/lob/shorewall/firewall and change the + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' + to 'recalculate_interface'.
    +
    + +
      +
    • The installer (install.sh) issues a misleading message + "Common functions installed in /var/lib/shorewall/functions" whereas + the file is installed in /usr/lib/shorewall/functions. The installer + also performs incorrectly when updating old configurations that had the + file /etc/shorewall/functions. Here + is an updated version that corrects these problems.
      +
      • + +
    + +

    Version 1.3.9

    + TUNNELS Broken in 1.3.9!!! There is an updated +firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall as described above.
    +
    + Version 1.3.8 +
      +
    • Use of shell variables in the LOG LEVEL or SYNPARMS + columns of the policy file doesn't work.
      • +
    • A DNAT rule with the same original and new IP +addresses but with different port numbers doesn't work (e.g., "DNAT +loc dmz:10.1.1.1:24 tcp 25 - 10.1.1.1")
      +
      • + +
    + Installing + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects these + problems. +

    Version 1.3.7b

    + + +

    DNAT rules where the source zone is 'fw' ($FW) + result in an error message. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this + problem.

    + + +

    Version 1.3.7a

    + + +

    "shorewall refresh" is not creating the proper + rule for FORWARDPING=Yes. Consequently, after + "shorewall refresh", the firewall will not forward + icmp echo-request (ping) packets. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this + problem.

    + + +

    Version <= 1.3.7a

    + + +

    If "norfc1918" and "dhcp" are both specified as + options on a given interface then RFC 1918 + checking is occurring before DHCP checking. This + means that if a DHCP client broadcasts using an + RFC 1918 source address, then the firewall will + reject the broadcast (usually logging it). This + has two problems:

    + + +
      +
    1. If the firewall + is running a DHCP server, the +client won't be able to obtain an IP address + lease from that server.
      2. +
    2. With this order + of checking, the "dhcp" option +cannot be used as a noise-reduction + measure where there are both dynamic and static + clients on a LAN segment.
      3. + +
    + + +

    + This version of the 1.3.7a firewall script + corrects the problem. It must be +installed in /var/lib/shorewall as +described above.

    + + +

    Version 1.3.7

    + + +

    Version 1.3.7 dead on arrival -- please use + version 1.3.7a and check your version against + these md5sums -- if there's a difference, please + download again.

    + + +
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    + +

    In other words, type "md5sum <whatever package you downloaded> + and compare the result with what you see above.

    + +

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the + .7 version in each sequence from now on.

    + +

    Version 1.3.6

    + +
      +
    • + + +

      If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, + an error occurs when the firewall script attempts to + add an SNAT alias.

      +
      • +
    • + + +

      The logunclean and dropunclean options + cause errors during startup when Shorewall is run with iptables + 1.2.7.

      +
      • + +
    + +

    These problems are fixed in + this correct firewall script which must be installed in + /var/lib/shorewall/ as described above. These problems are also + corrected in version 1.3.7.

    + +

    Two-interface Samples 1.3.6 (file two-interfaces.tgz)

    + +

    A line was inadvertently deleted from the "interfaces + file" -- this line should be added back in if the version that you + downloaded is missing it:

    + +

    net    eth0    detect    routefilter,dhcp,norfc1918

    + +

    If you downloaded two-interfaces-a.tgz then the above + line should already be in the file.

    + +

    Version 1.3.5-1.3.5b

    + +

    The new 'proxyarp' interface option doesn't work :-( + This is fixed in + this corrected firewall script which must be installed in + /var/lib/shorewall/ as described above.

    + +

    Versions 1.3.4-1.3.5a

    + +

    Prior to version 1.3.4, host file entries such as the + following were allowed:

    + +
    +
    	adm	eth0:1.2.4.5,eth0:5.6.7.8
    +
    + +
    +

    That capability was lost in version 1.3.4 so that it is only + possible to  include a single host specification on each line. + This problem is corrected by this + modified 1.3.5a firewall script. Install the script in +/var/lib/pub/shorewall/firewall as instructed above.

    +
    + +
    +

    This problem is corrected in version 1.3.5b.

    +
    + +

    Version 1.3.5

    + +

    REDIRECT rules are broken in this version. Install + + this corrected firewall script in /var/lib/pub/shorewall/firewall + as instructed above. This problem is corrected in version + 1.3.5a.

    + +

    Version 1.3.n, n < 4

    + +

    The "shorewall start" and "shorewall restart" commands + to not verify that the zones named in the /etc/shorewall/policy +file have been previously defined in the /etc/shorewall/zones +file. The "shorewall check" command does perform this verification +so it's a good idea to run that command after you have made configuration + changes.

    + +

    Version 1.3.n, n < 3

    + +

    If you have upgraded from Shorewall 1.2 and after + "Activating rules..." you see the message: "iptables: No chains/target/match + by that name" then you probably have an entry in /etc/shorewall/hosts + that specifies an interface that you didn't include +in /etc/shorewall/interfaces. To correct this problem, you + must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 + and later versions produce a clearer error message in +this case.

    + +

    Version 1.3.2

    + +

    Until approximately 2130 GMT on 17 June 2002, the + download sites contained an incorrect version of the .lrp file. That + file can be identified by its size (56284 bytes). The correct +version has a size of 38126 bytes.

    + +
      +
    • The code to detect a duplicate interface + entry in /etc/shorewall/interfaces contained a typo that + prevented it from working correctly.
      • +
    • "NAT_BEFORE_RULES=No" was broken; +it behaved just like "NAT_BEFORE_RULES=Yes".
      • + +
    + +

    Both problems are corrected in + this script which should be installed in /var/lib/shorewall + as described above.

    + +
      +
    • + + +

      The IANA have just announced the allocation of subnet + 221.0.0.0/8. This + updated rfc1918 file reflects that allocation.

      +
      • + +
    + +

    Version 1.3.1

    + +
      +
    • TCP SYN packets may be double counted + when LIMIT:BURST is included in a CONTINUE or ACCEPT policy + (i.e., each packet is sent through the limit chain twice).
      • +
    • An unnecessary jump to the policy +chain is sometimes generated for a CONTINUE policy.
      • +
    • When an option is given for more than + one interface in /etc/shorewall/interfaces then depending + on the option, Shorewall may ignore all but the first + appearence of the option. For example:
      +
      + net    eth0    dhcp
      + loc    eth1    dhcp
      +
      + Shorewall will ignore the 'dhcp' on eth1.
      • +
    • Update 17 June 2002 - The bug described + in the prior bullet affects the following options: +dhcp, dropunclean, logunclean, norfc1918, routefilter, +multi, filterping and noping. An additional bug has been +found that affects only the 'routestopped' option.
      +
      + Users who downloaded the corrected script + prior to 1850 GMT today should download and install + the corrected script again to ensure that this second + problem is corrected.
      • + +
    + +

    These problems are corrected in + this firewall script which should be installed in /etc/shorewall/firewall + as described above.

    + +

    Version 1.3.0

    + +
      +
    • Folks who downloaded 1.3.0 from the + links on the download page before 23:40 GMT, 29 May + 2002 may have downloaded 1.2.13 rather than 1.3.0. +The "shorewall version" command will tell you which version + that you have installed.
      • +
    • The documentation NAT.htm file uses + non-existent wallpaper and bullet graphic files. The + + corrected version is here.
      • + +
    + +
    +

    Upgrade Issues

    + +

    The upgrade issues have moved to a separate page.

    + +
    +

    Problem with + iptables version 1.2.3

    + +
    + +

    There are a couple of serious bugs in iptables 1.2.3 that + prevent it from working with Shorewall. Regrettably, RedHat + released this buggy iptables in RedHat 7.2. 

    + + +

    I have built a + corrected 1.2.3 rpm which you can download here  and I have + also built an +iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    + + +

    Update 11/9/2001: RedHat + has released an iptables-1.2.4 RPM of their own which you can + download from http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it works + fine.

    + + +

    If you would like to patch iptables 1.2.3 yourself, + the patches are available for download. This patch + which corrects a problem with parsing of the --log-level specification + while this patch + corrects a problem in handling the  TOS target.

    + + +

    To install one of the above patches:

    + + +
      +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • + + +
    +
    + + +

    Problems with kernels >= 2.4.18 + and RedHat iptables

    + +
    + +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 + may experience the following:

    + + +
    + + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    +
    + + +

    The RedHat iptables RPM is compiled with debugging enabled but the + user-space debugging code was not updated to reflect recent changes in + the Netfilter 'mangle' table. You can correct the problem +by installing + this iptables RPM. If you are already running a 1.2.5 version + of iptables, you will need to specify the --oldpackage option +to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    + + +

    Problems installing/upgrading + RPM on SuSE

    + + +

    If you find that rpm complains about a conflict + with kernel <= 2.2 yet you have a 2.4 kernel + installed, simply use the "--nodeps" option to + rpm.

    + + +

    Installing: rpm -ivh --nodeps <shorewall rpm>

    + + +

    Upgrading: rpm -Uvh --nodeps <shorewall rpm>

    + + +

    Problems with + iptables version 1.2.7 and MULTIPORT=Yes

    + + +

    The iptables 1.2.7 release of iptables has made + an incompatible change to the syntax used to + specify multiport match rules; as a consequence, + if you install iptables 1.2.7 you must be running + Shorewall 1.3.7a or later or:

    + + +
      +
    • set MULTIPORT=No + in /etc/shorewall/shorewall.conf; or
      • +
    • if you are running + Shorewall 1.3.6 you may install + + this firewall script in /var/lib/shorewall/firewall + as described above.
      • + +
    + +

    Problems with RH Kernel 2.4.18-10 and NAT
    +

    + /etc/shorewall/nat entries of the following form will result + in Shorewall being unable to start:
    +
    + +
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    192.0.2.22      eth0            192.168.9.22    yes                     yes
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + Error message is:
    + +
    Setting up NAT...
    iptables: Invalid argument
    Terminated

    + The solution is to put "no" in the LOCAL column. Kernel +support for LOCAL=yes has never worked properly and 2.4.18-10 has +disabled it. The 2.4.19 kernel contains corrected support under a new +kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
    + +

    Last updated 3/8/2003 - +Tom Eastep

    + +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    +

    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    + + diff --git a/STABLE/documentation/mailing_list.htm b/STABLE/documentation/mailing_list.htm index d27d4d905..ff74b41a7 100644 --- a/STABLE/documentation/mailing_list.htm +++ b/STABLE/documentation/mailing_list.htm @@ -2,121 +2,119 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - + - +
    + Powered by Postfix    
    + + + - - + +
    +
    - + +

    Vexira Logo -

    + - - - + +

     

    -     		- + +

    Shorewall Mailing Lists

    -     		(Postfix Logo) -
    - +     		(Postfix Logo) +
    + -
    - - + +
    +

    -
    -     
    -
    -
    - +

    REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please - read the Shorewall Support - Guide.
    -

    - +read the Shorewall Support +Guide.
    +

    If you experience problems with any of these lists, please - let me know

    - + let me know

    +

    Not able to Post Mail to shorewall.net?

    - +

    You can report such problems by sending mail to tom dot eastep - at hp dot com.

    - + at hp dot com.

    +

    A Word about SPAM Filters 

    - +

    Before subscribing please read my policy about list traffic that bounces. Also please note that the mail server - at shorewall.net checks incoming mail:
    -

    - + at shorewall.net checks incoming mail:
    +

    +
      -
    1. against Spamassassin - (including Vipul's Razor).
      -
      2. -
    2. to ensure that the sender address is fully qualified.
      3. -
    3. to verify that the sender's domain has an A or -MX record in DNS.
      4. -
    4. to ensure that the host name in the HELO/EHLO command - is a valid fully-qualified DNS name that resolves.
      5. - +
    5. against Spamassassin + (including Vipul's Razor).
      +
      6. +
    6. to ensure that the sender address is fully qualified.
      7. +
    7. to verify that the sender's domain has an A or MX +record in DNS.
      8. +
    8. to ensure that the host name in the HELO/EHLO command + is a valid fully-qualified DNS name that resolves.
      9. +
    - +

    Please post in plain text

    - A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net - "for continuous abuse" because it has been my policy to allow HTML in - list posts!!
    -
    - I think that blocking all HTML is a Draconian way to control - spam and that the ultimate losers here are not the spammers but the + A growing number of MTAs serving list subscribers are rejecting + all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net + "for continuous abuse" because it has been my policy to allow HTML in +list posts!!
    +
    + I think that blocking all HTML is a Draconian way to control +spam and that the ultimate losers here are not the spammers but the list subscribers whose MTAs are bouncing all shorewall.net mail. As one list subscriber wrote to me privately "These e-mail admin's need to get a (explitive deleted) life instead of trying to rid the planet @@ -124,36 +122,36 @@ of HTML based e-mail". Nevertheless, to allow subscribers to receive list posts as must as possible, I have now configured the list server at shorewall.net to strip all HTML from outgoing posts. This means that HTML-only posts will be bounced by the list server.
    - +

    Note: The list server limits posts to 120kb.
    -

    - +

    +

    Other Mail Delivery Problems

    - If you find that you are missing an occasional list post, your - e-mail admin may be blocking mail whose Received: headers contain - the names of certain ISPs. Again, I believe that such policies hurt more - than they help but I'm not prepared to go so far as to start stripping -Received: headers to circumvent those policies.
    - + If you find that you are missing an occasional list post, your +e-mail admin may be blocking mail whose Received: headers contain +the names of certain ISPs. Again, I believe that such policies hurt more +than they help but I'm not prepared to go so far as to start stripping Received: + headers to circumvent those policies.
    +

    Mailing Lists Archive Search

    - +
    - +

    Match: - + - Format: - + Format: + - Sort by: - + Sort by: + -
    - Search:

    -
    + Search:

    + - +

    Please do not try to download the entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't stand the traffic. If I catch you, you will be blacklisted.
    -

    - + +

    Shorewall CA Certificate

    - If you want to trust X.509 certificates issued by Shoreline - Firewall (such as the one used on my web site), you may download and install my CA certificate - in your browser. If you don't wish to trust my certificates then - you can either use unencrypted access when subscribing to Shorewall - mailing lists or you can use secure access (SSL) and accept the server's - certificate when prompted by your browser.
    - + in your browser. If you don't wish to trust my certificates then + you can either use unencrypted access when subscribing to Shorewall + mailing lists or you can use secure access (SSL) and accept the server's + certificate when prompted by your browser.
    +

    Shorewall Users Mailing List

    - +

    The Shorewall Users Mailing list provides a way for users - to get answers to questions and to report problems. Information - of general interest to the Shorewall user community is also posted - to this list.

    - + to get answers to questions and to report problems. Information + of general interest to the Shorewall user community is also posted + to this list.

    +

    Before posting a problem report to this list, please see - the problem reporting - guidelines.

    - + the problem reporting + guidelines.

    +

    To subscribe to the mailing list:
    -

    - +

    + - +

    To post to the list, post to shorewall-users@lists.shorewall.net.

    - +

    The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

    - +

    Note that prior to 1/1/2002, the mailing list was hosted at Sourceforge. The archives from that list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

    - +

    Shorewall Announce Mailing List

    - +

    This list is for announcements of general interest to the - Shorewall community. To subscribe:
    -

    - + Shorewall community. To subscribe:
    +

    +

    - + - +


    - The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.

    - +

    Shorewall Development Mailing List

    - +

    The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.

    - + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

    +

    To subscribe to the mailing list:
    -

    - +

    + - +

    To post to the list, post to shorewall-devel@lists.shorewall.net. 

    - +

    The list archives are at http://lists.shorewall.net/pipermail/shorewall-devel.

    - +

    How to Unsubscribe from one of - the Mailing Lists

    - + the Mailing Lists +

    There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists although Mailman 2.1 has attempted - to make this less confusing. To unsubscribe:

    - + from Mailman-managed lists although Mailman 2.1 has attempted +to make this less confusing. To unsubscribe:

    +
      -
    • - - +
    • +

      Follow the same link above that you used to subscribe - to the list.

      -
      • -
    • - - + to the list.

      +
      • +
    • +

      Down at the bottom of that page is the following text: - " To unsubscribe from <list name>, get a + " To unsubscribe from <list name>, get a password reminder, or change your subscription options enter your subscription email address:". Enter your email address in the box and click on the "Unsubscribe or edit options" button.

      -
      • -
    • - - +
      • +
    • +

      There will now be a box where you can enter your password - and click on "Unsubscribe"; if you have forgotten your password, - there is another button that will cause your password to be emailed - to you.

      -
      • - + and click on "Unsubscribe"; if you have forgotten your password, + there is another button that will cause your password to be emailed + to you.

      + +
    - -
    + +

    Frustrated by having to Rebuild Mailman to use it with Postfix?

    - +

    Check out these instructions

    - +

    Last updated 2/24/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.
    -

    +

    +
    +
    +
    diff --git a/STABLE/documentation/myfiles.htm b/STABLE/documentation/myfiles.htm index e43a34778..e12951d5e 100644 --- a/STABLE/documentation/myfiles.htm +++ b/STABLE/documentation/myfiles.htm @@ -1,189 +1,226 @@ - + My Shorewall Configuration - + + - + - + - + - - - + + - - - + + + +
    - +
    +

    About My Network

    -
    - +
    - +

    My Current Network

    - -
    + +

    Warning: I -use a combination of Static NAT and Proxy ARP, neither of which are relevant -to a simple configuration with a single public IP address. -If you have just a single public IP address, most of what you see here won't -apply to your setup so beware of copying parts of this configuration and expecting -them to work for you. What you copy may or may not work in your setup.
    -

    - + use a combination of Static NAT and Proxy ARP, neither of which are relevant + to a simple configuration with a single public IP address. + If you have just a single public IP address, most of what you see here won't + apply to your setup so beware of copying parts of this configuration and +expecting them to work for you. What you copy may or may not work in your +configuration.
    +

    +

    I have DSL service and have 5 static IP addresses (206.124.146.176-180). - My DSL "modem" (Fujitsu Speedport) - is connected to eth0. I have a local network connected to eth2 (subnet - 192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

    - + My DSL "modem" (Fujitsu Speedport) + is connected to eth0. I have a local network connected to eth2 (subnet + 192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

    +

    I use:
    -

    - +

    +
      -
    • Static NAT for ursa (my XP System) - Internal address 192.168.1.5 - and external address 206.124.146.178.
      • -
    • Proxy ARP for wookie (my Linux System). This system has two - IP addresses: 192.168.1.3/24 and 206.124.146.179/24.
      • -
    • SNAT through the primary gateway address (206.124.146.176) - for  my Wife's system (tarry) and the Wireless Access Point (wap)
      • - +
    • Static NAT for Ursa (my XP System) - Internal address 192.168.1.5 + and external address 206.124.146.178.
      • +
    • Static NAT for Wookie (my Linux System). Internal address +192.168.1.3 and external address 206.124.146.179.
      • +
    • SNAT through the primary gateway address (206.124.146.176) + for  my Wife's system (Tarry) and the laptop when connected through +the Wireless Access Point (wap)
      • +
    - -

    The firewall runs on a 128MB PII/233 with RH7.2 and Kernel 2.4.20-pre6.

    - + +

    The firewall runs on a 256MB PII/233 with RH8.0.

    +

    Wookie runs Samba and acts as the a WINS server.  Wookie is in its - own 'whitelist' zone called 'me'.

    - + own 'whitelist' zone called 'me'.

    +

    My laptop (eastept1) is connected to eth3 using a cross-over cable. - It runs its own Sygate firewall + It runs its own Sygate firewall software and is managed by Proxy ARP. It connects to the local network -through the PopTop server running on my firewall.

    - +through a PPTP server running on Ursa.

    +

    The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP -server (Pure-ftpd). The system also runs fetchmail to fetch our email -from our old and current ISPs. That server is managed through Proxy ARP.

    - + Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP + server (Pure-ftpd). The system also runs fetchmail to fetch our email + from our old and current ISPs. That server is managed through Proxy ARP.

    +

    The firewall system itself runs a DHCP server that serves the local - network.

    - -

    All administration and publishing is done using ssh/scp.

    - + network.

    + +

    All administration and publishing is done using ssh/scp. I have X installed +on both the firewall and the server but no X server or desktop is installed. +X applications tunnel through SSH to XWin.exe running on Ursa.

    +

    I run an SNMP server on my firewall to serve MRTG running - in the DMZ.

    - + in the DMZ.

    +

    -

    - +

    +

     

    - +

    The ethernet interface in the Server is configured with IP address 206.124.146.177, netmask 255.255.255.0. The server's default gateway is 206.124.146.254 (Router at my ISP. This is the same default gateway used by the firewall itself). On the firewall, - Shorewall automatically adds a host route to - 206.124.146.177 through eth1 (192.168.2.1) because + Shorewall automatically adds a host route to + 206.124.146.177 through eth1 (192.168.2.1) because of the entry in /etc/shorewall/proxyarp (see below).

    - +

    A similar setup is used on eth3 (192.168.3.1) which interfaces to my laptop (206.124.146.180).
    -

    - +

    +

    Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior - access.
    -

    - + access.
    +

    +

    -
    - +
    +

    Shorewall.conf

    - -
    	SUBSYSLOCK=/var/lock/subsys/shorewall
    	STATEDIR=/var/state/shorewall

    	LOGRATE=
    	LOGBURST=

    	ADD_IP_ALIASES="Yes"

    	CLAMPMSS=Yes

    	MULTIPORT=Yes
    - -

    Zones File:

    - -
    	#ZONE 	DISPLAY 	COMMENTS
    	net	Internet	Internet
    	me	Eastep		My Workstation
    	loc	Local		Local networks
    	dmz	DMZ		Demilitarized zone
    	tx	Texas		Peer Network in Dallas Texas
    	#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    - + +
    + 
    SHARED_DIR=/usr/share/shorewall
    LOGFILE=/var/log/firewall
    LOGRATE=
    LOGBURST=
    LOGUNCLEAN=info
    BLACKLIST_LOGLEVEL=
    LOGNEWNOTSYN=
    MACLIST_LOG_LEVEL=$LOG
    TCP_FLAGS_LOG_LEVEL=$LOG
    RFC1918_LOG_LEVEL=$LOG
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
    SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall
    MODULESDIR=
    FW=fw
    NAT_ENABLED=Yes
    MANGLE_ENABLED=Yes
    IP_FORWARDING=On
    ADD_IP_ALIASES=Yes
    ADD_SNAT_ALIASES=Yes
    TC_ENABLED=Yes
    CLEAR_TC=No
    MARK_IN_FORWARD_CHAIN=No
    CLAMPMSS=Yes
    ROUTE_FILTER=No
    NAT_BEFORE_RULES=No
    MULTIPORT=Yes
    DETECT_DNAT_IPADDRS=Yes
    MUTEX_TIMEOUT=60
    NEWNOTSYN=Yes
    BLACKLIST_DISPOSITION=DROP
    MACLIST_DISPOSITION=REJECT
    TCP_FLAGS_DISPOSITION=DROP
    +
    + +

    +

    Params File (Edited):

    + +
    MIRRORS=<list of shorewall mirror ip addresses>
    + NTPSERVERS=<list of the NTP servers I sync with>
    + LOG=ULOG
    + TEXAS=<ip address of gateway in Dallas>
    +
    + +

    Zones File

    + +
    + 
    #ZONE	DISPLAY		COMMENTS
    net     Internet        Internet
    me      Wookie          My Linux Workstation
    dmz     DMZ             Demilitarized zone
    loc     Local           Local networks
    tx      Texas           Peer Network in Dallas
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +
    +

    Interfaces File:

    - -
    + +
    +

    This is set up so that I can start the firewall before bringing up my Ethernet interfaces.

    -
    - -
    	#ZONE    INTERFACE	BROADCAST 	OPTIONS
    	net	eth0 		206.124.146.255	routefilter,norfc1918,blacklist,filterping
    	loc	eth2 		192.168.1.255	dhcp,filterping,maclist
    	dmz	eth1 		206.124.146.255	filterping
    	net	eth3		206.124.146.255 filterping,blacklist
    	-	texas 		-               filterping
    	loc	ppp+		-		filterping
    	#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    - +
    + +
    + 
    #ZONE	INERFACE	BROADCAST	OPTIONS
    net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
    loc     eth2            192.168.1.255   dhcp,maclist
    dmz     eth1            192.168.2.255
    net     eth3            206.124.146.255
    -       texas           192.168.9.255
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +
    +

    Hosts File:

    - -
    	#ZONE 		HOST(S)			OPTIONS
    	me		eth2:192.168.1.3,eth2:206.124.146.179
    	tx 		texas:192.168.9.0/24
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE -- DO NOT REMOVE
    - + +
    + 
    #ZONE		HOST(S)			OPTIONS
    me              eth2:192.168.1.3
    tx              texas:192.168.8.0/22
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +
    +

    Routestopped File:

    - -
    	#INTERFACE	HOST(S)
    	eth1		206.124.146.177
    	eth2 		-
    	eth3 		206.124.146.180
    - -

    Common File:

    - -
    	. /etc/shorewall/common.def
    	run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
    + +
    + 
    #INTERFACQ	HOST(S)
    eth1            206.124.146.177
    eth2            -
    eth3            206.124.146.180
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +

    Policy File:

    - -
    
-	#SOURCE	DEST	POLICY	LOG LEVEL	LIMIT:BURST
-	me	all	ACCEPT
-	tx	me	ACCEPT		#Give Texas access to my personal system
-	all	me	CONTINUE	#WARNING: You must be running Shorewall 1.3.1 or later for
    					    #	  this policy to work as expected!!!	
    	loc 	loc 	ACCEPT
    	loc 	net	ACCEPT
    	$FW	loc	ACCEPT
    	$FW	tx	ACCEPT
    	loc	tx	ACCEPT
    	loc	fw	REJECT
    	net	net	ACCEPT
    	net	all	DROP	info		10/sec:40
    	all	all	REJECT	info
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOTE
    - + +
    + 
    #SOURCE		DESTINATION	POLICY		LOG LEVEL	BURST:LIMIT
    me              all             ACCEPT
    tx              me              ACCEPT
    all             me              CONTINUE        -               2/sec:5
    loc             net             ACCEPT
    $FW             loc             ACCEPT
    $FW             tx              ACCEPT
    loc             tx              ACCEPT
    loc             fw              REJECT          $LOG
    net             net             ACCEPT
    net             all             DROP            $LOG            10/sec:40
    all             all             REJECT          $LOG
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +
    +

    Masq File:

    - +
    - +

    Although most of our internal systems use static NAT, my wife's system - (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with - laptops. Also, I masquerade wookie to the peer subnet in Texas.

    -
    - -
    	#INTERFACE 	SUBNET		ADDRESS
    	eth0 		192.168.1.0/24	206.124.146.176
            texas           206.124.146.179 192.168.1.254
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with + laptops. Also, I masquerade wookie to the peer subnet in Texas.

    + + +
    + 
    #INTERFACE              SUBNET          ADDRESS
    eth0:0.0.0.0/0          eth2            206.124.146.176
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    +
    +

    NAT File:

    - -
    	#EXTERNAL	INTERFACE	INTERNAL	ALL	LOCAL
    	206.124.146.178 eth0 		192.168.1.5 	No 	No
    	206.124.146.179 eth0 		192.168.1.3 	No 	No
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - + +
    + 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    206.124.146.178 eth0:0          192.168.1.5     No                      No
    206.124.146.179 eth0:1          192.168.1.3     No                      No
    192.168.1.193   eth2:0          206.124.146.177 No                      No
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    +
    +

    Proxy ARP File:

    - -
         	#ADDRESS	INTERFACE	EXTERNAL	HAVEROUTE
    	206.124.146.177 eth1 		eth0 		No
    	206.124.146.180	eth3		eth0		No
    	#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    - + +
    + 
    #ADDRESS                INTERFACE       EXTERNAL        HAVEROUTE
    206.124.146.177         eth1            eth0            No
    206.124.146.180         eth3            eth0            No
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +
    +

    Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):

    - -
    	#TYPE           ZONE    GATEWAY	
    	gre             net     $TEXAS
    	#LAST LINE -- DO NOT REMOVE
    - + +
    + 
    #TYPE			ZONE    GATEWAY         GATEWAY ZONE    PORT
    gre                     net     $TEXAS
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +
    + +

    Common File:

    + +
    + 
    . /etc/shorewall/common.def
    run_iptables -A common -p tcp --dport auth -j REJECT
    +
    +

    Rules File (The shell variables are set in /etc/shorewall/params):

    - -
         	#ACTION		SOURCE 		DEST 			PROTO	DEST 	SOURCE  ORIGINAL
    	#                       				PORT(S) PORT(S)	PORT(S)	DEST
    	#
    	# Local Network to Internet - Reject attempts by Trojans to call home
    	#
    	REJECT:info 	loc 		net 			tcp	6667
    	#
    	# Local Network to Firewall 
    	#
    	ACCEPT		loc		fw 			tcp 	ssh
    	ACCEPT		loc		fw			tcp	time
    	#
    	# Local Network to DMZ 
    	#
    	ACCEPT 		loc 		dmz 			udp	domain
    	ACCEPT		loc		dmz			tcp	smtp
    	ACCEPT		loc		dmz			tcp	domain
    	ACCEPT		loc		dmz			tcp	ssh
    	ACCEPT		loc		dmz			tcp	auth
    	ACCEPT		loc		dmz			tcp	imap
    	ACCEPT		loc		dmz			tcp	https
    	ACCEPT		loc		dmz			tcp	imaps
    	ACCEPT		loc		dmz			tcp	cvspserver
    	ACCEPT 		loc 		dmz 			tcp 	www
    	ACCEPT		loc		dmz			tcp	ftp
    	ACCEPT		loc		dmz			tcp	pop3
    	ACCEPT		loc		dmz			icmp	echo-request
    	#
    	# Internet to DMZ 
    	#
    	ACCEPT		net		dmz 			tcp	www
    	ACCEPT		net		dmz			tcp	smtp
    	ACCEPT		net		dmz			tcp	ftp
    	ACCEPT		net		dmz			tcp	auth
    	ACCEPT		net		dmz			tcp	https
    	ACCEPT		net		dmz			tcp	imaps
    	ACCEPT		net		dmz			tcp	domain
    	ACCEPT		net		dmz			tcp	cvspserver
    	ACCEPT		net		dmz			udp	domain
    	ACCEPT		net		dmz			icmp	echo-request
    	ACCEPT 		net:$MIRRORS	dmz			tcp	rsync
    	#
    	# Net to Me (ICQ chat and file transfers) 
    	#
    	ACCEPT		net		me			tcp	4000:4100
    	#
    	# Net to Local 
    	#
    	ACCEPT		net		loc			tcp	auth
    	REJECT		net		loc			tcp	www
    	ACCEPT		net		loc:192.168.1.5		tcp	1723
    	ACCEPT		net		loc:192.168.1.5		gre
    	#
    	# DMZ to Internet
    	#
    	ACCEPT		dmz		net			icmp	echo-request
    	ACCEPT		dmz		net			tcp	smtp
    	ACCEPT		dmz		net			tcp	auth
    	ACCEPT		dmz		net			tcp	domain
    	ACCEPT		dmz		net			tcp	www
    	ACCEPT		dmz		net			tcp	https
    	ACCEPT		dmz		net			tcp	whois
    	ACCEPT		dmz		net			tcp	echo
    	ACCEPT		dmz		net			udp	domain
    	ACCEPT		dmz 		net:$NTPSERVERS		udp	ntp
    	ACCEPT 		dmz 		net:$POPSERVERS		tcp	pop3
    	#
    	# The following compensates for a bug, either in some FTP clients or in the
    	# Netfilter connection tracking code that occasionally denies active mode
    	# FTP clients
    	#
    	ACCEPT:info 	dmz 		net			tcp	1024:	20
    	#
    	# DMZ to Firewall -- snmp
    	#
    	ACCEPT 		dmz 		fw 			tcp	snmp
    	ACCEPT		dmz		fw			udp	snmp
    	#
    	# DMZ to Local Network 
    	#
    	ACCEPT 		dmz 		loc			tcp	smtp
    	ACCEPT		dmz		loc			tcp	auth
    	ACCEPT		dmz		loc			icmp	echo-request
    	# Internet to Firewall
    	#
    	REJECT 		net		fw			tcp	www
    	#
    	# Firewall to Internet
    	#
    	ACCEPT 		fw 		net:$NTPSERVERS		udp	ntp
    	ACCEPT		fw		net			udp	domain
    	ACCEPT		fw		net			tcp	domain
    	ACCEPT		fw		net			tcp	www
    	ACCEPT		fw		net			tcp	https
    	ACCEPT		fw		net			tcp	ssh
    	ACCEPT		fw		net			tcp	whois
    	ACCEPT		fw		net 			icmp	echo-request
    	#
    	# Firewall to DMZ
    	#
    	ACCEPT 		fw 		dmz 			tcp 	www
    	ACCEPT 		fw 		dmz 			tcp 	ftp
    	ACCEPT 		fw 		dmz 			tcp 	ssh
    	ACCEPT 		fw 		dmz 			tcp 	smtp
    	ACCEPT 		fw 		dmz 			udp 	domain
    	#
    	# Let Texas Ping
    	#
    	ACCEPT 		tx 		fw 			icmp 	echo-request
    	ACCEPT		tx 		loc 			icmp 	echo-request

    	#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    - -

    Last updated 1/12/2003 - - Tom Eastep -

    - Copyright © -2001, 2002, 2003 Thomas M. Eastep.
    + +
    + 
    ################################################################################################################################################################
    #RESULT         CLIENT(S)                       SERVER(S)               PROTO   PORT(S)                                 CLIENT          ORIGINAL DEST:SNAT
    ################################################################################################################################################################
    # Local Network to Internet - Reject attempts by Trojans to call home
    #
    REJECT:$LOG     loc                             net                     tcp     6667
    #
    # Stop NETBIOS crap since our policy is ACCEPT
    #
    REJECT          loc                             net                     tcp     137,445
    REJECT          loc                             net                     udp     137:139
    LOG:$LOG        loc                             net                     tcp     137:139
    ################################################################################################################################################################
    # Local Network to Firewall
    #
    ACCEPT          loc                             fw                      tcp     ssh,time,10000
    ACCEPT          loc                             fw                      udp     snmp
    ACCEPT          loc                             fw                      udp     ntp
    ################################################################################################################################################################
    # Local Network to DMZ (10027 is our SMTP backdoor that bypasses virus/spam filtering)
    #
    ACCEPT          loc                             dmz                     udp     domain
    ACCEPT          loc                             dmz                     tcp     smtp,domain,ssh,imap,https,imaps,cvspserver,www,ftp,10027,10000,8080    -
    ################################################################################################################################################################
    # Internet to DMZ
    #
    ACCEPT          net                             dmz                     tcp     www,smtp,ftp,imaps,domain,cvspserver,https,imap -
    ACCEPT          net                             dmz                     udp     domain
    ACCEPT          net:$MIRRORS                    dmz                     tcp     rsync
    ACCEPT:$LOG     net                             dmz                     tcp     32768:61000                             20
    DROP            net                             dmz                     tcp     1433
    ################################################################################################################################################################
    #
    # Net to Local
    #
    # My laptop isn't NATTED when in its docking station. To allow access to the local lan, I need a VPN to Ursa which is enabled by the following "half"-rules.
    #
    DNAT-           net                             loc:192.168.1.5         tcp     1723                                    -               206.124.146.178
    DNAT-           net                             loc:192.168.1.5         gre     -                                       -               206.124.146.178
    #
    # When I'm "on the road", the following two rules allow me VPN access back home.
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     1723
    ACCEPT          net                             loc:192.168.1.5         gre
    #
    # ICQ to Ursa
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     4000:4100
    ################################################################################################################################################################
    # Net to me
    #
    ACCEPT          net                             me:192.168.1.3          tcp     4000:4100
    ################################################################################################################################################################
    # DMZ to Internet
    #
    ACCEPT          dmz                             net                     tcp     smtp,domain,www,https,whois,echo,2702,21,2703,ssh
    ACCEPT          dmz                             net                     udp     domain
    ACCEPT          dmz                             net:206.124.128.8       tcp     pop3
    ACCEPT          dmz                             net:66.216.26.115       tcp     pop3
    #
    # Something is wrong with the FTP connection tracking code or there is some client out there
    # that is sending a PORT command which that code doesn't understand. Either way,
    # the following works around the problem.
    #
    ACCEPT:$LOG     dmz                             net                     tcp     1024:                                   20
    ################################################################################################################################################################
    # DMZ to Firewall -- ntp & snmp
    #
    ACCEPT          dmz                             fw                      udp     ntp                                     ntp
    ACCEPT          dmz                             fw                      tcp     snmp
    ACCEPT          dmz                             fw                      udp     snmp
    ################################################################################################################################################################
    #
    # DMZ to Local Network
    #
    ACCEPT          dmz                             loc                     tcp     smtp
    ################################################################################################################################################################
    #
    # DMZ to Me -- NFS
    #
    ACCEPT          dmz                             me                      tcp     111
    ACCEPT          dmz                             me                      udp     111
    ACCEPT          dmz                             me                      udp     2049
    ACCEPT          dmz                             me                      udp     32700:
    ################################################################################################################################################################
    # Internet to Firewall
    #
    ACCEPT          net:eth3:206.124.146.180        fw                      udp     ntp                                     ntp
    REJECT          net                             fw                      tcp     www
    DROP            net                             fw                      tcp     1433
    DROP            net:eth3:!206.124.146.180       fw                      all
    ################################################################################################################################################################
    # Firewall to Internet
    #
    ACCEPT          fw                              net:$NTPSERVERS         udp     ntp                                     ntp
    ACCEPT          fw                              net                     udp     domain
    ACCEPT          fw                              net                     tcp     domain,www,https,ssh,1723,whois,1863
    ACCEPT          fw                              net                     udp     33435:33535
    ACCEPT          fw                              net                     icmp    8
    ################################################################################################################################################################
    # Firewall to DMZ
    #
    ACCEPT          fw                              dmz                     tcp     www,ftp,ssh,smtp
    ACCEPT          fw                              dmz                     udp     domain
    ACCEPT          fw                              dmz                     icmp    8
    REJECT          fw                              dmz                     udp     137:139
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +
    + +

    Tom Eastep

    + Copyright + © 2001, 2002, 2003 Thomas M. Eastep.
    +
    +


    diff --git a/STABLE/documentation/ping.html b/STABLE/documentation/ping.html index 31637d4a9..7a392c7bb 100644 --- a/STABLE/documentation/ping.html +++ b/STABLE/documentation/ping.html @@ -2,147 +2,183 @@ ICMP Echo-request (Ping) - + - + - + - - - + + - - - + + + +
    +

    ICMP Echo-request (Ping)

    -
    -
    - Shorewall 'Ping' management has evolved over time with the latest change - coming in Shorewall version 1.3.14. In that version, a new option (OLD_PING_HANDLING) - was added to /etc/shorewall/shorewall.conf. The value of that option determines - the overall handling of ICMP echo requests (pings).
    - -

    Shorewall Versions >= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf

    - In 1.3.14, Ping handling was put under control of the rules and policies - just like any other connection request. In order to accept ping requests -from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT and z1 -is not the firewall zone, you need a rule in /etc/shoreall/rules of the form:
    - -
    ACCEPT    z1    z2    +
    + Shorewall 'Ping' management has evolved over time with the latest change + coming in Shorewall version 1.4.0.
    + +

    Shorewall Versions >= 1.4.0

    + In order to accept ping requests from zone z1 to zone z2 where the policy +for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the +form:
    + +
    ACCEPT    z1    z2    icmp    8
    -
    - Example:
    -
    - To permit ping from the local zone to the firewall:
    - -
    ACCEPT    loc    fw    +
    + Example:
    +
    + To permit ping from the local zone to the firewall:
    + +
    ACCEPT    loc    fw    icmp    8
    -
    - If you would like to accept 'ping' by default even when the relevant -policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't -already exist and in that file place the following command:
    - -
    +
    + If you would like to accept 'ping' by default even when the relevant + policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't + already exist and in that file place the following command:
    + +
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    -
    - With that rule in place, if you want to ignore 'ping' from z1 to z2 then +
    + With that rule in place, if you want to ignore 'ping' from z1 to z2 then you need a rule of the form:
    - -
    DROP    z1    z2    + +
    DROP    z1    z2    icmp    8
    -
    - Example:
    -
    - To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    - -
    DROP    net    fw    +
    + Example:
    +
    + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    +
    + +
    DROP    net    fw    icmp    8
    -
    - +
    + +

    Shorewall Versions >= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf

    + In 1.3.14, Ping handling was put under control of the rules and policies + just like any other connection request. In order to accept ping requests +from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need +a rule in /etc/shoreall/rules of the form:
    + +
    ACCEPT    z1    z2    + icmp    8
    +
    + Example:
    +
    + To permit ping from the local zone to the firewall:
    + +
    ACCEPT    loc    fw    + icmp    8
    +
    + If you would like to accept 'ping' by default even when the relevant + policy is DROP or REJECT, create /etc/shorewall/icmpdef if it doesn't + already exist and in that file place the following command:
    + +
    + 
    run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT
    +
    + With that rule in place, if you want to ignore 'ping' from z1 to z2 then + you need a rule of the form:
    + +
    DROP    z1    z2    + icmp    8
    +
    + Example:
    +
    + To drop ping from the internet, you would need this rule in /etc/shorewall/rules:
    + +
    DROP    net    fw    + icmp    8
    +
    +
    - +

    Shorewall Versions < 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
    -

    - There are several aspects to the old Shorewall Ping management:
    - -
      -
    1. The noping and filterping interface options in /etc/shorewall/interfaces.
      2. -
    2. The FORWARDPING option in /etc/shorewall/shorewall.conf.
      3. -
    3. Explicit rules in /etc/shorewall/rules.
      4. - -
    - There are two cases to consider:
    - -
      -
    1. Ping requests addressed to the firewall itself; and
      2. -
    2. Ping requests being forwarded to another system. Included here are - all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple - routing.
      3. - -
    - These cases will be covered separately.
    - -

    Ping Requests Addressed to the Firewall Itself

    - For ping requests addressed to the firewall, the sequence is as follows:
    - -
      -
    1. If neither noping nor filterping are specified for -the interface that receives the ping request then the request will be responded - to with an ICMP echo-reply.
      2. -
    2. If noping is specified for the interface that receives the - ping request then the request is ignored.
      3. -
    3. If filterping is specified for the interface then the request - is passed to the rules/policy evaluation.
      4. - -
    - -

    Ping Requests Forwarded by the Firewall

    - These requests are always passed to rules/policy evaluation.
    - -

    Rules Evaluation

    - Ping requests are ICMP type 8. So the general rule format is:
    -
    -     Target    Source    - Destination    icmp    8
    -
    - Example 1. Accept pings from the net to the dmz (pings are responded to - with an ICMP echo-reply):
    -
    -     ACCEPT    net    dmz    - icmp    8
    -
    - Example 2. Drop pings from the net to the firewall
    -
    -     DROP    net    fw    - icmp    8
    - -

    Policy Evaluation

    - If no applicable rule is found, then the policy for the source to the -destination is applied.
    - -
      -
    1. If the relevant policy is ACCEPT then the request is responded to - with an ICMP echo-reply.
      2. -
    2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf - then the request is responded to with an ICMP echo-reply.
      3. -
    3. Otherwise, the relevant REJECT or DROP policy is used and the request - is either rejected or simply ignored.
      4. - -
    - -

    Updated 2/14/2003 - Tom Eastep -

    + + There are several aspects to the old Shorewall Ping management:
    +
      +
    1. The noping and filterping interface options in /etc/shorewall/interfaces.
      2. +
    2. The FORWARDPING option in /etc/shorewall/shorewall.conf.
      3. +
    3. Explicit rules in /etc/shorewall/rules.
      4. + +
    + There are two cases to consider:
    + +
      +
    1. Ping requests addressed to the firewall itself; and
      2. +
    2. Ping requests being forwarded to another system. Included here +are all cases of packet forwarding including NAT, DNAT rule, Proxy ARP +and simple routing.
      3. + +
    + These cases will be covered separately.
    + +

    Ping Requests Addressed to the Firewall Itself

    + For ping requests addressed to the firewall, the sequence is as follows:
    + +
      +
    1. If neither noping nor filterping are specified for + the interface that receives the ping request then the request will be responded + to with an ICMP echo-reply.
      2. +
    2. If noping is specified for the interface that receives the + ping request then the request is ignored.
      3. +
    3. If filterping is specified for the interface then the request + is passed to the rules/policy evaluation.
      4. + +
    + +

    Ping Requests Forwarded by the Firewall

    + These requests are always passed to rules/policy evaluation.
    + +

    Rules Evaluation

    + Ping requests are ICMP type 8. So the general rule format is:
    +
    +     Target    Source    + Destination    icmp    8
    +
    + Example 1. Accept pings from the net to the dmz (pings are responded +to with an ICMP echo-reply):
    +
    +     ACCEPT    net    dmz    + icmp    8
    +
    + Example 2. Drop pings from the net to the firewall
    +
    +     DROP    net    fw    + icmp    8
    + +

    Policy Evaluation

    + If no applicable rule is found, then the policy for the source to the +destination is applied.
    + +
      +
    1. If the relevant policy is ACCEPT then the request is responded +to with an ICMP echo-reply.
      2. +
    2. If FORWARDPING is set to Yes in /etc/shorewall/shorewall.conf + then the request is responded to with an ICMP echo-reply.
      3. +
    3. Otherwise, the relevant REJECT or DROP policy is used and the request + is either rejected or simply ignored.
      4. + +
    + +

    Updated 2/14/2003 - Tom Eastep +

    +

    Copyright © 2001, 2002, 2003 Thomas M. Eastep.

    +



    diff --git a/STABLE/documentation/ports.htm b/STABLE/documentation/ports.htm index 8a5d0a8f0..e6d655c99 100644 --- a/STABLE/documentation/ports.htm +++ b/STABLE/documentation/ports.htm @@ -184,13 +184,8 @@ to a server with IP address a.b.c.d in zone z2:
    -

    Note that my rules only cover NFS using UDP (the normal case) and your -milage may vary depending on the software you are using (I'm using RH8.0 -on both ends). In particular, the local port range in my server starts at -32768 (It's 32768 - 61000; I could probably get away with just opening those -ports).
    -
    -There is lots of additional information at  Note that my rules only cover NFS using UDP (the normal case). There +is lots of additional information at  http://nfs.sourceforge.net/nfs-howto/security.html

    diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index ba241ba59..7f3b37a5e 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -6,32 +6,34 @@ - + + - Shoreline Firewall (Shorewall) 1.3 + Shoreline Firewall (Shorewall) 1.4 - + + - + - + - + - - - - + - - - + + +
    + @@ -41,15 +43,28 @@ - +

    Shorwall Logo - Shorewall 1.3 - "iptables made easy"

    + (Shorewall Logo) + + + +
    +

    Shorewall 1.4 "iptables made easy" 

    +
    + + +

    +

    @@ -60,43 +75,42 @@ - - + + +
    Shorewall 1.3 Site is here                   +           
    -
    +
    +
    - -
    - -
    - + +
    + +
    + - + - + - + - + + + + + + + + + +
    + @@ -106,7 +120,8 @@ - + +

    What is it?

    @@ -119,11 +134,12 @@ - -

    The Shoreline Firewall, more commonly known as "Shorewall", is a - Netfilter (iptables) based firewall - that can be used on a dedicated firewall system, a multi-function - gateway/router/server or on a standalone GNU/Linux system.

    + + +

    The Shoreline Firewall, more commonly known as "Shorewall", is +a Netfilter (iptables) based +firewall that can be used on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

    @@ -135,29 +151,30 @@ - -

    This program is free software; you can redistribute it and/or modify - it under the terms - of Version -2 of the GNU General Public License as published by the Free Software - Foundation.
    -
    + +

    This program is free software; you can redistribute it and/or modify + it under the +terms of Version + 2 of the GNU General Public License as published by the Free +Software Foundation.
    - 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 General Public License - for more details.
    +
    -
    + 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 General Public License + for more details.
    - You should have received -a copy of the GNU General Public License - along with this program; if not, write to the - Free Software Foundation, Inc., 675 Mass -Ave, Cambridge, MA 02139, USA

    +
    + + You should have received + a copy of the GNU General Public License + along with this program; if not, write +to the Free Software Foundation, Inc., 675 + Mass Ave, Cambridge, MA 02139, USA

    @@ -169,7 +186,8 @@ Ave, Cambridge, MA 02139, USA

    - + +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -182,413 +200,390 @@ Ave, Cambridge, MA 02139, USA

    - + +

    - Jacques Nilo and - Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution called - Bering that features Shorewall-1.3.14 - and Kernel-2.4.20. You can find their work at: - http://leaf.sourceforge.net/devel/jnilo
    -

    - - - - - - -

    Congratulations to Jacques and Eric on the recent release of Bering -1.1!!!
    -

    - - - - - - -

    This is a mirror of the main Shorewall web site at SourceForge (http://shorewall.sf.net)

    - - - - - - - - - - - - - - -

    News

    - - - - - - - - - - - - -

    - - - - - - - - - -

    3/7/2003 - Shorewall 1.4.0 RC2 (New) -  

    - Shorewall 1.4 represents - the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall - over time.
    -
    - IMPORTANT: Shorewall 1.4.0 requires the iproute package - ('ip' utility).
    -
    - Function from 1.3 that has been omitted from this version include:
    - -
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no - longer supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      2. -
    2. Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate an error.
      -
      -
      3. -
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      4. -
    4. The 'routestopped' option in the /etc/shorewall/interfaces - and /etc/shorewall/hosts files is no longer supported and will generate - an error at startup if specified.
      -
      -
      5. -
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is -no longer accepted.
      -
      -
      6. -
    6. The ALLOWRELATED variable in shorewall.conf is no longer -supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
      7. -
    7. The icmp.def file has been removed.
      -
      8. - -
    - Changes for 1.4 include:
    - -
      -
    1. The /etc/shorewall/shorewall.conf file has been completely - reorganized into logical sections.
      -
      -
      2. -
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      3. -
    3. The firewall script, common functions file and version file -are now installed in /usr/share/shorewall.
      -
      -
      4. -
    4. Late arriving DNS replies are now silently dropped in the - common chain by default.
      -
      -
      5. -
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall - 1.4 no longer unconditionally accepts outbound ICMP packets. So if you - want to 'ping' from the firewall, you will need the appropriate rule or -policy.
      -
      -
      6. -
    6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      7. -
    7. 802.11b devices with names of the form wlan<n> - now support the 'maclist' option.
      -
      -
      8. -
    8. Explicit Congestion Notification (ECN - RFC 3168) -may now be turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
      -
      -    a) You must be running kernel 2.4.20
      -    b) You must have applied the patch in
      -    http://www.shorewall/net/pub/shorewall/ecn/patch.
      -    c) You must have iptables 1.2.7a installed.
      -
      -
      9. -
    9. The /etc/shorewall/params file is now processed first so that - variables may be used in the /etc/shorewall/shorewall.conf file.
      10. - -
    - You may download the release candidate from:
    - -
    http://www.shorewall.net/pub/shorewall/Beta
    - ftp://ftp.shorewall.net/pub/shorewall/Beta
    -
    - -

    2/8/2003 - Shorewall 1.3.14

    - - -

    New features include

    - - -
      -
    1. An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been (see - http://www.shorewall.net/ping.html).
      -
      - When OLD_PING_HANDLING=No, icmp echo (ping) is handled via - rules and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options - in /etc/shorewall/interfaces will all generate an error.
      -
      -
      2. -
    2. It is now possible to direct Shorewall to create a -"label" such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
      -  
      -    a) In the INTERFACE column of /etc/shorewall/masq
      -    b) In the INTERFACE column of /etc/shorewall/nat
      -  
      3. -
    3. Support for OpenVPN Tunnels.
      -
      -
      4. -
    4. Support for VLAN devices with names of the form $DEV.$VID - (e.g., eth0.0)
      -
      -
      5. -
    5. In /etc/shorewall/tcrules, the MARK value may be optionally - followed by ":" and either 'F' or 'P' to designate that the marking will - occur in the FORWARD or PREROUTING chains respectively. If this additional - specification is omitted, the chain used to mark packets will be determined - by the setting of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      -
      -
      6. -
    6. When an interface name is entered in the SUBNET column - of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic - from only the first subnet defined on that interface. It did not masquerade - traffic from:
      -  
      -    a) The subnets associated with other addresses on the -interface.
      -    b) Subnets accessed through local routers.
      -  
      - Beginning with Shorewall 1.3.14, if you enter an interface - name in the SUBNET column, shorewall will use the firewall's routing - table to construct the masquerading/SNAT rules.
      -  
      - Example 1 -- This is how it works in 1.3.14.
      -   
      - - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      - - - - 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      -  
      - When upgrading to Shorewall 1.3.14, if you have multiple -local subnets connected to an interface that is specified in the -SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq -file will need changing. In most cases, you will simply be able to remove -redundant entries. In some cases though, you might want to change from -using the interface name to listing specific subnetworks if the change -described above will cause masquerading to occur on subnetworks that you -don't wish to masquerade.
      -  
      - Example 2 -- Suppose that your current config is as follows:
      -   
      - - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, the second entry in /etc/shorewall/masq -is no longer required.
      -  
      - Example 3 -- What if your current configuration is like this?
      -  
      - - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, you would want to change the entry in  /etc/shorewall/masq - to:
      - - - - 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      -
      7. - - -
    -
    - - -

    2/5/2003 - Shorewall Support included in Webmin 1.060 -

    - Webmin version 1.060 now has Shorewall support included as -standard. See http://www.webmin.com. - - -

    - - - -

    - - -
      - - - - - - -
    - + Jacques Nilo + and Eric Wolzak have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.3.14 and Kernel-2.4.20. You can find + their work at: http://leaf.sourceforge.net/devel/jnilo
    +

    -

    More News

    +

    Congratulations to Jacques and Eric on the recent release of +Bering 1.1!!!
    +

    + +

    This is a mirror of the main Shorewall web site at SourceForge +(http://shorewall.sf.net)

    + +

    News

    + +

    3/17/2003 - Shorewall 1.4.0 (New) +

    + Shorewall 1.4 represents + the next step in the evolution of Shorewall. The main thrust of the + initial release is simply to remove the cruft that has accumulated in + Shorewall over time.
    +
    + IMPORTANT: Shorewall 1.4.0 requires the iproute package + ('ip' utility).
    +
    + Function from 1.3 that has been omitted from this version + include:
    + + +
      +
    1. The MERGE_HOSTS variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      +
      +
      2. +
    2. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
      3. +
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification + of the 'noping' or 'filterping' interface options.
      +
      +
      4. +
    4. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will generate + an error at startup if specified.
      +
      +
      5. +
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no + longer accepted.
      +
      +
      6. +
    6. The ALLOWRELATED variable in shorewall.conf is no longer +supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
      +
      7. +
    7. The icmp.def file has been removed.
      +
      8. + +
    + Changes for 1.4 include:
    + + +
      +
    1. The /etc/shorewall/shorewall.conf file has been completely + reorganized into logical sections.
      +
      +
      2. +
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
      3. +
    3. The firewall script, common functions file and version file + are now installed in /usr/share/shorewall.
      +
      +
      4. +
    4. Late arriving DNS replies are now silently dropped in the + common chain by default.
      +
      +
      5. +
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall + 1.4 no longer unconditionally accepts outbound ICMP packets. So if +you want to 'ping' from the firewall, you will need the appropriate rule +or policy.
      +
      +
      6. +
    6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
      7. +
    7. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
      +
      +
      8. +
    8. Explicit Congestion Notification (ECN - RFC 3168) + may now be turned off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility:
      +
      + a) You must be running kernel 2.4.20
      + b) You must have applied the patch in
      + http://www.shorewall/net/pub/shorewall/ecn/patch.
      + c) You must have iptables 1.2.7a installed.
      +
      +
      9. +
    9. The /etc/shorewall/params file is now processed first so that + variables may be used in the /etc/shorewall/shorewall.conf file.
      +
      +
      10. +
    10. Shorewall now gives a more helpful diagnostic when + the 'ipchains' compatibility kernel module is loaded and a 'shorewall start' + command is issued.
      +
      +
      11. +
    11. The SHARED_DIR variable has been removed from shorewall.conf. + This variable was for use by package maintainers and was not documented +for general use.
      +
      +
      12. +
    12. Shorewall now ignores 'default' routes when detecting masq'd + networks.
      +
      13. + +
    + +

    3/11/2003 - Shoreall 1.3.14a (New) +

    + +

    A roleup of the following bug fixes and other updates:

    + +
      +
    • There is an updated rfc1918 file that reflects the resent + allocation of 222.0.0.0/8 and 223.0.0.0/8.
      • +
    • The documentation for the routestopped file claimed that a +comma-separated list could appear in the second column while the code +only supported a single host or network address.
      • +
    • Log messages produced by 'logunclean' and 'dropunclean' were + not rate-limited. 802.11b devices with names of the form wlan<n> + don't support the 'maclist' interface option.
      • +
    • Log messages generated by RFC 1918 filtering are not rate +limited.
      • +
    • The firewall fails to start in the case +where you have "eth0 eth1" in /etc/shorewall/masq and the default route +is through eth1.
      • + +
    + + +

    2/8/2003 - Shorewall 1.3.14

    + + +

    New features include

    + + +
      +
    1. An OLD_PING_HANDLING option has been added +to shorewall.conf. When set to Yes, Shorewall ping handling is +as it has always been (see http://www.shorewall.net/ping.html).
      +
      + When OLD_PING_HANDLING=No, icmp echo (ping) is handled + via rules and policies just like any other connection request. +The FORWARDPING=Yes option in shorewall.conf and the 'noping' and +'filterping' options in /etc/shorewall/interfaces will all generate +an error.
      +
      +
      2. +
    2. It is now possible to direct Shorewall to create + a "label" such as "eth0:0" for IP addresses that it creates under + ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying + the label instead of just the interface name:
      +
      + a) In the INTERFACE column of /etc/shorewall/masq
      + b) In the INTERFACE column of /etc/shorewall/nat
      +
      3. +
    3. Support for OpenVPN Tunnels.
      +
      +
      4. +
    4. Support for VLAN devices with names of the +form $DEV.$VID (e.g., eth0.0)
      +
      +
      5. +
    5. In /etc/shorewall/tcrules, the MARK value may +be optionally followed by ":" and either 'F' or 'P' to designate that +the marking will occur in the FORWARD or PREROUTING chains respectively. +If this additional specification is omitted, the chain used to mark packets + will be determined by the setting of the MARK_IN_FORWARD_CHAIN option + in shorewall.conf.
      +
      +
      6. +
    6. When an interface name is entered in the SUBNET + column of the /etc/shorewall/masq file, Shorewall previously masqueraded + traffic from only the first subnet defined on that interface. It + did not masquerade traffic from:
      +
      + a) The subnets associated with other addresses +on the interface.
      + b) Subnets accessed through local routers.
      +
      + Beginning with Shorewall 1.3.14, if you enter an interface + name in the SUBNET column, shorewall will use the firewall's routing + table to construct the masquerading/SNAT rules.
      +
      + Example 1 -- This is how it works in 1.3.14.
      +
      + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      + + 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      +
      + When upgrading to Shorewall 1.3.14, if you have multiple + local subnets connected to an interface that is specified in the + SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq + file will need changing. In most cases, you will simply be able to remove + redundant entries. In some cases though, you might want to change from + using the interface name to listing specific subnetworks if the change + described above will cause masquerading to occur on subnetworks that you + don't wish to masquerade.
      +
      + Example 2 -- Suppose that your current config is as + follows:
      +
      - + + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + + + + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      +
      + In this case, the second entry in /etc/shorewall/masq + is no longer required.
      +
      + Example 3 -- What if your current configuration is +like this?
      +
      + + + + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      + + + + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      +
      + In this case, you would want to change the entry + in /etc/shorewall/masq to:
      + + + + + 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      +
      7. + + +
    +
    + + +

    2/5/2003 - Shorewall Support included in Webmin 1.060 +

    + Webmin version 1.060 now has Shorewall support included + as standard. See http://www.webmin.com. + + +

    More News

    +

    Donations

    -     		M
    + +
    + +
    + + + + + + + + + + + + - - - -
    + + + + + + + + + + +

    + +

    + + + + + + + + + + + + +

    Shorewall is free +but if you try it and find it useful, please consider making a donation + to Starlight +Children's Foundation. Thanks!

    + +
    - -
    - -
    - - - - - - - - - - - - - - - - - - - - - + + +
    - - - - - - - - - -

    - -  

    - - - - - - - - - - - -

    Shorewall is free but -if you try it and find it useful, please consider making a donation - to Starlight Children's -Foundation. Thanks!

    - -
    - -

    Updated 3/7/2003 - Tom Eastep - -
    -

    -
    -
    -
    + +

    Updated 3/17/2003 - Tom Eastep + +
    +

    diff --git a/STABLE/documentation/shorewall_extension_scripts.htm b/STABLE/documentation/shorewall_extension_scripts.htm index 650be5874..73910506c 100644 --- a/STABLE/documentation/shorewall_extension_scripts.htm +++ b/STABLE/documentation/shorewall_extension_scripts.htm @@ -1,133 +1,126 @@ - + - + - + - + Shorewall Extension Scripts - + - - + + - + - + - - + +
    - + +

    Extension Scripts

    -
    - -

    Extension scripts are user-provided scripts that are invoked at various -points during firewall start, restart, stop and clear. The scripts are -placed in /etc/shorewall and are processed using the Bourne shell "source" + +

    Extension scripts are user-provided scripts that are invoked at various +points during firewall start, restart, stop and clear. The scripts are +placed in /etc/shorewall and are processed using the Bourne shell "source" mechanism. The following scripts can be supplied:

    - +
      -
    • init -- invoked early in "shorewall start" and "shorewall restart"
      • -
    • start -- invoked after the firewall has been started or restarted.
      • -
    • stop -- invoked as a first step when the firewall is being stopped.
      • -
    • stopped -- invoked after the firewall has been stopped.
      • -
    • clear -- invoked after the firewall has been cleared.
      • -
    • refresh -- invoked while the firewall is being refreshed but before +
    • init -- invoked early in "shorewall start" and "shorewall +restart"
      • +
    • start -- invoked after the firewall has been started or restarted.
      • +
    • stop -- invoked as a first step when the firewall is being stopped.
      • +
    • stopped -- invoked after the firewall has been stopped.
      • +
    • clear -- invoked after the firewall has been cleared.
      • +
    • refresh -- invoked while the firewall is being refreshed but before the common and/or blacklst chains have been rebuilt.
      • -
    • newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' +
    • newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn' chain has been created but before any rules have been added to it.
      • - +
    - -

    If your version of Shorewall doesn't have the file that you want + +

    If your version of Shorewall doesn't have the file that you want to use from the above list, you can simply create the file yourself.

    -

    You can also supply a script with the same name as any of the filter - chains in the firewall and the script will be invoked after the /etc/shorewall/rules - file has been processed but before the /etc/shorewall/policy file has been - processed.

    + +

    You can also supply a script with the same name as any of the filter + chains in the firewall and the script will be invoked after the /etc/shorewall/rules + file has been processed but before the /etc/shorewall/policy file has +been processed.

    - -

    The /etc/shorewall/common file receives special treatment. If this file -is present, the rules that it defines will totally replace the default -rules in the common chain. These default rules are contained in the -file /etc/shorewall/common.def which may be used as a starting point + +

    The /etc/shorewall/common file receives special treatment. If this file +is present, the rules that it defines will totally replace the default +rules in the common chain. These default rules are contained in the +file /etc/shorewall/common.def which may be used as a starting point for making your own customized file.

    - -

    Rather than running iptables directly, you should run it using the - function run_iptables. Similarly, rather than running "ip" directly, - you should use run_ip. These functions accept the same arguments as the - underlying command but cause the firewall to be stopped if an error occurs + +

    Rather than running iptables directly, you should run it using the + function run_iptables. Similarly, rather than running "ip" directly, +you should use run_ip. These functions accept the same arguments as the + underlying command but cause the firewall to be stopped if an error occurs during processing of the command.

    - -

    If you decide to create /etc/shorewall/common it is a good idea to -use the following technique

    + +

    If you decide to create /etc/shorewall/common it is a good idea to use +the following technique

    - +

    /etc/shorewall/common:

    - -
    - + +
    + 
    . /etc/shorewall/common.def
    <add your rules here>
    -
    - -

    If you need to supercede a rule in the released common.def file, you can -add the superceding rule before the '.' command. Using this technique allows - you to add new rules while still getting the benefit of the latest common.def +

    + +

    If you need to supercede a rule in the released common.def file, you can +add the superceding rule before the '.' command. Using this technique allows + you to add new rules while still getting the benefit of the latest common.def file.

    - -

    Remember that /etc/shorewall/common defines rules that are only applied -if the applicable policy is DROP or REJECT. These rules are NOT applied + +

    Remember that /etc/shorewall/common defines rules that are only applied +if the applicable policy is DROP or REJECT. These rules are NOT applied if the policy is ACCEPT or CONTINUE.

    - -

    If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will -be rejected by the firewall. It is recommended with this setting that you -create the file /etc/shorewall/icmpdef and in it place the following commands:

    - - - - -
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - - -

    Last updated 12/22/2002 - Last updated 2/18/2003 - Tom Eastep

    - -

    Copyright 2002 Thomas -M. Eastep

    -
    + +

    Copyright 2002, 2003 +Thomas M. Eastep

    +
    +
    diff --git a/STABLE/documentation/shorewall_prerequisites.htm b/STABLE/documentation/shorewall_prerequisites.htm index cf7e0e9b7..b66ccc400 100644 --- a/STABLE/documentation/shorewall_prerequisites.htm +++ b/STABLE/documentation/shorewall_prerequisites.htm @@ -1,68 +1,68 @@ - + - + - + - + Shorewall Prerequisites - + - - - + + - - - + + + +
    +

    Shorewall Requirements

    -
    -
    -Shorewall Requires:
    - +
    + Shorewall Requires:
    +
      -
    • A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6. - Check here for kernel configuration -information. If you are looking for a firewall for use with 2.2 -kernels, see the Seattle Firewall - site .
      • -
    • iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The - buggy iptables version 1.2.3 is included in RedHat 7.2 and you should -upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4 +
    • A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6. + Check here for kernel configuration information. + If you are looking for a firewall for use with 2.2 kernels, see the Seattle Firewall site + .
      • +
    • iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The + buggy iptables version 1.2.3 is included in RedHat 7.2 and you should +upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4 is available from RedHat + href="http://www.redhat.com/support/errata/RHSA-2001-144.html">from RedHat and in the Shorewall Errata.
      • -
    • Some features require iproute ("ip" utility). The iproute package - is included with most distributions but may not be installed by default. - The official download site is ftp://ftp.inr.ac.ru/ip-routing. -
      • -
    • A Bourne shell or derivative such as bash or ash. This shell must -have correct support for variable expansion formats ${variable%pattern - }, ${variable%%pattern}, ${variable#pattern - } and ${variable##pattern}.
      • -
    • The firewall monitoring display is greatly improved if you have +
    • Iproute ("ip" utility). The iproute package is included with +most distributions but may not be installed by default. The official +download site is ftp://ftp.inr.ac.ru/ip-routing. +
      • +
    • A Bourne shell or derivative such as bash or ash. This shell must + have correct support for variable expansion formats ${variable%pattern + }, ${variable%%pattern}, ${variable#pattern + } and ${variable##pattern}.
      • +
    • The firewall monitoring display is greatly improved if you have awk (gawk) installed.
      • - +
    - -

    Last updated 11/10/2002 - Last updated 2/21/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    + size="2">Copyright     © 2001, 2002, 2003 Thomas M. Eastep.

    +
    +


    diff --git a/STABLE/documentation/shorewall_quickstart_guide.htm b/STABLE/documentation/shorewall_quickstart_guide.htm index e2b34db40..06c5478f9 100644 --- a/STABLE/documentation/shorewall_quickstart_guide.htm +++ b/STABLE/documentation/shorewall_quickstart_guide.htm @@ -2,306 +2,320 @@ + + + + Shorewall QuickStart Guide - + + - + - - - + + - + (HOWTO's)
    + Version 4.0 + + - + +
    +
    - +

    Shorewall QuickStart Guides - (HOWTO's)
    - Version 3.1

    -
    - +

    With thanks to Richard who reminded me once again that we must all first walk before we can run.
    - The French Translations are courtesy of Patrice Vetsel
    -

    - + The French Translations are courtesy of Patrice Vetsel
    +

    +

    The Guides

    - +

    These guides provide step-by-step instructions for configuring Shorewall - in common firewall setups.

    - + in common firewall setups.

    +

    The following guides are for users who have a single public IP address:

    - + - +

    The above guides are designed to get your first firewall up and running - quickly in the three most common Shorewall configurations.

    - + quickly in the three most common Shorewall configurations.

    +

    The Shorewall Setup Guide outlines - the steps necessary to set up a firewall where there are multiple - public IP addresses involved or if you want to learn more about -Shorewall than is explained in the single-address guides above.

    - + the steps necessary to set up a firewall where there are multiple + public IP addresses involved or if you want to learn more about + Shorewall than is explained in the single-address guides above.

    +
      -
    • 1.0 Introduction
      • -
    • 2.0 -Shorewall Concepts
      • -
    • 3.0 - Network Interfaces
      • -
    • 4.0 - Addressing, Subnets and Routing - - - - - -
      • -
    • 5.0 -Setting up your Network - - - - -
        -
      • 5.2 - Non-routed - - - - +

        Documentation Index

        - +

        The following documentation covers a variety of topics and supplements - the QuickStart Guides - described above. Please review the appropriate guide before trying - to use this documentation directly.

        - + the QuickStart Guides + described above        . Please review the appropriate guide before +trying to use this documentation directly.

        +
          -
        • Aliased -(virtual) Interfaces (e.g., eth0:0)
          -
          • -
        • Blacklisting +
        • Aliased (virtual) Interfaces +(e.g., eth0:0)
          +
          • +
        • Blacklisting + + +
            +
          • Static Blacklisting using /etc/shorewall/blacklist
            • +
          • Dynamic Blacklisting using /sbin/shorewall
            • + + +
          +
          • +
        • Common + configuration file features
            -
          • Static Blacklisting using /etc/shorewall/blacklist
            • -
          • Dynamic Blacklisting using /sbin/shorewall
            • - - -
          -
          • -
        • Common configuration - file features - - -
          • -
        • Configuration File Reference - Manual - +
          • +
        • Configuration File + Reference Manual + -
          • -
        • DHCP
          • -
        • +
        • DHCP
          • +
        • Extension Scripts (How -to extend Shorewall without modifying Shorewall code)
          • -
        • Fallback/Uninstall
          • -
        • Firewall - Structure
          • -
        • Kernel - Configuration
          • -
        • Logging
          -
          • -
        • MAC Verification
          -
          • -
        • My Configuration Files (How I personally - use Shorewall)
          • -
        • 'Ping' Management
          -
          • -
        • Port Information - -
            -
          • Which applications use which ports
            • -
          • Ports used by Trojans
            • - - -
          -
          • -
        • Proxy ARP
          • -
        • Samba
          • -
        • Starting/stopping the Firewall
          • - -
            -
          • Description of all /sbin/shorewall commands
            • -
          • How to safely test a Shorewall configuration change
            -
            • - -
          -
        • Static NAT
          • -
        • Squid as a Transparent Proxy - with Shorewall
          +to extend Shorewall without modifying Shorewall code through the use of +files in /etc/shorewall -- /etc/shorewall/start, /etc/shorewall/stopped, +etc.)
          • +
        • Fallback/Uninstall
          • +
        • Firewall + Structure
          • +
        • Kernel + Configuration
          • +
        • Logging
          +
          • +
        • MAC Verification
          +
          • +
        • My Shorewall Configuration + (How I personally use Shorewall)
          • -
        • Traffic Shaping/QOS
          • -
        • VPN - - - +

          If you use one of these guides and have a suggestion for improvement please let me know.

          - -

          Last modified 3/5/2003 - Tom Eastep

          - + +

          Last modified 3/12/2003 - Tom Eastep

          +

          Copyright 2002, 2003 Thomas M. - Eastep
          -

          -
          -
          -
          -
          + Eastep
          +


          diff --git a/STABLE/documentation/shorewall_setup_guide.htm b/STABLE/documentation/shorewall_setup_guide.htm index 3e99fc871..bb9699d0d 100644 --- a/STABLE/documentation/shorewall_setup_guide.htm +++ b/STABLE/documentation/shorewall_setup_guide.htm @@ -1,427 +1,207 @@ - + - + - + - + Shorewall Setup Guide - + - +

          Shorewall Setup Guide

          - +

          1.0 Introduction
          - 2.0 Shorewall Concepts
          - 3.0 Network Interfaces
          - 4.0 Addressing, Subnets and Routing

          - -
          + 2.0 Shorewall Concepts
          + 3.0 Network Interfaces
          + 4.0 Addressing, Subnets and Routing

          + +

          4.1 IP Addresses
          - 4.2 Subnets
          - 4.3 Routing
          - 4.4 Address Resolution Protocol
          - 4.5 RFC 1918

          -
          - -

          5.0 Setting up your Network

          - -
          -

          5.1 Routed
          - 5.2 Non-routed

          - -
          -

          5.2.1 SNAT
          - 5.2.2 DNAT
          - 5.2.3 Proxy ARP
          - 5.2.4 Static NAT

          + 4.2 Subnets
          + 4.3 Routing
          + 4.4 Address Resolution Protocol
          + 4.5 RFC 1918

          - + +

          5.0 Setting up your Network

          + +
          +

          5.1 Routed
          + 5.2 Non-routed

          + +
          +

          5.2.1 SNAT
          + 5.2.2 DNAT
          + 5.2.3 Proxy ARP
          + 5.2.4 Static NAT

          +
          +

          5.3 Rules
          - 5.4 Odds and Ends

          -
          - + 5.4 Odds and Ends

          +
          +

          6.0 DNS
          - 7.0 Starting and Stopping the Firewall

          - + 7.0 Starting and Stopping the Firewall

          +

          1.0 Introduction

          - +

          This guide is intended for users who are setting up Shorewall in an environment - where a set of public IP addresses must be managed or who want to know -more about Shorewall than is contained in the single-address guides. Because - the range of possible applications is so broad, the Guide will give you - general guidelines and will point you to other resources as necessary.

          - + the range of possible applications is so broad, the Guide will give you + general guidelines and will point you to other resources as necessary.

          +

          -     If you run LEAF Bering, your Shorewall configuration is NOT what - I release -- I suggest that you consider installing a stock Shorewall +     If you run LEAF Bering, your Shorewall configuration is NOT what + I release -- I suggest that you consider installing a stock Shorewall lrp from the shorewall.net site before you proceed.

          - -

          This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell -if this package is installed by the presence of an ip program on -your firewall system. As root, you can use the 'which' command to check -for this program:

          - + +

          Shorewall requires that the iproute/iproute2 package be installed (on + RedHat, the package is called iproute). You can tell if +this package is installed by the presence of an ip program on your + firewall system. As root, you can use the 'which' command to check for +this program:

          + 
               [root@gateway root]# which ip
               /sbin/ip
               [root@gateway root]#
          - +

          I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are flagged - with - .

          - + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged + with + .

          +

          -     If you edit your configuration files on a Windows system, you must - save them as Unix files if your editor supports that option or you must - run them through dos2unix before trying to use them with Shorewall. Similarly, - if you copy a configuration file from your Windows hard drive to a floppy - disk, you must run dos2unix against the copy before using it with Shorewall.

          - +     If you edit your configuration files on a Windows system, you +must save them as Unix files if your editor supports that option or you +must run them through dos2unix before trying to use them with Shorewall. +Similarly, if you copy a configuration file from your Windows hard drive +to a floppy disk, you must run dos2unix against the copy before using it +with Shorewall.

          + - +

          2.0 Shorewall Concepts

          - +

          The configuration files for Shorewall are contained in the directory /etc/shorewall -- for most setups, you will only need to deal with a few of these as described in this guide. Skeleton files are created during the Shorewall Installation Process.

          - +

          As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and some contain default entries.

          - + file on your system -- each file contains detailed configuration instructions + and some contain default entries.

          +

          Shorewall views the network where it is running as being composed of a - set of zones. In the default installation, the following zone names - are used:

          - + set of zones. In the default installation, the following zone names + are used:

          + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
          NameDescription
          netThe Internet
          locYour Local Network
          dmzDemilitarized Zone
          NameDescription
          netThe Internet
          locYour Local Network
          dmzDemilitarized Zone
          - +

          Zones are defined in the /etc/shorewall/zones - file.

          - + file.

          +

          Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw but that may be changed in the + the firewall itself is known as fw but that may be changed in the /etc/shorewall/shorewall.conf -file. In this guide, the default name (fw) will be used.

          - + file. In this guide, the default name (fw) will be used.

          +

          With the exception of fw, Shorewall attaches absolutely no meaning - to zone names. Zones are entirely what YOU make of them. That means that - you should not expect Shorewall to do something special "because this is - the internet zone" or "because that is the DMZ".

          - + to zone names. Zones are entirely what YOU make of them. That means that + you should not expect Shorewall to do something special "because this +is the internet zone" or "because that is the DMZ".

          +

          -     Edit the /etc/shorewall/zones file and make any changes necessary.

          - +     Edit the /etc/shorewall/zones file and make any changes necessary.

          +

          Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

          - + in terms of zones.

          + - +

          Shorewall is built on top of the Netfilter - kernel facility. Netfilter implements a connection - tracking function that allows what is often referred to as stateful - inspection of packets. This stateful property allows firewall rules - to be defined in terms of connections rather than in terms of -packets. With Shorewall, you:

          - + tracking function that allows what is often referred to as stateful + inspection of packets. This stateful property allows firewall rules + to be defined in terms of connections rather than in terms of + packets. With Shorewall, you:

          +
            -
          1. Identify the source zone.
            2. -
          2. Identify the destination zone.
            3. -
          3. If the POLICY from the client's zone to the server's -zone is what you want for this client/server pair, you need do nothing -further.
            4. -
          4. If the POLICY is not what you want, then you must add -a rule. That rule is expressed in terms of the client's zone and the - server's zone.
            5. - +
          5. Identify the source zone.
            6. +
          6. Identify the destination zone.
            7. +
          7. If the POLICY from the client's zone to the server's + zone is what you want for this client/server pair, you need do nothing + further.
            8. +
          8. If the POLICY is not what you want, then you must add + a rule. That rule is expressed in terms of the client's zone and +the server's zone.
            9. +
          - +

          Just because connections of a particular type are allowed from zone A to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed - from zone A to zone B. It rather means that you can have - a proxy running on the firewall that accepts a connection from zone A -and then establishes its own separate connection from the firewall to zone -B.

          - + from zone A to zone B          . It rather means that you can have + a proxy running on the firewall that accepts a connection from zone +A and then establishes its own separate connection from the firewall to +zone B.

          +

          For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file -matches the connection request then the first policy in /etc/shorewall/policy -that matches the request is applied. If that policy is REJECT or DROP  the - request is first checked against the rules in /etc/shorewall/common.def.

          - + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  +the request is first checked against the rules in /etc/shorewall/common.def.

          +

          The default /etc/shorewall/policy file has the following policies:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          -
          - -

          The above policy will:

          - -
            -
          1. allow all connection requests from your local network to the -internet
            2. -
          2. drop (ignore) all connection requests from the internet to your - firewall or local network and log a message at the info level -(here is a description of log levels).
            3. -
          3. reject all other connection requests and log a message at the - info level. When a request is rejected, the firewall will -return an RST (if the protocol is TCP) or an ICMP port-unreachable packet -for other protocols.
            4. - -
          - -

          -     At this point, edit your /etc/shorewall/policy and make any changes - that you wish.

          - -

          3.0 Network Interfaces

          - -

          For the remainder of this guide, we'll refer to the following - diagram. While it may not look like your own network, it can be used to - illustrate the important aspects of Shorewall configuration.

          - -

          In this diagram:

          - -
            -
          • The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used - to isolate your internet-accessible servers from your local systems so -that if one of those servers is compromised, you still have the firewall -between the compromised system and your local systems.
            • -
          • The Local Zone consists of systems Local 1, Local 2 and Local -3.
            • -
          • All systems from the ISP outward comprise the Internet Zone. -
            • - -
          - -

          -

          - -

          The simplest way to define zones is to simply associate the - zone name (previously defined in /etc/shorewall/zones) with a network interface. - This is done in the /etc/shorewall/interfaces - file.

          - -

          The firewall illustrated above has three network interfaces. - Where Internet connectivity is through a cable or DSL "Modem", the External - Interface will be the Ethernet adapter that is connected to that "Modem" - (e.g., eth0)  unless you connect via Point-to-Point - Protocol over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External Interface - will be a ppp interface (e.g., ppp0). If you connect via a regular - modem, your External Interface will also be ppp0. If you connect - using ISDN, you external interface will be ippp0.

          - -

          -     If your external interface is ppp0 or ippp0 then -you will want to set CLAMPMSS=yes in -/etc/shorewall/shorewall.conf.

          - -

          Your Local Interface will be an Ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local computers - will be connected to the same switch (note: If you have only a single local - system, you can connect the firewall directly to the computer using a -cross-over cable).

          - -

          Your DMZ Interface will also be an Ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ - computers will be connected to the same switch (note: If you have only a - single DMZ system, you can connect the firewall directly to the computer - using a cross-over cable).

          - -

          - Do not connect more than one interface to the same hub or switch - (even for testing). It won't work the way that you expect it to and you - will end up confused and believing that Linux networking doesn't work at -all.

          - -

          For the remainder of this Guide, we will assume that:

          - -
            -
          • -

            The external interface is eth0.

            -
            • -
          • -

            The Local interface is eth1.

            -
            • -
          • -

            The DMZ interface is eth2.

            -
            • - -
          - -

          The Shorewall default configuration does not define the contents - of any zone. To define the above configuration using the /etc/shorewall/interfaces - file, that file would might contain:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          ZoneInterfaceBroadcastOptions
          neteth0detectnorfc1918
          loceth1detect 
          dmzeth2detect 
          -
          - -

          -     Edit the /etc/shorewall/interfaces file and define the network -interfaces on your firewall and associate each interface with a zone. -If you have a zone that is interfaced through more than one interface, -simply include one entry for each interface and repeat the zone name as -many times as necessary.

          - -

          Example:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          ZoneInterfaceBroadcastOptions
          neteth0detectnorfc1918
          loceth1detect 
          loceth2detectdhcp
          -
          - -
          -

          When you have more than one interface to a zone, you will - usually want a policy that permits intra-zone traffic:

          -
          - -
          -
          + +
          - + @@ -430,80 +210,302 @@ many times as necessary.

          - + - - + + + + + + + + + + + + + + + +
          Source Zone Destination Zone Policy
          loclocnet ACCEPT    
          netallDROPinfo 
          allallREJECTinfo 
          -
          - + +

          The above policy will:

          + +
            +
          1. allow all connection requests from your local network to the + internet
            2. +
          2. drop (ignore) all connection requests from the internet to +your firewall or local network and log a message at the info +level (here is a description of log +levels).
            3. +
          3. reject all other connection requests and log a message at the + info level. When a request is rejected, the firewall will + return an RST (if the protocol is TCP) or an ICMP port-unreachable packet + for other protocols.
            4. + +
          + +

          +     At this point, edit your /etc/shorewall/policy and make any changes + that you wish.

          + +

          3.0 Network Interfaces

          + +

          For the remainder of this guide, we'll refer to the following + diagram. While it may not look like your own network, it can be used to + illustrate the important aspects of Shorewall configuration.

          + +

          In this diagram:

          + +
            +
          • The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is +used to isolate your internet-accessible servers from your local systems +so that if one of those servers is compromised, you still have the firewall + between the compromised system and your local systems.
            • +
          • The Local Zone consists of systems Local 1, Local 2 and Local + 3.
            • +
          • All systems from the ISP outward comprise the Internet Zone. +
            • + +
          + +

          +

          + +

          The simplest way to define zones is to simply associate the + zone name (previously defined in /etc/shorewall/zones) with a network +interface. This is done in the /etc/shorewall/interfaces + file.

          + +

          The firewall illustrated above has three network interfaces. + Where Internet connectivity is through a cable or DSL "Modem", the External + Interface will be the Ethernet adapter that is connected to that "Modem" + (e.g., eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External +Interface will be a ppp interface (e.g., ppp0). If you connect via +a regular modem, your External Interface will also be ppp0. If +you connect using ISDN, you external interface will be ippp0.

          + +

          +     If your external interface is ppp0 or ippp0 then + you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

          + +

          Your Local Interface will be an Ethernet adapter (eth0, + eth1 or eth2) and will be connected to a hub or switch. Your local computers + will be connected to the same switch (note: If you have only a single +local system, you can connect the firewall directly to the computer using +a cross-over cable).

          + +

          Your DMZ Interface will also be an Ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ + computers will be connected to the same switch (note: If you have only +a single DMZ system, you can connect the firewall directly to the computer + using a cross-over cable).

          + +

          + Do not connect more than one interface to the same hub or +switch (even for testing). It won't work the way that you expect it to +and you will end up confused and believing that Linux networking doesn't +work at all.

          + +

          For the remainder of this Guide, we will assume that:

          + +
            +
          • +

            The external interface is eth0.

            +
            • +
          • +

            The Local interface is eth1.

            +
            • +
          • +

            The DMZ interface is eth2.

            +
            • + +
          + +

          The Shorewall default configuration does not define the contents + of any zone. To define the above configuration using the /etc/shorewall/interfaces + file, that file would might contain:

          + +
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ZoneInterfaceBroadcastOptions
          neteth0detectnorfc1918
          loceth1detect 
          dmzeth2detect 
          +
          +

          -     You may define more complicated zones using the + +

          Example:

          + +
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ZoneInterfaceBroadcastOptions
          neteth0detectnorfc1918
          loceth1detect 
          loceth2detectdhcp
          +
          + +
          +

          When you have more than one interface to a zone, you will + usually want a policy that permits intra-zone traffic:

          +
          + +
          +
          + + + + + + + + + + + + + + + + + + +
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          loclocACCEPT  
          +
          +
          + +

          +     You may define more complicated zones using the /etc/shorewall/hosts file but in most - cases, that isn't necessary.

          - + cases, that isn't necessary.

          +

          4.0 Addressing, Subnets and Routing

          - +

          Normally, your ISP will assign you a set of Public - IP addresses. You will configure your firewall's external interface to use - one of those addresses permanently and you will then have to decide how - you are going to use the rest of your addresses. Before we tackle that question - though, some background is in order.

          - + IP addresses. You will configure your firewall's external interface to +use one of those addresses permanently and you will then have to decide +how you are going to use the rest of your addresses. Before we tackle that +question though, some background is in order.

          +

          If you are thoroughly familiar with IP addressing and routing, - you may go to the next section.

          - + you may go to the next section.

          +

          The following discussion barely scratches the surface of addressing and routing. If you are interested in learning more about this subject, I highly recommend "IP Fundamentals: What Everyone Needs to Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

          - +

          4.1 IP Addresses

          - +

          IP version 4 (IPv4) addresses are 32-bit numbers. - The notation w.x.y.z refers to an address where the high-order byte has -value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 - and express it in hexadecimal, we get:

          - -
          + The notation w.x.y.z refers to an address where the high-order byte has + value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 + and express it in hexadecimal, we get:

          + +

          C0.00.02.0E

          -
          - +
          +

          or looking at it as a 32-bit integer

          - -
          + +

          C000020E

          -
          - +
          +

          4.2 Subnets

          - +

          You will still hear the terms "Class A network", "Class B - network" and "Class C network". In the early days of IP, networks only - came in three sizes (there were also Class D networks but they were used - differently):

          - -
          + network" and "Class C network". In the early days of IP, networks only + came in three sizes (there were also Class D networks but they were used + differently):

          + +

          Class A - netmask 255.0.0.0, size = 2 ** 24

          - +

          Class B - netmask 255.255.0.0, size = 2 ** 16

          - +

          Class C - netmask 255.255.255.0, size = 256

          -
          - +
          +

          The class of a network was uniquely determined by the value - of the high order byte of its address so you could look at an IP address - and immediately determine the associated netmask. The netmask is - a number that when logically ANDed with an address isolates the network - number; the remainder of the address is the host number. For - example, in the Class C address 192.0.2.14, the network number is hex C00002 - and the host number is hex 0E.

          - + of the high order byte of its address so you could look at an IP address + and immediately determine the associated netmask. The netmask is + a number that when logically ANDed with an address isolates the network + number; the remainder of the address is the host number. For + example, in the Class C address 192.0.2.14, the network number is hex C00002 + and the host number is hex 0E.

          +

          As the internet grew, it became clear that such a gross partitioning of the 32-bit address space was going to be very limiting (early on, large corporations and universities were assigned their own class A @@ -511,1997 +513,2007 @@ partitioning of the 32-bit address space was going to be very limiting (early these networks into smaller subnetworks evolved; that technique is referred to as Classless InterDomain Routing (CIDR). Today, any system that you are likely to work with will understand CIDR and Class-based networking - is largely a thing of the past.

          - + is largely a thing of the past.

          +

          A subnetwork (often referred to as a subnet) is - a contiguous set of IP addresses such that:

          - + a contiguous set of IP addresses such that:

          +
            -
          1. +

          2. The number of addresses in the set is a power of 2; and

            -
            3. -
          3. +
            4. +

          4. The first address in the set is a multiple of the set - size.

            -
            5. -
          5. + size.

            +
            6. +

          6. The first address in the subnet is reserved and is referred - to as the subnet address.

            -
            7. -
          7. + to as the subnet address.

            +
            8. +

          8. The last address in the subnet is reserved as the subnet's - broadcast address.

            -
            9. - + broadcast address.

            + +
          - +

          As you can see by this definition, in each subnet of size - n there are (n - 2) usable addresses (addresses that can - be assigned to hosts). The first and last address in the subnet are used - for the subnet address and subnet broadcast address respectively. Consequently, - small subnetworks are more wasteful of IP addresses than are large ones. -

          - + n there are (n - 2) usable addresses (addresses that can + be assigned to hosts). The first and last address in the subnet are +used for the subnet address and subnet broadcast address respectively. +Consequently, small subnetworks are more wasteful of IP addresses than +are large ones.

          +

          Since n is a power of two, we can easily calculate - the Natural Logarithm (log2) of n. For the more common - subnet sizes, the size and its natural logarithm are given in the following - table:

          - -
          + the Natural Logarithm (log2) of n. For the more +common subnet sizes, the size and its natural logarithm are given in the + following table:

          + +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          nlog2 n(32 - log2 n)
          8329
          16428
          32527
          64626
          128725
          256824
          512923
          10241022
          20481121
          40961220
          81921319
          163841418
          327681517
          655361616
          nlog2 n(32 - log2 n)
          8329
          16428
          32527
          64626
          128725
          256824
          512923
          10241022
          20481121
          40961220
          81921319
          163841418
          327681517
          655361616
          -
          - +
          +

          You will notice that the above table also contains a column - for (32 - log2 n). That number is the Variable Length Subnet - Mask for a network of size n. From the above table, we can - derive the following one which is a little easier to use.

          - -
          + for (32 - log2 n). That number is the Variable Length Subnet + Mask for a network of size n. From the above table, we can + derive the following one which is a little easier to use.

          + +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          Size of SubnetVLSMSubnet Mask
          8/29255.255.255.248
          16/28255.255.255.240
          32/27255.255.255.224
          64/26255.255.255.192
          128/25255.255.255.128
          256/24255.255.255.0
          512/23255.255.254.0
          1024/22255.255.252.0
          2048/21255.255.248.0
          4096/20255.255.240.0
          8192/19255.255.224.0
          16384/18255.255.192.0
          32768/17255.255.128.0
          65536/16255.255.0.0
          2 ** 24/8255.0.0.0
          Size of SubnetVLSMSubnet Mask
          8/29255.255.255.248
          16/28255.255.255.240
          32/27255.255.255.224
          64/26255.255.255.192
          128/25255.255.255.128
          256/24255.255.255.0
          512/23255.255.254.0
          1024/22255.255.252.0
          2048/21255.255.248.0
          4096/20255.255.240.0
          8192/19255.255.224.0
          16384/18255.255.192.0
          32768/17255.255.128.0
          65536/16255.255.0.0
          2 ** 24/8255.0.0.0
          -
          - +
          +

          Notice that the VLSM is written with a slash ("/") -- you - will often hear a subnet of size 64 referred to as a "slash 26" subnet - and one of size 8 referred to as a "slash 29".

          - + will often hear a subnet of size 64 referred to as a "slash 26" subnet + and one of size 8 referred to as a "slash 29".

          +

          The subnet's mask (also referred to as its netmask) is - simply a 32-bit number with the first "VLSM" bits set to one and the -remaining bits set to zero. For example, for a subnet of size 64, the -subnet mask has 26 leading one bits:

          - -
          + simply a 32-bit number with the first "VLSM" bits set to one and the + remaining bits set to zero. For example, for a subnet of size 64, the + subnet mask has 26 leading one bits:

          + +

          11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 - = 255.255.255.192

          -
          - + = 255.255.255.192

          +
          +

          The subnet mask has the property that if you logically AND - the subnet mask with an address in the subnet, the result is the subnet - address. Just as important, if you logically AND the subnet mask with - an address outside the subnet, the result is NOT the subnet address. As - we will see below, this property of subnet masks is very useful in routing.

          - + the subnet mask with an address in the subnet, the result is the subnet + address. Just as important, if you logically AND the subnet mask with + an address outside the subnet, the result is NOT the subnet address. +As we will see below, this property of subnet masks is very useful in +routing.

          +

          For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork as - "a.b.c.d/v" using CIDR Notation. 

          - + Variable Length Subnet Mask is /v, we denote the subnetwork as + "a.b.c.d/v" using CIDR Notation. 

          +

          Example:

          - -
          + +
          - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
          Subnet:10.10.10.0 - 10.10.10.127
          Subnet Size:128
          Subnet Address:10.10.10.0
          Broadcast Address:10.10.10.127
          CIDR Notation:10.10.10.0/25
          Subnet:10.10.10.0 - 10.10.10.127
          Subnet Size:128
          Subnet Address:10.10.10.0
          Broadcast Address:10.10.10.127
          CIDR Notation:10.10.10.0/25
          -
          - +
          +

          There are two degenerate subnets that need mentioning; namely, - the subnet with one member and the subnet with 2 ** 32 members.

          - -
          + the subnet with one member and the subnet with 2 ** 32 members.

          + +
          - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
          Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
          132255.255.255.255a.b.c.d/32
          2 ** 3200.0.0.00.0.0.0/0
          Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
          132255.255.255.255a.b.c.d/32
          2 ** 3200.0.0.00.0.0.0/0
          -
          - -

          So any address a.b.c.d may also be written a.b.c.d/32 - and the set of all possible IP addresses is written 0.0.0.0/0.

          - -

          Later in this guide, you will see the notation a.b.c.d/v - used to describe the ip configuration of a network interface (the 'ip' -utility also uses this syntax). This simply means that the interface is -configured with ip address a.b.c.d and with the netmask that corresponds -to VLSM /v.

          - -

          Example: 192.0.2.65/29

          - -

              The interface is configured with IP address 192.0.2.65 - and netmask 255.255.255.248.

          - -

          4.3 Routing

          - -

          One of the purposes of subnetting is that it forms the basis - for routing. Here's the routing table on my firewall:

          - -
          -
          - 
          [root@gateway root]# netstat -nr
          Kernel IP routing table
          Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
          192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
          206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
          206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
          192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
          192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
          192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
          206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
          192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
          127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
          0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
          [root@gateway root]#
          -
          - + +

          So any address a.b.c.d may also be written a.b.c.d/32 + and the set of all possible IP addresses is written 0.0.0.0/0.

          + +

          Later in this guide, you will see the notation a.b.c.d/v + used to describe the ip configuration of a network interface (the 'ip' + utility also uses this syntax). This simply means that the interface is + configured with ip address a.b.c.d and with the netmask that corresponds + to VLSM /v.

          + +

          Example: 192.0.2.65/29

          + +

              The interface is configured with IP address 192.0.2.65 + and netmask 255.255.255.248.

          + +

          4.3 Routing

          + +

          One of the purposes of subnetting is that it forms the basis + for routing. Here's the routing table on my firewall:

          + +
          +
          + 
          [root@gateway root]# netstat -nr
          Kernel IP routing table
          Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
          192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
          206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
          206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
          192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
          192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
          192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
          206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
          192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
          127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
          0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
          [root@gateway root]#
          +
          +
          +

          The device texas is a GRE tunnel to a peer site in - the Dallas, Texas area.
          -
          - The first three routes are host routes since they indicate how - to get to a single host. In the 'netstat' output this can be seen by the - "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags column. - The remainder are 'net' routes since they tell the kernel how to route -packets to a subnetwork. The last route is the default route and -the gateway mentioned in that route is called the default gateway.

          - + the Dallas, Texas area.
          +
          + The first three routes are host routes since they indicate +how to get to a single host. In the 'netstat' output this can be seen +by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags +column. The remainder are 'net' routes since they tell the kernel how +to route packets to a subnetwork. The last route is the default route +and the gateway mentioned in that route is called the default gateway.

          +

          When the kernel is trying to send a packet to IP address A, it starts at the top of the routing table and:

          - +
            -
          • +

          • A is logically ANDed with the 'Genmask' value in the table entry.

            -
            • -
          • +
            • +

          • The result is compared with the 'Destination' value in - the table entry.

            -
            • -
          • + the table entry.

            +
            • +

          • If the result and the 'Destination' value are the same, - then:

            - + then:

            +
              -
            • +
            • +

              If the 'Gateway' column is non-zero, the packet is - sent to the gateway over the interface named in the 'Iface' column.

              -
              • -
            • + sent to the gateway over the interface named in the 'Iface' column.

              +
              • +
            • +

              Otherwise, the packet is sent directly to A over - the interface named in the 'iface' column.

              -
              • - + the interface named in the 'iface' column.

              + +
            -
            • -
          • +
            • +

          • Otherwise, the above steps are repeated on the next entry - in the table.

            -
            • - + in the table.

            + +
          - +

          Since the default route matches any IP address (A land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table entries are sent to the default gateway which is usually a router at your ISP.

          - +

          Lets take an example. Suppose that we want to route a packet - to 192.168.1.5. That address clearly doesn't match any of the host routes - in the table but if we logically and that address with 255.255.255.0, the - result is 192.168.1.0 which matches this routing table entry:

          - -
          -
          + to 192.168.1.5. That address clearly doesn't match any of the host routes + in the table but if we logically and that address with 255.255.255.0, +the result is 192.168.1.0 which matches this routing table entry:

          + +
          +
          192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
          -
          - +
          +

          So to route a packet to 192.168.1.5, the packet is sent directly over eth2.

          -
          - + +

          One more thing needs to be emphasized -- all outgoing packet - are sent using the routing table and reply packets are not a special case. - There seems to be a common mis-conception whereby people think that request - packets are like salmon and contain a genetic code that is magically transferred - to reply packets so that the replies follow the reverse route taken by -the request. That isn't the case; the replies may take a totally different -route back to the client than was taken by the requests -- they are totally -independent.

          - + are sent using the routing table and reply packets are not a special case. + There seems to be a common mis-conception whereby people think that request + packets are like salmon and contain a genetic code that is magically +transferred to reply packets so that the replies follow the reverse route +taken by the request. That isn't the case; the replies may take a totally +different route back to the client than was taken by the requests -- they +are totally independent.

          +

          4.4 Address Resolution Protocol

          - +

          When sending packets over Ethernet, IP addresses aren't used. - Rather Ethernet addressing is based on Media Access Control (MAC) - addresses. Each Ethernet device has it's own unique  MAC address which -is burned into a PROM on the device during manufacture. You can obtain the -MAC of an Ethernet device using the 'ip' utility:

          - -
          -
          + Rather Ethernet addressing is based on Media Access Control (MAC) + addresses. Each Ethernet device has it's own unique  MAC address which + is burned into a PROM on the device during manufacture. You can obtain +the MAC of an Ethernet device using the 'ip' utility:

          + +
          + 
          [root@gateway root]# ip addr show eth0
          2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
          link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
          inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
          inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
          inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
          [root@gateway root]#
          -
          -
          - -
          +
          +
          + +

          As you can see from the above output, the MAC is 6 bytes (48 bits) wide. A card's MAC is usually also printed on a label attached to the card itself.

          -
          - -
          +
          + +

          Because IP uses IP addresses and Ethernet uses MAC addresses, - a mechanism is required to translate an IP address into a MAC address; - that is the purpose of the Address Resolution Protocol (ARP). -Here is ARP in action:

          -
          - -
          -
          -
          + a mechanism is required to translate an IP address into a MAC address; + that is the purpose of the Address Resolution Protocol (ARP). + Here is ARP in action:

          +
          + +
          +
          + 
          [root@gateway root]# tcpdump -nei eth2 arp
          tcpdump: listening on eth2
          09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
          09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

          2 packets received by filter
          0 packets dropped by kernel
          [root@gateway root]#
          +
          +
          +
          + +

          In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants + to know the MAC of the device with IP address 192.168.1.19. The system + having that IP address is responding that the MAC address of the device + with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

          + +

          In order to avoid having to exchange ARP information each + time that an IP packet is to be sent, systems maintain an ARP cache + of IP<->MAC correspondences. You can see the ARP cache on your system + (including your Windows system) using the 'arp' command:

          + +
          +
          + 
          [root@gateway root]# arp -na
          ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
          ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
          ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
          ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
          ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
          -
          - -

          In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants - to know the MAC of the device with IP address 192.168.1.19. The system -having that IP address is responding that the MAC address of the device -with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

          - -

          In order to avoid having to exchange ARP information each - time that an IP packet is to be sent, systems maintain an ARP cache - of IP<->MAC correspondences. You can see the ARP cache on your system - (including your Windows system) using the 'arp' command:

          - -
          -
          - 
          [root@gateway root]# arp -na
          ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
          ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
          ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
          ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
          ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
          -
          -
          - +

          The leading question marks are a result of my having specified - the 'n' option (Windows 'arp' doesn't allow that option) which causes the - 'arp' program to forego IP->DNS name translation. Had I not given that - option, the question marks would have been replaced with the FQDN corresponding - to each IP address. Notice that the last entry in the table records the - information we saw using tcpdump above.

          - + the 'n' option (Windows 'arp' doesn't allow that option) which causes +the 'arp' program to forego IP->DNS name translation. Had I not given +that option, the question marks would have been replaced with the FQDN +corresponding to each IP address. Notice that the last entry in the table +records the information we saw using tcpdump above.

          +

          4.5 RFC 1918

          - +

          IP addresses are allocated by the Internet Assigned Number Authority (IANA) - who delegates allocations on a geographic basis to Regional Internet - Registries (RIRs). For example, allocation for the Americas and for - sub-Sahara Africa is delegated to the American - Registry for Internet Numbers (ARIN). These RIRs may in turn delegate - to national registries. Most of us don't deal with these registrars but - rather get our IP addresses from our ISP.

          - + who delegates allocations on a geographic basis to Regional Internet + Registries (RIRs). For example, allocation for the Americas and for + sub-Sahara Africa is delegated to the American + Registry for Internet Numbers (ARIN). These RIRs may in turn delegate + to national registries. Most of us don't deal with these registrars but + rather get our IP addresses from our ISP.

          +

          It's a fact of life that most of us can't afford as many Public IP addresses as we have devices to assign them to so we end up making use of Private IP addresses. RFC 1918 reserves several IP address ranges for this purpose:

          - -
          + +
               10.0.0.0    - 10.255.255.255
               172.16.0.0  - 172.31.255.255
               192.168.0.0 - 192.168.255.255
          -
          - -
          +
          + +

          The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. This is understandable - given that anyone can select any of these addresses for their private - use.

          -
          - -
          + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. This is understandable + given that anyone can select any of these addresses for their private + use.

          +
          + +

          When selecting addresses from these ranges, there's a couple - of things to keep in mind:

          -
          - -
          + of things to keep in mind:

          +
          + +
            -
          • +

          • As the IPv4 address space becomes depleted, more and more organizations (including ISPs) are beginning to use RFC 1918 addresses - in their infrastructure.

            -
            • -
          • + in their infrastructure.

            +
            • +

          • You don't want to use addresses that are being used by - your ISP or by another organization with whom you want to establish - a VPN relationship.

            -
            • - + your ISP or by another organization with whom you want to establish + a VPN relationship.

            + +
          -
          - -
          +
          + +

          So it's a good idea to check with your ISP to see if they - are using (or are planning to use) private addresses before you decide - the addresses that you are going to use.

          -
          - -
          + are using (or are planning to use) private addresses before you decide + the addresses that you are going to use.

          +
          + +

          5.0 Setting up your Network

          -
          - -
          +
          + +

          The choice of how to set up your network depends primarily - on how many Public IP addresses you have vs. how many addressable entities - you have in your network. Regardless of how many addresses you have, -your ISP will handle that set of addresses in one of two ways:

          -
          - -
          + on how many Public IP addresses you have vs. how many addressable entities + you have in your network. Regardless of how many addresses you have, + your ISP will handle that set of addresses in one of two ways:

          +
          + +
            -
          1. +

          2. Routed - Traffic to any of your addresses will - be routed through a single gateway address. This will generally - only be done if your ISP has assigned you a complete subnet (/29 or larger). - In this case, you will assign the gateway address as the IP address -of your firewall/router's external interface.

            -
            3. -
          3. + be routed through a single gateway address. This will generally + only be done if your ISP has assigned you a complete subnet (/29 or +larger). In this case, you will assign the gateway address as the IP +address of your firewall/router's external interface.

            +
            4. +

          4. Non-routed - Your ISP will send traffic to each - of your addresses directly.

            -
            5. - + of your addresses directly.

            + +
          -
          - -
          +
          + +

          In the subsections that follow, we'll look at each of these - separately.
          -

          - + separately.
          +

          +

          Before we begin, there is one thing for you to check:

          - +

          -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
          -

          - +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
          +

          +
            -
          • NAT_ENABLED=Yes
            • -
          • IP_FORWARDING=On
            -
            • - +
          • NAT_ENABLED=Yes
            • +
          • IP_FORWARDING=On
            +
            • +
          -
          - -
          +
          + +

          5.1 Routed

          -
          - -
          +
          + +

          Let's assume that your ISP has assigned you the subnet 192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses - 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address -is 192.0.2.65. Your ISP has also told you that you should use a netmask -of 255.255.255.0 (so your /28 is part of a larger /24). With this many -IP addresses, you are able to subnet your /28 into two /29's and set up -your network as shown in the following diagram.

          -
          - -
          + 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address + is 192.0.2.65. Your ISP has also told you that you should use a netmask + of 255.255.255.0 (so your /28 is part of a larger /24). With this many + IP addresses, you are able to subnet your /28 into two /29's and set +up your network as shown in the following diagram.

          +
          + +

          -

          -
          - -
          +

          +
          + +

          Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ would be configured to 192.0.2.66 and the default gateway for hosts in the local network would be 192.0.2.73.

          -
          - -
          +
          + +

          Notice that this arrangement is rather wasteful of public - IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet addresses, - 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and 192.0.2.66 - and 168.0.2.73 for internal addresses on the firewall/router. Nevertheless, - it shows how subnetting can work and if we were dealing with a /24 rather - than a /28 network, the use of 6 IP addresses out of 256 would be justified - because of the simplicity of the setup.

          -
          - -
          + IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet +addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and +192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router. +Nevertheless, it shows how subnetting can work and if we were dealing +with a /24 rather than a /28 network, the use of 6 IP addresses out of +256 would be justified because of the simplicity of the setup.

          +
          + +

          The astute reader may have noticed that the Firewall/Router's - external interface is actually part of the DMZ subnet (192.0.2.64/29). - What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The -routing table on DMZ 1 will look like this:

          -
          - -
          -
          + external interface is actually part of the DMZ subnet (192.0.2.64/29). + What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The + routing table on DMZ 1 will look like this:

          +
          + +
          +
          Kernel IP routing table
          Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
          192.0.2.64 	0.0.0.0 	255.255.255.248 U     40  0         0 eth0
          0.0.0.0 	192.0.2.66	0.0.0.0 	UG    40  0         0 eth0
          -
          -
          - -
          +
          + + +

          This means that DMZ 1 will send an ARP "who-has 192.0.2.65" - request and no device on the DMZ Ethernet segment has that IP address. - Oddly enough, the firewall will respond to the request with the MAC address - of its DMZ Interface!! DMZ 1 can then send Ethernet frames addressed - to that MAC address and the frames will be received (correctly) by the - firewall/router.

          -
          - -
          + request and no device on the DMZ Ethernet segment has that IP address. + Oddly enough, the firewall will respond to the request with the MAC +address of its DMZ Interface!! DMZ 1 can then send Ethernet frames +addressed to that MAC address and the frames will be received (correctly) +by the firewall/router.

          +
          + +

          It is this rather unexpected ARP behavior on the part of the Linux Kernel that prompts the warning earlier in this guide regarding the connecting of multiple firewall/router interfaces to the same hub or switch. When an ARP request for one of the firewall/router's IP addresses is sent by another system connected to the hub/switch, all of the firewall's - interfaces that connect to the hub/switch can respond! It is then a race - as to which "here-is" response reaches the sender first.

          -
          - -
          + interfaces that connect to the hub/switch can respond! It is then a +race as to which "here-is" response reaches the sender first.

          +
          + +

          5.2 Non-routed

          -
          - -
          +
          + +

          If you have the above situation but it is non-routed, you can configure your network exactly as described above with one additional - twist; simply specify the "proxyarp" option on all three firewall interfaces - in the /etc/shorewall/interfaces file.

          -
          - -
          + twist; simply specify the "proxyarp" option on all three firewall interfaces + in the /etc/shorewall/interfaces file.

          +
          + +

          Most of us don't have the luxury of having enough public IP addresses to set up our networks as shown in the preceding example (even if the setup is routed).

          -
          - -
          +
          + +

          For the remainder of this section, assume that your ISP - has assigned you IP addresses 192.0.2.176-180 and has told you to use - netmask 255.255.255.0 and default gateway 192.0.2.254.

          -
          - -
          + has assigned you IP addresses 192.0.2.176-180 and has told you to use + netmask 255.255.255.0 and default gateway 192.0.2.254.

          +
          + +

          Clearly, that set of addresses doesn't comprise a subnetwork - and there aren't enough addresses for all of the network interfaces. -There are four different techniques that can be used to work around this -problem.

          -
          - -
          + and there aren't enough addresses for all of the network interfaces. + There are four different techniques that can be used to work around this + problem.

          +
          + +
            -
          • +

          • Source Network Address Translation (SNAT).

            -
            • -
          • +
            • +

          • Destination Network Address Translation (DNAT) - also known as Port Forwarding.

            -
            • -
          • + also known as Port Forwarding.

            +
            • +

          • Proxy ARP.

            -
            • -
          • +
            • +

          • Network Address Translation (NAT) also referred - to as Static NAT.

            -
            • - + to as Static NAT.

            + +
          -
          - -
          +
          + +

          Often a combination of these techniques is used. Each of these will be discussed in the sections that follow.

          -
          - -
          +
          + +

           5.2.1 SNAT

          -
          - -
          +
          + +

          With SNAT, an internal LAN segment is configured using RFC - 1918 addresses. When a host A on this internal segment initiates - a connection to host B on the internet, the firewall/router rewrites - the IP header in the request to use one of your public IP addresses as - the source address. When B responds and the response is received - by the firewall, the firewall changes the destination address back to - the RFC 1918 address of A and forwards the response back to A.

          -
          - -
          + 1918 addresses. When a host A on this internal segment initiates + a connection to host B on the internet, the firewall/router rewrites + the IP header in the request to use one of your public IP addresses +as the source address. When B responds and the response is received + by the firewall, the firewall changes the destination address back +to the RFC 1918 address of A and forwards the response back to +A.

          +
          + +

          Let's suppose that you decide to use SNAT on your local zone - and use public address 192.0.2.176 as both your firewall's external IP - address and the source IP address of internet requests sent from that + and use public address 192.0.2.176 as both your firewall's external +IP address and the source IP address of internet requests sent from that zone.

          -
          - -
          +
          + +

          -

          -
          - + + +
          The local zone has been subnetted as 192.168.201.0/29 - (netmask 255.255.255.248).
          - + (netmask 255.255.255.248). +
           
          - +
          -     The systems in the local zone would be configured with a default - gateway of 192.168.201.1 (the IP address of the firewall's local interface).
          - +     The systems in the local zone would be configured with a default + gateway of 192.168.201.1 (the IP address of the firewall's local interface). +
           
          - +
          -     SNAT is configured in Shorewall using the /etc/shorewall/masq file.
          - -
          -
          + +
          +
          - - - - - - - - - - - - - + + + + + + + + + + + + +
          INTERFACESUBNETADDRESS
          eth0192.168.201.0/29192.0.2.176
          INTERFACESUBNETADDRESS
          eth0192.168.201.0/29192.0.2.176
          -
          -
          - -
          +
          +
          + +

          This example used the normal technique of assigning the same - public IP address for the firewall external interface and for SNAT. If - you wanted to use a different IP address, you would either have to use - your distributions network configuration tools to add that IP address - to the external interface or you could set ADD_SNAT_ALIASES=Yes in -/etc/shorewall/shorewall.conf and Shorewall will add the address for you.

          -
          - -
          + public IP address for the firewall external interface and for SNAT. +If you wanted to use a different IP address, you would either have to +use your distributions network configuration tools to add that IP address + to the external interface or you could set ADD_SNAT_ALIASES=Yes in + /etc/shorewall/shorewall.conf and Shorewall will add the address for you.

          +
          + +

          5.2.2 DNAT

          -
          - -
          +
          + +

          When SNAT is used, it is impossible for hosts on the internet - to initiate a connection to one of the internal systems since those systems - do not have a public IP address. DNAT provides a way to allow selected - connections from the internet.

          -
          - -
          + to initiate a connection to one of the internal systems since those +systems do not have a public IP address. DNAT provides a way to allow +selected connections from the internet.

          +
          + +

          -      Suppose that your daughter wants to run a web server on her -system "Local 3". You could allow connections to the internet to her -server by adding the following entry in /etc/shorewall/rules:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
          DNATnetloc:192.168.201.4tcpwww-192.0.2.176
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
          DNATnetloc:192.168.201.4tcpwww-192.0.2.176
          -
          -
          - -
          +
          + + +

          If one of your daughter's friends at address A wants - to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external - IP address) and the firewall will rewrite the destination IP address -to 192.168.201.4 (your daughter's system) and forward the request. When -your daughter's server responds, the firewall will rewrite the source -address back to 192.0.2.176 and send the response back to A.

          -
          - -
          + IP address) and the firewall will rewrite the destination IP address + to 192.168.201.4 (your daughter's system) and forward the request. When + your daughter's server responds, the firewall will rewrite the source + address back to 192.0.2.176 and send the response back to A.

          +
          + +

          This example used the firewall's external IP address for DNAT. You can use another of your public IP addresses but Shorewall will not add that address to the firewall's external interface for you.

          -
          - -
          +
          + +

          5.2.3 Proxy ARP

          -
          - -
          +
          + +

          The idea behind proxy ARP is that:

          -
          - -
          +
          + +
            -
          • +

          • A host H behind your firewall is assigned one of your public IP addresses (A) and is assigned the same netmask (M) as the firewall's external interface.

            -
            • -
          • +
            • +

          • The firewall responds to ARP "who has" requests for A. -

            -
            • -
          • +

            +
            • +

          • When H issues an ARP "who has" request for an address in the subnetwork defined by A and M, the firewall will respond (with the MAC if the firewall interface to H).

            -
            • - + +
          -
          - -
          +
          + +

          Let suppose that we decide to use Proxy ARP on the DMZ in - our example network.

          -
          - -
          + our example network.

          +
          + +

          -

          -
          - +

          + +
          Here, we've assigned the IP addresses 192.0.2.177 to - system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned - an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface - on the firewall. That address and netmask isn't relevant - just be sure - it doesn't overlap another subnet that you've defined.
          - + system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned + an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface + on the firewall. That address and netmask isn't relevant - just be sure + it doesn't overlap another subnet that you've defined. +
           
          - +
          -     The Shorewall configuration of Proxy ARP is done using the -/etc/shorewall/proxyarp file.
          - -
          -
          +     The Shorewall configuration of Proxy ARP is done using the + /etc/shorewall/proxyarp file.
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
          ADDRESSINTERFACEEXTERNALHAVE ROUTE
          192.0.2.177eth2eth0No
          192.0.2.178eth2eth0No
          ADDRESSINTERFACEEXTERNALHAVE ROUTE
          192.0.2.177eth2eth0No
          192.0.2.178eth2eth0No
          -
          -
          - -
          + +
          + +

          Because the HAVE ROUTE column contains No, Shorewall will - add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
          -

          - -

          The ethernet interfaces on DMZ 1 and DMZ 2 should be configured -to have the IP addresses shown but should have the same default gateway as -the firewall itself -- namely 192.0.2.254.
          -

          -
          - -
          -

          -
          - -
          -
          -

          A word of warning is in order here. ISPs typically configure - their routers with a long ARP cache timeout. If you move a system from - parallel to your firewall to behind your firewall with Proxy ARP, it -will probably be HOURS before that system can communicate with the internet. - There are a couple of things that you can try:
          + add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

          +

          The ethernet interfaces on DMZ 1 and DMZ 2 should be configured + to have the IP addresses shown but should have the same default gateway as + the firewall itself -- namely 192.0.2.254.
          +

          +
          + +
          +

          +
          + +
          +
          +

          A word of warning is in order here. ISPs typically configure + their routers with a long ARP cache timeout. If you move a system from + parallel to your firewall to behind your firewall with Proxy ARP, it +will probably be HOURS before that system can communicate with the internet. + There are a couple of things that you can try:
          +

          +
            -
          1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, - Vol 1 reveals that a
            -
            - "gratuitous" ARP packet should cause the ISP's router to refresh their -ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the -MAC address for its own IP; in addition to ensuring that the IP address +
          2. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP +Illustrated, Vol 1 reveals that a
            +
            + "gratuitous" ARP packet should cause the ISP's router to refresh their + ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the + MAC address for its own IP; in addition to ensuring that the IP address isn't a duplicate,...
            -
            - "if the host sending the gratuitous ARP has just changed its hardware -address..., this packet causes any other host...that has an entry in its -cache for the old hardware address to update its ARP cache entry accordingly."
            -
            - Which is, of course, exactly what you want to do when you switch a host - from being exposed to the Internet to behind Shorewall using proxy ARP -(or static NAT for that matter). Happily enough, recent versions of Redhat's -iputils package include "arping", whose "-U" flag does just that:
            -
            -     arping -U -I <net if> <newly proxied - IP>
            -     arping -U -I eth0 66.58.99.83 # for example
            -
            - Stevens goes on to mention that not all systems respond correctly to gratuitous - ARPs, but googling for "arping -U" seems to support the idea that it works - most of the time.
            -
            -
            3. -
          3. You can call your ISP and ask them to purge the stale ARP cache - entry but many either can't or won't purge individual entries.
            4. - +
            + "if the host sending the gratuitous ARP has just changed its hardware + address..., this packet causes any other host...that has an entry in its + cache for the old hardware address to update its ARP cache entry accordingly."
            +
            + Which is, of course, exactly what you want to do when you switch a host + from being exposed to the Internet to behind Shorewall using proxy ARP + (or static NAT for that matter). Happily enough, recent versions of Redhat's + iputils package include "arping", whose "-U" flag does just that:
            +
            +     arping -U -I <net if> <newly proxied + IP>
            +     arping -U -I eth0 66.58.99.83 # for example
            +
            + Stevens goes on to mention that not all systems respond correctly to +gratuitous ARPs, but googling for "arping -U" seems to support the idea +that it works most of the time.
            +
            + +
          4. You can call your ISP and ask them to purge the stale ARP cache + entry but many either can't or won't purge individual entries.
            5. +
          - You can determine if your ISP's gateway ARP cache is stale using ping - and tcpdump. Suppose that we suspect that the gateway router has a stale - ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:
          - -
          + You can determine if your ISP's gateway ARP cache is stale using +ping and tcpdump. Suppose that we suspect that the gateway router has +a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump +as follows:
          + +
          	tcpdump -nei eth0 icmp
          -
          - -
          +
          + +

          Now from 130.252.100.19, ping the ISP's gateway (which we - will assume is 130.252.100.254):

          -
          - -
          + will assume is 130.252.100.254):

          +
          + +
          	ping 130.252.100.254
          -
          -
          - -
          +
          +
          + +

          We can now observe the tcpdump output:

          -
          - -
          +
          + +
          	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
          	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
          -
          - -
          +
          + +

          Notice that the source MAC address in the echo request is - different from the destination MAC address in the echo reply!! In this - case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 - was the MAC address of DMZ 1. In other words, the gateway's ARP cache - still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the - firewall's eth0.

          -
          - -
          + different from the destination MAC address in the echo reply!! In this + case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 + was the MAC address of DMZ 1. In other words, the gateway's ARP cache + still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the + firewall's eth0.

          +
          + +

          5.2.4 Static NAT

          -
          - -
          +
          + +

          With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public - IP addresses. For outgoing connections SNAT (Source Network Address -Translation) occurs and on incoming connections DNAT (Destination Network -Address Translation) occurs. Let's go back to our earlier example involving -your daughter's web server running on system Local 3.

          -
          - -
          + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT (Source Network Address + Translation) occurs and on incoming connections DNAT (Destination Network + Address Translation) occurs. Let's go back to our earlier example involving + your daughter's web server running on system Local 3.

          +
          + +

          -

          -
          - -
          +

          +
          + +

          Recall that in this setup, the local network is using SNAT - and is sharing the firewall external IP (192.0.2.176) for outbound connections. - This is done with the following entry in /etc/shorewall/masq:

          -
          - -
          -
          + and is sharing the firewall external IP (192.0.2.176) for outbound connections. + This is done with the following entry in /etc/shorewall/masq:

          +
          + +
          +
          - - - - - - - - - - - - - + + + + + + + + + + + + +
          INTERFACESUBNETADDRESS
          eth0192.168.201.0/29192.0.2.176
          INTERFACESUBNETADDRESS
          eth0192.168.201.0/29192.0.2.176
          -
          -
          - -
          + +
          + +

          -     Suppose now that you have decided to give your daughter her own - IP address (192.0.2.179) for both inbound and outbound connections. You - would do that by adding an entry in /etc/shorewall/nat.

          -
          - -
          -
          +     Suppose now that you have decided to give your daughter her +own IP address (192.0.2.179) for both inbound and outbound connections. +You would do that by adding an entry in /etc/shorewall/nat.

          +
          + +
          +
          - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
          EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
          192.0.2.179eth0192.168.201.4NoNo
          EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
          192.0.2.179eth0192.168.201.4NoNo
          -
          -
          - -
          + +
          + +

          With this entry in place, you daughter has her own IP address - and the other two local systems share the firewall's IP address.

          -
          - -
          + and the other two local systems share the firewall's IP address.

          +
          + +

          -     Once the relationship between 192.0.2.179 and 192.168.201.4 is - established by the nat file entry above, it is no longer appropriate - to use a DNAT rule for you daughter's web server -- you would rather -just use an ACCEPT rule:

          -
          - -
          -
          +     Once the relationship between 192.0.2.179 and 192.168.201.4 +is established by the nat file entry above, it is no longer appropriate + to use a DNAT rule for you daughter's web server -- you would rather + just use an ACCEPT rule:

          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
          ACCEPTnetloc:192.168.201.4tcpwww  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
          ACCEPTnetloc:192.168.201.4tcpwww  
          -
          -
          - -
          + +
          + +

          5.3 Rules

          -
          - -
          +
          + +

          -     With the default policies, your local systems (Local 1-3) can -access any servers on the internet and the DMZ can't access any other -host (including the firewall). With the exception of DNAT rules which cause address translation and allow -the translated connection request to pass through the firewall, the way -to allow connection requests through your firewall is to use ACCEPT rules.

          -
          - -
          + the translated connection request to pass through the firewall, the way + to allow connection requests through your firewall is to use ACCEPT +rules.

          +
          + +

          NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't - used in this section, they won't be shown

          -
          - -
          + used in this section, they won't be shown

          +
          + +

          You probably want to allow ping between your zones:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORT
          ACCEPTnetdmzicmpecho-request
          ACCEPTnetlocicmpecho-request
          ACCEPTdmzlocicmpecho-request
          ACCEPTlocdmzicmpecho-request
          ACTIONSOURCEDESTINATIONPROTOCOLPORT
          ACCEPTnetdmzicmpecho-request
          ACCEPTnetlocicmpecho-request
          ACCEPTdmzlocicmpecho-request
          ACCEPTlocdmzicmpecho-request
          -
          -
          - -
          + +
          + +

          Let's suppose that you run mail and pop3 servers on DMZ 2 - and a Web Server on DMZ 1. The rules that you would need are:

          -
          - -
          -
          + and a Web Server on DMZ 1. The rules that you would need are:

          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
          ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
          ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
          ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
          ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
          ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
          ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
          ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
          ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
          ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
          ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
          ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
          ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
          ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
          ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
          ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
          ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
          -
          -
          - -
          + +
          + +

          If you run a public DNS server on 192.0.2.177, you would need to add the following rules:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
          ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
          ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
          ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
          ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
          ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
          ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
          ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
          ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
          ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
          ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
          ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
          ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
          ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
          ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
          -
          -
          - -
          + +
          + +

          You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which through - its scp utility can also do publishing and software update distribution.

          -
          - -
          -
          + and DMZ systems from the local network -- I recommend SSH which through + its scp utility can also do publishing and software update distribution.

          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTlocdmztcpssh# SSH to the DMZ
          ACCEPTlocfwtcpssh# SSH to the Firewall
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTlocdmztcpssh# SSH to the DMZ
          ACCEPTlocfwtcpssh# SSH to the Firewall
          -
          -
          - -
          + +
          + +

          5.4 Odds and Ends

          -
          - -
          +
          + +

          The above discussion reflects my personal preference for using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I prefer to use NAT only in cases where a system that is part of an RFC 1918 subnet needs to have it's own public IP. 

          -
          - -
          +
          + +

          -     If you haven't already, it would be a good idea to browse through - /etc/shorewall/shorewall.conf just - to see if there is anything there that might be of interest. You might - also want to look at the other configuration files that you haven't touched - yet just to get a feel for the other things that Shorewall can do.

          -
          - -
          +     If you haven't already, it would be a good idea to browse through + /etc/shorewall/shorewall.conf just + to see if there is anything there that might be of interest. You might + also want to look at the other configuration files that you haven't +touched yet just to get a feel for the other things that Shorewall can +do.

          +
          + +

          In case you haven't been keeping score, here's the final set of configuration files for our sample network. Only those that were modified from the original installation are shown.

          -
          - -
          +
          + +

          /etc/shorewall/interfaces (The "options" will be very site-specific).

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ZoneInterfaceBroadcastOptions
          neteth0detectnorfc1918,routefilter
          loceth1detect 
          dmzeth2detect 
          ZoneInterfaceBroadcastOptions
          neteth0detectnorfc1918,routefilter
          loceth1detect 
          dmzeth2detect 
          -
          -
          - -
          + +
          + +

          The setup described here requires that your network interfaces - be brought up before Shorewall can start. This opens a short window during - which you have no firewall protection. If you replace 'detect' with -the actual broadcast addresses in the entries above, you can bring up -Shorewall before you bring up your network interfaces.

          -
          - -
          -
          + be brought up before Shorewall can start. This opens a short window +during which you have no firewall protection. If you replace 'detect' +with the actual broadcast addresses in the entries above, you can bring +up Shorewall before you bring up your network interfaces.

          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ZoneInterfaceBroadcastOptions
          neteth0192.0.2.255norfc1918,routefilter
          loceth1192.168.201.7 
          dmzeth2192.168.202.7 
          ZoneInterfaceBroadcastOptions
          neteth0192.0.2.255norfc1918,routefilter
          loceth1192.168.201.7 
          dmzeth2192.168.202.7 
          -
          -
          - -
          + +
          + +

          /etc/shorewall/masq - Local subnet

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - + + + + + + + + + + + + +
          INTERFACESUBNETADDRESS
          eth0192.168.201.0/29192.0.2.176
          INTERFACESUBNETADDRESS
          eth0192.168.201.0/29192.0.2.176
          -
          -
          - -
          + +
          + +

          /etc/shorewall/proxyarp - DMZ

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
          ADDRESSINTERFACEEXTERNALHAVE ROUTE
          192.0.2.177eth2eth0No
          192.0.2.178eth2eth0No
          ADDRESSINTERFACEEXTERNALHAVE ROUTE
          192.0.2.177eth2eth0No
          192.0.2.178eth2eth0No
          -
          -
          - -
          + +
          + +

          /etc/shorewall/nat- Daughter's System

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
          EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
          192.0.2.179eth0192.168.201.4NoNo
          EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
          192.0.2.179eth0192.168.201.4NoNo
          -
          -
          - -
          + +
          + +

          /etc/shorewall/rules

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
          ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
          ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
          ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
          ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
          ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
          ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
          ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
          ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
          ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
          ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
          ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
          ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
          ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
          ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
          ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
          ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
          ACCEPTnetdmzicmpecho-request# Ping
          ACCEPTnetlocicmpecho-request#  "
          ACCEPTdmzlocicmpecho-request# "
          ACCEPTlocdmzicmpecho-request# "
          ACCEPTlocdmztcpssh# SSH to the DMZ
          ACCEPTlocfwtcpssh# SSH to the Firewall
          ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
          ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
          ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
          ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
          ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
          ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
          ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
          ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
          ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
          ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
          ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
          ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
          ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
          ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
          ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
          ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
          ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
          ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
          ACCEPTnetdmzicmpecho-request# Ping
          ACCEPTnetlocicmpecho-request#  "
          ACCEPTdmzlocicmpecho-request# "
          ACCEPTlocdmzicmpecho-request# "
          ACCEPTlocdmztcpssh# SSH to the DMZ
          ACCEPTlocfwtcpssh# SSH to the Firewall
          -
          -
          - -
          + +
          + +

          6.0 DNS

          -
          - -
          +
          + +

          Given the collection of RFC 1918 and public addresses in this setup, it only makes sense to have separate internal and external DNS servers. You can combine the two into a single BIND 9 server using Views. If you are not interested in Bind 9 views, you can go to the next section.

          -
          - -
          +
          + +

          Suppose that your domain is foobar.net and you want the two - DMZ systems named www.foobar.net and mail.foobar.net and you want the - three local systems named "winken.foobar.net, blinken.foobar.net and nod.foobar.net. - You want your firewall to be known as firewall.foobar.net externally -and it's interface to the local network to be know as gateway.foobar.net -and its interface to the dmz as dmz.foobar.net. Let's have the DNS server - on 192.0.2.177 which will also be known by the name ns1.foobar.net.

          -
          - -
          + DMZ systems named www.foobar.net and mail.foobar.net and you want the + three local systems named "winken.foobar.net, blinken.foobar.net and +nod.foobar.net. You want your firewall to be known as firewall.foobar.net +externally and it's interface to the local network to be know as gateway.foobar.net + and its interface to the dmz as dmz.foobar.net. Let's have the DNS server + on 192.0.2.177 which will also be known by the name ns1.foobar.net.

          +
          + +

          The /etc/named.conf file would look like this:

          -
          - -
          -
          -
          +
          + +
          +
          + 
          options {
          	directory "/var/named";
          	listen-on { 127.0.0.1 ; 192.0.2.177; };
          };

          logging {
          	channel xfer-log {
          		file "/var/log/named/bind-xfer.log";
          		print-category yes;
          		print-severity yes;
          		print-time yes;
          		severity info;
          	};
          	category xfer-in { xfer-log; };
          	category xfer-out { xfer-log; };
          	category notify { xfer-log; };
          };
          -
          - -
          +
          + + 
          #
          # This is the view presented to our internal systems
          #

          view "internal" {
          	#
          	# These are the clients that see this view
          	#
          	match-clients { 192.168.201.0/29;
          			192.168.202.0/29;
          			127.0.0/24;
          			192.0.2.176/32; 
          			192.0.2.178/32;
          			192.0.2.179/32;
          			192.0.2.180/32; };
          	#
          	# If this server can't complete the request, it should use outside
          	# servers to do so
          	#
          	recursion yes;

          	zone "." in {
          		type hint;
          		file "int/root.cache";
          	};

          	zone "foobar.net" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "int/db.foobar";
          	};

          	zone "0.0.127.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "int/db.127.0.0";	
          	};

          	zone "201.168.192.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "int/db.192.168.201";
          	};

          	zone "202.168.192.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "int/db.192.168.202";
          	};

          	zone "176.2.0.192.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "db.192.0.2.176";
          	};
           (or status NAT for that matter)
          	zone "177.2.0.192.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "db.192.0.2.177";
          	};

          	zone "178.2.0.192.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "db.192.0.2.178";
          	};

          	zone "179.2.0.192.in-addr.arpa" in {
          		type master;
          		notify no;
          		allow-update { none; };
          		file "db.206.124.146.179";
          	};

          };
          #
          # This is the view that we present to the outside world
          #
          view "external" {
          	match-clients { any; };
          	#
          	# If we can't answer the query, we tell the client so
          	#
          	recursion no;

          	zone "foobar.net" in {
          		type master;
          		notify yes;
          		allow-update {none; };
          		allow-transfer { <secondary NS IP>; };
          		file "ext/db.foobar";
          	};

          	zone "176.2.0.192.in-addr.arpa" in {
           		type master;
          		notify yes;
          		allow-update { none; };
          		allow-transfer { <secondary NS IP>; };
          		file "db.192.0.2.176";
          	};

          	zone "177.2.0.192.in-addr.arpa" in {
          		type master;
          		notify yes;
          		allow-update { none; };
          		allow-transfer { <secondary NS IP>; };
          		file "db.192.0.2.177";
          	};

          	zone "178.2.0.192.in-addr.arpa" in {
          		type master;
          		notify yes;
          		allow-update { none; };
          		allow-transfer { <secondary NS IP>; };
          		file "db.192.0.2.178";
          	};

          	zone "179.2.0.192.in-addr.arpa" in {
          		type master;
          		notify yes;
          		allow-update { none; };
          		allow-transfer { <secondary NS IP>; };
          		file "db.192.0.2.179";
          	};
          };
          -
          -
          -
          - -
          +
          +
          +
          + +

          Here are the files in /var/named (those not shown are usually - included in your bind disbribution).

          - + included in your bind disbribution).

          +

          db.192.0.2.176 - This is the reverse zone for the firewall's - external interface

          - -
          + external interface

          + +
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
          ; Filename: db.192.0.2.176
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          			2001102303 ; serial
          			10800 ; refresh (3 hour)
          			3600 ; retry (1 hour)
          			604800 ; expire (7 days)
          			86400 ) ; minimum (1 day)
          ;
          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @	604800	IN NS	ns1.foobar.net.
          @	604800	IN NS	<name of secondary ns>.
          ;
          ; ############################################################
          ; Iverse Address Arpa Records (PTR's) 
          ; ############################################################
          176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
          -
          -
          - -
          + +
          + +
          db.192.0.2.177 - This is the reverse zone for the www/DNS - server -
          + server +
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
          ; Filename: db.192.0.2.177
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          			2001102303 ; serial
          			10800 ; refresh (3 hour)
          			3600 ; retry (1 hour)
          			604800 ; expire (7 days)
          			86400 ) ; minimum (1 day)
          ;
          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @	604800	IN NS	ns1.foobar.net.
          @	604800	IN NS	<name of secondary ns>.
          ;
          ; ############################################################
          ; Iverse Address Arpa Records (PTR's) 
          ; ############################################################
          177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
          -
          -
          -
          - -
          + +
          + + +
          db.192.0.2.178 - This is the reverse zone for the mail - server -
          + server +
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
          ; Filename: db.192.0.2.178
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          			2001102303 ; serial
          			10800 ; refresh (3 hour)
          			3600 ; retry (1 hour)
          			604800 ; expire (7 days)
          			86400 ) ; minimum (1 day)
          ;
          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @	604800	IN NS	ns1.foobar.net.
          @	604800	IN NS	<name of secondary ns>.
          ;
          ; ############################################################
          ; Iverse Address Arpa Records (PTR's) 
          ; ############################################################
          178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
          -
          -
          -
          - -
          + +
          + + +
          db.192.0.2.179 - This is the reverse zone for daughter's - web server's public IP -
          + web server's public IP +
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
          ; Filename: db.192.0.2.179
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          			2001102303 ; serial
          			10800 ; refresh (3 hour)
          			3600 ; retry (1 hour)
          			604800 ; expire (7 days)
          			86400 ) ; minimum (1 day)
          ;
          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @	604800	IN NS	ns1.foobar.net.
          @	604800	IN NS	<name of secondary ns>.
          ;
          ; ############################################################
          ; Iverse Address Arpa Records (PTR's) 
          ; ############################################################
          179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
          -
          -
          -
          - -
          + +
          + + +

          int/db.127.0.0 - The reverse zone for localhost

          -
          - -
          -
          +
          + +
          +
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
          ; Filename: db.127.0.0
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          				2001092901 ; serial
          				10800 ; refresh (3 hour)
          				3600 ; retry (1 hour)
          				604800 ; expire (7 days)
          				86400 ) ; minimum (1 day)
          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @	604800		IN NS	ns1.foobar.net.

          ; ############################################################
          ; Iverse Address Arpa Records (PTR's)
          ; ############################################################
          1	86400		IN PTR	localhost.foobar.net.
          -
          -
          - -
          + +
          + +

          int/db.192.168.201 - Reverse zone for the local net. This - is only shown to internal clients

          -
          - -
          -
          + is only shown to internal clients

          +
          + +
          +
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
          ; Filename: db.192.168.201
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
          				2002032501 ; serial
          				10800 ; refresh (3 hour)
          				3600 ; retry (1 hour)
          				604800 ; expire (7 days)
          				86400 ) ; minimum (1 day)

          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @	604800		IN NS	ns1.foobar.net.

          ; ############################################################
          ; Iverse Address Arpa Records (PTR's)
          ; ############################################################
          1	86400		IN PTR 	gateway.foobar.net.
          2	86400		IN PTR	winken.foobar.net.
          3	86400		IN PTR	blinken.foobar.net.
          4	86400		IN PTR	nod.foobar.net.
          -
          -
          - -
          + +
          + +

          int/db.192.168.202 - Reverse zone for the firewall's DMZ interface

          -
          - -
          -
          -
          +
          + +
          +
          + 
          ; ############################################################
          ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
          ; Filename: db.192.168.202
          ; ############################################################
          @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
          				2002032501 ; serial
          				10800 ; refresh (3 hour)
          				3600 ; retry (1 hour)
          				604800 ; expire (7 days)
          				86400 ) ; minimum (1 day)

          ; ############################################################
          ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
          ; ############################################################
          @		604800	IN NS	ns1.foobar.net.

          ; ############################################################
          ; Iverse Address Arpa Records (PTR's)
          ; ############################################################
          1 		86400 IN PTR	dmz.foobar.net.
          -
          -
          -
          - -
          +
          +
          +
          + +

          int/db.foobar - Forward zone for use by internal clients.

          -
          - -
          -
          +
          + +
          +
          ;##############################################################
          ; Start of Authority for foobar.net.
          ; Filename: db.foobar
          ;##############################################################
          @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          			2002071501 ; serial
          			10800 ; refresh (3 hour)
          			3600 ; retry (1 hour)
          			604800 ; expire (7 days)
          			86400 ); minimum (1 day)
          ;############################################################
          ; foobar.net Nameserver Records (NS)
          ;############################################################
          @ 		604800	IN NS	ns1.foobar.net.

          ;############################################################
          ; Foobar.net Office Records (ADDRESS)
          ;############################################################
          localhost	86400 	IN A 	127.0.0.1

          firewall	86400	IN A	192.0.2.176
          www		86400	IN A	192.0.2.177
          ns1 		86400	IN A 	192.0.2.177
          www		86400	IN A	192.0.2.177

          gateway		86400	IN A 	192.168.201.1
          winken		86400	IN A 	192.168.201.2
          blinken		86400	IN A	192.168.201.3
          nod		86400	IN A	192.168.201.4
          -
          -
          - -
          + +
          + +

          ext/db.foobar - Forward zone for external clients

          -
          - -
          -
          -
          +
          + +
          +
          + 
          ;##############################################################
          ; Start of Authority for foobar.net.
          ; Filename: db.foobar
          ;##############################################################
          @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
          			2002052901 ; serial
          			10800 ; refresh (3 hour)
          			3600 ; retry (1 hour)
          			604800 ; expire (7 days)
          			86400 ); minimum (1 day)
          ;############################################################
          ; Foobar.net Nameserver Records (NS)
          ;############################################################
          @		86400	IN NS	ns1.foobar.net.
          @		86400	IN NS	<secondary NS>.
          ;############################################################
          ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
          ;############################################################
          localhost	86400	IN A	127.0.0.1
          ;
          ; The firewall itself
          ;
          firewall	86400	IN A	192.0.2.176
          ;
          ; The DMZ
          ;
          ns1		86400	IN A	192.0.2.177
          www		86400	IN A	192.0.2.177
          mail		86400	IN A	192.0.2.178
          ;
          ; The Local Network
          ;
          nod		86400	IN A	192.0.2.179

          ;############################################################
          ; Current Aliases for foobar.net (CNAME)
          ;############################################################

          ;############################################################
          ; foobar.net MX Records (MAIL EXCHANGER)
          ;############################################################
          foobar.net.	86400	IN A	192.0.2.177
          		86400 	IN MX 0 mail.foobar.net.
          		86400	IN MX 1 <backup MX>.
          -
          -
          -
          - -
          +
          +
          +
          + +

          7.0 Starting and Stopping - Your Firewall

          -
          - -
          + Your Firewall +
          + +

          The installation procedure configures - your system to start Shorewall at system boot.

          -
          - -
          + your system to start Shorewall at system boot.

          +
          + +

          The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing - is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

          -
          - -
          + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

          +
          + +

          -     Edit the /etc/shorewall/routestopped file and configure those -systems that you want to be able to access the firewall when it is stopped.

          -
          - -
          +     Edit the /etc/shorewall/routestopped file and configure those + systems that you want to be able to access the firewall when it is stopped.

          +
          + +

          WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have - added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall - try" command.

          -
          - -

          Last updated 2/13/2003 - alternate configuration + and test it using the "shorewall + try" command.

          + + +

          Last updated 2/21/2003 - Tom Eastep

          - +

          Copyright 2002, 2003 - Thomas M. Eastep

          -
          + Thomas M. Eastep

          +
          +
          +



          diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index fbd0c0545..cf7699c5a 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -7,7 +7,7 @@ - + Shoreline Firewall (Shorewall) 1.3 @@ -17,22 +17,22 @@ - + - + - + - + - - + + + + + - + + - +
          @@ -43,14 +43,14 @@ - +

          Shorwall Logo - Shorewall 1.3 - Shorewall 1.4 - "iptables made easy"

          @@ -63,35 +63,37 @@ - - -
          - +
          - +
          - + - + - + - + - + - + - + + - +
          + @@ -102,7 +104,8 @@ - + +

          What is it?

          @@ -116,12 +119,12 @@ - +

          The Shoreline Firewall, more commonly known as  "Shorewall", is - a Netfilter (iptables) - based firewall that can be used on a dedicated firewall system, - a multi-function gateway/router/server or on a standalone GNU/Linux - system.

          + a Netfilter (iptables) + based firewall that can be used on a dedicated firewall system, + a multi-function gateway/router/server or on a standalone + GNU/Linux system.

          @@ -134,29 +137,29 @@ - +

          This program is free software; you can redistribute it and/or modify - it under the terms - of Version - 2 of the GNU General Public License as published by the Free Software - Foundation.
          + it under the +terms of Version + 2 of the GNU General Public License as published by the Free Software + Foundation.
          -
          +
          - 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 General Public License - for more details.
          + 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 General Public License + for more details.
          -
          +
          - You should have received - a copy of the GNU General Public License - along with this program; if not, write to - the Free Software Foundation, Inc., 675 - Mass Ave, Cambridge, MA 02139, USA

          + You should have received + a copy of the GNU General Public License + along with this program; if not, write +to the Free Software Foundation, Inc., 675 + Mass Ave, Cambridge, MA 02139, USA

          @@ -169,7 +172,7 @@ - +

          Copyright 2001, 2002, 2003 Thomas M. Eastep

          @@ -183,26 +186,26 @@ - +

          - Jacques Nilo - and Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution - called Bering that features - Shorewall-1.3.14 and Kernel-2.4.20. You can find - their work at: Jacques +Nilo and Eric Wolzak have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.3.14 and Kernel-2.4.20. You can find + their work at: http://leaf.sourceforge.net/devel/jnilo

          - Congratulations to -Jacques and Eric on the recent release of Bering 1.1!!! -
          -           + Congratulations + to Jacques and Eric on the recent release of Bering + 1.1!!!
          +           - +

          News

          @@ -218,222 +221,257 @@ Jacques and Eric on the recent release of Bering 1.1!!! - -

          3/7/2003 - Shorewall 1.4.0 RC2  3/17/2003 - Shorewall 1.4.0  (New) -  

          - Shorewall 1.4 represents - the next step in the evolution of Shorewall. The main thrust of the initial - release is simply to remove the cruft that has accumulated in Shorewall - over time.
          -
          - IMPORTANT: Shorewall 1.4.0 requires the iproute package - ('ip' utility).
          -
          - Function from 1.3 that has been omitted from this version include:
          - -
            -
          1. The MERGE_HOSTS variable in shorewall.conf is no - longer supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
            -
            -
            2. -
          2. Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate an error.
            -
            -
            3. -
          3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
            -
            -
            4. -
          4. The 'routestopped' option in the /etc/shorewall/interfaces - and /etc/shorewall/hosts files is no longer supported and will generate - an error at startup if specified.
            -
            -
            5. -
          5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is -no longer accepted.
            -
            -
            6. -
          6. The ALLOWRELATED variable in shorewall.conf is no longer -supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
            +  

            + Shorewall 1.4 represents + the next step in the evolution of Shorewall. The main thrust of the +initial release is simply to remove the cruft that has accumulated in +Shorewall over time.

            -
            7. -
          7. The icmp.def file has been removed.
            -
            8. - -
          - Changes for 1.4 include:
          - -
            -
          1. The /etc/shorewall/shorewall.conf file has been completely - reorganized into logical sections.
            -
            -
            2. -
          2. LOG is now a valid action for a rule (/etc/shorewall/rules).
            -
            -
            3. -
          3. The firewall script, common functions file and version file -are now installed in /usr/share/shorewall.
            -
            -
            4. -
          4. Late arriving DNS replies are now silently dropped in the - common chain by default.
            -
            -
            5. -
          5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall - 1.4 no longer unconditionally accepts outbound ICMP packets. So if you - want to 'ping' from the firewall, you will need the appropriate rule or -policy.
            -
            -
            6. -
          6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
            -
            -
            7. -
          7. 802.11b devices with names of the form wlan<n> - now support the 'maclist' option.
            -
            -
            8. -
          8. Explicit Congestion Notification (ECN - RFC 3168) -may now be turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
            -
            -    a) You must be running kernel 2.4.20
            -    b) You must have applied the patch in
            -    http://www.shorewall/net/pub/shorewall/ecn/patch.
            -    c) You must have iptables 1.2.7a installed.
            -
            -
            9. -
          9. The /etc/shorewall/params file is now processed first so that - variables may be used in the /etc/shorewall/shorewall.conf file.
            10. - -
          - You may download the Release Candidate from:
          - -
          http://www.shorewall.net/pub/shorewall/Beta
          - ftp://ftp.shorewall.net/pub/shorewall/Beta
          -
          - -

          2/8/2003 - Shorewall 1.3.14

          + IMPORTANT: Shorewall 1.4.0 requires the iproute package + ('ip' utility).
          +
          + Function from 1.3 that has been omitted from this version +include:
          - -

          New features include

          - - +
            -
          1. An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been -(see http://www.shorewall.net/ping.html).
            -
            - When OLD_PING_HANDLING=No, icmp echo (ping) is handled via -rules and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options -in /etc/shorewall/interfaces will all generate an error.
            -
            -
            2. -
          2. It is now possible to direct Shorewall to create a -"label" such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
            -  
            -    a) In the INTERFACE column of /etc/shorewall/masq
            -    b) In the INTERFACE column of /etc/shorewall/nat
            -  
            3. -
          3. Support for OpenVPN Tunnels.
            -
            -
            4. -
          4. Support for VLAN devices with names of the form $DEV.$VID - (e.g., eth0.0)
            +
          5. The MERGE_HOSTS variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.

            6. -
          6. In /etc/shorewall/tcrules, the MARK value may be optionally - followed by ":" and either 'F' or 'P' to designate that the marking will - occur in the FORWARD or PREROUTING chains respectively. If this additional - specification is omitted, the chain used to mark packets will be determined - by the setting of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
            -
            -
            7. -
          7. When an interface name is entered in the SUBNET column - of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic - from only the first subnet defined on that interface. It did not masquerade - traffic from:
            -  
            -    a) The subnets associated with other addresses on the interface.
            -    b) Subnets accessed through local routers.
            -  
            - Beginning with Shorewall 1.3.14, if you enter an interface -name in the SUBNET column, shorewall will use the firewall's routing -table to construct the masquerading/SNAT rules.
            -  
            - Example 1 -- This is how it works in 1.3.14.
            -   
            +
          8. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
            +
            +
            9. +
          9. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification + of the 'noping' or 'filterping' interface options.
            +
            +
            10. +
          10. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will generate + an error at startup if specified.
            +
            +
            11. +
          11. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no +longer accepted.
            +
            +
            12. +
          12. The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
            +
            +
            13. +
          13. The icmp.def file has been removed.
            +
            14. +
          + Changes for 1.4 include:
          + + +
            +
          1. The /etc/shorewall/shorewall.conf file has been completely + reorganized into logical sections.
            +
            +
            2. +
          2. LOG is now a valid action for a rule (/etc/shorewall/rules).
            +
            +
            3. +
          3. The firewall script, common functions file and version file + are now installed in /usr/share/shorewall.
            +
            +
            4. +
          4. Late arriving DNS replies are now silently dropped in the +common chain by default.
            +
            +
            5. +
          5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall + 1.4 no longer unconditionally accepts outbound ICMP packets. So if you + want to 'ping' from the firewall, you will need the appropriate rule or + policy.
            +
            +
            6. +
          6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
            +
            +
            7. +
          7. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
            +
            +
            8. +
          8. Explicit Congestion Notification (ECN - RFC 3168) + may now be turned off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility:
            +
            +    a) You must be running kernel 2.4.20
            +    b) You must have applied the patch in
            +    http://www.shorewall/net/pub/shorewall/ecn/patch.
            +    c) You must have iptables 1.2.7a installed.
            +
            +
            9. +
          9. The /etc/shorewall/params file is now processed first so that + variables may be used in the /etc/shorewall/shorewall.conf file.
            +
            +
            10. +
          10. Shorewall now gives a more helpful diagnostic when + the 'ipchains' compatibility kernel module is loaded and a 'shorewall start' + command is issued.
            +
            +
            11. +
          11. The SHARED_DIR variable has been removed from shorewall.conf. + This variable was for use by package maintainers and was not documented +for general use.
            +
            +
            12. +
          12. Shorewall now ignores 'default' routes when detecting masq'd + networks.
            +
            13. +
          + +

          3/11/2003 - Shoreall 1.3.14a (New) +  

          + +

          A roleup of the following bug fixes and other updates:

          + +
            +
          • There is an updated rfc1918 file that reflects the resent +allocation of 222.0.0.0/8 and 223.0.0.0/8. 
            • +
          • The documentation for the routestopped file claimed that a comma-separated + list could appear in the second column while the code only supported a + single host or network address. 
            • +
          • Log messages produced by 'logunclean' and 'dropunclean' were + not rate-limited. 
            • +
          • 802.11b devices with names of the form wlan<n> +don't support the 'maclist' interface option. 
            • +
          • Log messages generated by RFC 1918 filtering are not rate limited. 
            • +
          • The firewall fails to start in the case where you have "eth0 + eth1" in /etc/shorewall/masq and the default route is through eth1 +
            • + +
          + + +

          2/8/2003 - Shorewall 1.3.14

          + + +

          New features include

          + + +
            +
          1. An OLD_PING_HANDLING option has been added to shorewall.conf. + When set to Yes, Shorewall ping handling is as it has always been + (see http://www.shorewall.net/ping.html).
            +
            + When OLD_PING_HANDLING=No, icmp echo (ping) is handled +via rules and policies just like any other connection request. The +FORWARDPING=Yes option in shorewall.conf and the 'noping' and 'filterping' +options in /etc/shorewall/interfaces will all generate an error.
            +
            +
            2. +
          2. It is now possible to direct Shorewall to create + a "label" such as  "eth0:0" for IP addresses that it creates under + ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying + the label instead of just the interface name:
            +  
            +    a) In the INTERFACE column of /etc/shorewall/masq
            +    b) In the INTERFACE column of /etc/shorewall/nat
            +  
            3. +
          3. Support for OpenVPN Tunnels.
            +
            +
            4. +
          4. Support for VLAN devices with names of the form +$DEV.$VID (e.g., eth0.0)
            +
            +
            5. +
          5. In /etc/shorewall/tcrules, the MARK value may be +optionally followed by ":" and either 'F' or 'P' to designate that the +marking will occur in the FORWARD or PREROUTING chains respectively. +If this additional specification is omitted, the chain used to mark packets +will be determined by the setting of the MARK_IN_FORWARD_CHAIN option +in shorewall.conf.
            +
            +
            6. +
          6. When an interface name is entered in the SUBNET +column of the /etc/shorewall/masq file, Shorewall previously masqueraded + traffic from only the first subnet defined on that interface. It +did not masquerade traffic from:
            +  
            +    a) The subnets associated with other addresses on the + interface.
            +    b) Subnets accessed through local routers.
            +  
            + Beginning with Shorewall 1.3.14, if you enter an interface + name in the SUBNET column, shorewall will use the firewall's routing + table to construct the masquerading/SNAT rules.
            +  
            + Example 1 -- This is how it works in 1.3.14.
            +   
            - + 
               [root@gateway test]# cat /etc/shorewall/masq
               #INTERFACE              SUBNET                  ADDRESS
               eth0                    eth2                    206.124.146.176
               #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
            - + 
               [root@gateway test]# ip route show dev eth2
               192.168.1.0/24  scope link
               192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
            - + 
               [root@gateway test]# shorewall start
               ...
               Masqueraded Subnets and Hosts:
                   To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
                   To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
               Processing /etc/shorewall/tos...
            -  
            - When upgrading to Shorewall 1.3.14, if you have multiple local - subnets connected to an interface that is specified in the SUBNET column - of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will -need changing. In most cases, you will simply be able to remove redundant -entries. In some cases though, you might want to change from using the -interface name to listing specific subnetworks if the change described +  
            + When upgrading to Shorewall 1.3.14, if you have multiple + local subnets connected to an interface that is specified in the +SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq +file will need changing. In most cases, you will simply be able to remove +redundant entries. In some cases though, you might want to change from +using the interface name to listing specific subnetworks if the change described above will cause masquerading to occur on subnetworks that you don't wish to masquerade.
            -  
            - Example 2 -- Suppose that your current config is as follows:
            -   
            +  
            + Example 2 -- Suppose that your current config is as follows:
            +   
            - + 
               [root@gateway test]# cat /etc/shorewall/masq
               #INTERFACE              SUBNET                  ADDRESS
               eth0                    eth2                    206.124.146.176
               eth0                    192.168.10.0/24         206.124.146.176
               #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
            - + 
               [root@gateway test]# ip route show dev eth2
               192.168.1.0/24  scope link
               192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
               [root@gateway test]#
            -  
            -    In this case, the second entry in /etc/shorewall/masq is - no longer required.
            -  
            - Example 3 -- What if your current configuration is like this?
            -  
            +  
            +    In this case, the second entry in /etc/shorewall/masq + is no longer required.
            +  
            + Example 3 -- What if your current configuration is like + this?
            +  
            - + 
               [root@gateway test]# cat /etc/shorewall/masq
               #INTERFACE              SUBNET                  ADDRESS
               eth0                    eth2                    206.124.146.176
               #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
            - + 
               [root@gateway test]# ip route show dev eth2
               192.168.1.0/24  scope link
               192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
               [root@gateway test]#
            -  
            -    In this case, you would want to change the entry in  /etc/shorewall/masq - to:
            +  
            +    In this case, you would want to change the entry in  + /etc/shorewall/masq to:
            - + 
               #INTERFACE              SUBNET                  ADDRESS
               eth0                    192.168.1.0/24          206.124.146.176
               #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
            -
            7. - - + + +
          - +

          2/5/2003 - Shorewall Support included in Webmin 1.060 -

          - Webmin version 1.060 now has Shorewall support included as -standard. See http://www.webmin.com - - -

          +

          + Webmin version 1.060 now has Shorewall support included +as standard. See http://www.webmin.com + @@ -442,7 +480,8 @@ standard. See http://www.webmin.com< - + + @@ -460,7 +500,8 @@ standard. See http://www.webmin.com< - + +

          More News

          @@ -474,7 +515,7 @@ standard. See http://www.webmin.com< - +

          @@ -482,25 +523,26 @@ standard. See           http://www.webmin.com< - +

          SourceForge Logo -

          + - +

          - + +

          This site is hosted by the generous folks at SourceForge.net

          @@ -509,43 +551,44 @@ standard. See http://www.webmin.com< - +

          Donations

          -
          -
          -
          + -
          + - + - + - + - + - + - + - +
          @@ -556,12 +599,12 @@ standard. See http://www.webmin.com< - +

          -

          +

          @@ -573,35 +616,34 @@ standard. See http://www.webmin.com< - + +

          Shorewall is free but if you try it and find it useful, please consider making a donation - to Starlight Children's Foundation. Thanks!

          -
          - -

          Updated 3/7/2003 - Tom Eastep + +

          Updated 3/17/2003 - Tom Eastep -
          -

          -
          -
          +
          +


          diff --git a/STABLE/documentation/standalone.htm b/STABLE/documentation/standalone.htm index da3d40560..1029c35e2 100644 --- a/STABLE/documentation/standalone.htm +++ b/STABLE/documentation/standalone.htm @@ -1,425 +1,425 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
          +

          Standalone Firewall

          -
          - +

          Version 2.0.1

          - -

          Setting up Shorewall on a standalone Linux system is very - easy if you understand the basics and follow the documentation.

          - -

          This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in one of its most common configurations:

          - + +

          Setting up Shorewall on a standalone Linux system is very + easy if you understand the basics and follow the documentation.

          + +

          This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its most common configurations:

          +
            -
          • Linux system
            • -
          • Single external IP address
            • -
          • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
            • - +
          • Linux system
            • +
          • Single external IP address
            • +
          • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
            • +
          - -

          This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell -if this package is installed by the presence of an ip program on -your firewall system. As root, you can use the 'which' command to check -for this program:

          - + +

          Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program on + your firewall system. As root, you can use the 'which' command to check + for this program:

          + 
               [root@gateway root]# which ip
               /sbin/ip
               [root@gateway root]#
          - -

          I recommend that you read through the guide first to familiarize yourself - with what's involved then go back through it again making your configuration - changes.  Points at which configuration changes are recommended are flagged - with - .

          +

          I recommend that you read through the guide first to familiarize yourself + with what's involved then go back through it again making your configuration + changes.  Points at which configuration changes are recommended are flagged + with + .

          +

          -     If you edit your configuration files on a Windows system, you must - save them as Unix files if your editor supports that option or you must - run them through dos2unix before trying to use them. Similarly, if you -copy a configuration file from your Windows hard drive to a floppy disk, -you must run dos2unix against the copy before using it with Shorewall.

          - +     If you edit your configuration files on a Windows system, you +must save them as Unix files if your editor supports that option or you +must run them through dos2unix before trying to use them. Similarly, if +you copy a configuration file from your Windows hard drive to a floppy +disk, you must run dos2unix against the copy before using it with Shorewall.

          + - +

          Shorewall Concepts

          - +

          -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you only need to deal with a few of - these as described in this guide. After you have installed Shorewall, download the one-interface sample, - un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall - (they will replace files with the same names that were placed in /etc/shorewall + href="/pub/shorewall/LATEST.samples/one-interface.tgz">one-interface sample, + un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall during Shorewall installation).

          - -

          As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

          - -

          Shorewall views the network where it is running as being composed of a - set of zones. In the one-interface sample configuration, only one - zone is defined:

          - + +

          As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

          + +

          Shorewall views the network where it is running as being composed of a + set of zones. In the one-interface sample configuration, only +one zone is defined:

          + - + + + + + - - - - - - - - - + + + + +
          NameDescription
          NameDescription
          netThe Internet
          netThe Internet
          - +

          Shorewall zones are defined in /etc/shorewall/zones.

          - -

          Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

          - -

          Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

          - + +

          Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

          + +

          Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

          + - -

          For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file -matches the connection request then the first policy in /etc/shorewall/policy -that matches the request is applied. If that policy is REJECT or DROP  -the request is first checked against the rules in /etc/shorewall/common (the -samples provide that file for you).

          - -

          The /etc/shorewall/policy file included with the one-interface sample has -the following policies:

          - -
          + +

          For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common +(the samples provide that file for you).

          + +

          The /etc/shorewall/policy file included with the one-interface sample +has the following policies:

          + +
          - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
          SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
          SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
          fwnetACCEPT  
          netall
          -           		DROPinfo 
          allallREJECTinfo 
          fwnetACCEPT  
          netall
          +           		DROPinfo 
          allallREJECTinfo 
          -
          - +
          +

          The above policy will:

          - +
            -
          1. allow all connection requests from the firewall to the internet
            2. -
          2. drop (ignore) all connection requests from the internet to your - firewall
            3. -
          3. reject all other connection requests (Shorewall requires this -catchall policy).
            4. - +
          4. allow all connection requests from the firewall to the internet
            5. +
          5. drop (ignore) all connection requests from the internet to your + firewall
            6. +
          6. reject all other connection requests (Shorewall requires this + catchall policy).
            7. +
          - -

          At this point, edit your /etc/shorewall/policy and make any changes that - you wish.

          - + +

          At this point, edit your /etc/shorewall/policy and make any changes that + you wish.

          +

          External Interface

          - -

          The firewall has a single network interface. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter (eth0) that is connected to that "Modem"  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be - a ppp0. If you connect via a regular modem, your External Interface - will also be ppp0. If you connect using ISDN, your external interface - will be ippp0.

          - + +

          The firewall has a single network interface. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter (eth0) that is connected to that +"Modem"  unless you connect via Point-to-Point +Protocol over Ethernet (PPPoE) or Point-to-Point +Tunneling Protocol (PPTP) in which case the External +Interface will be a ppp0. If you connect via a regular modem, your +External Interface will also be ppp0. If you connect using ISDN, +your external interface will be ippp0.

          +

          -     The Shorewall one-interface sample configuration assumes that the - external interface is eth0. If your configuration is different, -you will have to modify the sample /etc/shorewall/interfaces file accordingly. - While you are there, you may wish to review the list of options that are - specified for the interface. Some hints:

          - +     The Shorewall one-interface sample configuration assumes that +the external interface is eth0. If your configuration is different, + you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that +are specified for the interface. Some hints:

          +
            -
          • -

            If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

            -
            • -
          • -

            If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

            -
            • - +
          • +

            If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

            +
            • +
          • +

            If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the +option list.

            +
            • +
          - -
          + +

          IP Addresses

          -
          - -
          -

          RFC 1918 reserves several Private IP address ranges - for use in private networks:

          - -
          +
          + +
          +

          RFC 1918 reserves several Private IP address ranges + for use in private networks:

          + +
               10.0.0.0    - 10.255.255.255
               172.16.0.0  - 172.31.255.255
               192.168.0.0 - 192.168.255.255
          -
          - -

          These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs - are assigning these addresses then using Network Address Translation - to rewrite packet headers when forwarding to/from the internet.

          - +
          + +

          These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, ISPs + are assigning these addresses then using Network Address Translation + to rewrite packet headers when forwarding to/from the internet.

          +

          -      Before starting Shorewall, you should look at the IP address -of your external interface and if it is one of the above ranges, you should - remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

          -
          - -
          -

          Enabling other Connections

          +      Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you +should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

          - -
          -

          If you wish to enable connections from the internet to your - firewall, the general format is:

          -
          - -
          -
          + +
          +

          Enabling other Connections

          +
          + +
          +

          If you wish to enable connections from the internet to your + firewall, the general format is:

          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfw<protocol><port>  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfw<protocol><port>  
          -
          +
          +
          + +
          +

          Example - You want to run a Web Server and a POP3 Server +on your firewall system:

          - -
          -

          Example - You want to run a Web Server and a POP3 Server on -your firewall system:

          -
          - -
          -
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp80  
          ACCEPTnetfwtcp110  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp80  
          ACCEPTnetfwtcp110  
          -
          +
          +
          + +
          +

          If you don't know what port and protocol a particular +application uses, see here.

          - -
          -

          If you don't know what port and protocol a particular application -uses, see here.

          -
          - -
          -

          Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want - shell access to your firewall from the internet, use SSH:

          -
          - -
          -
          + +
          +

          Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp22  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp22  
          -
          -
          - -
          +
          +
          + +

          -     At this point, edit /etc/shorewall/rules to add other connections - as desired.

          -
          - -
          -

          Starting and Stopping Your Firewall

          +     At this point, edit /etc/shorewall/rules to add other connections + as desired.

          - -
          + +
          +

          Starting and Stopping Your Firewall

          +
          + +

          Arrow -     The installation procedure configures - your system to start Shorewall at system boot but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file -/etc/shorewall/startup_disabled.
          -

          - -

          IMPORTANT: Users of the .deb - package must edit /etc/default/shorewall and set 'startup=1'.
          -

          -
          +     The installation procedure configures + your system to start Shorewall at system boot but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
          +

          -
          -

          The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing - is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

          -
          - -
          -

          WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have - added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall - try" command.

          -
          - -

          Last updated 1/26/2003 - IMPORTANT: Users of the .deb + package must edit /etc/default/shorewall and set 'startup=1'.
          +

          +
          + +
          +

          The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, routing + is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

          +
          + +
          +

          WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have + added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

          +
          + +

          Last updated 2/21/2003 - Tom Eastep

          - -

          Copyright 2002, 2003 + +

          Copyright 2002, 2003 Thomas M. Eastep

          -
          +
          +



          diff --git a/STABLE/documentation/starting_and_stopping_shorewall.htm b/STABLE/documentation/starting_and_stopping_shorewall.htm index c3d8cf4e1..4936e8b4d 100644 --- a/STABLE/documentation/starting_and_stopping_shorewall.htm +++ b/STABLE/documentation/starting_and_stopping_shorewall.htm @@ -1,13 +1,13 @@ - + - + - + - + Starting and Stopping Shorewall @@ -15,39 +15,39 @@ - + - - + + - + - + - - + +
          + - +

          Starting/Stopping and Monitoring - the Firewall

          + the Firewall -
          - +

          If you have a permanent internet connection such as DSL or Cable, - I recommend that you start the firewall automatically at boot. Once - you have installed "firewall" in your init.d directory, simply type - "chkconfig --add firewall". This will start the firewall in run - levels 2-5 and stop it in run levels 1 and 6. If you want to configure - your firewall differently from this default, you can use the "--level" - option in chkconfig (see "man chkconfig") or using your favorite - graphical run-level editor.

          + I recommend that you start the firewall automatically at boot. +Once you have installed "firewall" in your init.d directory, simply +type "chkconfig --add firewall". This will start the firewall +in run levels 2-5 and stop it in run levels 1 and 6. If you want +to configure your firewall differently from this default, you can +use the "--level" option in chkconfig (see "man chkconfig") or using +your favorite graphical run-level editor.

          @@ -55,282 +55,287 @@ - +

          Important Notes:
          -

          - +

          +
            -
          1. Shorewall startup is disabled by default. Once you have configured - your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. - Note: Users of the .deb package must edit /etc/default/shorewall and -set 'startup=1'.
            -
            2. -
          2. If you use dialup, you may want to start the firewall in - your /etc/ppp/ip-up.local script. I recommend just placing "shorewall - restart" in that script.
            3. - +
          3. Shorewall startup is disabled by default. Once you have +configured your firewall, you can enable startup by removing the file +/etc/shorewall/startup_disabled. Note: Users of the .deb package must +edit /etc/default/shorewall and set 'startup=1'.
            +
            4. +
          4. If you use dialup, you may want to start the firewall + in your /etc/ppp/ip-up.local script. I recommend just placing + "shorewall restart" in that script.
            5. +
          - +

          - +

          You can manually start and stop Shoreline Firewall using the "shorewall" - shell program:

          + shell program:

          - +
            -
          • shorewall start - starts the firewall
            • -
          • shorewall stop - stops the firewall
            • -
          • shorewall restart - stops the firewall (if it's - running) and then starts it again
            • -
          • shorewall reset - reset the packet and byte counters - in the firewall
            • -
          • shorewall clear - remove all rules and chains - installed by Shoreline Firewall
            • -
          • shorewall refresh - refresh the rules involving the broadcast - addresses of firewall interfaces and the black and white lists.
            • - +
          • shorewall start - starts the firewall
            • +
          • shorewall stop - stops the firewall
            • +
          • shorewall restart - stops the firewall (if it's + running) and then starts it again
            • +
          • shorewall reset - reset the packet and byte counters + in the firewall
            • +
          • shorewall clear - remove all rules and chains + installed by Shoreline Firewall
            • +
          • shorewall refresh - refresh the rules involving the broadcast + addresses of firewall interfaces, the black list, traffic control rules and ECN control rules.
            • +
          - If you include the keyword debug as the first argument, then a -shell trace of the command is produced as in:
          - + If you include the keyword debug as the first argument, then + a shell trace of the command is produced as in:
          + 
          	shorewall debug start 2> /tmp/trace
          - +

          The above command would trace the 'start' command and place the trace information in the file /tmp/trace
          -

          - +

          +

          The Shorewall State Diagram is shown at the - bottom of this page.
          -

          - + bottom of this page.
          +

          +

          The "shorewall" program may also be used to monitor the firewall.

          - +
            -
          • shorewall status - produce a verbose report about the firewall - (iptables -L -n -v)
            • -
          • shorewall show chain - produce a verbose report about - chain (iptables -L chain -n -v)
            • -
          • shorewall show nat - produce a verbose report about the nat - table (iptables -t nat -L -n -v)
            • -
          • shorewall show tos - produce a verbose report about the mangle - table (iptables -t mangle -L -n -v)
            • -
          • shorewall show log - display the last 20 packet log entries.
            • -
          • shorewall show connections - displays the IP connections -currently being tracked by the firewall.
            • -
          • shorewall - show - tc - displays information - about the traffic control/shaping configuration.
            • -
          • shorewall monitor [ delay ] - Continuously display the firewall - status, last 20 log entries and nat. When the log entry display - changes, an audible alarm is sounded.
            • -
          • shorewall hits - Produces several reports about the Shorewall - packet log messages in the current /var/log/messages file.
            • -
          • shorewall version - Displays the installed version number.
            • -
          • shorewall check - Performs a cursory validation - of the zones, interfaces, hosts, rules and policy files. The "check" command does not parse and validate - the generated iptables commands so even though the "check" command - completes successfully, the configuration may fail to start. See the - recommended way to make configuration changes described below. -
            • -
          • shorewall try configuration-directory [ timeout - ] - Restart shorewall using the specified configuration and if an -error occurs or if the timeout option is given and the new configuration - has been up for that many seconds then shorewall is restarted using - the standard configuration.
            • -
          • shorewall deny, shorewall reject, shorewall accept and shorewall - save implement dynamic blacklisting.
            • -
          • shorewall logwatch (added in version 1.3.2) - Monitors the - LOGFILE and produces an audible alarm when new - Shorewall messages are logged.
            • - +
          • shorewall status - produce a verbose report about the +firewall (iptables -L -n -v)
            • +
          • shorewall show chain - produce a verbose report + about chain (iptables -L chain -n -v)
            • +
          • shorewall show nat - produce a verbose report about the + nat table (iptables -t nat -L -n -v)
            • +
          • shorewall show tos - produce a verbose report about the + mangle table (iptables -t mangle -L -n -v)
            • +
          • shorewall show log - display the last 20 packet log entries.
            • +
          • shorewall show connections - displays the IP connections + currently being tracked by the firewall.
            • +
          • shorewall + show + tc - displays + information about the traffic control/shaping configuration.
            • +
          • shorewall monitor [ delay ] - Continuously display the + firewall status, last 20 log entries and nat. When the log +entry display changes, an audible alarm is sounded.
            • +
          • shorewall hits - Produces several reports about the Shorewall + packet log messages in the current /var/log/messages file.
            • +
          • shorewall version - Displays the installed version + number.
            • +
          • shorewall check - Performs a cursory validation of the + zones, interfaces, hosts, rules and policy files.
            +
            + The "check" command is totally unsuppored +and does not parse and validate the generated iptables commands. Even +though the "check" command completes successfully, the configuration +may fail to start. Problem reports that complain about errors that the 'check' +command does not detect will not be accepted.
            +
            + See the recommended way to make configuration changes described below.
            +
            +
            • +
          • shorewall try configuration-directory [ timeout + ] - Restart shorewall using the specified configuration and if an + error occurs or if the timeout option is given and the new +configuration has been up for that many seconds then shorewall is +restarted using the standard configuration.
            • +
          • shorewall deny, shorewall reject, shorewall accept and + shorewall save implement dynamic + blacklisting.
            • +
          • shorewall logwatch (added in version 1.3.2) - Monitors + the LOGFILE and produces an audible alarm when + new Shorewall messages are logged.
            • +
          - Finally, the "shorewall" program may be used to dynamically alter the - contents of a zone.
          - + Finally, the "shorewall" program may be used to dynamically alter + the contents of a zone.
          +
            -
          • shorewall add interface[:host] zone - Adds - the specified interface (and host if included) to the specified zone.
            • -
          • shorewall delete interface[:host] zone - -Deletes the specified interface (and host if included) from the specified +
          • shorewall add interface[:host] zone - + Adds the specified interface (and host if included) to the specified zone.
            • - +
          • shorewall delete interface[:host] zone - + Deletes the specified interface (and host if included) from the specified + zone.
            • +
          - +
          Examples:
          - +
          shorewall add ipsec0:192.0.2.24 vpn1 - -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
          - shorewall delete ipsec0:192.0.2.24 vpn1 - -- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1
          -
          -
          - - -

          The shorewall start, shorewall restart, shorewall check  and - shorewall try commands allow you to specify which Shorewall configuration - to use:

          - - -
          - - -

          shorewall [ -c configuration-directory ] {start|restart|check}
          - shorewall try configuration-directory

          + -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
          + shorewall delete ipsec0:192.0.2.24 +vpn1 -- deletes the address 192.0.2.24 from interface ipsec0 +from zone vpn1
          +
          - + +

          The shorewall start, shorewall restart, shorewall check, and + shorewall try commands allow you to specify which Shorewall configuration + to use:

          + + +
          + + +

          shorewall [ -c configuration-directory ] {start|restart|check}
          + shorewall try configuration-directory

          +
          + +

          If a configuration-directory is specified, each time that Shorewall - is going to use a file in /etc/shorewall it will first look in the configuration-directory - . If the file is present in the configuration-directory, that - file will be used; otherwise, the file in /etc/shorewall will be used.

          + is going to use a file in /etc/shorewall it will first look in the +configuration-directory . If the file is present in the configuration-directory, +that file will be used; otherwise, the file in /etc/shorewall will be +used.

          - +

          When changing the configuration of a production firewall, I recommend - the following:

          + the following:

          - +
            -
          • mkdir /etc/test
            • +
          • mkdir /etc/test
            • -
          • cd /etc/test
            • +
          • cd /etc/test
            • -
          • <copy any files that you need to change from /etc/shorewall - to . and change them here>
            • +
          • <copy any files that you need to change from + /etc/shorewall to . and change them here>
            • +
          • shorewall -c . check
            • +
          • <correct any errors found by check and check again>
            • -
          • shorewall -c . check
            • -
          • <correct any errors found by check and check again>
            • - -
          • /sbin/shorewall try .
            • - +
          • /sbin/shorewall + try .
            • +
          - +

          If the configuration starts but doesn't work, just "shorewall restart" - to restore the old configuration. If the new configuration fails to -start, the "try" command will automatically start the old one for you.

          + to restore the old configuration. If the new configuration fails +to start, the "try" command will automatically start the old one for +you.

          - +

          When the new configuration works then just

          - +
            -
          • cp * /etc/shorewall
            • +
          • cp * /etc/shorewall
            • -
          • cd
            • +
          • cd
            • -
          • rm -rf /etc/test
            • - +
          • rm -rf /etc/test
            • +
          - +

          The Shorewall State Diargram is depicted below.
          -

          - +

          +
          (State Diagram) -
          -
          - -

           
          -

          - You will note that the commands that result in state transitions use -the word "firewall" rather than "shorewall". That is because the actual transitions - are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall on - Debian); /sbin/shorewall runs 'firewall" according to the following table:
          -
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          shorewall start
          -           		firewall start
          -
          shorewall stop
          -           		firewall stop
          -
          shorewall restart
          -           		firewall restart
          -
          shorewall add
          -           		firewall add
          -
          shorewall delete
          -           		firewall delete
          -
          shorewall refresh
          -           		firewall refresh
          -
          shorewall try
          -           		firewall -c <new configuration> restart
          - If unsuccessful then firewall start (standard configuration)
          - If timeout then firewall restart (standard configuration)
          -
          -
          - -

          Updated 2/10/2003 - Tom Eastep -

          - - - -

          Copyright - © 2001, 2002, 2003 Thomas M. Eastep.

          - - -
          -
          -
          -

          -
          -
          -
          +
          + +

           
          +

          + You will note that the commands that result in state transitions +use the word "firewall" rather than "shorewall". That is because the actual + transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall + on Debian); /sbin/shorewall runs 'firewall" according to the following table:
          +
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          shorewall start
          +           		firewall start
          +
          shorewall stop
          +           		firewall stop
          +
          shorewall restart
          +           		firewall restart
          +
          shorewall add
          +           		firewall add
          +
          shorewall delete
          +           		firewall delete
          +
          shorewall refresh
          +           		firewall refresh
          +
          shorewall try
          +           		firewall -c <new configuration> restart
          + If unsuccessful then firewall start (standard configuration)
          + If timeout then firewall restart (standard configuration)
          +
          +
          + +

          Updated 2/27/2003 - Tom Eastep +

          + + + +

          Copyright + © 2001, 2002, 2003 Thomas M. Eastep.
          +


          diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index f5b99a6f1..0f85ded95 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -3,406 +3,337 @@ - + - + - - - - - - - - Shorewall Support Guide - - - - - - + - - - + + - + + + - - + +
          +
          - + +

          Shorewall Support Guide -

          -
          - -

          While I don't answer Shorewall  questions - emailed directly to me, I try to spend some time each day answering questions - on the Shorewall Users Mailing List and on the Support Forum.

          - -

          -Tom Eastep

          - -

          Before Reporting a Problem

          - "Well at least you tried to read the documentation, which is a lot - more than some people on this list appear to do."
          -
          - -
          - Wietse Venema - On the Postfix mailing list
          -
          -
          - There are a number of sources - for problem solution information. Please try these before you -post. -

          - -

          - + +

          Before Reporting a Problem or Asking a Question
          +

          + There are a number +of sources of Shorewall information. Please try these before you post. + + - -

          - - - -

          - -
            -
          • The Errata has links to download updated - components.
            • - -
          - -

          - -
            -
          • The Mailing -List Archives search facility can locate posts about similar - problems:
            • - -
          - -

          - -

          Mailing List Archive Search

          - -
          + a number of tips to help you solve common problems. +
          • - -

          Match: - - - Format: +

        • The Errata has links to download updated + components.
          • - - - Sort by: - - - -
          - Search: -

          - - -

          Problem Reporting Guidelines

          - "Let me see if I can translate your message into a -real-world example. It would be like saying that you have three -rooms at home, and when you walk into one of the rooms, you detect -this strange smell. Can anyone tell you what that strange smell is?
          -
          - Now, all of us could do some wonderful guessing as to -the smell and even what's causing it. You would be absolutely amazed - at the range and variety of smells we could come up with. Even more - amazing is that all of the explanations for the smells would be completely - plausible."
          -
          - -
          - Russell Mosemann on the Postfix mailing list
          -
          -
          - - -

          - -
            -
          • Please remember we only know what is posted in your message. - Do not leave out any information that appears to be correct, or was - mentioned in a previous post. There have been countless posts by people - who were sure that some part of their configuration was correct when - it actually contained a small error. We tend to be skeptics where detail - is lacking.
            -
            -
            • -
          • Please keep in mind that you're asking for free - technical support. Any help we offer is an act of generosity, not -an obligation. Try to make it easy for us to help you. Follow good, -courteous practices in writing and formatting your e-mail. Provide -details that we need if you expect good answers. Exact quoting -of error messages, log entries, command output, and other output is better -than a paraphrase or summary.
            -
            -
            • -
          • Please don't describe - your environment and then ask us to send you custom - configuration files. We're here to answer your questions but - we can't do your job for you.
            -
            -
            • -
          • When reporting a problem, ALWAYS include - this information:
            • - +
          • The Site and Mailing + List Archives search facility can locate documents and posts + about similar problems:
            • +
          - + + +

          Site and Mailing List Archive Search

          + +
          +
          Match: + + + Format: + + Sort by: + + Include Mailing + List Archives: + +
          + Search:
          +
          +
          + +

          Problem Reporting Guidelines
          +

          + +
            - +
          • Please remember we only know what is posted +in your message. Do not leave out any information that appears to +be correct, or was mentioned in a previous post. There have been +countless posts by people who were sure that some part of their + configuration was correct when it actually contained a small error. + We tend to be skeptics where detail is lacking.
            +
            +
            • +
          • Please keep in mind that you're asking for + free technical support. Any help we offer +is an act of generosity, not an obligation. Try to make it easy +for us to help you. Follow good, courteous practices in writing +and formatting your e-mail. Provide details that we need if you expect +good answers. Exact quoting of error messages, log entries, + command output, and other output is better than a paraphrase or summary.
            +
            +
            • +
          • Please don't + describe your environment and then ask us to send you + custom configuration files. We're here to answer your +questions but we can't do your job for you.
            +
            +
            • +
          • When reporting a problem, ALWAYS + include this information:
            • + +
          + +
            + +
              -
            • the exact version of Shorewall you are running.
              -
              - shorewall version
              -
              -
              • - +
            • the exact version of Shorewall you are running.
              +
              + shorewall version
              +
              +
              • + +
            - + +
              -
            • the exact kernel version you are running
              -
              - uname -a
              -
              -
              • - +
            • the exact kernel version you are running
              +
              + uname -a
              +
              +
              • + +
            - + +
              -
            • the complete, exact output of
              -
              - ip addr show
              -
              -
              • - +
            • the complete, exact output of
              +
              + ip addr show
              +
              +
              • + +
            - + +
              -
            • the complete, exact output of
              -
              - ip route show
              -
              -
              • - +
            • the complete, exact output of
              +
              + ip route show
              +
              +
              • + +
            - + +
              -
            • If your kernel is modularized, the exact output from
              -
              - lsmod
              -
              -
              • -
            • the exact wording of any If your kernel is modularized, the exact +output from
              +
              + lsmod
              +
              +
              • +
            • the exact wording of any ping failure responses
              -
              -
              • -
            • If you installed Shorewall using one of the QuickStart Guides, - please indicate which one.
              -
              -
              • -
            • If you are running Shorewall under Mandrake using the Mandrake - installation of Shorewall, please say so.
              -
              -
              • - +
              + +
            • If you installed Shorewall using one of the QuickStart + Guides, please indicate which one.
              +
              +
              • +
            • If you are running Shorewall under Mandrake using + the Mandrake installation of Shorewall, please say so.
              +
              +
              • + +
            - +
          - +
            -
          • NEVER include the output of "NEVER include the output of "iptables -L". Instead, if you are having connection problems of - any kind then:
            -
            - 1. /sbin/shorewall/reset
            -
            - 2. Try the connection that is failing.
            -
            - 3. /sbin/shorewall status > /tmp/status.txt
            -
            - 4. Post the /tmp/status.txt file as an attachment.
            -
            -
            • -
          • As a general matter, please do not edit the diagnostic - information in an attempt to conceal your IP address, netmask, - nameserver addresses, domain name, etc. These aren't secrets, and concealing - them often misleads us (and 80% of the time, a hacker could derive -them anyway from information contained in the SMTP headers of your post).
            • - + any kind then:
            +
            + 1. /sbin/shorewall/reset
            +
            + 2. Try the connection that is failing.
            +
            + 3. /sbin/shorewall status > /tmp/status.txt
            +
            + 4. Post the /tmp/status.txt file as an attachment.
            +
            + +
          • As a general + matter, please do not edit the diagnostic information + in an attempt to conceal your IP address, netmask, nameserver addresses, + domain name, etc. These aren't secrets, and concealing them often + misleads us (and 80% of the time, a hacker could derive them anyway + from information contained in the SMTP headers of your post).
            +
            +
            • +
          • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when + you exercise the function that is giving you problems? If so, include + the message(s) in your post along with a copy of your /etc/shorewall/interfaces + file.
            +
            +
            • +
          • Please include any of the Shorewall configuration files + (especially the /etc/shorewall/hosts file if you have + modified that file) that you think are relevant. If you + include /etc/shorewall/rules, please include /etc/shorewall/policy + as well (rules are meaningless unless one also knows the policies).
            +
            +
            • +
          • If an error occurs when you try to "shorewall start", include a + trace (See the Troubleshooting + section for instructions).
            +
            +
            • +
          • The list server limits posts to 120kb so don't post GIFs + of your network layout, etc. to the Mailing +List -- your post will be rejected.
            • +
          - -
            - -
          - -

          - -
            - -
          - -

          - -
            -
          • Do you see -any "Shorewall" messages ("/sbin/shorewall -show log") when you exercise the function that -is giving you problems? If so, include the message(s) in your post -along with a copy of your /etc/shorewall/interfaces file.
            -
            -
            • -
          • Please include any of the Shorewall configuration files - (especially the /etc/shorewall/hosts file if you have -modified that file) that you think are relevant. If you -include /etc/shorewall/rules, please include /etc/shorewall/policy -as well (rules are meaningless unless one also knows the policies). -
            • - -
          - -

          - -
            - -
          - -

          - -
            -
          • If an error occurs - when you try to "shorewall start", - include a trace (See the Troubleshooting - section for instructions).
            • - -
          - -

          - -
            -
          • - -

            The list server limits posts to 120kb so don't post GIFs of - your network layout, etc. to the Mailing List -- your - post will be rejected.

            -
            • - -
          - The author gratefully acknowleges that the above list was heavily - plagiarized from the excellent LEAF document by Ray Olszewski - found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
          - -

          Please post in plain text

          - -
          - A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist -shorewall.net "for continuous abuse" because it has been my policy to -allow HTML in list posts!!
          -
          - I think that blocking all HTML is a Draconian way to control - spam and that the ultimate losers here are not the spammers but the - list subscribers whose MTAs are bouncing all shorewall.net mail. As - one list subscriber wrote to me privately "These e-mail admin's need -to get a (expletive deleted) life instead of trying to rid the planet -of HTML based e-mail". Nevertheless, to allow subscribers to receive list -posts as must as possible, I have now configured the list server at shorewall.net -to strip all HTML from outgoing posts.
          - -

          Where to Send your Problem Report or to Ask for Help

          -
          - + + + +The author gratefully acknowleges that the above list was heavily +plagiarized from the excellent LEAF document by Ray Olszewski + found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
          +
          + +

          When using the mailing list, please post in plain text

          + +
          + A growing number of MTAs serving list subscribers are rejecting + all HTML traffic. At least one MTA has gone so far as to blacklist + shorewall.net "for continuous abuse" because it has been my policy + to allow HTML in list posts!!
          +
          + I think that blocking all HTML is a Draconian + way to control spam and that the ultimate losers here are not +the spammers but the list subscribers whose MTAs are bouncing +all shorewall.net mail. As one list subscriber wrote to me privately + "These e-mail admin's need to get a (expletive deleted) life + instead of trying to rid the planet of HTML based e-mail". Nevertheless, + to allow subscribers to receive list posts as must as possible, I have + now configured the list server at shorewall.net to strip all HTML +from outgoing posts.
          +
          + + +

          Where to Send your Problem Report or to Ask for Help

          + + +
          +

          If you run Shorewall under Bering -- please post your question or problem - to the LEAF Users - mailing list.

          - If you run Shorewall under MandrakeSoft Multi Network - Firewall (MNF) and you have not purchased an MNF license from MandrakeSoft - then you can post non MNF-specific Shorewall questions to the Shorewall users mailing - list or to the Shorewall Support -Forum. Do not expect to get free MNF support on the list or forum.
          + to the LEAF + Users mailing list. + If you run Shorewall under MandrakeSoft Multi + Network Firewall (MNF) and you have not purchased an MNF license + from MandrakeSoft then you can post non MNF-specific Shorewall questions + to the Shorewall + users mailing list. Do not expect to get free MNF support +on the list or forum.
          - +

          Otherwise, please post your question or problem to the Shorewall users mailing - list or to the Shorewall Support -Forum.

          -
          + list.

          + -

          The Shorewall List Server provides additional information about Shorewall Mailing Lists.
          -

          + +

          To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users + .
          +

          + +

          For information on other Shorewall mailing lists, go to http://lists.shorewall.net/mailing_list.htm
          +

          - -

          Last Updated 3/6/2003 - Tom Eastep

          + +

          Last Updated 3/14/2003 - Tom Eastep

          - +

          Copyright © 2001, 2002, 2003 Thomas M. Eastep.

          -
          +

          diff --git a/STABLE/documentation/three-interface.htm b/STABLE/documentation/three-interface.htm index 2d1310098..976cb8b33 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,1215 +1,1222 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
          - +
          +

          Three-Interface Firewall

          -
          - +

          Version 2.0.1

          - -

          Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the basics - and follow the documentation.

          - -

          This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in one of its more popular configurations:

          - + +

          Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the +basics and follow the documentation.

          + +

          This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its more popular configurations:

          +
            -
          • Linux system used as a firewall/router for a small local +
          • Linux system used as a firewall/router for a small local network.
            • -
          • Single public IP address.
            • -
          • DMZ connected to a separate ethernet interface.
            • -
          • Connection through DSL, Cable Modem, ISDN, Frame Relay, - dial-up, ...
            • - +
          • Single public IP address.
            • +
          • DMZ connected to a separate ethernet interface.
            • +
          • Connection through DSL, Cable Modem, ISDN, Frame Relay, + dial-up, ...
            • +
          - +

          Here is a schematic of a typical installation.

          - +

          -

          - -

          This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell - if this package is installed by the presence of an ip program - on your firewall system. As root, you can use the 'which' command to -check for this program:

          - -
               [root@gateway root]# which ip
               /sbin/ip
               [root@gateway root]#
          - -

          I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are -flagged with - . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo)

          + +

          Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can +tell if this package is installed by the presence of an ip program + on your firewall system. As root, you can use the 'which' command to + check for this program:

          + +
               [root@gateway root]# which ip
               /sbin/ip
               [root@gateway root]#
          +

          I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are + flagged with + . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo) +

          +

          -     If you edit your configuration files on a Windows system, - you must save them as Unix files if your editor supports that option - or you must run them through dos2unix before trying to use them. Similarly, - if you copy a configuration file from your Windows hard drive to a floppy - disk, you must run dos2unix against the copy before using it with Shorewall.

          - +     If you edit your configuration files on a Windows system, + you must save them as Unix files if your editor supports that option + or you must run them through dos2unix before trying to use them. Similarly, + if you copy a configuration file from your Windows hard drive to a +floppy disk, you must run dos2unix against the copy before using it with +Shorewall.

          + - +

          Shorewall Concepts

          - +

          -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you will only need to deal with a -few of these as described in this guide. After you have installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy - the files to /etc/shorewall (the files will replace files with the same - names that were placed in /etc/shorewall when Shorewall was installed).

          - -

          As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

          - -

          Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, the - following zone names are used:

          - + href="/pub/shorewall/LATEST.samples/three-interfaces.tgz">three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy + the files to /etc/shorewall (the files will replace files with the +same names that were placed in /etc/shorewall when Shorewall was installed).

          + +

          As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration +instructions and default entries.

          + +

          Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, +the following zone names are used:

          + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
          NameDescription
          NameDescription
          netThe Internet
          locYour Local Network
          dmzDemilitarized Zone
          netThe Internet
          locYour Local Network
          dmzDemilitarized Zone
          - +

          Zone names are defined in /etc/shorewall/zones.

          - -

          Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

          - -

          Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

          - + +

          Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

          + +

          Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

          +
            -
          • You express your default policy for connections from +
          • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
            • -
          • You define exceptions to those default policies in the +
          • You define exceptions to those default policies in the /etc/shorewall/rules file.
            • - +
          - -

          For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  - the request is first checked against the rules in /etc/shorewall/common - (the samples provide that file for you).

          - -

          The /etc/shorewall/policy file included with the three-interface sample - has the following policies:

          - -
          + +

          For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that +file matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or +DROP  the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

          + +

          The /etc/shorewall/policy file included with the three-interface sample + has the following policies:

          + +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          -
          - -
          -

          In the three-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

          - - - - - - - - - - - - - - - - - - - - -
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          fwnetACCEPT  
          -
          - -

          The above policy will:

          - -
            -
          1. allow all connection requests from your local network -to the internet
            2. -
          2. drop (ignore) all connection requests from the internet - to your firewall or local network
            3. -
          3. optionally accept all connection requests from the firewall - to the internet (if you uncomment the additional policy)
            4. -
          4. reject all other connection requests.
            5. - -
          - -

          -     At this point, edit your /etc/shorewall/policy file and -make any changes that you wish.

          - -

          Network Interfaces

          - -

          -

          - -

          The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., - eth0)  unless you connect via Point-to-Point - Protocol over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect via - a regular modem, your External Interface will also be ppp0. If -you connect using ISDN, you external interface will be ippp0.

          - -

          -     If your external interface is ppp0 or ippp0 then - you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

          - -

          Your Local Interface will be an ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local -computers will be connected to the same switch (note: If you have only -a single local system, you can connect the firewall directly to the computer -using a cross-over cable).

          - -

          Your DMZ Interface will also be an ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your - DMZ computers will be connected to the same switch (note: If you have - only a single DMZ system, you can connect the firewall directly to the - computer using a cross-over cable).

          - -

          - Do not connect more than one interface to the same -hub or switch (even for testing). It won't work the way that you expect - it to and you will end up confused and believing that Shorewall doesn't - work at all.

          - -

          -     The Shorewall three-interface sample configuration assumes - that the external interface is eth0, the local interface is eth1 - and the DMZ interface is eth2. If your configuration is -different, you will have to modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the list - of options that are specified for the interfaces. Some hints:

          - -
            -
          • - -

            If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

            -
            • -
          • - -

            If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the - option list.

            -
            • - -
          - -

          IP Addresses

          - -

          Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you -a single Public IP address. This address may be assigned via the - Dynamic Host Configuration Protocol (DHCP) or as part of establishing - your connection when you dial in (standard modem) or establish your PPP - connection. In rare cases, your ISP may assign you a static IP -address; that means that you configure your firewall's external interface - to use that address permanently. Regardless of how the address is - assigned, it will be shared by all of your systems when you access the -Internet. You will have to assign your own addresses for your internal network -(the local and DMZ Interfaces on your firewall plus your other computers). -RFC 1918 reserves several Private IP address ranges for this purpose:

          - -
          -
               10.0.0.0    - 10.255.255.255
               172.16.0.0  - 172.31.255.255
               192.168.0.0 - 192.168.255.255
          -
          - -
          -

          -     Before starting Shorewall, you should look at the IP -address of your external interface and if it is one of the above -ranges, you should remove the 'norfc1918' option from the external -interface's entry in /etc/shorewall/interfaces.

          -
          - -
          -

          You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another - subnet. For our purposes, we can consider a subnet to consists of -a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a -Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved -as the Subnet Address and x.y.z.255 is reserved as the Subnet -Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive "1" bits from - the left of the subnet mask.

          -
          - -
          -

          Example sub-network:

          -
          - -
          -
          - - - - - - + - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + - - -
          Range:10.10.10.0 - 10.10.10.255
          Subnet Address:10.10.10.0
          Broadcast Address:10.10.10.255
          CIDR Notation:10.10.10.0/24
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          -
          -
          - -
          -

          It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

          -
          - -
          -

          One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

          -
          - -
          -

          -     Your local computers (Local Computers 1 & 2) should - be configured with their default gateway set to the IP address - of the firewall's internal interface and your DMZ computers ( DMZ -Computers 1 & 2) should be configured with their default gateway -set to the IP address of the firewall's DMZ interface.  

          -
          - -

          The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning - more about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

          - -

          The remainder of this quide will assume that you have configured - your network as shown here:

          - -

          -

          - -

          The default gateway for the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.
          -

          - -

          -     WARNING: Your ISP  might assign -your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 -subnet then you will need to select a DIFFERENT RFC 1918 subnet for your -local network and if it is in the 10.10.11.0/24 subnet then you will need -to select a different RFC 1918 subnet for your DMZ.
          -

          - -

          IP Masquerading (SNAT)

          - -

          The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one - of your local systems (let's assume local computer 1) sends a connection - request to an internet host, the firewall must perform Network Address - Translation (NAT). The firewall rewrites the source address in the - packet to be the address of the firewall's external interface; in other - words, the firewall makes it look as if the firewall itself is initiating - the connection.  This is necessary so that the destination host will be - able to route return packets back to the firewall (remember that packets - whose destination address is reserved by RFC 1918 can't be routed accross - the internet). When the firewall receives a return packet, it rewrites - the destination address back to 10.10.10.1 and forwards the packet on - to local computer 1.

          - -

          On Linux systems, the above process is often referred to as - IP Masquerading and you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

          - -
            -
          • - -

            Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

            -
            • -
          • -

            SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

            -
            • - -
          - -

          In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

          - -

          -     If your external firewall interface is eth0, your -local interface eth1 and your DMZ interface is eth2 then -you do not need to modify the file provided with the sample. Otherwise, -edit /etc/shorewall/masq and change it to match your configuration.

          - -

          -     If your external IP is static, you can enter it in the -third column in the /etc/shorewall/masq entry if you like although -your firewall will work fine if you leave that column empty. Entering -your static IP in column 3 makes
          - processing outgoing packets a little more efficient.
          -

          - -

          -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
          -

          - -
            -
          • NAT_ENABLED=Yes
            • -
          • IP_FORWARDING=On
            -
            • - -
          - -

          Port Forwarding (DNAT)

          - -

          One of your goals will be to run one or more servers on your - DMZ computers. Because these computers have RFC-1918 addresses, it is - not possible for clients on the internet to connect directly to them. - It is rather necessary for those clients to address their connection -requests to your firewall who rewrites the destination address to the -address of your server and forwards the packet to that server. When your -server responds, the firewall automatically performs SNAT to rewrite -the source address in the response.

          - -

          The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure -port forwarding using DNAT rules in the /etc/shorewall/rules file.

          - -

          The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>  
          -
          - -

          If you don't specify the <server port>, it is assumed to be -the same as <port>.

          - -

          Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
          ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
          -
          - -

          A couple of important points to keep in mind:

          - -
            -
          • When you are connecting to your server from your local - systems, you must use the server's internal IP address (10.10.11.2).
            • -
          • Many ISPs block incoming connection requests to port -80. If you have problems connecting to your web server, try the -following rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
            • - -
          - -
          - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:10.10.11.2:80tcp5000  
          -
          - -

          If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can - replace the loc->dmz rule above with:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:10.10.11.2:80tcp80-<external IP>
          -
          - -

          If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows -(assume that your external interface is eth0):

          - -
            -
          1. Include the following in /etc/shorewall/params:
            -
            - ETH0_IP=`find_interface_address eth0`
            -  
            2. -
          2. Make your loc->dmz rule:
            3. - -
          - -
          - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATloc
          -           		dmz:10.10.11.2:80tcp80-$ETH0_IP
          -
          - -

          If you want to access your server from the DMZ using your external IP -address, see FAQ 2a.

          - -

          -     At this point, add the DNAT and ACCEPT rules for your servers. -

          - -

          Domain Name Server (DNS)

          - -

          Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver - will be automatically configured (e.g., the /etc/resolv.conf file will - be written). Alternatively, your ISP may have given you the IP address - of a pair of DNS name servers for you to manually configure as -your primary and secondary name servers. It is your responsibility - to configure the resolver in your internal systems. You can take one -of two approaches:

          - -
            -
          • - -

            You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers -or if those addresses are available on their web site, you can configure - your internal systems to use those addresses. If that information -isn't available, look in /etc/resolv.conf on your firewall system -- -the name servers are given in "nameserver" records in that file.

            -
            • -
          • - -

            -     You can configure a Caching Name Server on your - firewall or in your DMZ. Red Hat has an RPM for a caching name - server (which also requires the 'bind' RPM) and for Bering users, - there is dnscache.lrp. If you take this approach, you configure your - internal systems to use the caching name server as their primary (and - only) name server. You use the internal IP address of the firewall -(10.10.10.254 in the example above) for the name server address if -you choose to run the name server on your firewall. To allow your local -systems to talk to your caching name server, you must open port 53 -(both UDP and TCP) from the local network to the server; you do that -by adding the rules in /etc/shorewall/rules.

            -
            • - -
          - -
          -

          If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp53  
          ACCEPTlocfwudp53  
          ACCEPTdmzfwtcp53  
          ACCEPTdmzfwudp53  
          -

          -
          - -
          -
          -

          Run name server on DMZ computer 1

          +
          + +
          +

          In the three-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

          - + id="AutoNumber3"> + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + - - + +
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocdmz:10.10.11.1tcp53  
          ACCEPTlocdmz:10.10.11.1udp53  
          ACCEPTfwdmz:10.10.10.1tcp53  
          ACCEPTfwdmz:10.10.10.1udp53  
          fwnetACCEPT  
          -
          -
          +
          + +

          The above policy will:

          + +
            +
          1. allow all connection requests from your local network + to the internet
            2. +
          2. drop (ignore) all connection requests from the internet + to your firewall or local network
            3. +
          3. optionally accept all connection requests from the firewall + to the internet (if you uncomment the additional policy)
            4. +
          4. reject all other connection requests.
            5. + +
          + +

          +     At this point, edit your /etc/shorewall/policy file and + make any changes that you wish.

          + +

          Network Interfaces

          + +

          +

          + +

          The firewall has three network interfaces. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter that is connected to that "Modem" (e.g., + eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect +via a regular modem, your External Interface will also be ppp0. +If you connect using ISDN, you external interface will be ippp0.

          + +

          +     If your external interface is ppp0 or ippp0 +then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

          + +

          Your Local Interface will be an ethernet adapter (eth0, + eth1 or eth2) and will be connected to a hub or switch. Your local + computers will be connected to the same switch (note: If you have +only a single local system, you can connect the firewall directly to +the computer using a cross-over cable).

          + +

          Your DMZ Interface will also be an ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your + DMZ computers will be connected to the same switch (note: If you have + only a single DMZ system, you can connect the firewall directly to the + computer using a cross-over cable).

          + +

          + Do not connect more than one interface to the same +hub or switch (even for testing). It won't work the way that you expect + it to and you will end up confused and believing that Shorewall doesn't + work at all.

          + +

          +     The Shorewall three-interface sample configuration assumes + that the external interface is eth0, the local interface is +eth1 and the DMZ interface is eth2. If your configuration +is different, you will have to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list + of options that are specified for the interfaces. Some hints:

          + +
            +
          • + +

            If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

            +
            • +
          • + +

            If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from +the option list.

            +
            • -
            +
          + +

          IP Addresses

          + +

          Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via +the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. Regardless of how the address +is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses for your internal +network (the local and DMZ Interfaces on your firewall plus your other +computers). RFC 1918 reserves several Private IP address ranges for +this purpose:

          + +
          +
               10.0.0.0    - 10.255.255.255
               172.16.0.0  - 172.31.255.255
               192.168.0.0 - 192.168.255.255
          +
          + +
          +

          +     Before starting Shorewall, you should look at the IP +address of your external interface and if it is one of the above +ranges, you should remove the 'norfc1918' option from the external +interface's entry in /etc/shorewall/interfaces.

          +
          + +
          +

          You will want to assign your local addresses from one + sub-network or subnet and your DMZ addresses from another + subnet. For our purposes, we can consider a subnet to consists of +a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a +Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved as + the Subnet Address and x.y.z.255 is reserved as the Subnet +Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits from + the left of the subnet mask.

          +
          + +
          +

          Example sub-network:

          +
          + +
          +
          + + + + + + + + + + + + + + + + + + + + + +
          Range:10.10.10.0 - 10.10.10.255
          Subnet Address:10.10.10.0
          Broadcast Address:10.10.10.255
          CIDR Notation:10.10.10.0/24
          +
          +
          + +
          +

          It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above +example) or the last usable address (10.10.10.254).

          +
          + +
          +

          One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

          +
          + +
          +

          +     Your local computers (Local Computers 1 & 2) should + be configured with their default gateway set to the IP address + of the firewall's internal interface and your DMZ computers ( DMZ + Computers 1 & 2) should be configured with their default gateway + set to the IP address of the firewall's DMZ interface.  

          +
          + +

          The foregoing short discussion barely scratches the surface + regarding subnetting and routing. If you are interested in learning + more about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", +Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

          + +

          The remainder of this quide will assume that you have configured + your network as shown here:

          + +

          +

          + +

          The default gateway for the DMZ computers would be 10.10.11.254 + and the default gateway for the Local computers would be 10.10.10.254.
          +

          + +

          +     WARNING: Your ISP  might assign + your external interface an RFC 1918 address. If that address is in the +10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918 +subnet for your local network and if it is in the 10.10.11.0/24 subnet then +you will need to select a different RFC 1918 subnet for your DMZ.
          +

          + +

          IP Masquerading (SNAT)

          + +

          The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When one + of your local systems (let's assume local computer 1) sends a connection + request to an internet host, the firewall must perform Network Address + Translation (NAT). The firewall rewrites the source address in +the packet to be the address of the firewall's external interface; in +other words, the firewall makes it look as if the firewall itself is +initiating the connection.  This is necessary so that the destination +host will be able to route return packets back to the firewall (remember +that packets whose destination address is reserved by RFC 1918 can't + be routed accross the internet). When the firewall receives a return +packet, it rewrites the destination address back to 10.10.10.1 and +forwards the packet on to local computer 1.

          + +

          On Linux systems, the above process is often referred to +as IP Masquerading and you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

          + +
            +
          • + +

            Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

            +
            • +
          • + +

            SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

            +
            • + +
          + +

          In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

          + +

          +     If your external firewall interface is eth0, your + local interface eth1 and your DMZ interface is eth2 +then you do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change it to match your configuration.

          + +

          +     If your external IP is static, you can enter it in the +third column in the /etc/shorewall/masq entry if you like although +your firewall will work fine if you leave that column empty. Entering +your static IP in column 3 makes
          + processing outgoing packets a little more efficient.
          +

          + +

          +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
          +

          + +
            +
          • NAT_ENABLED=Yes
            • +
          • IP_FORWARDING=On
            +
            • + +
          + +

          Port Forwarding (DNAT)

          + +

          One of your goals will be to run one or more servers on your + DMZ computers. Because these computers have RFC-1918 addresses, it +is not possible for clients on the internet to connect directly to +them. It is rather necessary for those clients to address their connection + requests to your firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When your + server responds, the firewall automatically performs SNAT to rewrite + the source address in the response.

          + +

          The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

          + +

          The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

          + +
          + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:<server local ip address> [:<server + port>]<protocol><port>  
          +
          + +

          If you don't specify the <server port>, it is assumed to +be the same as <port>.

          + +

          Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

          + +
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
          ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
          +
          + +

          A couple of important points to keep in mind:

          + +
            +
          • When you are connecting to your server from your local + systems, you must use the server's internal IP address (10.10.11.2).
            • +
          • Many ISPs block incoming connection requests to port +80. If you have problems connecting to your web server, try the following + rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
            • + +
          + +
          + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:10.10.11.2:80tcp5000  
          +
          + +

          If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you +can replace the loc->dmz rule above with:

          + +
          + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetdmz:10.10.11.2:80tcp80-<external IP>
          +
          + +

          If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows + (assume that your external interface is eth0):

          + +
            +
          1. Include the following in /etc/shorewall/params:
            +
            + ETH0_IP=`find_interface_address eth0`
            +  
            2. +
          2. Make your loc->dmz rule:
            3. + +
          + +
          + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATloc
          +           		dmz:10.10.11.2:80tcp80-$ETH0_IP
          +
          + +

          If you want to access your server from the DMZ using your external IP + address, see FAQ 2a.

          + +

          +     At this point, add the DNAT and ACCEPT rules for your +servers.

          + +

          Domain Name Server (DNS)

          + +

          Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver + will be automatically configured (e.g., the /etc/resolv.conf file +will be written). Alternatively, your ISP may have given you the IP +address of a pair of DNS name servers for you to manually configure +as your primary and secondary name servers. It is your responsibility + to configure the resolver in your internal systems. You can take one + of two approaches:

          + +
            +
          • + +

            You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system +-- the name servers are given in "nameserver" records in that file. +

            +
            • +
          • + +

            +     You can configure a Caching Name Server on your + firewall or in your DMZ. Red Hat has an RPM for a caching +name server (which also requires the 'bind' RPM) and for Bering +users, there is dnscache.lrp. If you take this approach, you configure +your internal systems to use the caching name server as their primary +(and only) name server. You use the internal IP address of the firewall +(10.10.10.254 in the example above) for the name server address if +you choose to run the name server on your firewall. To allow your local +systems to talk to your caching name server, you must open port 53 +(both UDP and TCP) from the local network to the server; you do that +by adding the rules in /etc/shorewall/rules.

            +
            • + +
          + +
          +

          If you run the name server on the firewall: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp53  
          ACCEPTlocfwudp53  
          ACCEPTdmzfwtcp53  
          ACCEPTdmzfwudp53  
          +

          +
          + +
          +
          +

          Run name server on DMZ computer 1

          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocdmz:10.10.11.1tcp53  
          ACCEPTlocdmz:10.10.11.1udp53  
          ACCEPTfwdmz:10.10.10.1tcp53  
          ACCEPTfwdmz:10.10.10.1udp53  
          +
          +
          + +

          Other Connections

          -
          - -
          +
          + +

          The three-interface sample includes the following rules:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTfwnetudp53  
          ACCEPTfwnettcp53  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTfwnetudp53  
          ACCEPTfwnettcp53  
          -
          + +
          + +
          +

          Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy +allowing all connections from the firewall to the internet.

          - -
          -

          Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

          -
          - -
          + +

          The sample also includes:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp22  
          ACCEPTlocdmztcp22  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp22  
          ACCEPTlocdmztcp22  
          -
          + +
          + +
          +

          That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers + from your local systems.

          - -
          -

          That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers - from your local systems.

          -
          - -
          -

          If you wish to enable other connections between your systems, - the general format is:

          -
          - -
          -
          + +
          +

          If you wish to enable other connections between your systems, + the general format is:

          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPT<source zone><destination zone><protocol><port>  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPT<source zone><destination zone><protocol><port>  
          -
          +
          +
          + +
          +

          Example - You want to run a publicly-available DNS server + on your firewall system:

          - -
          -

          Example - You want to run a publicly-available DNS server - on your firewall system:

          -
          - -
          -
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
          ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
          ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
          -
          +
          +
          + +
          +

          Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

          - -
          -

          Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

          -
          - -
          -

          If you don't know what port and protocol a particular application -uses, look here.

          -
          - -
          -

          Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you - want shell access to your firewall from the internet, use SSH:

          -
          - -
          -
          + +
          +

          If you don't know what port and protocol a particular +application uses, look here.

          +
          + +
          +

          Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you + want shell access to your firewall from the internet, use SSH:

          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp22  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp22  
          -
          -
          - -
          +
          +
          + +

          +

          (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     Bering users will want to add the following two rules to be compatible with Jacques's Shorewall configuration.
          -

          -
          -
          +

          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTloc
          -           		fwudp
          -           		53
          -           		#Allow DNS Cache towork
          -
          ACCEPTlocfwtcp80#Allow weblet to work
          -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTloc
          +           		fwudp
          +           		53
          +           		#Allow DNS Cache towork
          +
          ACCEPTlocfwtcp80#Allow weblet to work
          +
          -
          -
          +
          +
          +

          -     Now modify /etc/shorewall/rules to add or remove other +     Now modify /etc/shorewall/rules to add or remove other connections as required.

          -
          - -
          -

          Starting and Stopping Your Firewall

          - -
          + +
          +

          Starting and Stopping Your Firewall

          +
          + +

          Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
          -

          - +

          +

          IMPORTANT: Users of the .deb package must edit /etc/default/shorewall + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
          -

          +

          +
          + +
          +

          The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" +command. If you want to totally remove any trace of Shorewall from +your Netfilter configuration, use "shorewall clear".

          - -
          -

          The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

          -
          - -
          + +

          -     The three-interface sample assumes that you want to enable - routing to/from eth1 (your local network) and eth2 (DMZ) - when Shorewall is stopped. If these two interfaces don't connect -to your local network and DMZ or if you want to enable a different +     The three-interface sample assumes that you want to enable + routing to/from eth1 (your local network) and eth2 (DMZ) + when Shorewall is stopped. If these two interfaces don't connect +to your local network and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped accordingly.

          -
          - -
          -

          WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you -have added an entry for the IP address that you are connected from -to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the + +

          - -

          Last updated 1/30/2003 - + +

          Last updated 2/21/2003 - Tom Eastep

          - -

          Copyright 2002, 2003 + +

          Copyright 2002, 2003 Thomas M. Eastep

          -
          +
          +



          diff --git a/STABLE/documentation/traffic_shaping.htm b/STABLE/documentation/traffic_shaping.htm index 9f4a40dbb..cbc5ea160 100644 --- a/STABLE/documentation/traffic_shaping.htm +++ b/STABLE/documentation/traffic_shaping.htm @@ -1,331 +1,339 @@ - + - + - + - + Traffic Shaping - + - - - + + - - - + + + +
          - +
          + +

          Traffic Shaping/Control

          -
          - -

          Beginning with version 1.2.0, Shorewall has limited support - for traffic shaping/control. In order to use traffic shaping under Shorewall, - it is essential that you get a copy of the Linux Advanced Routing and Shaping HOWTO, - version 0.3.0 or later. You must also install the iproute (iproute2) -package to provide the "ip" and "tc" utilities.

          - + +

          Shorewall has limited support for traffic shaping/control. + In order to use traffic shaping under Shorewall, it is essential that + you get a copy of the Linux Advanced Routing + and Shaping HOWTO, version 0.3.0 or later.

          +

          Shorewall traffic shaping support consists of the following:

          - +
            -
          • A new TC_ENABLED parameter in /etc/shorewall.conf. - Traffic Shaping also requires that you enable packet mangling.
            • -
          • A new CLEAR_TC parameter in /etc/shorewall.conf (Added in -Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the -setting of this variable determines whether Shorewall clears the traffic -shaping configuration during Shorewall [re]start and Shorewall stop.
            -
            • -
          • /etc/shorewall/tcrules - A file where you can specify - firewall marking of packets. The firewall mark value may be used -to classify packets for traffic shaping/control.
            -
            • -
          • /etc/shorewall/tcstart - A user-supplied file that - is sourced by Shorewall during "shorewall start" and which you can - use to define your traffic shaping disciplines and classes. I have - provided a sample - that does table-driven CBQ shaping but if you read the traffic shaping - sections of the HOWTO mentioned above, you can probably code your - own faster than you can learn how to use my sample. I personally -use HTB (see -below). HTB support may eventually become an integral part of Shorewall +
          • A new TC_ENABLED parameter in /etc/shorewall.conf. + Traffic Shaping also requires that you enable packet mangling.
            • +
          • A new CLEAR_TC parameter in /etc/shorewall.conf (Added +in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), +the setting of this variable determines whether Shorewall clears the traffic + shaping configuration during Shorewall [re]start and Shorewall stop.
            +
            • +
          • /etc/shorewall/tcrules - A file where you can + specify firewall marking of packets. The firewall mark value may + be used to classify packets for traffic shaping/control.
            +
            • +
          • /etc/shorewall/tcstart - A user-supplied file + that is sourced by Shorewall during "shorewall start" and which + you can use to define your traffic shaping disciplines and classes. + I have provided a sample that does + table-driven CBQ shaping but if you read the traffic shaping sections + of the HOWTO mentioned above, you can probably code your own faster + than you can learn how to use my sample. I personally use HTB (see below). +HTB support may eventually become an integral part of Shorewall since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20, HTB is a standard part of the kernel but iproute2 must be patched in order to use it.
            -
            - In tcstart, when you want to run the 'tc' utility, use the - run_tc function supplied by shorewall if you want tc errors to stop - the firewall.
            -
            - You can generally use off-the-shelf traffic shaping scripts by simply - copying them to /etc/shorewall/tcstart. I use + In tcstart, when you want to run the 'tc' utility, use + the run_tc function supplied by shorewall if you want tc errors + to stop the firewall.
            +
            + You can generally use off-the-shelf traffic shaping scripts by +simply copying them to /etc/shorewall/tcstart. I use             The Wonder Shaper (HTB version) - that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and - modified it according to the Wonder Shaper README). WARNING: If -you use use Masquerading or SNAT (i.e., you only have one external IP address) - then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb] - script won't work. Traffic shaping occurs after SNAT has already been applied - so when traffic shaping happens, all outbound traffic will have as a source - address the IP addresss of your firewall's external interface.
            -
            • -
          • /etc/shorewall/tcclear - A user-supplied file that - is sourced by Shorewall when it is clearing traffic shaping. This - file is normally not required as Shorewall's method of clearing qdisc - and filter definitions is pretty general.
            • - + that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart +and modified it according to the Wonder Shaper README). WARNING: If + you use use Masquerading or SNAT (i.e., you only have one external IP address) + then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb] + script won't work. Traffic shaping occurs after SNAT has already been +applied so when traffic shaping happens, all outbound traffic will have +as a source address the IP addresss of your firewall's external interface.
            + +
          • /etc/shorewall/tcclear - A user-supplied file + that is sourced by Shorewall when it is clearing traffic shaping. + This file is normally not required as Shorewall's method of clearing + qdisc and filter definitions is pretty general.
            • +
          - Shorewall allows you to start traffic shaping when Shorewall itself starts - or it allows you to bring up traffic shaping when you bring up your interfaces.
          -
          - To start traffic shaping when Shorewall starts:
          - + Shorewall allows you to start traffic shaping when Shorewall itself +starts or it allows you to bring up traffic shaping when you bring up your +interfaces.
          +
          + To start traffic shaping when Shorewall starts:
          +
            -
          1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
            2. -
          2. Supply an /etc/shorewall/tcstart script to configure your traffic -shaping rules.
            3. -
          3. Optionally supply an /etc/shorewall/tcclear script to stop traffic - shaping. That is usually unnecessary.
            4. -
          4. If your tcstart script uses the 'fwmark' classifier, you can mark -packets using entries in /etc/shorewall/tcrules.
            5. - +
          5. Set TC_ENABLED=Yes and CLEAR_TC=Yes
            6. +
          6. Supply an /etc/shorewall/tcstart script to configure your traffic + shaping rules.
            7. +
          7. Optionally supply an /etc/shorewall/tcclear script to stop traffic + shaping. That is usually unnecessary.
            8. +
          8. If your tcstart script uses the 'fwmark' classifier, you can +mark packets using entries in /etc/shorewall/tcrules.
            9. +
          - To start traffic shaping when you bring up your network interfaces, you -will have to arrange for your traffic shaping configuration script to be run -at that time. How you do that is distribution dependent and will not be covered -here. You then should:
          - + To start traffic shaping when you bring up your network interfaces, +you will have to arrange for your traffic shaping configuration script to +be run at that time. How you do that is distribution dependent and will not +be covered here. You then should:
          +
            -
          1. Set TC_ENABLED=Yes and CLEAR_TC=No
            2. -
          2. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.
            3. -
          3. If your tcstart script uses the 'fwmark' classifier, you - can mark packets using entries in /etc/shorewall/tcrules.
            4. - +
          4. Set TC_ENABLED=Yes and CLEAR_TC=No
            5. +
          5. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear + scripts.
            6. +
          6. If your tcstart script uses the 'fwmark' classifier, + you can mark packets using entries in /etc/shorewall/tcrules.
            7. +
          - +

          Kernel Configuration

          - +

          This screen shot show how I've configured QoS in my Kernel:

          - +

          -

          - +

          +

          /etc/shorewall/tcrules

          - +

          The fwmark classifier provides a convenient way to classify - packets for traffic shaping. The /etc/shorewall/tcrules file provides - a means for specifying these marks in a tabular fashion.
          -

          - + packets for traffic shaping. The /etc/shorewall/tcrules file provides + a means for specifying these marks in a tabular fashion.
          +

          +

          Normally, packet marking occurs in the PREROUTING chain before - any address rewriting takes place. This makes it impossible to mark inbound - packets based on their destination address when SNAT or Masquerading are - being used. Beginning with Shorewall 1.3.12, you can cause packet marking - to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option -in shorewall.conf.
          -

          - + any address rewriting takes place. This makes it impossible to mark inbound + packets based on their destination address when SNAT or Masquerading +are being used. Beginning with Shorewall 1.3.12, you can cause packet +marking to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN +option in shorewall.conf.
          +

          +

          Columns in the file are as follows:

          - +
            -
          • MARK - Specifies the mark value is to be assigned in case - of a match. This is an integer in the range 1-255. Beginning with Shorewall -version 1.3.14, this value may be optionally followed by ":" and either 'F' -or 'P' to designate that the marking will occur in the FORWARD or PREROUTING -chains respectively. If this additional specification is omitted, the chain -used to mark packets will be determined by the setting of the MARK_IN_FORWARD_CHAIN -option in shorewall.conf.
            -
            - Example - 5
            -
            • -
          • SOURCE - The source of the packet. If the packet originates - on the firewall, place "fw" in this column. Otherwise, this is a - comma-separated list of interface names, IP addresses, MAC addresses in - Shorewall Format and/or Subnets.
            -
            - Examples
            -     eth0
            -     192.168.2.4,192.168.1.0/24
            -
            • -
          • DEST -- Destination of the packet. Comma-separated list -of IP addresses and/or subnets.
            -
            • -
          • PROTO - Protocol - Must be the name of a protocol from - /etc/protocol, a number or "all"
            -
            • -
          • PORT(S) - Destination Ports. A comma-separated list of -Port names (from /etc/services), port numbers or port ranges (e.g., -21:22); if the protocol is "icmp", this column is interpreted as -the destination icmp type(s).
            -
            • -
          • CLIENT PORT(S) - (Optional) Port(s) used by the client. -If omitted, any source port is acceptable. Specified as a comma-separate - list of port names, port numbers or port ranges.
            • - +
          • MARK - Specifies the mark value is to be assigned in + case of a match. This is an integer in the range 1-255. Beginning +with Shorewall version 1.3.14, this value may be optionally followed by +":" and either 'F' or 'P' to designate that the marking will occur in the +FORWARD or PREROUTING chains respectively. If this additional specification +is omitted, the chain used to mark packets will be determined by the setting +of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
            +
            + Example - 5
            +
            • +
          • SOURCE - The source of the packet. If the packet originates + on the firewall, place "fw" in this column. Otherwise, this is a + comma-separated list of interface names, IP addresses, MAC addresses + in Shorewall Format and/or Subnets.
            +
            + Examples
            +     eth0
            +     192.168.2.4,192.168.1.0/24
            +
            • +
          • DEST -- Destination of the packet. Comma-separated +list of IP addresses and/or subnets.
            +
            • +
          • PROTO - Protocol - Must be the name of a protocol from + /etc/protocol, a number or "all"
            +
            • +
          • PORT(S) - Destination Ports. A comma-separated list +of Port names (from /etc/services), port numbers or port ranges (e.g., + 21:22); if the protocol is "icmp", this column is interpreted +as the destination icmp type(s).
            +
            • +
          • CLIENT PORT(S) - (Optional) Port(s) used by the client. + If omitted, any source port is acceptable. Specified as a comma-separate + list of port names, port numbers or port ranges.
            • +
          - +

          Example 1 - All packets arriving on eth1 should be marked - with 1. All packets arriving on eth2 and eth3 should be marked with 2. - All packets originating on the firewall itself should be marked with 3.

          - + with 1. All packets arriving on eth2 and eth3 should be marked with + 2. All packets originating on the firewall itself should be marked with + 3.

          + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + +
          MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
          1eth10.0.0.0/0all  
          2eth20.0.0.0/0all  
          2
          +           		eth3
          +           		0.0.0.0/0
          +           		all
          +
          +
          +
          MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
          1eth10.0.0.0/0all  
          2eth20.0.0.0/0all  
          2
          -           		eth3
          -           		0.0.0.0/0
          -           		all
          -
          -
          -
          3fw0.0.0.0/0all  
          3fw0.0.0.0/0all  
          - +

          Example 2 - All GRE (protocol 47) packets not originating - on the firewall and destined for 155.186.235.151 should be marked with - 12.

          - + on the firewall and destined for 155.186.235.151 should be marked with + 12.

          + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
          MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
          120.0.0.0/0155.186.235.15147  
          MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
          120.0.0.0/0155.186.235.15147  
          - +

          Example 3 - All SSH packets originating in 192.168.1.0/24 - and destined for 155.186.235.151 should be marked with 22.

          - + and destined for 155.186.235.151 should be marked with 22.

          + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
          MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
          22192.168.1.0/24155.186.235.151tcp22 
          MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
          22192.168.1.0/24155.186.235.151tcp22 
          - +

          My Setup
          -

          - + +

          While I am currently using the HTB version of The Wonder Shaper (I just copied - wshaper.htb to /etc/shorewall/tcstart and modified it as shown -in the Wondershaper README), I have also run with the following set of + wshaper.htb to /etc/shorewall/tcstart and modified it as shown + in the Wondershaper README), I have also run with the following set of hand-crafted rules in my /etc/shorewall/tcstart file:
          -

          - -
          +

          + +
          run_tc qdisc add dev eth0 root handle 1: htb default 30

          run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

          echo "   Added Top Level Class -- rate 384kbit"
          - + 
          run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
          run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
          run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
          - + 
          echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
          - + 
          run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
          run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
          run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
          - + 
          echo "   Enabled PFIFO on Second Level Classes"
          - + 
          run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
          run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
          run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
          - + 
          echo "   Defined fwmark filters"
          -
          - +
          +

          My tcrules file that went with this tcstart file is shown in Example 1 - above. You can look at my network configuration - to get an idea of why I wanted these particular rules.
          -

          - + above. You can look at my configuration to +see why I wanted shaping of this type.
          +

          +
            -
          1. I wanted to allow up to 140kbits/second for traffic outbound -from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic - can use all available bandwidth if there is no traffic from the local systems - or from my laptop or firewall).
            2. -
          2. My laptop and local systems could use up to 224kbits/second.
            3. -
          3. My firewall could use up to 20kbits/second.
            -
            4. - +
          4. I wanted to allow up to 140kbits/second for traffic outbound + from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic + can use all available bandwidth if there is no traffic from the local +systems or from my laptop or firewall).
            5. +
          5. My laptop and local systems could use up to 224kbits/second.
            6. +
          6. My firewall could use up to 20kbits/second.
            7. +
          - -

          Last Updated 2/13/2003 - Tom Eastep

          - + You see the rest of my Shorewall configuration +to see how this fit in.
          + +

          Last Updated 3/5/2003 - Tom Eastep

          +

          Copyright - © 2001, 2002, 2003 Thomas M. Eastep.
          -

          + © 2001, 2002, 2003 Thomas M. Eastep.
          +

          +
          +
          +
          +
          diff --git a/STABLE/documentation/troubleshoot.htm b/STABLE/documentation/troubleshoot.htm index cc4d05907..b438ec1f7 100644 --- a/STABLE/documentation/troubleshoot.htm +++ b/STABLE/documentation/troubleshoot.htm @@ -1,237 +1,233 @@ - + Shorewall Troubleshooting - + - + - + - - - + + - - - + + + + +
          - +
          +

          Shorewall TroubleshootingBeating head on table -

          -
          - +

          Check the Errata

          - +

          Check the Shorewall Errata to be - sure that there isn't an update that you are missing for your version - of the firewall.

          - + sure that there isn't an update that you are missing for your version + of the firewall.

          +

          Check the FAQs

          - +

          Check the FAQs for solutions to common - problems.

          - + problems.

          +

          If the firewall fails to start

          - If you receive an error message when starting or restarting -the firewall and you can't determine the cause, then do the following: - + If you receive an error message when starting or restarting + the firewall and you can't determine the cause, then do the following: +
            -
          • Make a note of the error message that you see.
            -
            • -
          • shorewall debug start 2> /tmp/trace
            • -
          • Look at the /tmp/trace file and see if that helps you - determine what the problem is. Be sure you find the place in the log -where the error message you saw is generated -- in 99.9% of the cases, it -will not be near the end of the log because after startup errors, Shorewall -goes through a "shorewall stop" phase which will also be traced.
            • -
          • If you still can't determine what's wrong then see the - support page.
            • - +
          • Make a note of the error message that you see.
            +
            • +
          • shorewall debug start 2> /tmp/trace
            • +
          • Look at the /tmp/trace file and see if that helps you + determine what the problem is. Be sure you find the place in the log + where the error message you saw is generated -- in 99.9% of the cases, it + will not be near the end of the log because after startup errors, Shorewall + goes through a "shorewall stop" phase which will also be traced.
            • +
          • If you still can't determine what's wrong then see the + support page.
            • +
          - Here's an example. During startup, a user sees the following:
          - -
          + Here's an example. During startup, a user sees the following:
          + +
          Adding Common Rules
          iptables: No chain/target/match by that name
          Terminated
          -
          - A search through the trace for "No chain/target/match by that name" turned -up the following:  -
          +
          + A search through the trace for "No chain/target/match by that name" turned + up the following:  +
          + echo 'Adding Common Rules'
          + add_common_rules
          + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
          ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
          ++ sed 's/!/! /g'
          + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
          iptables: No chain/target/match by that name
          -
          - The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with -tcp-reset". In this case, the user had compiled his own kernel and had forgotten -to include REJECT target support (see kernel.htm) - +
          + The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with + tcp-reset". In this case, the user had compiled his own kernel and had forgotten + to include REJECT target support (see kernel.htm) +

          Your network environment

          - +

          Many times when people have problems with Shorewall, the problem is actually an ill-conceived network setup. Here are several popular snafus: -

          - +

          +
            -
          • Port Forwarding where client and server are in -the same subnet. See FAQ 2.
            • -
          • Changing the IP address of a local system to be in the external - subnet, thinking that Shorewall will suddenly believe that the system - is in the 'net' zone.
            • -
          • Multiple interfaces connected to the same HUB or Switch. -Given the way that the Linux kernel respond to ARP "who-has" requests, -this type of setup does NOT work the way that you expect it to.
            • - +
          • Port Forwarding where client and server are in + the same subnet. See FAQ 2.
            • +
          • Changing the IP address of a local system to be in the +external subnet, thinking that Shorewall will suddenly believe that +the system is in the 'net' zone.
            • +
          • Multiple interfaces connected to the same HUB or Switch. + Given the way that the Linux kernel respond to ARP "who-has" requests, + this type of setup does NOT work the way that you expect it to.
            • +
          - +

          If you are having connection problems:

          - +

          If the appropriate policy for the connection that you are - trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING - TO MAKE IT WORK. Such additional rules will NEVER make it work, they + trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING + TO MAKE IT WORK. Such additional rules will NEVER make it work, they add clutter to your rule set and they represent a big security hole in the event that you forget to remove them later.

          - +

          I also recommend against setting all of your policies to ACCEPT in an effort to make something work. That robs you of one of - your best diagnostic tools - the "Shorewall" messages that Netfilter - will generate when you try to connect in a way that isn't permitted - by your rule set.

          - + your best diagnostic tools - the "Shorewall" messages that Netfilter + will generate when you try to connect in a way that isn't permitted + by your rule set.

          +

          Check your log ("/sbin/shorewall show log"). If you don't - see Shorewall messages, then your problem is probably NOT a Shorewall -problem. If you DO see packet messages, it may be an indication that you -are missing one or more rules -- see FAQ 17.

          - + see Shorewall messages, then your problem is probably NOT a Shorewall + problem. If you DO see packet messages, it may be an indication that you + are missing one or more rules -- see FAQ 17.

          +

          While you are troubleshooting, it is a good idea to clear - two variables in /etc/shorewall/shorewall.conf:

          - + two variables in /etc/shorewall/shorewall.conf:

          +

          LOGRATE=""
          - LOGBURST=""

          - + LOGBURST=""

          +

          This way, you will see all of the log messages being generated (be sure to restart shorewall after clearing these variables).

          - +

          Example:

          - - + +

          Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 - LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 -LEN=47

          -           + LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 + LEN=47

          +

          Let's look at the important parts of this message:

          - +
            -
          • all2all:REJECT - This packet was REJECTed out of the all2all - chain -- the packet was rejected under the "all"->"all" REJECT +
          • all2all:REJECT - This packet was REJECTed out of the all2all + chain -- the packet was rejected under the "all"->"all" REJECT policy (see FAQ 17).
            • -
          • IN=eth2 - the packet entered the firewall via eth2
            • -
          • OUT=eth1 - if accepted, the packet would be sent on eth1
            • -
          • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
            • -
          • DST=192.168.1.3 - the packet is destined for 192.168.1.3
            • -
          • PROTO=UDP - UDP Protocol
            • -
          • DPT=53 - DNS
            • - +
          • IN=eth2 - the packet entered the firewall via eth2
            • +
          • OUT=eth1 - if accepted, the packet would be sent on eth1
            • +
          • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
            • +
          • DST=192.168.1.3 - the packet is destined for 192.168.1.3
            • +
          • PROTO=UDP - UDP Protocol
            • +
          • DPT=53 - DNS
            • +
          - +

          In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 - is in the "loc" zone. I was missing the rule:

          - + is in the "loc" zone. I was missing the rule:

          +

          ACCEPT    dmz    loc    udp    53
          -

          - +

          +

          See FAQ 17 for additional information - about how to interpret the chain name appearing in a Shorewall log message.
          -

          - + about how to interpret the chain name appearing in a Shorewall log message.
          +

          +

          'Ping' Problems?

          -Either can't ping when you think you should be able to or are able to ping -when you think that you shouldn't be allowed? Shorewall's 'Ping' Management is described here.
          +

          Other Gotchas

          - + - +

          Still Having Problems?

          - +

          See the support page.
          -

          - - +

          + +
          -           -

          Last updated 1/7/2003 - Tom Eastep

          - +           +

          Last updated 2/21/2003 - Tom Eastep

          +

          Copyright - © 2001, 2002 Thomas M. Eastep.
          -

          + © 2001, 2002 Thomas M. Eastep.
          +

          +
          +
          diff --git a/STABLE/documentation/two-interface.htm b/STABLE/documentation/two-interface.htm index a12c37b39..35b70685d 100644 --- a/STABLE/documentation/two-interface.htm +++ b/STABLE/documentation/two-interface.htm @@ -1,1047 +1,1048 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
          +
          - +

          Basic Two-Interface Firewall

          -
          - -

          Setting up a Linux system as a firewall for a small network - is a fairly straight-forward task if you understand the basics and - follow the documentation.

          - -

          This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in its most common configuration:

          - + +

          Setting up a Linux system as a firewall for a small network + is a fairly straight-forward task if you understand the basics and + follow the documentation.

          + +

          This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in its most common configuration:

          +
            -
          • Linux system used as a firewall/router for a small +
          • Linux system used as a firewall/router for a small local network.
            • -
          • Single public IP address.
            • -
          • Internet connection through cable modem, DSL, ISDN, -Frame Relay, dial-up ...
            • - +
          • Single public IP address.
            • +
          • Internet connection through cable modem, DSL, ISDN, + Frame Relay, dial-up ...
            • +
          - +

          Here is a schematic of a typical installation.

          - +

          -

          - -

          If you are running Shorewall under Mandrake 9.0 or later, you can easily - configure the above setup using the Mandrake "Internet Connection Sharing" - applet. From the Mandrake Control Center, select "Network & Internet" - then "Connection Sharing".
          -

          -

          Note however, that the Shorewall configuration produced by Mandrake -Internet Connection Sharing is strange and is apt to confuse you if you use -the rest of this documentation (it has two local zones; "loc" and "masq" -where "loc" is empty; this conflicts with this documentation which assumes -a single local zone "loc"). We therefore recommend that once you have set -up this sharing that you uninstall the Mandrake Shorewall RPM and install -the one from the download page then follow the -instructions in this Guide.
          -

          +

          + +

          If you are running Shorewall under Mandrake 9.0 or later, you can easily + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing".
          +

          -


          -

          - -

          This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can -tell if this package is installed by the presence of an ip program - on your firewall system. As root, you can use the 'which' command to - check for this program:

          - -
               [root@gateway root]# which ip
               /sbin/ip
               [root@gateway root]#
          - -

          I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are - flagged with - . Configuration notes that are unique to LEAF/Bering are marked - with (LEAF Logo) +

          Note however, that the Shorewall configuration produced by Mandrake +Internet Connection Sharing is strange and is apt to confuse you if you use +the rest of this documentation (it has two local zones; "loc" and "masq" where +"loc" is empty; this conflicts with this documentation which assumes a single +local zone "loc"). We therefore recommend that once you have set up this +sharing that you uninstall the Mandrake Shorewall RPM and install the one +from the download page then follow the instructions +in this Guide.

          + +

          Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can + tell if this package is installed by the presence of an ip +program on your firewall system. As root, you can use the 'which' +command to check for this program:

          + +
               [root@gateway root]# which ip
               /sbin/ip
               [root@gateway root]#
          +

          I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are + flagged with + . Configuration notes that are unique to LEAF/Bering are +marked with (LEAF Logo) +

          +

          -     If you edit your configuration files on a Windows system, - you must save them as Unix files if your editor supports that option - or you must run them through dos2unix before trying to use them. Similarly, - if you copy a configuration file from your Windows hard drive to a floppy - disk, you must run dos2unix against the copy before using it with Shorewall.

          - +     If you edit your configuration files on a Windows system, + you must save them as Unix files if your editor supports that option + or you must run them through dos2unix before trying to use them. Similarly, + if you copy a configuration file from your Windows hard drive to a +floppy disk, you must run dos2unix against the copy before using it with +Shorewall.

          + - +

          Shorewall Concepts

          - +

          -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you will only need to deal with +     The configuration files for Shorewall are contained in the directory + /etc/shorewall -- for simple setups, you will only need to deal with a few of these as described in this guide. After you have installed Shorewall, download the two-interface sample, - un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to -/etc/shorewall (these files will replace files with the same name).

          - -

          As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

          - -

          Shorewall views the network where it is running as being composed of a - set of zones. In the two-interface sample configuration, the - following zone names are used:

          - + href="/pub/shorewall/LATEST.samples/two-interfaces.tgz">two-interface sample, + un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to + /etc/shorewall (these files will replace files with the same name).

          + +

          As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration +instructions and default entries.

          + +

          Shorewall views the network where it is running as being composed of a + set of zones. In the two-interface sample configuration, +the following zone names are used:

          + - + + + + + - - - - - - - - - - - - - + + + + + + + + +
          NameDescription
          NameDescription
          netThe Internet
          locYour Local Network
          netThe Internet
          locYour Local Network
          - -

          Zones are defined in the /etc/shorewall/zones - file.

          - -

          Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

          - -

          Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

          - + +

          Zones are defined in the /etc/shorewall/zones + file.

          + +

          Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

          + +

          Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

          +
            -
          • You express your default policy for connections from +
          • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
            • -
          • You define exceptions to those default policies in +
          • You define exceptions to those default policies in the /etc/shorewall/rules file.
            • - +
          - -

          For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that -file matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or -DROP  the request is first checked against the rules in /etc/shorewall/common - (the samples provide that file for you).

          - -

          The /etc/shorewall/policy file included with the two-interface sample has -the following policies:

          - -
          + +

          For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that + file matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or + DROP  the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

          + +

          The /etc/shorewall/policy file included with the two-interface sample +has the following policies:

          + +
          - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - - + +
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          -
          - -
          -

          In the two-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

          - +
          + +
          +

          In the two-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

          + - + + + + + + + + - - - - - - - - - - - - - + + + + + + - - + +
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          Source ZoneDestination ZonePolicyLog LevelLimit:Burst
          fwnetACCEPT  
          fwnetACCEPT  
          -
          - +
          +

          The above policy will:

          - +
            -
          1. allow all connection requests from your local network - to the internet
            2. -
          2. drop (ignore) all connection requests from the internet - to your firewall or local network
            3. -
          3. optionally accept all connection requests from the +
          4. allow all connection requests from your local network + to the internet
            5. +
          5. drop (ignore) all connection requests from the internet + to your firewall or local network
            6. +
          6. optionally accept all connection requests from the firewall to the internet (if you uncomment the additional policy)
            7. -
          7. reject all other connection requests.
            8. - +
          8. reject all other connection requests.
            9. +
          - +

          -     At this point, edit your /etc/shorewall/policy and make +     At this point, edit your /etc/shorewall/policy and make any changes that you wish.

          - +

          Network Interfaces

          - +

          -

          - -

          The firewall has two network interfaces. Where Internet -connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect - via a regular modem, your External Interface will also be ppp0. - If you connect via ISDN, your external interface will be ippp0.

          - +

          + +

          The firewall has two network interfaces. Where Internet connectivity +is through a cable or DSL "Modem", the External Interface will be +the ethernet adapter that is connected to that "Modem" (e.g., eth0)  + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect + via a regular modem, your External Interface will also be ppp0. + If you connect via ISDN, your external interface will be ippp0.

          +

          -     If your external interface is ppp0 or ippp0  +     If your external interface is ppp0 or ippp0  then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

          - -

          Your Internal Interface will be an ethernet adapter - (eth1 or eth0) and will be connected to a hub or switch. Your other - computers will be connected to the same hub/switch (note: If you have - only a single internal system, you can connect the firewall directly - to the computer using a cross-over cable).

          - + +

          Your Internal Interface will be an ethernet adapter + (eth1 or eth0) and will be connected to a hub or switch. Your other + computers will be connected to the same hub/switch (note: If you +have only a single internal system, you can connect the firewall +directly to the computer using a cross-over cable).

          +

          - Do not connect the internal and external interface - to the same hub or switch (even for testing). It won't work the way - that you think that it will and you will end up confused and believing + Do not connect the internal and external interface + to the same hub or switch (even for testing). It won't work the way + that you think that it will and you will end up confused and believing that Shorewall doesn't work at all.

          - +

          -     The Shorewall two-interface sample configuration assumes - that the external interface is eth0 and the internal interface - is eth1. If your configuration is different, you will have to - modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the -list of options that are specified for the interfaces. Some hints:

          - +     The Shorewall two-interface sample configuration assumes + that the external interface is eth0 and the internal interface + is eth1. If your configuration is different, you will have +to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list + of options that are specified for the interfaces. Some hints:

          +
            +
          • + +

            If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-". +

            +
          • - -

            If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

            -
            • -
          • - -

            If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the - option list.

            -
            • - + +

            If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from +the option list.

            + +
          - +

          IP Addresses

          - -

          Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you - a single Public IP address. This address may be assigned via -the Dynamic Host Configuration Protocol (DHCP) or as part of establishing - your connection when you dial in (standard modem) or establish your PPP - connection. In rare cases, your ISP may assign you a static IP -address; that means that you configure your firewall's external interface - to use that address permanently. However your external address -is assigned, it will be shared by all of your systems when you access the - Internet. You will have to assign your own addresses in your internal network -(the Internal Interface on your firewall plus your other computers). RFC -1918 reserves several Private IP address ranges for this purpose:

          - -
          + +

          Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via + the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. However your external address + is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses in your internal +network (the Internal Interface on your firewall plus your other computers). +RFC 1918 reserves several Private IP address ranges for this purpose:

          + +
               10.0.0.0    - 10.255.255.255
               172.16.0.0  - 172.31.255.255
               192.168.0.0 - 192.168.255.255
          -
          - -
          +
          + +

          -     Before starting Shorewall, you should look at the IP - address of your external interface and if it is one of the above - ranges, you should remove the 'norfc1918' option from the external +     Before starting Shorewall, you should look at the +IP address of your external interface and if it is one of the above + ranges, you should remove the 'norfc1918' option from the external interface's entry in /etc/shorewall/interfaces.

          -
          - -
          -

          You will want to assign your addresses from the same - sub-network (subnet).  For our purposes, we can consider a subnet - to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a -subnet will have a Subnet Mask of 255.255.255.0. The address -x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is -reserved as the Subnet Broadcast Address. In Shorewall, -a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive leading "1" bits -from the left of the subnet mask.

          -
          - -
          +
          + +
          +

          You will want to assign your addresses from the same + sub-network (subnet).  For our purposes, we can consider a subnet + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such +a subnet will have a Subnet Mask of 255.255.255.0. The address + x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is + reserved as the Subnet Broadcast Address. In Shorewall, + a subnet is described using Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive leading "1" +bits from the left of the subnet mask.

          +
          + +

          Example sub-network:

          -
          - -
          -
          +
          + +
          +
          - - - - - + - - - - - - - - - - - + + + + + + + + + + + + + + + - - + +
          Range:10.10.10.0 - 10.10.10.255
          Subnet Address:10.10.10.0
          Broadcast Address:10.10.10.255
          CIDR Notation:10.10.10.0/24
          Range:10.10.10.0 - 10.10.10.255
          Subnet Address:10.10.10.0
          Broadcast Address:10.10.10.255
          CIDR Notation:10.10.10.0/24
          -
          + +
          + +
          +

          It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above + example) or the last usable address (10.10.10.254).

          - -
          -

          It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above -example) or the last usable address (10.10.10.254).

          -
          - -
          -

          One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

          -
          - -
          + +
          +

          One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

          +
          + +

          -     Your local computers (computer 1 and computer 2 in -the above diagram) should be configured with their default gateway - to be the IP address of the firewall's internal interface.      +     Your local computers (computer 1 and computer 2 in +the above diagram) should be configured with their default gateway + to be the IP address of the firewall's internal interface.     

          -
          - -

          The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning - more about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

          - -

          The remainder of this quide will assume that you have configured - your network as shown here:

          - +
          + +

          The foregoing short discussion barely scratches the surface + regarding subnetting and routing. If you are interested in learning + more about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", +Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

          + +

          The remainder of this quide will assume that you have configured + your network as shown here:

          +

          -

          - +

          +

          The default gateway for computer's 1 & 2 would be 10.10.10.254.
          -

          - +

          +

          -     WARNING: Your ISP might assign - your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 - subnet then you will need to select a DIFFERENT RFC 1918 subnet for your -local network.
          -

          - +     WARNING: Your ISP might assign + your external interface an RFC 1918 address. If that address is in the +10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918 +subnet for your local network.
          +

          +

          IP Masquerading (SNAT)

          - -

          The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one - of your local systems (let's assume computer 1) sends a connection request - to an internet host, the firewall must perform Network Address -Translation (NAT). The firewall rewrites the source address in -the packet to be the address of the firewall's external interface; in -other words, the firewall makes it look as if the firewall itself is -initiating the connection.  This is necessary so that the destination -host will be able to route return packets back to the firewall (remember -that packets whose destination address is reserved by RFC 1918 can't -be routed across the internet so the remote host can't address its response -to computer 1). When the firewall receives a return packet, it rewrites -the destination address back to 10.10.10.1 and forwards the packet on to -computer 1.

          - -

          On Linux systems, the above process is often referred to as - IP Masquerading but you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

          - + +

          The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When +one of your local systems (let's assume computer 1) sends a connection +request to an internet host, the firewall must perform Network +Address Translation (NAT). The firewall rewrites the source address +in the packet to be the address of the firewall's external interface; +in other words, the firewall makes it look as if the firewall itself +is initiating the connection.  This is necessary so that the destination + host will be able to route return packets back to the firewall (remember + that packets whose destination address is reserved by RFC 1918 can't + be routed across the internet so the remote host can't address its response + to computer 1). When the firewall receives a return packet, it rewrites + the destination address back to 10.10.10.1 and forwards the packet on +to computer 1.

          + +

          On Linux systems, the above process is often referred to +as IP Masquerading but you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

          +
            +
          • + +

            Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

            +
          • - -

            Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

            -
            • -
          • - -

            SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

            -
            • - + +

            SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

            + +
          - -

          In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use Masquerading - if your external IP is dynamic and SNAT if the IP is static.

          - + +

          In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file. You will normally use Masquerading + if your external IP is dynamic and SNAT if the IP is static.

          +

          -     If your external firewall interface is eth0, you - do not need to modify the file provided with the sample. Otherwise, - edit /etc/shorewall/masq and change the first column to the name -of your external interface and the second column to the name of your -internal interface.

          - +     If your external firewall interface is eth0, you + do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change the first column to the name of + your external interface and the second column to the name of your internal + interface.

          +

          -     If your external IP is static, you can enter it in the - third column in the /etc/shorewall/masq entry if you like although - your firewall will work fine if you leave that column empty. Entering - your static IP in column 3 makes processing outgoing packets a little +     If your external IP is static, you can enter it in the + third column in the /etc/shorewall/masq entry if you like although + your firewall will work fine if you leave that column empty. Entering + your static IP in column 3 makes processing outgoing packets a little more efficient.
          -
          - + -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
          -

          - +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
          +

          +
            -
          • NAT_ENABLED=Yes
            • -
          • IP_FORWARDING=On
            -
            • - +
          • NAT_ENABLED=Yes
            • +
          • IP_FORWARDING=On
            +
            • +
          - +

          Port Forwarding (DNAT)

          - -

          One of your goals may be to run one or more servers on your - local computers. Because these computers have RFC-1918 addresses, -it is not possible for clients on the internet to connect directly to -them. It is rather necessary for those clients to address their connection - requests to the firewall who rewrites the destination address to the - address of your server and forwards the packet to that server. When -your server responds, the firewall automatically performs SNAT to rewrite - the source address in the response.

          - -

          The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure + +

          One of your goals may be to run one or more servers on your + local computers. Because these computers have RFC-1918 addresses, + it is not possible for clients on the internet to connect directly +to them. It is rather necessary for those clients to address their +connection requests to the firewall who rewrites the destination address +to the address of your server and forwards the packet to that server. +When your server responds, the firewall automatically performs SNAT +to rewrite the source address in the response.

          + +

          The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file.

          - -

          The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

          - -
          + +

          The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

          + +
          - + + + + + + + + + + - - - - - - - - - - - - + + - - - - - + + + + + - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetloc:<server local ip address> [:<server + DNATnetloc:<server local ip address> [:<server port>]<protocol><port>  
          <protocol><port>  
          -
          - -

          Example - you run a Web Server on computer 2 and you want to forward incoming - TCP port 80 to that system:

          - -
          - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetloc:10.10.10.2tcp80  
          -
          - -

          A couple of important points to keep in mind:

          - -
            -
          • You must test the above rule from a client outside -of your local network (i.e., don't test from a browser running on -computers 1 or 2 or on the firewall). If you want to be able to -access your web server using the IP address of your external interface, -see Shorewall FAQ #2.
            • -
          • Many ISPs block incoming connection requests to port - 80. If you have problems connecting to your web server, try the -following rule and try connecting to port 5000.
            • - -
          - -
          - - - - - - - - - - - - - - - - - - - - - - - -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetloc:10.10.10.2:80tcp5000  
          -
          - -

          -     At this point, modify /etc/shorewall/rules to add any -DNAT rules that you require.

          - -

          Domain Name Server (DNS)

          - -

          Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver - will be automatically configured (e.g., the /etc/resolv.conf file will - be written). Alternatively, your ISP may have given you the IP address - of a pair of DNS name servers for you to manually configure as - your primary and secondary name servers. Regardless of how DNS gets -configured on your firewall, it is your responsibility to configure -the resolver in your internal systems. You can take one of two approaches:

          - -
            -
          • - -

            You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers - or if those addresses are available on their web site, you can configure - your internal systems to use those addresses. If that information - isn't available, look in /etc/resolv.conf on your firewall system --- the name servers are given in "nameserver" records in that file. -

            -
            • -
          • + + +
          + +

          Example - you run a Web Server on computer 2 and you want to forward incoming + TCP port 80 to that system:

          + +
          + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetloc:10.10.10.2tcp80  
          +
          + +

          A couple of important points to keep in mind:

          + +
            +
          • You must test the above rule from a client outside +of your local network (i.e., don't test from a browser running on +computers 1 or 2 or on the firewall). If you want to be able to access +your web server using the IP address of your external interface, see + Shorewall FAQ #2.
            • +
          • Many ISPs block incoming connection requests to port + 80. If you have problems connecting to your web server, try the +following rule and try connecting to port 5000.
            • + +
          + +
          + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          DNATnetloc:10.10.10.2:80tcp5000  
          +
          + +

          +     At this point, modify /etc/shorewall/rules to add any + DNAT rules that you require.

          + +

          Domain Name Server (DNS)

          + +

          Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver + will be automatically configured (e.g., the /etc/resolv.conf file +will be written). Alternatively, your ISP may have given you the IP +address of a pair of DNS name servers for you to manually configure +as your primary and secondary name servers. Regardless of how DNS gets + configured on your firewall, it is your responsibility to configure + the resolver in your internal systems. You can take one of two approaches:

          + +
            +
          • + +

            You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system + -- the name servers are given in "nameserver" records in that file. +

            +
            • +
          • +

            -     You can configure a Caching Name Server on your - firewall. Red Hat has an RPM for a caching name server - (the RPM also requires the 'bind' RPM) and for Bering users, there - is dnscache.lrp. If you take this approach, you configure your internal - systems to use the firewall itself as their primary (and only) name -server. You use the internal IP address of the firewall (10.10.10.254 -in the example above) for the name server address. To allow your -local systems to talk to your caching name server, you must open port -53 (both UDP and TCP) from the local network to the firewall; you -do that by adding the following rules in /etc/shorewall/rules.

            -
            • - +     You can configure a Caching Name Server on your + firewall. Red Hat has an RPM for a caching name server + (the RPM also requires the 'bind' RPM) and for Bering users, there + is dnscache.lrp. If you take this approach, you configure your internal + systems to use the firewall itself as their primary (and only) name server. + You use the internal IP address of the firewall (10.10.10.254 in the + example above) for the name server address. To allow your local systems + to talk to your caching name server, you must open port 53 (both UDP + and TCP) from the local network to the firewall; you do that by adding + the following rules in /etc/shorewall/rules.

            + +
          - -
          + +
          - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp53  
          ACCEPTlocfwudp53  
          ACCEPTlocfwtcp53  
          ACCEPTlocfwudp53  
          -
          - -
          +
          + +

          Other Connections

          -
          - -
          +
          + +

          The two-interface sample includes the following rules:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTfwnettcp53  
          ACCEPTfwnetudp53  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTfwnettcp53  
          ACCEPTfwnetudp53  
          -
          + +
          + +
          +

          Those rules allow DNS access from your firewall and may be + removed if you uncommented the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

          - -
          -

          Those rules allow DNS access from your firewall and may be - removed if you uncommented the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

          -
          - -
          + +

          The sample also includes:

          -
          - -
          -
          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp22  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTlocfwtcp22  
          -
          + +
          + +
          +

          That rule allows you to run an SSH server on your firewall + and connect to that server from your local systems.

          - -
          -

          That rule allows you to run an SSH server on your firewall - and connect to that server from your local systems.

          -
          - -
          -

          If you wish to enable other connections between your firewall - and other systems, the general format is:

          -
          - -
          -
          + +
          +

          If you wish to enable other connections between your firewall + and other systems, the general format is:

          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPT<source zone><destination zone><protocol><port>  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPT<source zone><destination zone><protocol><port>  
          -
          +
          +
          + +
          +

          Example - You want to run a Web Server on your firewall + system:

          - -
          -

          Example - You want to run a Web Server on your firewall - system:

          -
          - -
          -
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp80#Allow web accessfrom the internet
          ACCEPTlocfwtcp80#Allow web accessfrom the local network
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp80#Allow web accessfrom the internet
          ACCEPTlocfwtcp80#Allow web accessfrom the local network
          -
          +
          +
          + +
          +

          Those two rules would of course be in addition to the rules + listed above under "You can configure a Caching Name Server on +your firewall"

          - -
          -

          Those two rules would of course be in addition to the rules - listed above under "You can configure a Caching Name Server on your - firewall"

          -
          - -
          -

          If you don't know what port and protocol a particular application -uses, look here.

          -
          - -
          -

          Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you - want shell access to your firewall from the internet, use SSH:

          -
          - -
          -
          + +
          +

          If you don't know what port and protocol a particular +application uses, look here.

          +
          + +
          +

          Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If +you want shell access to your firewall from the internet, use SSH:

          +
          + +
          +
          - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp22  
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTnetfwtcp22  
          -
          -
          - -
          +
          +
          + +

          (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     Bering users will want to add the following two rules to be compatible with Jacques's Shorewall configuration.

          - -
          -
          + +
          +
          - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTloc
          -           		fwudp
          -           		53
          -           		#Allow DNS Cache towork
          -
          ACCEPTlocfwtcp80#Allow weblet to work
          -
          ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
          ACCEPTloc
          +           		fwudp
          +           		53
          +           		#Allow DNS Cache towork
          +
          ACCEPTlocfwtcp80#Allow weblet to work
          +
          -
          -
          - +
          +
          +


          - -     Now edit your /etc/shorewall/rules file to add or delete - other connections as required.

          -
          - -
          -

          Starting and Stopping Your Firewall

          + +     Now edit your /etc/shorewall/rules file to add or +delete other connections as required.

          - -
          + +
          +

          Starting and Stopping Your Firewall

          +
          + +

          Arrow -     The installation procedure - configures your system to start Shorewall at system boot  but beginning -with Shorewall version 1.3.9 startup is disabled so that your system -won't try to start Shorewall before configuration is complete. Once you -have completed configuration of your firewall, you can enable Shorewall -startup by removing the file /etc/shorewall/startup_disabled.
          -

          - +     The installation procedure + configures your system to start Shorewall at system boot  but beginning + with Shorewall version 1.3.9 startup is disabled so that your system + won't try to start Shorewall before configuration is complete. Once +you have completed configuration of your firewall, you can enable Shorewall + startup by removing the file /etc/shorewall/startup_disabled.
          +

          +

          IMPORTANT: Users of the .deb package must edit /etc/default/shorewall + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
          -

          +

          +
          + +
          +

          The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from + your Netfilter configuration, use "shorewall clear".

          - -
          -

          The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall from -your Netfilter configuration, use "shorewall clear".

          -
          - -
          + +

          -     The two-interface sample assumes that you want to enable - routing to/from eth1 (the local network) when Shorewall is -stopped. If your local network isn't connected to eth1 or if you -wish to enable access to/from other hosts, change /etc/shorewall/routestopped +     The two-interface sample assumes that you want to enable + routing to/from eth1 (the local network) when Shorewall is + stopped. If your local network isn't connected to eth1 or if +you wish to enable access to/from other hosts, change /etc/shorewall/routestopped accordingly.

          -
          - -
          -

          WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you - have added an entry for the IP address that you are connected from - to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the + +

          - -

          Last updated 2/13/2003 - + +

          Last updated 2/21/2003 - Tom Eastep

          - -

          Copyright 2002, 2003 + +

          Copyright 2002, 2003 Thomas M. Eastep
          -

          +

          +

          diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm index 88f1cbcd7..79d1c7aa7 100644 --- a/STABLE/documentation/upgrade_issues.htm +++ b/STABLE/documentation/upgrade_issues.htm @@ -1,233 +1,310 @@ - + Upgrade Issues - + + - + - + - + - - - + + - - - + + + +
          - +
          +

          Upgrade Issues

          -
          - +

          For upgrade instructions see the Install/Upgrade page.

          - -

          Version >= 1.3.14

          - -     Beginning in version 1.3.14, Shorewall treats entries in /etc/shorewall/masq differently. The change -involves entries with an interface name in the SUBNET (second) -column:
          - -
            -
          • Prior to 1.3.14, Shorewall would detect the FIRST subnet on the interface -(as shown by "ip addr show interface") and would masquerade traffic -from that subnet. Any other subnets that routed through eth1 needed their -own entry in /etc/shorewall/masq to be masqueraded or to have SNAT applied.
            • -
          • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's routing -table to determine ALL subnets routed through the named interface. Traffic -originating in ANY of those subnets is masqueraded or has SNAT applied.
            • - -
          - You will need to make a change to your configuration if:
          - -
            -
          1. You have one or more entries in /etc/shorewall/masq with an interface -name in the SUBNET (second) column; and
            2. -
          2. That interface connects to more than one subnetwork.
            3. - -
          - Two examples:
          + +

          + +

          Version >= 1.4.0

          + IMPORTANT: Shorewall >=1.4.0 REQUIRES the iproute package +('ip' utility).

          -  Example 1 -- Suppose that your current config is as follows:
          -   
          - -
          	[root@gateway test]# cat /etc/shorewall/masq
          	#INTERFACE              SUBNET                  ADDRESS
          	eth0                    eth2                    206.124.146.176
          	eth0                    192.168.10.0/24         206.124.146.176
          	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
          	[root@gateway test]# ip route show dev eth2
          	192.168.1.0/24  scope link
          	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
          	[root@gateway test]#
          - -
          In this case, the second entry in /etc/shorewall/masq is no longer -required.
          -
          - Example 2-- What if your current configuration is like this?
          - -
          	[root@gateway test]# cat /etc/shorewall/masq	
          	#INTERFACE              SUBNET                  ADDRESS	
          	eth0                    eth2                    206.124.146.176
          	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
          	[root@gateway test]# ip route show dev eth2	
          	192.168.1.0/24  scope link
          	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
          	[root@gateway test]#
          - -
          In this case, you would want to change the entry in /etc/shorewall/masq -to:
          -
          - -
          	#INTERFACE              SUBNET                  ADDRESS	
          	eth0                    192.168.1.0/24          206.124.146.176
          	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
          - -    Version 1.3.14 also introduced simplified ICMP echo-request (ping) handling. -The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf is used -to specify that the old (pre-1.3.14) ping handling is to be used (If the -option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes -is assumed). I don't plan on supporting the old handling indefinitely so -I urge current users to migrate to using the new handling as soon as possible. -See the 'Ping' handling documentation for details.
          -

          Version 1.3.10

          - If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to version - 1.3.10, you will need to use the '--force' option:
          -
          + If you are upgrading from a version < 1.4.0, then:
          + +
            +
          • The noping and forwardping interface options are +no longer supported nor is the FORWARDPING option in shorewall.conf. +ICMP echo-request (ping) packets are treated just like any other connection +request and are subject to rules and policies.
            • +
          • Interface names of the form <device>:<integer> in +/etc/shorewall/interfaces now generate a Shorewall error at startup (they +always have produced warnings in iptables).
            • +
          • The MERGE_HOSTS variable has been removed from shorewall.conf. +Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents +are determined by BOTH the interfaces and hosts files when there are entries +for the zone in both files.
            • +
          • The routestopped option in the interfaces and hosts file +has been eliminated; use entries in the routestopped file instead.
            • +
          • The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted; you must convert to using the new syntax.
            • +
          • The ALLOWRELATED variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
            • +
          • Late-arriving DNS replies are not dropped by default; +there is no need for your own /etc/shorewall/common file simply to avoid +logging these packets.
            • +
          • The 'firewall', 'functions' and 'version' file have been + moved to /usr/share/shorewall.
            • +
          • The icmp.def file has been removed. If you include it +from /etc/shorewall/icmpdef, you will need to modify that file.
            • +
          • The 'multi' interface option is no longer supported.  Shorewall + will generate rules for sending packets back out the same interface that +they arrived on in two cases:
            • -
            - 
            rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
            -
            - -

            Version >= 1.3.9

            - The 'functions' file has moved to /usr/lib/shorewall/functions. If you - have an application that uses functions from that file, your application - will need to be changed to reflect this change of location.
            +
          + +
            -

            Version >= 1.3.8

            - -

            If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

            - -

            Version >= 1.3.7

            - -

            Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following rules - in their /etc/shorewall/icmpdef file (creating - this file if necessary):

            - -
            	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
            	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
            	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
            	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
            	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
            - -

            Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" - command from that file since the icmp.def file is now empty.

            - -

            Upgrading Bering to - Shorewall >= 1.3.3

            - -

            To properly upgrade with Shorewall version - 1.3.3 and later:

            - +
              +
            • There is an explicit policy for the source zone to or from + the destination zone. An explicit policy names both zones and does not use + the 'all' reserved word.
              • + +
            + +
              +
            • There are one or more rules for traffic for the source zone to +or from the destination zone including rules that use the 'all' reserved +word. Exception: if the source zone and destination zone are the same then +the rule must be explicit - it must name the zone in both the SOURCE and +DESTINATION columns.
              • + +
            +
          • If you followed the advice in FAQ #2 and call find_interface_address +in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
            +
            • + +
          + +
            + +
          + +

          Version >= 1.3.14

          + +      Beginning in version 1.3.14, Shorewall treats entries in /etc/shorewall/masq differently. The change + involves entries with an interface name in the SUBNET (second) + column:
          + +
            +
          • Prior to 1.3.14, Shorewall would detect the FIRST subnet on the + interface (as shown by "ip addr show interface") and would masquerade + traffic from that subnet. Any other subnets that routed through eth1 needed + their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT + applied.
            • +
          • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's + routing table to determine ALL subnets routed through the named interface. + Traffic originating in ANY of those subnets is masqueraded or has SNAT +applied.
            • + +
          + You will need to make a change to your configuration if:
          +
            -
          1. Be sure you have a backup -- you - will need to transcribe any Shorewall configuration - changes that you have made to the new - configuration.
            2. -
          2. Replace the shorwall.lrp package - provided on the Bering floppy with the -later one. If you did not obtain the later -version from Jacques's site, see additional -instructions below.
            3. -
          3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall - entry if present. Then do not forget to - backup root.lrp !
            4. - -
          - -

          The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions - for setting up a two-interface firewall plus you also need to add - the following two Bering-specific rules to /etc/shorewall/rules:

          - -
          - 
          # Bering specific rules:
          # allow loc to fw udp/53 for dnscache to work
          # allow loc to fw tcp/80 for weblet to work
          #
          ACCEPT loc fw udp 53
          ACCEPT loc fw tcp 80
          -
          - -

          Version 1.3.6 and 1.3.7

          - -

          If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions 1.3.6 -and 1.3.7

          - -
            -
          1. - -

            Create the file /etc/shorewall/newnotsyn and in it add - the following rule
            -
            - run_iptables -A newnotsyn -j RETURN -# So that the connection tracking table can be rebuilt
            -                                     # from non-SYN packets - after takeover.
            -  

            -
            2. -
          2. -

            Create /etc/shorewall/common (if you don't already - have that file) and include the following:
            -
            - run_iptables -A common -p tcp --tcp-flags - ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
            -                                                                     - #tracking table.
            - . /etc/shorewall/common.def

            -
            3. +
          3. You have one or more entries in /etc/shorewall/masq with an interface + name in the SUBNET (second) column; and
            4. +
          4. That interface connects to more than one subnetwork.
          - + Two examples:
          +
          +  Example 1 -- Suppose that your current config is as follows:
          +   
          + +
          	[root@gateway test]# cat /etc/shorewall/masq
          	#INTERFACE              SUBNET                  ADDRESS
          	eth0                    eth2                    206.124.146.176
          	eth0                    192.168.10.0/24         206.124.146.176
          	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
          	[root@gateway test]# ip route show dev eth2
          	192.168.1.0/24  scope link
          	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
          	[root@gateway test]#
          + +
          In this case, the second entry in /etc/shorewall/masq is no longer + required.
          +
          + Example 2-- What if your current configuration is like this?
          + +
          	[root@gateway test]# cat /etc/shorewall/masq	
          	#INTERFACE              SUBNET                  ADDRESS	
          	eth0                    eth2                    206.124.146.176
          	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
          	[root@gateway test]# ip route show dev eth2	
          	192.168.1.0/24  scope link
          	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
          	[root@gateway test]#
          + +
          In this case, you would want to change the entry in /etc/shorewall/masq + to:
          +
          + +
          	#INTERFACE              SUBNET                  ADDRESS	
          	eth0                    192.168.1.0/24          206.124.146.176
          	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
          + +     Version 1.3.14 also introduced simplified ICMP echo-request (ping) + handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf + is used to specify that the old (pre-1.3.14) ping handling is to be used + (If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes + is assumed). I don't plan on supporting the old handling indefinitely so + I urge current users to migrate to using the new handling as soon as possible. + See the 'Ping' handling documentation for details.
          + +

          Version 1.3.10

          + If you have installed the 1.3.10 Beta 1 RPM and are now upgrading +to version 1.3.10, you will need to use the '--force' option:
          +
          + +
          + 
          rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
          +
          + +

          Version >= 1.3.9

          + The 'functions' file has moved to /usr/lib/shorewall/functions. +If you have an application that uses functions from that file, your application + will need to be changed to reflect this change of location.
          + +

          Version >= 1.3.8

          + +

          If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

          + +

          Version >= 1.3.7

          + +

          Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following rules + in their /etc/shorewall/icmpdef file (creating + this file if necessary):

          + +
          	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
          	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
          	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
          	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
          	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
          + +

          Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + command from that file since the icmp.def file is now empty.

          + +

          Upgrading Bering to + Shorewall >= 1.3.3

          + +

          To properly upgrade with Shorewall version + 1.3.3 and later:

          + +
            +
          1. Be sure you have a backup +-- you will need to transcribe any Shorewall + configuration changes that you have +made to the new configuration.
            2. +
          2. Replace the shorwall.lrp +package provided on the Bering floppy +with the later one. If you did not obtain +the later version from Jacques's site, +see additional instructions below.
            3. +
          3. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall + entry if present. Then do not forget +to backup root.lrp !
            4. + +
          + +

          The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions + for setting up a two-interface firewall plus you also need to add + the following two Bering-specific rules to /etc/shorewall/rules:

          + +
          + 
          # Bering specific rules:
          # allow loc to fw udp/53 for dnscache to work
          # allow loc to fw tcp/80 for weblet to work
          #
          ACCEPT loc fw udp 53
          ACCEPT loc fw tcp 80
          +
          + +

          Version 1.3.6 and 1.3.7

          + +

          If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions 1.3.6 + and 1.3.7

          + +
            +
          1. + +

            Create the file /etc/shorewall/newnotsyn and in it add + the following rule
            +
            + run_iptables -A newnotsyn -j RETURN + # So that the connection tracking table can be rebuilt
            +                                     # from non-SYN +packets after takeover.
            +  

            +
            2. +
          2. + +

            Create /etc/shorewall/common (if you don't already + have that file) and include the following:
            +
            + run_iptables -A common -p tcp +--tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild +connection
            +                                                                     + #tracking table.
            + . /etc/shorewall/common.def

            +
            3. + +
          +

          Versions >= 1.3.5

          - -

          Some forms of pre-1.3.0 rules file syntax are no - longer supported.

          - + +

          Some forms of pre-1.3.0 rules file syntax are no + longer supported.

          +

          Example 1:

          - -
          + +
          	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
          -
          - +
          +

          Must be replaced with:

          - -
          + +
          	DNAT	net	loc:192.168.1.12:22	tcp	11111
          -
          - -
          +
          + +

          Example 2:

          -
          - -
          +
          + +
          	ACCEPT	loc	fw::3128	tcp	80	-	all
          -
          - -
          +
          + +

          Must be replaced with:

          -
          - -
          +
          + +
          	REDIRECT	loc	3128	tcp	80
          -
          - +
          +

          Version >= 1.3.2

          - -

          The functions and versions files together with the - 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those applications - should be modified accordingly.

          - -

          Last updated 1/25/2003 - - Tom Eastep

          - -

          Copyright - © 2001, 2002, 2003 Thomas M. Eastep.
          -

          + +

          The functions and versions files together with the + 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those applications + should be modified accordingly.

          + +

          Last updated 3/6/2003 - +Tom Eastep

          + +

          Copyright + © 2001, 2002, 2003 Thomas M. Eastep.
          +

          +
          +
          +
          +
          +


          diff --git a/STABLE/documentation/whitelisting_under_shorewall.htm b/STABLE/documentation/whitelisting_under_shorewall.htm index c0a706c56..47518f19d 100644 --- a/STABLE/documentation/whitelisting_under_shorewall.htm +++ b/STABLE/documentation/whitelisting_under_shorewall.htm @@ -1,281 +1,326 @@ + - - - - - -Whitelisting under Shorewall + + + + + + + + + Whitelisting under Shorewall - - - - - - - + + +
          -

          Whitelisting under Shorewall

          -
          + + + + + +
          +

          Whitelisting under Shorewall

          +
          -

          For a brief time, the 1.2 version of Shorewall supported an -/etc/shorewall/whitelist file. This file was intended to contain a list of IP -addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist file was -implemented as a stop-gap measure until the facilities necessary for -implementing white lists using zones was in place. As of Version 1.3 RC1, those -facilities were available.

          -

          White lists are most often used to give special privileges to a -set  of hosts within an organization. Let us suppose that we have the -following environment:

          + +

          For a brief time, the 1.2 version of Shorewall supported an + /etc/shorewall/whitelist file. This file was intended to contain a list of +IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist +file was implemented as a stop-gap measure until the facilities necessary +for implementing white lists using zones was in place. As of Version 1.3 +RC1, those facilities were available.

          + +

          White lists are most often used to give special privileges +to a set  of hosts within an organization. Let us suppose that we have the + following environment:

          +
            -
          • A firewall with three interfaces -- one to the internet, one - to a local network and one to a DMZ.
            • -
          • The local network uses SNAT to the internet and is comprised - of the class B network 10.10.0.0/16 (Note: While this example uses an RFC 1918 - local network, the technique described here in no way depends on that or on - SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).
            • -
          • The network operations staff have workstations with IP - addresses in the class C network 10.10.10.0/24
            • -
          • We want the network operations staff to have full access to - all other hosts.
            • -
          • We want the network operations staff to bypass the transparent - HTTP proxy running on our firewall.
            • +
          • A firewall with three interfaces -- one to the internet, one to +a local network and one to a DMZ.
            • +
          • The local network uses SNAT to the internet and is comprised of +the class B network 10.10.0.0/16 (Note: While this example uses an RFC 1918 + local network, the technique described here in no way depends on that or +on SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).
            • +
          • The network operations staff have workstations with IP addresses +in the class C network 10.10.10.0/24
            • +
          • We want the network operations staff to have full access to all +other hosts.
            • +
          • We want the network operations staff to bypass the transparent + HTTP proxy running on our firewall.
            • +
          +

          The basic approach will be that we will place the operations -staff's class C in its own zone called ops. Here are the appropriate -configuration files:

          + staff's class C in its own zone called ops. Here are the appropriate + configuration files:

          +

          Zone File

          -
          + +
          - - - - - - + - - - - - - - - - - - - - - - - - - - - -
          - ZONE - DISPLAY - COMMENTS
          netNetInternet
          opsOperationsOperations Staff's Class C
          locLocalLocal Class B
          dmzDMZDemilitarized zone
          -
          -

          The ops zone has been added to the standard 3-zone zones file -- since -ops is a sub-zone of loc, we list it BEFORE loc.

          + ZONE + DISPLAY + COMMENTS + + + net + Net + Internet + + + ops + Operations + Operations Staff's Class C + + + loc + Local + Local Class B + + + dmz + DMZ + Demilitarized zone + + + + +
          + +

          The ops zone has been added to the standard 3-zone zones file -- +since ops is a sub-zone of loc, we list it BEFORE loc.

          +

          Interfaces File

          -
          + +
          - - - - - - + - - - - - - - - - - - - - - - - - - -
          - ZONE - INTERFACE - BROADCAST - OPTIONS
          neteth0<whatever><options>
          dmzeth1<whatever>routestopped
          -eth210.10.255.255 
          -
          -

          Because eth2 interfaces to two zones (ops and loc), we -don't specify a zone for it here.

          + ZONE + INTERFACE + BROADCAST + OPTIONS + + + net + eth0 + <whatever> + <options> + + + dmz + eth1 + <whatever> +
          + + + + - + eth2 + 10.10.255.255 +   + + + + + +
          + +

          Because eth2 interfaces to two zones (ops and loc), +we don't specify a zone for it here.

          +

          Hosts File

          -
          + +
          + + - - - - - + - - - - - - - - - - - - - - -
          - ZONE - HOST(S) - OPTIONS
          opseth2:10.10.10.0/24routestopped
          loceth2:0.0.0.0/0 
          -
          + ZONE + HOST(S) + OPTIONS + + + ops + eth2:10.10.10.0/24 +
          + + + + loc + eth2:0.0.0.0/0 +   + + + + + +
          +

          Here we define the ops and loc zones. When Shorewall is -stopped, only the hosts in the ops zone will be allowed to access the -firewall and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than -10.10.0.0/16 so that the limited broadcast address (255.255.255.255) falls into -that zone. If I used 10.10.0.0/16 then I would have to have a separate entry for -that special address.

          +stopped, only the hosts in the ops zone will be allowed to access the + firewall and the DMZ. I use 0.0.0.0/0 to define the loc zone rather +than 10.10.0.0/16 so that the limited broadcast address (255.255.255.255) +falls into that zone. If I used 10.10.0.0/16 then I would have to have a +separate entry for that special address.

          +

          Policy File

          -
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + +
          + -
          SOURCEDEST - POLICY - LOG LEVELLIMIT:BURST
          opsallACCEPT  
          allopsCONTINUE  
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          -
          -

          Two entries for ops have been added to the standard 3-zone policy file. -WARNING: You must be running Shorewall 1.3.1 or later -for the above to work properly.

          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          SOURCEDEST POLICY LOG LEVELLIMIT:BURST
          opsallACCEPT  
          allopsCONTINUE  
          locnetACCEPT  
          netallDROPinfo 
          allallREJECTinfo 
          + + +

          Two entries for ops have been added to the standard 3-zone policy +file.

          +

          Rules File

          + +
          + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
          ACTIONSOURCEDEST PROTODEST
          + PORT(S)          		SOURCE
          + PORT(S)          		ORIGINAL
          + DEST
          REDIRECTloc!ops3128tcphttp  
          ...      
          +
          + +

          This is the rule that transparently redirects web traffic to the transparent + proxy running on the firewall. The SOURCE column explicitly excludes the +ops zone from the rule.

          +

          Routestopped File

          +
          - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + - -
          ACTIONSOURCEDEST - PROTODEST
          - PORT(S)          		SOURCE
          - PORT(S)          		ORIGINAL
          - DEST
          REDIRECTloc!ops3128tcphttp  
          ...      
          INTERFACE
          +           		HOST(S)
          eth1
          +
          +
          eth2
          +           		10.10.10.0/24
          + + + +
          -

          This is the rule that transparently redirects web traffic to the transparent -proxy running on the firewall. The SOURCE column explicitly excludes the ops -zone from the rule.

          - -

          - Updated 5/31/2002 - Tom -Eastep -

          + + +

          Updated 2/18/2003 - Tom Eastep +

          - -

          Copyright - © 2002 Thomas M. Eastep.

          + +

          Copyright + © 2002, 2003Thomas M. Eastep.

          - - - - \ No newline at end of file +
          +
          + + diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index 8f1c374d9..40cac8cd8 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -1,16 +1,16 @@ #!/bin/sh # -# Script to back out the installation of Shoreline Firewall and to restore the previous version of +# Script to back out the installation of Shoreline Firewall and to restore the previous version of # the program # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Shorewall documentation is available at http://seattlefirewall.dyndns.org # # This program is free software; you can redistribute it and/or modify -# it under the terms of Version 2 of the GNU General Public License +# it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, @@ -25,10 +25,10 @@ # Usage: # # You may only use this script to back out the installation of the version -# shown below. Simply run this script to revert to your prior version of +# shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.3.14 +VERSION=1.4.0 usage() # $1 = exit status { @@ -46,17 +46,21 @@ restore_file() # $1 = file to restore echo "ERROR: Could not restore $1" exit 1 fi - fi + fi } -if [ ! -f /usr/lib/shorewall/version-${VERSION}.bkout ]; then +if [ ! -f /usr/share/shorewall/version-${VERSION}.bkout ]; then echo "Shorewall Version $VERSION is not installed" exit 1 fi echo "Backing Out Installation of Shorewall $VERSION" -if [ -L /usr/lib/shorewall/firewall ]; then +if [ -L /usr/share/shorewall/init ]; then + FIREWALL=`ls -l /usr/share/shorewall/firewall | sed 's/^.*> //'` + restore_file $FIREWALL + restore_file /usr/share/shorewall/firewall +elif [ -L /usr/lib/shorewall/firewall ]; then FIREWALL=`ls -l /usr/lib/shorewall/firewall | sed 's/^.*> //'` restore_file $FIREWALL elif [ -L /var/lib/shorewall/firewall ]; then @@ -73,7 +77,7 @@ restore_file /sbin/shorewall [ -f /etc/shorewall.conf.$VERSION ] && rm -f /etc/shorewall.conf.$VERSION restore_file /etc/shorewall/shorewall.conf - + restore_file /etc/shorewall/functions restore_file /usr/lib/shorewall/functions restore_file /var/lib/shorewall/functions @@ -88,7 +92,7 @@ restore_file /etc/shorewall/zones restore_file /etc/shorewall/policy restore_file /etc/shorewall/interfaces - + restore_file /etc/shorewall/hosts restore_file /etc/shorewall/rules @@ -127,6 +131,8 @@ restore_file /etc/shorewall/stop restore_file /etc/shorewall/stopped +restore_file /etc/shorewall/ecn + if [ -f /usr/lib/shorewall/version-${VERSION}.bkout ]; then restore_file /usr/lib/shorewall/version oldversion="`cat /usr/lib/shorewall/version`" diff --git a/STABLE/firewall b/STABLE/firewall index af76eea43..03630b5fe 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -1,8 +1,8 @@ #!/bin/sh # -# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V1.3 6/14/2002 +# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V1.4 3/14/2003 # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # @@ -12,7 +12,7 @@ # Complete documentation is available at http://shorewall.net # # This program is free software; you can redistribute it and/or modify -# it under the terms of Version 2 of the GNU General Public License +# it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, @@ -29,18 +29,17 @@ # # Commands are: # -# shorewall start Starts the firewall +# shorewall start Starts the firewall # shorewall restart Restarts the firewall # shorewall stop Stops the firewall # shorewall status Displays firewall status # shorewall reset Resets iptabless packet and # byte counts -# shorewall clear Remove all Shorewall chains +# shorewall clear Remove all Shorewall chains # and rules/policies. # shorewall refresh . Rebuild the common chain -# shorewall check Verify the more heavily-used -# configuration files. - +# shorewall check Verify the more heavily-used +# configuration files. # # Search a list looking for a match -- returns zero if a match found # 1 otherwise @@ -95,8 +94,8 @@ error_message() # $* = Error Message # fatal_error() # $* = Error Message { - echo " $@" >&2 - stop_firewall + echo " Error: $@" >&2 + [ $command = check ] || stop_firewall exit 2 } @@ -106,7 +105,7 @@ fatal_error() # $* = Error Message # startup_error() # $* = Error Message { - echo " $@" >&2 + echo " Error: $@" >&2 my_mutex_off [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR kill $$ @@ -225,13 +224,12 @@ run_tc() { # variable ${1}_exists and set its value to Yes to indicate that the chain now # exists. # -createchain() # $1 = chain name, $2 = If non-null, don't create default rules +createchain() # $1 = chain name, $2 = If "yes", create default rules { run_iptables -N $1 - if [ $# -eq 1 ]; then - state="ESTABLISHED" - [ -n "$ALLOWRELATED" ] && state="$state,RELATED" + if [ $2 = yes ]; then + state="ESTABLISHED,RELATED" run_iptables -A $1 -m state --state $state -j ACCEPT [ -z "$NEWNOTSYN" ] && \ run_iptables -A $1 -m state --state NEW -p tcp ! --syn -j newnotsyn @@ -259,7 +257,7 @@ chain_exists() # $1 = chain name { qt iptables -L $1 -n } - + # # Query NetFilter about the existence of a mangle chain # @@ -267,13 +265,13 @@ mangle_chain_exists() # $1 = chain name { qt iptables -t mangle -L $1 -n } - + # # Ensure that a chain exists (create it if it doesn't) # ensurechain() # $1 = chain name { - havechain $1 || createchain $1 + havechain $1 || createchain $1 yes } # @@ -311,7 +309,7 @@ havenatchain() # $1 = name of chain } # -# Ensure that a chain exists (create it if it doesn't) +# Ensure that a nat chain exists (create it if it doesn't) # ensurenatchain() # $1 = chain name { @@ -341,7 +339,7 @@ deletechain() # $1 = name of chain is_policy_chain() # $1 = name of chain { eval test \"\$${1}_is_policy\" = Yes -} +} # # Set a standard chain's policy @@ -367,6 +365,14 @@ flushnat() # $1 = name of chain run_iptables -t nat -F $1 } +# +# Flush one of the Mangle table chains +# +flushmangle() # $1 = name of chain +{ + run_iptables -t mangle -F $1 +} + # # Chain name base for an interface # @@ -374,7 +380,7 @@ chain_base() #$1 = interface { local c=${1%%+*} - case $c in + case $c in *.*) echo ${c%.*}_${c#*.} ;; @@ -388,7 +394,7 @@ chain_base() #$1 = interface # Find interfaces to a given zone # # Search the variables representing the contents of the interfaces file and -# for each record matching the passed ZONE, echo the expanded contents of +# for each record matching the passed ZONE, echo the expanded contents of # the "INTERFACE" column # find_interfaces() # $1 = interface zone @@ -456,7 +462,15 @@ dnat_chain() # $1 = zone # snat_chain() # $1 = zone { - echo ${1}_snat + echo `chain_base $1`_snat +} + +# +# ECN Chain to an interface +# +ecn_chain() # $1 = interface +{ + echo ${1}_ecn } # @@ -494,16 +508,19 @@ determine_interfaces() { for zone in $zones; do interfaces=`find_interfaces $zone` interfaces=`echo $interfaces` # Remove extra trash - eval ${zone}_interfaces="\$interfaces" + eval ${zone}_interfaces=\"\$interfaces\" done } - + # # Determine the defined hosts in each zone and generate report # determine_hosts() { - do_a_zone() - { + + for zone in $zones; do + hosts=`find_hosts $zone` + hosts=`echo $hosts` # Remove extra trash + eval interfaces=\$${zone}_interfaces for interface in $interfaces; do @@ -513,12 +530,9 @@ determine_hosts() { hosts="$hosts $interface:0.0.0.0/0" fi done - } - recalculate_interfaces() - { interfaces= - + for host in $hosts; do interface=${host%:*} if ! list_search $interface $interfaces; then @@ -531,32 +545,6 @@ determine_hosts() { done eval ${zone}_interfaces="\$interfaces" - } - - for zone in $zones; do - hosts=`find_hosts $zone` - hosts=`echo $hosts` # Remove extra trash - - if [ -n "MERGE_HOSTS" ]; then - # - # Zone will be the union of its host and interface definitions - # - do_a_zone - recalculate_interfaces - elif [ -n "$hosts" ]; then - # - # Zone is defined in terms of hosts -- derive the interface list - # from the host list - # - recalculate_interface - else - # - # If no hosts are defined for a zone then the zone consists of any - # host that can send us messages via the interfaces to the zone - # - do_a_zone - fi - eval ${zone}_hosts="\$hosts" if [ -n "$hosts" ]; then @@ -564,7 +552,7 @@ determine_hosts() { display_list "$display Zone:" $hosts else error_message "Warning: Zone $zone is empty" - fi + fi done } @@ -586,41 +574,44 @@ validate_interfaces_file() { [ "x$z" = "x-" ] && z= - if [ -n "$z" ]; then + if [ -n "$z" ]; then validate_zone $z || startup_error "Invalid zone ($z) in record \"$r\"" fi - [ "x$interface" = "xlo" ] && \ - startup_error "Error: The loopback interface (lo) may not be defined in /etc/shorewall/interfaces" + if [ -n "`ip link show $interface 2> /dev/null | grep LOOPBACK`" ]; then + startup_error "The loopback interface ($interface) may not be defined in /etc/shorewall/interfaces" + fi list_search $interface $all_interfaces && \ - startup_error "Error: Duplicate Interface $interface" - + startup_error "Duplicate Interface $interface" + + case $interface in + *:*) + startup_error "Invalid Interface Name: $interface" + ;; + esac + all_interfaces="$all_interfaces $interface" options=`separate_list $options` interface=`chain_base $interface` - + eval ${interface}_broadcast="$subnet" eval ${interface}_zone="$z" eval ${interface}_options=\"$options\" for option in $options; do case $option in - dhcp|routestopped|norfc1918|multi|tcpflags) + dhcp|norfc1918|tcpflags) ;; routefilter|dropunclean|logunclean|blacklist|proxyarp|maclist|-) ;; - noping|filterping) - [ -n "$OLD_PING_HANDLING" ] || \ - startup_error "Option $option only allowed with old ping handling" - ;; *) error_message "Warning: Invalid option ($option) in record \"$r\"" ;; esac done - - [ -z "$all_interfaces" ] && startup_error "Error: No Interfaces Defined" + + [ -z "$all_interfaces" ] && startup_error "No Interfaces Defined" done < $TMP_DIR/interfaces } @@ -642,7 +633,7 @@ validate_hosts_file() { for option in `separate_list $options`; do case $option in - routestopped|maclist|-) + maclist|-) ;; *) error_message "Warning: Invalid option ($option) in record \"$r\"" @@ -661,331 +652,6 @@ validate_hosts_file() { mac_match() # $1 = MAC address formated as described above { echo "--match mac --mac-source `echo $1 | sed 's/~//;s/-/:/g'`" -} - -# -# validate a record from the rules file -# -# The caller has loaded the column contents from the record into the following -# variables: -# -# target clients servers protocol ports cports address -# -# and has loaded a space-separated list of their values in "rule". -# -validate_rule() { - # - # Ensure that the passed comma-separated list has 15 or fewer elements - # - validate_list() { - local temp="`separate_list $1`" - - [ `echo $temp | wc -w` -le 15 ] - } - - # - # validate one rule - # - validate_a_rule() { - # - # Determine the format of the client - # - cli= - - [ -n "$client" ] && case "$client" in - -) - ;; - *:*) - cli="-i ${client%:*} -s ${client#*:}" - ;; - ~*) - cli=`mac_match $client` - ;; - *.*.*) - # - # IP Address, address or subnet - # - cli="-s $client" - ;; - *) - # - # Assume that this is a device name - # - cli="-i $client" - ;; - esac - - dest_interface= - - [ -n "$server" ] && case "$server" in - -) - serv= - ;; - *.*.*) - serv=$server - ;; - ~*) - startup_error "Error: Rule \"$rule\" - Destination may not be specified by MAC Address" - ;; - *) - dest_interface="-o $server" - serv= - ;; - esac - # - # Setup PROTOCOL, PORT and STATE variables - # - sports="" - dports="" - state="-m state --state NEW" - proto=$protocol - addr=$address - servport=$serverport - - case $proto in - tcp|udp|TCP|UDP|6|17) - [ -n "$port" ] && [ "x${port}" != "x-" ] && \ - dports="--dport $port" - [ -n "$cport" ] && [ "x${cport}" != "x-" ] && \ - sports="--sport $cport" - ;; - icmp|ICMP|0) - [ -n "$port" ] && dports="--icmp-type $port" - state="" - ;; - related|RELATED) - proto= - state="-m state --state RELATED" - ;; - *) - state= - [ -n "$port" ] && [ "x${port}" != "x-" ] && \ - startup_error "Port number not allowed with protocol " \ - "\"$proto\"; rule: \"$rule\"" - ;; - esac - - proto="${proto:+-p $proto}" - - case "$logtarget" in - REJECT) - target=reject - [ -n "$servport" ] && \ - startup_error "Error: server port may not be specified in a REJECT rule;"\ - "rule: \"$rule\"" - ;; - ACCEPT) - [ -n "$servport" ] && \ - startup_error "Error: server port may not be specified in an ACCEPT rule;"\ - "rule: \"$rule\"" - ;; - REDIRECT) - [ -n "$serv" ] && startup_error "Error: REDIRECT rules cannot"\ - " specify a server IP; rule: \"$rule\"" - servport=${servport:=$port} - ;; - DNAT) - [ -n "$serv" ] || startup_error "Error: DNAT rules require a" \ - " server address; rule: \"$rule\"" - ;; - esac - - if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" ]; then - error_message "Warning -- Rule \"$rule\" is a POLICY" - error_message " -- and should be moved to the policy file" - fi - - if [ -n "${serv}${servport}" ]; then - # - # Destination is a Specific Server or we're redirecting a port - # - if [ -n "$addr" -a "$addr" != "$serv" ]; then - # - # Must use Prerouting DNAT - # - if [ -z "$NAT_ENABLED" ]; then - startup_error \ - "Error - Rule \"$rule\" requires NAT which is disabled" - fi - - if [ "$target" != "ACCEPT" ]; then - startup_error "Error - Only ACCEPT rules may specify " \ - "port mapping; rule \"$rule\"" - fi - fi - else - [ -n "$addr" ] && startup_error \ - "Error: An ADDRESS ($addr) is only allowed in" \ - " a DNAT or REDIRECT rule: \"$rule\"" - fi - } - # - # V a l i d a t e _ R u l e S t a r t s H e r e - # - # Parse the Target and Clients columns - # - if [ "$target" = "${target%:*}" ]; then - loglevel= - else - loglevel="${target#*:}" - target="${target%:*}" - expandv loglevel - fi - - logtarget="$target" - # - # DNAT and REDIRECT targets were implemented in version 1.3 to replace - # an older syntax. We simply map the new syntax into the old and proceed; - # that way, people who have files with the old syntax don't need to - # convert right away. - # - case $target in - DNAT) - target=ACCEPT - address=${address:=detect} - ;; - DNAT-) - target=ACCEPT - address=${address:=detect} - logtarget=DNAT - ;; - REDIRECT) - target=ACCEPT - address=${address:=all} - if [ "x-" = "x$servers" ]; then - servers=$FW - else - servers="fw::$servers" - fi - ;; - ACCEPT|DROP|REJECT) - ;; - *) - startup_error "Error: Invalid target;" \ - " rule: \"$rule\"" - - esac - - if [ "$clients" = "${clients%:*}" ]; then - clientzone="$clients" - clients= - else - clientzone="${clients%%:*}" - clients="${clients#*:}" - [ -z "$clientzone" -o -z "$clients" ] && \ - startup_error "Error: Empty source zone or qualifier: rule \"$rule\"" - fi - - if [ "$clientzone" = "${clientzone%\!*}" ]; then - excludezones= - else - excludezones="${clientzone#*\!}" - clientzone="${clientzone%\!*}" - - [ "$logtarget" = DNAT ] || [ "$logtarget" = REDIRECT ] ||\ - startup_error "Error: Exclude list only allowed with DNAT or REDIRECT" - fi - # - # Validate the Source Zone - # - if ! validate_zone $clientzone; then - [ "x$clientzone" = xall ] || startup_error "Error: Undefined Client Zone in rule \"$rule\"" - fi - - source=$clientzone - - [ $source = $FW ] && source_hosts= || eval source_hosts=\"\$${source}_hosts\" - - # - # Parse the servers column - # - if [ "$servers" = "${servers%:*}" ] ; then - serverzone="$servers" - servers= - serverport= - else - serverzone="${servers%%:*}" - servers="${servers#*:}" - if [ "$servers" != "${servers%:*}" ] ; then - serverport="${servers#*:}" - servers="${servers%:*}" - [ -z "$serverzone" -o -z "$serverport" ] && \ - startup_error "Error: Empty destination zone or server port: rule \"$rule\"" - else - serverport= - [ -z "$serverzone" -o -z "$servers" ] && \ - startup_error "Error: Empty destination zone or qualifier: rule \"$rule\"" - fi - fi - # - # Validate the destination zone - # - if ! validate_zone $serverzone; then - [ "x$serverzone" = xall ] || startup_error "Error: Undefined Server Zone in rule \"$rule\"" - fi - - dest=$serverzone - - chain=${source}2${dest} - - if [ "x$chain" = x${FW}2${FW} ]; then - case $logtarget in - REDIRECT) - ;; - *) - error_message "WARNING: fw -> fw rules are not supported; rule \"$rule\" ignored" - return - ;; - esac - fi - - # - # Check length of port lists if MULTIPORT set - # - if [ -n "$MULTIPORT" ]; then - validate_list $ports || - error_message "Warning: Too many destination ports: Rule \"$rule\"" - validate_list $cports || - error_message "Warning: Too many source ports: Rule \"$rule\"" - fi - - # - # Iterate through the various lists validating individual rules - # - for client in `separate_list ${clients:=-}`; do - for server in `separate_list ${servers:=-}`; do - for port in `separate_list ${ports:=-}`; do - for cport in `separate_list ${cports:=-}`; do - validate_a_rule - done - done - done - done - - echo " Rule \"$rule\" validated." -} - -# -# validate the rules file -# -validate_rules() # $1 = name of rules file -{ - strip_file rules - - while read target clients servers protocol ports cports address; do - expandv clients servers protocol ports cports address - case "$target" in - - ACCEPT*|DROP*|REJECT*|DNAT*|REDIRECT*) - rule="`echo $target $clients $servers $protocol $ports $cports $address`" - validate_rule - ;; - *) - rule="`echo $target $clients $servers $protocol $ports $cports $address`" - startup_error "Error: Invalid Target - rule \"$rule\" ignored" - ;; - esac - done < $TMP_DIR/rules } # @@ -1013,7 +679,7 @@ validate_policy() all_policy_chains= - strip_file policy $policy + strip_file policy while read client server policy loglevel synparams; do expandv client server policy loglevel synparams @@ -1027,7 +693,7 @@ validate_policy() ;; *) if ! validate_zone $client; then - startup_error "Error: Undefined zone $client" + startup_error "Undefined zone $client" fi esac @@ -1037,7 +703,7 @@ validate_policy() ;; *) if ! validate_zone $server; then - startup_error "Error: Undefined zone $server" + startup_error "Undefined zone $server" fi esac @@ -1045,17 +711,17 @@ validate_policy() ACCEPT|REJECT|DROP|CONTINUE) ;; *) - startup_error "Error: Invalid policy $policy" + startup_error "Invalid policy $policy" ;; esac chain=${client}2${server} [ "x$chain" = "x${FW}2${FW}" ] && \ - startup_error "Error: fw->fw policy not allowed: $policy" - + startup_error "fw->fw policy not allowed: $policy" + if is_policy_chain $chain ; then - startup_error "Error: Duplicate policy $policy" + startup_error "Duplicate policy $policy" fi [ "x$loglevel" = "x-" ] && loglevel= @@ -1084,7 +750,7 @@ validate_policy() else for zone in $zones $FW all; do eval pc=\$${zone}2${server}_policychain - + if [ -z "$pc" ]; then eval ${zone}2${server}_policychain=$chain print_policy $zone $server @@ -1094,16 +760,16 @@ validate_policy() elif [ -n "$serverwild" ]; then for zone in $zones $FW all; do eval pc=\$${client}2${zone}_policychain - + if [ -z "$pc" ]; then - eval ${client}2${zone}_policychain=$chain + eval ${client}2${zone}_policychain=$chain print_policy $client $zone fi done else eval ${chain}_policychain=${chain} print_policy $client $server - fi + fi done < $TMP_DIR/policy } @@ -1127,33 +793,13 @@ find_broadcasts() { done } -# -# Find interface broadcast addresses -# -find_interface_broadcasts() # $1 = Interface name -{ - eval bcast=\$`chain_base ${1}`_broadcast - - if [ "x$bcast" = "xdetect" ]; then - addr="`ip addr show $interface 2> /dev/null`" - if [ -n "`echo "$addr" | grep 'inet.*brd '`" ]; then - addr="`echo "$addr" | \ - grep "inet " | sed 's/^.* inet.*brd //;s/scope.*//'`" - echo $addr | cut -d' ' -f 1 - fi - elif [ "x${bcast}" != "x-" ]; then - echo `separate_list $bcast` - fi - -} - # # Find interface address--returns the first IP address assigned to the passed # device # find_interface_address() # $1 = interface { - # + # # get the line of output containing the first IP address # addr=`ip addr show $1 2> /dev/null | grep inet | head -n1` @@ -1194,7 +840,7 @@ find_hosts_by_option() # $1 = option eval options=\$`chain_base ${interface}`_options list_search $1 $options && \ echo ${interface}:0.0.0.0/0 - done + done } # @@ -1250,6 +896,10 @@ stop_firewall() { case $command in stop|clear) ;; + check) + kill $$ + exit 2 + ;; *) set +x ;; @@ -1257,6 +907,8 @@ stop_firewall() { stopping="Yes" + terminator= + deletechain shorewall run_user_exit stop @@ -1275,9 +927,9 @@ stop_firewall() { deleteallchains - hosts="`find_hosts_by_option routestopped`" + hosts= - strip_file routestopped + strip_file routestopped while read interface host; do expandv interface host @@ -1347,7 +999,7 @@ clear_firewall() { run_iptables -F echo 1 > /proc/sys/net/ipv4/ip_forward - + setpolicy INPUT ACCEPT setpolicy FORWARD ACCEPT setpolicy OUTPUT ACCEPT @@ -1374,7 +1026,7 @@ setup_tunnels() # $1 = name of tunnels file run_iptables -A $outchain -p 51 -d $1 -j ACCEPT run_iptables -A $outchain -p udp -d $1 --dport 500 --sport 500 $options - + if [ $2 = ipsec ]; then run_iptables -A $inchain -p udp -s $1 --sport 500 --dport 500 $options else @@ -1481,7 +1133,7 @@ setup_tunnels() # $1 = name of tunnels file else error_message "Invalid gateway zone ($z)" \ " -- Tunnel \"$tunnel\" Ignored" - fi + fi done < $TMP_DIR/tunnels } @@ -1524,8 +1176,6 @@ setup_proxy_arp() { > ${STATEDIR}/proxyarp - strip_file proxyarp - while read address interface external haveroute; do expandv address interface external haveroute setup_one_proxy_arp @@ -1580,7 +1230,7 @@ setup_mac_lists() { eth*|wlan*) ;; *) - fatal_error "Error: MAC verification is only supported on ethernet and 802.11b devices: $interface" + fatal_error "MAC verification is only supported on ethernet and 802.11b devices: $interface" ;; esac @@ -1589,7 +1239,6 @@ setup_mac_lists() { # # Process the maclist file producing the verification rules # - strip_file maclist while read interface mac addresses; do expandv interface mac addresses @@ -1597,9 +1246,9 @@ setup_mac_lists() { chain=`mac_chain $interface` if ! havechain $chain ; then - fatal_error "Error: No hosts on $interface have the maclist option specified" + fatal_error "No hosts on $interface have the maclist option specified" fi - + macpart=`mac_match $mac` if [ -z "$addresses" ]; then @@ -1631,7 +1280,7 @@ setup_mac_lists() { blob=`ip addr show $interface 2> /dev/null | grep inet | sed 's/inet //; s/brd //; s/scope.*//;'` [ -z "$blob" ] && \ - fatal_error "Error: Interface $interface must be up before Shorewall can start" + fatal_error "Interface $interface must be up before Shorewall can start" set -- $blob @@ -1663,13 +1312,13 @@ setup_mac_lists() { for hosts in $maclist_hosts; do interface=${hosts%:*} hosts=${hosts#*:} - for chain in `first_chains $interface` ; do + for chain in `first_chains $interface` ; do run_iptables -A $chain -s $hosts -m state --state NEW \ -j `mac_chain $interface` done done -} - +} + # # Set up SYN flood protection # @@ -1690,7 +1339,7 @@ setup_syn_flood_chain () # # Enable SYN flood protection on a chain -# +# # Insert a jump rule to the protection chain from the first chain. Inserted # as the second rule and restrict the jump to SYN packets # @@ -1730,13 +1379,11 @@ setup_nat() { # > ${STATEDIR}/nat - strip_file nat - echo "Setting up NAT..." while read external interface internal allints localnat; do expandv external interface internal allints localnat - + iface=${interface%:*} if [ -n "$ADD_IP_ALIASES" ]; then @@ -1747,7 +1394,7 @@ setup_nat() { then addnatrule nat_in -d $external -j DNAT --to-destination $internal addnatrule nat_out -s $internal -j SNAT --to-source $external - + if [ "$localnat" = "Yes" -o "$localnat" = "yes" ]; then run_iptables2 -t nat -A OUTPUT -d $external \ -j DNAT --to-destination $internal @@ -1787,7 +1434,55 @@ delete_nat() { } # -# Process a TC Rule - $marking_chain is assumed to contain the name of the +# Setup ECN disabling rules +# +setup_ecn() # $1 = file name +{ + local interfaces + local hosts + local h + + strip_file ecn $1 + + echo "Processing $1..." + + while read interface host; do + expandv interface host + list_search $interface $all_interfaces || \ + startup_error "Unknown interface $interface" + list_search $interface $interfaces || \ + interfaces="$interfaces $interface" + [ "x$host" = "x-" ] && host= + for h in `separate_list ${host:-0.0.0.0/0}`; do + hosts="$hosts $interface:$h" + done + done < $TMP_DIR/ecn + + if [ -n "$interfaces" ]; then + echo "Setting up ECN control on${interfaces}..." + + for interface in $interfaces; do + chain=`ecn_chain $interface` + if mangle_chain_exists $chain; then + flushmangle $chain + else + run_iptables -t mangle -N $chain + run_iptables -t mangle -A POSTROUTING -p tcp -o $interface -j $chain + run_iptables -t mangle -A OUTPUT -p tcp -o $interface -j $chain + fi + done + + for host in $hosts; do + interface=${host%:*} + h=${host#*:} + run_iptables -t mangle -A `ecn_chain $interface` -p tcp -d $h -j ECN --ecn-tcp-remove + echo " ECN Disabled to $h through $interface" + done + fi +} + +# +# Process a TC Rule - $marking_chain is assumed to contain the name of the # default marking chain # process_tc_rule() @@ -1809,19 +1504,19 @@ process_tc_rule() ;; *) if ! list_search $source $all_interfaces; then - fatal_error "Error: Unknown interface $source in rule \"$rule\"" + fatal_error "Unknown interface $source in rule \"$rule\"" fi - + r="-i $source " ;; esac fi if [ "$mark" != "${mark%:*}" ]; then - + [ "$chain" = tcout ] && \ fatal_error "Chain designator not allowed when source is \$FW; rule \"$rule\"" - + case "${mark#*:}" in p|P) chain=tcpre @@ -1836,7 +1531,7 @@ process_tc_rule() mark="${mark%:*}" fi - + [ "x$dest" = "x-" ] || r="${r}-d $dest " [ "$proto" = "all" ] || r="${r}-p $proto " [ "x$port" = "x-" ] || r="${r}--dport $port " @@ -1866,7 +1561,7 @@ setup_tc1() { # # Create the TC mangle chains # - + run_iptables -t mangle -N tcpre run_iptables -t mangle -N tcfor run_iptables -t mangle -N tcout @@ -1883,7 +1578,7 @@ setup_tc1() { # # Link to the TC mangle chains from the main chains # - + run_iptables -t mangle -A FORWARD -j tcfor run_iptables -t mangle -A PREROUTING -j tcpre run_iptables -t mangle -A OUTPUT -j tcout @@ -1924,6 +1619,66 @@ delete_tc() done } +# +# Check the configuration +# +check_config() { + + disclaimer() { + echo + echo "WARNING: THE 'check' COMMAND IS TOTALLY UNSUPPORTED AND PROBLEM" + echo " REPORTS COMPLAINING ABOUT ERRORS THAT IT DIDN'T CATCH" + echo " WILL NOT BE ACCEPTED" + echo + } + + disclaimer + + echo "Verifying Configuration..." + + verify_os_version + + load_kernel_modules + + echo "Determining Zones..." + + determine_zones + + [ -z "$zones" ] && startup_error "ERROR: No Zones Defined" + + display_list "Zones:" $zones + + echo "Validating interfaces file..." + + validate_interfaces_file + + echo "Validating hosts file..." + + validate_hosts_file + + echo "Determining Hosts in Zones..." + + determine_interfaces + determine_hosts + + echo "Validating rules file..." + + rules=`find_file rules` + strip_file rules $rules + process_rules + + echo "Validating policy file..." + + validate_policy + + rm -rf $TMP_DIR + + echo "Configuration Validated" + + disclaimer + +} + # # Refresh queuing and classes # @@ -1934,7 +1689,7 @@ refresh_tc() { [ -n "$CLEAR_TC" ] && delete_tc [ -n "$MARK_IN_FORWARD_CHAIN" ] && chain=tcfor || chain=tcpre - + if mangle_chain_exists $chain; then # # Flush the TC mangle chains @@ -1950,7 +1705,7 @@ refresh_tc() { while read mark sources dests proto ports sports; do expandv mark sources dests proto ports sports rule=`echo "$mark $sources $dests $proto $ports $sports"` - process_tc_rule + process_tc_rule done < $TMP_DIR/tcrules run_user_exit tcstart @@ -1964,6 +1719,8 @@ refresh_tc() { # Add a NAT rule - Helper function for the rules file processor # # The caller has established the following variables: +# command = The current command -- if 'check', we just go through +# the motions. # cli = Source IP, interface or MAC Specification # serv = Destination IP Specification # servport = Port the server is listening on @@ -1978,19 +1735,18 @@ refresh_tc() { add_nat_rule() { local chain - # Be sure NAT is enabled + # Be sure we should and can NAT - if [ -z "$NAT_ENABLED" ]; then - fatal_error \ - "Error - Rule \"$rule\" requires NAT which is disabled" - fi - - # Onle ACCEPT (plus DNAT and REDIRECT) may result in NAT - - if [ "$target" != "ACCEPT" ]; then - fatal_error "Error - Only DNAT and REDIRECT rules may specify " \ - "port mapping; rule \"$rule\"" - fi + case $logtarget in + DNAT|REDIRECT) + if [ -z "$NAT_ENABLED" ]; then + fatal_error "Rule \"$rule\" requires NAT which is disabled" + fi + ;; + *) + fatal_error "Only DNAT and REDIRECT rules may specify port mapping; rule \"$rule\"" + ;; + esac # Parse SNAT address if any @@ -2031,32 +1787,34 @@ add_nat_rule() { # Generate nat table rules - if [ "$source" = "$FW" ]; then - run_iptables2 -t nat -A OUTPUT $proto $sports -d $addr \ - $multiport $dports -j $target1 - else - chain=`dnat_chain $source` - - if [ -n "$excludezones" ]; then - chain=nonat${nonat_seq} - nonat_seq=$(($nonat_seq + 1)) - createnatchain $chain - addnatrule `dnat_chain $source` -j $chain - for z in $excludezones; do - eval hosts=\$${z}_hosts - for host in $hosts; do - for adr in $addr; do - addnatrule $chain $proto -s ${host#*:} \ - $multiport $sports -d $adr $dports -j RETURN + if [ $command != check ]; then + if [ "$source" = "$FW" ]; then + run_iptables2 -t nat -A OUTPUT $proto $sports -d $addr \ + $multiport $dports -j $target1 + else + chain=`dnat_chain $source` + + if [ -n "$excludezones" ]; then + chain=nonat${nonat_seq} + nonat_seq=$(($nonat_seq + 1)) + createnatchain $chain + addnatrule `dnat_chain $source` -j $chain + for z in $excludezones; do + eval hosts=\$${z}_hosts + for host in $hosts; do + for adr in $addr; do + addnatrule $chain $proto -s ${host#*:} \ + $multiport $sports -d $adr $dports -j RETURN + done done done + fi + + for adr in $addr; do + addnatrule $chain $proto $cli $sports \ + -d $adr $multiport $dports -j $target1 done fi - - for adr in $addr; do - addnatrule $chain $proto $cli $sports \ - -d $adr $multiport $dports -j $target1 - done fi # Replace destination port by the new destination port @@ -2073,14 +1831,14 @@ add_nat_rule() { if [ -n "$snat" ]; then if [ -n "$cli" ]; then - addnatrule `snat_chain $dest` $proto $cli $multiport \ + [ $command = check ] || addnatrule `snat_chain $dest` $proto $cli $multiport \ $sports -d $serv $dports -j SNAT --to-source $snat else for source_host in $source_hosts; do [ "x${source_host#*:}" = "x0.0.0.0/0" ] && \ error_message "Warning: SNAT will occur on all connections to this server and port - rule \"$rule\"" - - addnatrule `snat_chain $dest` \ + + [ $command = check ] || addnatrule `snat_chain $dest` \ -s ${source_host#*:} $proto $sports $multiport \ -d $serv $dports -j SNAT --to-source $snat done @@ -2092,6 +1850,8 @@ add_nat_rule() { # Add one Filter Rule -- Helper function for the rules file processor # # The caller has established the following variables: +# check = current command. If 'check', we're executing a 'check' +# which only goes through the motions. # client = SOURCE IP or MAC # server = DESTINATION IP or interface # protocol = Protocol @@ -2128,20 +1888,19 @@ add_a_rule() # Set destination variables dest_interface= + serv= [ -n "$server" ] && case "$server" in -) - serv= ;; *.*.*) serv=$server ;; ~*) - fatal_error "Error: Rule \"$rule\" - Destination may not be specified by MAC Address" + fatal_error "Rule \"$rule\" - Destination may not be specified by MAC Address" ;; *) dest_interface="-o $server" - serv= ;; esac @@ -2182,109 +1941,112 @@ add_a_rule() ;; all|ALL) [ -n "$port" ] && [ "x${port}" != "x-" ] && \ - fatal_error "Port number not allowed with \"all\";" \ - " rule: \"$rule\"" + fatal_error "Port number not allowed with \"all\"; rule: \"$rule\"" proto= ;; - related|RELATED) - proto= - state="-m state --state RELATED" - ;; *) state= [ -n "$port" ] && [ "x${port}" != "x-" ] && \ - fatal_error "Port number not allowed with protocol " \ - "\"$proto\"; rule: \"$rule\"" + fatal_error "Port number not allowed with protocol \"$proto\"; rule: \"$rule\"" ;; esac proto="${proto:+-p $proto}" # Some misc. setup - + case "$logtarget" in REJECT) target=reject [ -n "$servport" ] && \ - fatal_error "Error: server port may not be specified in a REJECT rule;"\ + fatal_error "Server port may not be specified in a REJECT rule;"\ "rule: \"$rule\"" ;; REDIRECT) - [ -n "$serv" ] && startup_error "Error: REDIRECT rules cannot"\ + [ -n "$serv" ] && startup_error "REDIRECT rules cannot"\ " specify a server IP; rule: \"$rule\"" servport=${servport:=$port} ;; DNAT) - [ -n "$serv" ] || fatal_error "Error: DNAT rules require a" \ + [ -n "$serv" ] || fatal_error "DNAT rules require a" \ " server address; rule: \"$rule\"" ;; + LOG) + [ -z "$loglevel" ] && fatal_error "LOG requires log level" + ;; esac # Complain if the rule is really a policy - + if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" ]; then error_message "Warning -- Rule \"$rule\" is a POLICY" error_message " -- and should be moved to the policy file" fi if [ -n "${serv}${servport}" ]; then + if [ $command != check ]; then - # A specific server or server port given + # A specific server or server port given - if [ -n "$addr" -a "$addr" != "$serv" ]; then - add_nat_rule - elif [ -n "$servport" -a "$servport" != "$port" ]; then - add_nat_rule - fi - - if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then - serv="${serv:+-d $serv}" - - if [ -n "$loglevel" ]; then - if [ "$loglevel" = ULOG ]; then - run_iptables2 -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j ULOG $LOGPARMS \ - --ulog-prefix "Shorewall:$chain:$logtarget:" - else - run_iptables2 -A $chain $proto $multiport \ - $state $cli $sports $serv $dports -j LOG $LOGPARMS \ - --log-prefix "Shorewall:$chain:$logtarget:" \ - --log-level $loglevel - fi + if [ -n "$addr" -a "$addr" != "$serv" ]; then + add_nat_rule + elif [ -n "$servport" -a "$servport" != "$port" ]; then + add_nat_rule fi + + if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then + serv="${serv:+-d $serv}" + + if [ -n "$loglevel" ]; then + if [ "$loglevel" = ULOG ]; then + run_iptables2 -A $chain $proto $multiport \ + $state $cli $sports $serv $dports -j ULOG $LOGPARMS \ + --ulog-prefix "Shorewall:$chain:$logtarget:" + else + run_iptables2 -A $chain $proto $multiport \ + $state $cli $sports $serv $dports -j LOG $LOGPARMS \ + --log-prefix "Shorewall:$chain:$logtarget:" \ + --log-level $loglevel + fi + fi + - - run_iptables2 -A $chain $proto $multiport $state $cli $sports \ - $serv $dports -j $target + run_iptables2 -A $chain $proto $multiport $state $cli $sports \ + $serv $dports -j $target + fi fi else # Destination is a simple zone [ -n "$addr" ] && fatal_error \ - "Error: An ORIGINAL DESTINATION ($addr) is only allowed in" \ + "An ORIGINAL DESTINATION ($addr) is only allowed in" \ " a DNAT or REDIRECT: \"$rule\"" - if [ -n "$loglevel" ]; then - if [ "$loglevel" = ULOG ]; then - run_iptables2 -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j ULOG \ - $LOGPARMS --ulog-prefix "Shorewall:$chain:$logtarget:" - else - run_iptables2 -A $chain $proto $multiport \ - $dest_interface $state $cli $sports $dports -j LOG \ - $LOGPARMS --log-prefix "Shorewall:$chain:$logtarget:" \ - --log-level $loglevel + if [ $command != check ]; then + if [ -n "$loglevel" ]; then + if [ "$loglevel" = ULOG ]; then + run_iptables2 -A $chain $proto $multiport \ + $dest_interface $state $cli $sports $dports -j ULOG \ + $LOGPARMS --ulog-prefix "Shorewall:$chain:$logtarget:" + else + run_iptables2 -A $chain $proto $multiport \ + $dest_interface $state $cli $sports $dports -j LOG \ + $LOGPARMS --log-prefix "Shorewall:$chain:$logtarget:" \ + --log-level $loglevel + fi + fi + + if [ $logtarget != LOG ]; then + run_iptables2 -A $chain $proto $multiport $dest_interface $state \ + $cli $sports $dports -j $target fi fi - - run_iptables2 -A $chain $proto $multiport $dest_interface $state \ - $cli $sports $dports -j $target fi } # -# Process a record from the rules file +# Process a record from the rules file for the 'start', 'restart' or 'check' commands # process_rule() # $1 = target # $2 = clients @@ -2292,7 +2054,7 @@ process_rule() # $1 = target # $4 = protocol # $5 = ports # $6 = cports - # $7 = address + # $7 = address { local target="$1" local clients="$2" @@ -2304,7 +2066,7 @@ process_rule() # $1 = target local rule="`echo $target $clients $servers $protocol $ports $cports $address`" # Function Body -- isolate log level - + if [ "$target" = "${target%:*}" ]; then loglevel= else @@ -2351,9 +2113,9 @@ process_rule() # $1 = target clientzone="${clients%%:*}" clients="${clients#*:}" [ -z "$clientzone" -o -z "$clients" ] && \ - fatal_error "Error: Empty source zone or qualifier: rule \"$rule\"" + fatal_error "Empty source zone or qualifier: rule \"$rule\"" fi - + if [ "$clientzone" = "${clientzone%\!*}" ]; then excludezones= else @@ -2361,11 +2123,11 @@ process_rule() # $1 = target clientzone="${clientzone%\!*}" [ "$logtarget" = DNAT ] || [ "$logtarget" = REDIRECT ] ||\ - fatal_error "Error: Exclude list only allowed with DNAT or REDIRECT" + fatal_error "Exclude list only allowed with DNAT or REDIRECT" fi if ! validate_zone $clientzone; then - fatal_error "Error: Undefined Client Zone in rule \"$rule\"" + fatal_error "Undefined Client Zone in rule \"$rule\"" fi # Parse and validate destination @@ -2385,16 +2147,16 @@ process_rule() # $1 = target serverport="${servers#*:}" servers="${servers%:*}" [ -z "$serverzone" -o -z "$serverport" ] && \ - fatal_error "Error: Empty destination zone or server port: rule \"$rule\"" + fatal_error "Empty destination zone or server port: rule \"$rule\"" else serverport= [ -z "$serverzone" -o -z "$servers" ] && \ - startup_error "Error: Empty destination zone or qualifier: rule \"$rule\"" + startup_error "Empty destination zone or qualifier: rule \"$rule\"" fi fi if ! validate_zone $serverzone; then - fatal_error "Error: Undefined Server Zone in rule \"$rule\"" + fatal_error "Undefined Server Zone in rule \"$rule\"" fi dest=$serverzone @@ -2403,7 +2165,7 @@ process_rule() # $1 = target chain=${source}2${dest} - ensurechain $chain + [ $command = check ] || ensurechain $chain if [ "x$chain" = x${FW}2${FW} ]; then case $logtarget in @@ -2415,7 +2177,7 @@ process_rule() # $1 = target ;; esac else - ensurechain $chain + [ $command = check ] || ensurechain $chain fi # Generate Netfilter rule(s) @@ -2447,11 +2209,15 @@ process_rule() # $1 = target done fi - echo " Rule \"$rule\" added." + if [ $command = check ]; then + echo " Rule \"$rule\" checked." + else + echo " Rule \"$rule\" added." + fi } # -# Process the rules file +# Process the rules file for the 'start', 'restart' or 'check' command. # process_rules() # $1 = name of rules file { @@ -2468,12 +2234,10 @@ process_rules() # $1 = name of rules file done } - strip_file rules $1 - while read xtarget xclients xservers xprotocol xports xcports xaddress; do - case "$xtarget" in + case "${xtarget%:*}" in - ACCEPT|ACCEPT:*|DROP|DROP:*|REJECT|REJECT:*|DNAT|DNAT-|DNAT:*|DNAT-:*|REDIRECT|REDIRECT:*) + ACCEPT|DROP|REJECT|DNAT|DNAT|DNAT-|REDIRECT|LOG|CONTINUE) expandv xclients xservers xprotocol xports xcports xaddress if [ "x$xclients" = xall ]; then @@ -2484,20 +2248,20 @@ process_rules() # $1 = name of rules file process_wildcard_rule continue fi - + if [ "x$xservers" = xall ]; then xservers="$zones $FW" process_wildcard_rule continue fi - + process_rule $xtarget $xclients $xservers $xprotocol $xports $xcports $xaddress ;; *) rule="`echo $xtarget $xclients $xservers $xprotocol $xports $xcports $xaddress`" - fatal_error "Error: Invalid Target in rule \"$rule\"" + fatal_error "Invalid Target in rule \"$rule\"" ;; - + esac done < $TMP_DIR/rules } @@ -2873,7 +2637,7 @@ default_policy() # $1 = client $2 = server if [ -n "$chain1" ]; then apply_default $1 $2 else - fatal_error "Error: No default policy for zone $1 to zone $2" + fatal_error "No default policy for zone $1 to zone $2" fi } @@ -2893,7 +2657,7 @@ complete_standard_chain() # $1 = chain, $2 = source zone, $3 = destination zone local policychain= run_user_exit $1 - + eval policychain=\$${2}2${3}_policychain if [ -n "$policychain" ]; then @@ -2918,12 +2682,12 @@ rules_chain() # $1 = source zone, $2 = destination zone local chain=${1}2${2} havechain $chain && { echo $chain; return; } - + eval chain=\$${chain}_policychain [ -n "$chain" ] && { echo $chain; return; } - fatal_error "Error: No appropriate chain for zone $1 to zone $2" + fatal_error "No appropriate chain for zone $1 to zone $2" } # @@ -2936,8 +2700,12 @@ get_routed_subnets() # $1 = interface name ip route show dev $1 2> /dev/null | while read address rest; do - [ "$address" = "${address%/*}" ] && address="${address}/32" - echo $address + if [ "x$address" = xdefault ]; then + error_message "Warning: default route ignored on interface $1" + else + [ "$address" = "${address%/*}" ] && address="${address}/32" + echo $address + fi done } @@ -2977,9 +2745,9 @@ setup_masq() interface=${fullinterface%:*} if ! list_search $interface $all_interfaces; then - fatal_error "Error: Unknown interface $interface" + fatal_error "Unknown interface $interface" fi - + if [ "$subnet" = "${subnet%!*}" ]; then nomasq= else @@ -2991,7 +2759,7 @@ setup_masq() iface= source="$subnet" - + case $subnet in *.*.*) ;; @@ -3014,7 +2782,7 @@ setup_masq() if [ -n "$address" -a -n "$ADD_SNAT_ALIASES" ]; then list_search $address $aliases_to_add || \ - aliases_to_add="$aliases_to_add $address $fullinterface" + aliases_to_add="$aliases_to_add $address $fullinterface" fi destination=$destnet @@ -3022,7 +2790,7 @@ setup_masq() if [ -n "$nomasq" ]; then newchain=masq${masq_seq} createnatchain $newchain - + if [ -n "$subnet" ]; then for s in $subnet; do addnatrule $chain -d $destnet $iface -s $s -j $newchain @@ -3040,7 +2808,7 @@ setup_masq() for addr in `separate_list $nomasq`; do addnatrule $chain -s $addr -j RETURN done - + source="$source except $nomasq" else destnet="-d $destnet" @@ -3077,18 +2845,6 @@ setup_masq() done < $TMP_DIR/masq } -# -# Setup Intrazone chain if appropriate -# -setup_intrazone() # $1 = zone -{ - eval hosts=\$${1}_hosts - - if have_interfaces_in_zone_with_option $1 multi; then - ensurechain ${1}2${1} - fi -} - # # Add a record to the blacklst chain # @@ -3136,13 +2892,13 @@ process_blacklist_rec() { source="-s $addr" ;; esac - + if [ -n "$protocol" ]; then proto=" -p $protocol " case $protocol in tcp|TCP|6|udp|UDP|17) - if [ -n "$ports" ]; then + if [ -n "$ports" ]; then if [ -n "$MULTIPORT" -a \ "$ports" != "${ports%,*}" -a \ "$ports" = "${ports%:*}" -a \ @@ -3183,7 +2939,7 @@ process_blacklist_rec() { elif [ -n "$protocol" ]; then addr="$addr $protocol" fi - + echo " $addr added to Black List" done } @@ -3207,7 +2963,7 @@ setup_blacklist() { for chain in `first_chains $interface`; do run_iptables -A $chain -j blacklst done - + echo " Blacklisting enabled on $interface" done @@ -3258,6 +3014,9 @@ verify_os_version() { startup_error "Shorewall version $version does not work with kernel version $osversion" ;; esac + + [ $command = start -a -n "`lsmod 2> /dev/null | grep '^ipchains'`" ] && \ + startup_error "Shorewall can't start with the ipchains kernel module loaded - see FAQ #8" } # @@ -3269,7 +3028,7 @@ add_ip_aliases() local interface local primary - do_one() + do_one() { # # Folks feel uneasy if they don't see all of the same @@ -3301,7 +3060,7 @@ add_ip_aliases() } set -- $aliases_to_add - + while [ $# -gt 0 ]; do external=$1 interface=$2 @@ -3312,7 +3071,7 @@ add_ip_aliases() interface="${interface%:*}" label="label $interface:$label" fi - + primary=`find_interface_address $interface` shift;shift [ "x${primary}" = "x${external}" ] || do_one @@ -3335,6 +3094,13 @@ load_kernel_modules() { fi } +# Verify that the 'ip' program is installed + +verify_ip() { + qt which ip ||\ + startup_error "Shorewall $version requires the iproute package ('ip' utility)" +} + # # Perform Initialization # - Delete all old rules @@ -3349,7 +3115,7 @@ initialize_netfilter () { determine_zones - [ -z "$zones" ] && startup_error "ERROR: No Zones Defined" + [ -z "$zones" ] && startup_error "No Zones Defined" display_list "Zones:" $zones @@ -3370,6 +3136,21 @@ initialize_netfilter () { determine_interfaces determine_hosts + run_user_exit init + + # + # The some files might be large so strip them while the firewall is still running + # (restart command). This reduces the length of time that the firewall isn't + # accepting new connections. + # + + strip_file rules + strip_file proxyarp + strip_file maclist + strip_file nat + + terminator=fatal_error + deletechain shorewall [ -n "$NAT_ENABLED" ] && delete_nat @@ -3382,33 +3163,31 @@ initialize_netfilter () { [ -n "$CLEAR_TC" ] && delete_tc - run_user_exit init - echo "Deleting user chains..." setpolicy INPUT DROP setpolicy OUTPUT DROP setpolicy FORWARD DROP - + deleteallchains setcontinue FORWARD setcontinue INPUT setcontinue OUTPUT # - # Allow DNS lookups during startup for FQDNs + # Allow DNS lookups during startup for FQDNs and deep-six INVALID packets # - run_iptables -A INPUT -p udp --dport 53 -j ACCEPT # I suppose that there - # is an idiot somewhere - # who needs this - run_iptables -A OUTPUT -p udp --dport 53 -j ACCEPT - run_iptables -A FORWARD -p udp --dport 53 -j ACCEPT + for chain in INPUT OUTPUT FORWARD; do + run_iptables -A $chain -p udp --dport 53 -j ACCEPT + run_iptables -A $chain -m state --state INVALID -j DROP + done + [ -n "$CLAMPMSS" ] && \ run_iptables -A FORWARD -p tcp \ --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu - + if [ -z "$NEWNOTSYN" ]; then createchain newnotsyn no run_user_exit newnotsyn @@ -3423,13 +3202,13 @@ initialize_netfilter () { fi run_iptables -A newnotsyn -j DROP - fi + fi createchain icmpdef no createchain common no createchain reject no createchain dynamic no - + if [ -f /var/lib/shorewall/save ]; then echo "Restoring dynamic rules..." @@ -3443,7 +3222,7 @@ initialize_netfilter () { esac done < /var/lib/shorewall/save fi - + echo "Creating input Chains..." for interface in $all_interfaces; do @@ -3458,14 +3237,7 @@ initialize_netfilter () { # Build the common chain -- called during [re]start and refresh # build_common_chain() { - - if [ -n "$OLD_PING_HANDLING" ]; then - # - # PING - # - [ -n "$FORWARDPING" ] && \ - run_iptables -A icmpdef -p icmp --icmp-type echo-request -j ACCEPT - fi + # # Common ICMP rules # @@ -3486,7 +3258,7 @@ build_common_chain() { if [ -n "$NEWNOTSYN" ]; then run_iptables -A common -p tcp --tcp-flags ACK ACK -j ACCEPT run_iptables -A common -p tcp --tcp-flags RST RST -j ACCEPT - fi + fi # # BROADCASTS # @@ -3591,9 +3363,9 @@ add_common_rules() { if [ -n "$norfc1918_interfaces" ]; then echo "Enabling RFC1918 Filtering" - + strip_file rfc1918 - + createchain rfc1918 no createchain logdrop no @@ -3613,13 +3385,13 @@ add_common_rules() { run_iptables -t mangle -A logdrop -j `logdisp man1918` run_iptables -t mangle -A logdrop -j DROP fi - + while read subnet target; do case $target in logdrop|DROP|RETURN) ;; *) - fatal_error " Error:Illegal target ($target) for $subnet" + fatal_error "Illegal target ($target) for $subnet" ;; esac @@ -3632,23 +3404,23 @@ add_common_rules() { run_iptables2 -t mangle -A man1918 -d $subnet -j $target fi done < $TMP_DIR/rfc1918 - + for interface in $norfc1918_interfaces; do for chain in `first_chains $interface`; do - run_iptables -A $chain -j rfc1918 + run_iptables -A $chain -m state --state NEW -j rfc1918 done - + [ -n "$MANGLE_ENABLED" ] && \ - run_iptables -t mangle -A PREROUTING -i $interface -j man1918 + run_iptables -t mangle -A PREROUTING -m state --state NEW -i $interface -j man1918 done fi - + interfaces=`find_interfaces_by_option tcpflags` if [ -n "$interfaces" ]; then echo "Setting up TCP Flags checking..." - + createchain tcpflags no if [ -n "$TCP_FLAGS_LOG_LEVEL" ]; then @@ -3688,7 +3460,7 @@ add_common_rules() { # hosts a web server. # run_iptables -A tcpflags -p tcp --syn --sport 0 $disposition - + for interface in $interfaces; do for chain in `first_chains $interface`; do run_iptables -A $chain -p tcp -j tcpflags @@ -3705,11 +3477,7 @@ add_common_rules() { # run_iptables -A INPUT -i lo -j ACCEPT run_iptables -A OUTPUT -o lo -j ACCEPT - - # - # Enable icmp output - # - run_iptables -A OUTPUT -p icmp -j ACCEPT + # # Route Filtering # @@ -3781,7 +3549,7 @@ apply_policy_rules() { # related sessions associated with sessions going # in the other direction # - createchain $chain + createchain $chain yes # # If either client or server is 'all' then this MUST be @@ -3802,11 +3570,11 @@ apply_policy_rules() { fi done + # # Add policy rules to canonical chains # for zone in $FW $zones; do - setup_intrazone $zone for zone1 in $FW $zones; do chain=${zone}2${zone1} if havechain $chain; then @@ -3820,7 +3588,7 @@ apply_policy_rules() { # # Activate the rules # -activate_rules() +activate_rules() { local PREROUTING_rule=1 local POSTROUTING_rule=1 @@ -3832,11 +3600,11 @@ activate_rules() local sourcechain=$1 destchain=$2 shift shift - + havenatchain $destchain && \ run_iptables -t nat -A $sourcechain $@ -j $destchain } - + # # Jump to a RULES chain from one of the builtin nat chains # @@ -3848,7 +3616,7 @@ activate_rules() local sourcechain=$1 destchain=$2 shift shift - + if havenatchain $destchain; then if [ -n "$NAT_BEFORE_RULES" ]; then run_iptables -t nat -A $sourcechain $@ -j $destchain @@ -3871,8 +3639,6 @@ activate_rules() addnatjump POSTROUTING `output_chain $interface` -o $interface done - multi_interfaces=`find_interfaces_by_option multi` - > ${STATEDIR}/chains > ${STATEDIR}/zones @@ -3886,12 +3652,12 @@ activate_rules() echo "$FW $zone $chain1" >> ${STATEDIR}/chains echo "$zone $FW $chain2" >> ${STATEDIR}/chains - + for host in $source_hosts; do interface=${host%:*} subnet=${host#*:} - run_iptables -A OUTPUT -o $interface -d $subnet -j $chain1 + run_iptables -A OUTPUT -o $interface -d $subnet -j $chain1 # # Add jumps from the builtin chains for DNAT and SNAT rules @@ -3920,16 +3686,16 @@ activate_rules() interface=${host%:*} subnet=${host#*:} chain1=`forward_chain $interface` - + if [ -n "$have_canonical" ]; then - multi=yes + bounce=yes else case $interface in *+*) - multi=yes + bounce=yes ;; *) - list_search $interface $multi_interfaces && multi=yes || multi= + bounce= ;; esac fi @@ -3938,9 +3704,8 @@ activate_rules() interface1=${host1%:*} subnet1=${host1#*:} - if [ $interface != $interface1 -o -n "$multi" ]; then - run_iptables -A $chain1 -s $subnet \ - -o $interface1 -d $subnet1 -j $chain + if [ $interface != $interface1 -o -n "$bounce" ]; then + run_iptables -A $chain1 -s $subnet -o $interface1 -d $subnet1 -j $chain fi done done @@ -3957,13 +3722,10 @@ activate_rules() complete_standard_chain OUTPUT $FW all complete_standard_chain FORWARD all all - run_iptables -D INPUT -m state --state ESTABLISHED -j ACCEPT - run_iptables -D OUTPUT -m state --state ESTABLISHED -j ACCEPT - run_iptables -D FORWARD -m state --state ESTABLISHED -j ACCEPT - - run_iptables -D INPUT -p udp --dport 53 -j ACCEPT - run_iptables -D OUTPUT -p udp --dport 53 -j ACCEPT - run_iptables -D FORWARD -p udp --dport 53 -j ACCEPT + for chain in INPUT OUTPUT FORWARD; do + run_iptables -D $chain -m state --state ESTABLISHED -j ACCEPT + run_iptables -D $chain -p udp --dport 53 -j ACCEPT + done } # @@ -3985,6 +3747,8 @@ define_firewall() # $1 = Command (Start or Restart) verify_os_version + verify_ip + load_kernel_modules echo "Initializing..." @@ -4018,26 +3782,6 @@ define_firewall() # $1 = Command (Start or Restart) process_rules $rules - if [ -n "$OLD_PING_HANDLING" ]; then - echo "Setting up ICMP Echo handling..." - - filterping_interfaces="`find_interfaces_by_option filterping`" - noping_interfaces="`find_interfaces_by_option noping`" - - for interface in $all_interfaces; do - if ! list_search $interface $filterping_interfaces; then - if list_search $interface $noping_interfaces; then - target=DROP - else - target=ACCEPT - fi - - run_iptables -A `input_chain $interface` \ - -p icmp --icmp-type echo-request -j $target - fi - done - fi - policy=`find_file policy` echo "Processing $policy..." @@ -4052,6 +3796,10 @@ define_firewall() # $1 = Command (Start or Restart) [ -f $tos ] && [ -n "$MANGLE_ENABLED" ] && process_tos $tos + ecn=`find_file ecn` + + [ -f $ecn ] && [ -n "$MANGLE_ENABLED" ] && setup_ecn $ecn + [ -n "$TC_ENABLED" ] && setup_tc echo "Activating Rules..." @@ -4073,50 +3821,6 @@ define_firewall() # $1 = Command (Start or Restart) rm -rf $TMP_DIR } -# -# Check the configuration -# -check_config() { - echo "Verifying Configuration..." - - verify_os_version - - load_kernel_modules - - echo "Determining Zones..." - - determine_zones - - [ -z "$zones" ] && startup_error "ERROR: No Zones Defined" - - display_list "Zones:" $zones - - echo "Validating interfaces file..." - - validate_interfaces_file - - echo "Validating hosts file..." - - validate_hosts_file - - echo "Determining Hosts in Zones..." - - determine_interfaces - determine_hosts - - echo "Validating rules file..." - - validate_rules - - echo "Validating policy file..." - - validate_policy - - rm -rf $TMP_DIR - - echo "Configuration Validated" -} - # # Rebuild the common chain # @@ -4130,7 +3834,7 @@ refresh_firewall() validate_interfaces_file - [ -z "$zones" ] && startup_error "ERROR: No Zones Defined" + [ -z "$zones" ] && startup_error "No Zones Defined" determine_interfaces @@ -4147,10 +3851,13 @@ refresh_firewall() # refresh_blacklist + ecn=`find_file ecn` + + [ -f $ecn ] && [ -n "$MANGLE_ENABLED" ] && setup_ecn $ecn # # Refresh Traffic Control # - [ -n "$TC_ENABLED" ] && refresh_tc + [ -n "$TC_ENABLED" ] && refresh_tc report "Shorewall Refreshed" @@ -4172,13 +3879,13 @@ add_to_zone() # $1 = [:] $2 = zone do_iptables() # $@ = command { if ! iptables $@ ; then - startup_error "Error: can't add $1 to zone $2" + startup_error "Can't add $1 to zone $2" fi } output_rule_num() { local num=`iptables -L OUTPUT -n --line-numbers | grep icmp | cut -d' ' -f1 | head -n1` - + [ -n "$num" ] && echo $(($num+1)) } # @@ -4197,32 +3904,33 @@ add_to_zone() # $1 = [:] $2 = zone # zone=$2 - validate_zone $zone || startup_error "Error: Unknown zone: $zone" + validate_zone $zone || startup_error "Unknown zone: $zone" - [ "$zone" = $FW ] && startup_error "Error: Can't add $1 to firewall zone" + [ "$zone" = $FW ] && startup_error "Can't add $1 to firewall zone" # # Be sure that Shorewall has been restarted using a DZ-aware version of the code # - [ -f ${STATEDIR}/chains ] || startup_error "Error: ${STATEDIR}/chains -- file not found" - [ -f ${STATEDIR}/zones ] || startup_error "Error: ${STATEDIR}/zones -- file not found" + [ -f ${STATEDIR}/chains ] || startup_error "${STATEDIR}/chains -- file not found" + [ -f ${STATEDIR}/zones ] || startup_error "${STATEDIR}/zones -- file not found" # # Be sure that the interface was present at last [re]start # if ! chain_exists `input_chain $interface` ; then - startup_error "Error: Unknown interface $interface" + startup_error "Unknown interface $interface" fi # # Build lists of interfaces with special rules # dhcp_interfaces=`find_interfaces_by_option dhcp` blacklist_interfaces=`find_interfaces_by_option blacklist` - filterping_interfaces=`find_interfaces_by_option filterping` maclist_interfaces=`find_interfaces_by_option maclist` tcpflags_interfaces=`find_interfaces_by_option tcpflags` # # Normalize the first argument to this function # newhost="$interface:$host" + + terminator=fatal_error # # Create a new Zone state file # @@ -4235,15 +3943,15 @@ add_to_zone() # $1 = [:] $2 = zone for h in $hosts; do if [ "$h" = "$newhost" ]; then rm -f ${STATEDIR}/zones_$$ - startup_error "Error: $1 already in zone $zone" + startup_error "$1 already in zone $zone" fi done - + [ -z "$hosts" ] && hosts=$newhost || hosts="$hosts $newhost" fi eval ${z}_hosts=\"$hosts\" - + echo "$z $hosts" >> ${STATEDIR}/zones_$$ done < ${STATEDIR}/zones @@ -4251,7 +3959,7 @@ add_to_zone() # $1 = [:] $2 = zone # # If the zone passed in the command has a dnat chain then insert a rule in # the nat table PREROUTING chain to jump to that chain when the source - # matches the new host(s) + # matches the new host(s)# # chain=${zone}_dnat @@ -4274,10 +3982,6 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=2 fi - if list_search $interface $filterping_interfaces; then - rulenum=$(($rulenum + 1)) - fi - if list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi @@ -4286,7 +3990,7 @@ add_to_zone() # $1 = [:] $2 = zone rulenum=$(($rulenum + 1)) fi - do_iptables -I `input_chain $interface` $rulenum -s $host -j $chain + do_iptables -I `input_chain $interface` $rulenum -s $host -j $chain else # # Insert rules into the passed interface's forward chain @@ -4299,7 +4003,7 @@ add_to_zone() # $1 = [:] $2 = zone base=`chain_base $interface` eval rulenum=\$${base}_rulenum - + if [ -z "$rulenum" ]; then if list_search $interface $blacklist_interfaces; then rulenum=3 @@ -4310,16 +4014,16 @@ add_to_zone() # $1 = [:] $2 = zone if list_search $interface $maclist_interfaces; then rulenum=$(($rulenum + 1)) fi - + if list_search $interface $tcpflags_interfaces; then rulenum=$(($rulenum + 1)) fi fi - + for h in $dest_hosts; do iface=${h%:*} hosts=${h#*:} - + if [ "$iface" != "$interface" -o "$hosts" != "$host" ]; then do_iptables -I $source_chain $rulenum -s $host -o $iface -d $hosts -j $chain rulenum=$(($rulenum + 1)) @@ -4342,7 +4046,7 @@ add_to_zone() # $1 = [:] $2 = zone # We insert them after any blacklist rules # eval source_hosts=\"\$${z1}_hosts\" - + for h in $source_hosts; do iface=${h%:*} hosts=${h#*:} @@ -4350,7 +4054,7 @@ add_to_zone() # $1 = [:] $2 = zone base=`chain_base $iface` eval rulenum=\$${base}_rulenum - + if [ -z "$rulenum" ]; then if list_search $iface $blacklist_interfaces; then rulenum=3 @@ -4371,7 +4075,7 @@ add_to_zone() # $1 = [:] $2 = zone done < ${STATEDIR}/chains echo "$1 added to zone $2" -} +} # # Delete a host or subnet from a zone @@ -4389,7 +4093,7 @@ delete_from_zone() # $1 = [:] $2 = zone if [ "$z" = "$zone" ]; then temp=$hosts hosts= - + for h in $temp; do if [ "$h" = "$delhost" ]; then echo Yes @@ -4398,7 +4102,7 @@ delete_from_zone() # $1 = [:] $2 = zone fi done fi - + echo "$z $hosts" >> ${STATEDIR}/zones_$$ done < ${STATEDIR}/zones @@ -4418,19 +4122,19 @@ delete_from_zone() # $1 = [:] $2 = zone zone=$2 - validate_zone $zone || startup_error "Error: Unknown zone: $zone" + validate_zone $zone || startup_error "Unknown zone: $zone" - [ "$zone" = $FW ] && startup_error "Error: Can't remove $1 from firewall zone" + [ "$zone" = $FW ] && startup_error "Can't remove $1 from firewall zone" # # Be sure that Shorewall has been restarted using a DZ-aware version of the code # - [ -f ${STATEDIR}/chains ] || startup_error "Error: ${STATEDIR}/chains -- file not found" - [ -f ${STATEDIR}/zones ] || startup_error "Error: ${STATEDIR}/zones -- file not found" + [ -f ${STATEDIR}/chains ] || startup_error "${STATEDIR}/chains -- file not found" + [ -f ${STATEDIR}/zones ] || startup_error "${STATEDIR}/zones -- file not found" # # Be sure that the interface was present at last [re]start # if ! chain_exists `input_chain $interface` ; then - startup_error "Error: Unknown interface $interface" + startup_error "Unknown interface $interface" fi # # Normalize the first argument to this function @@ -4447,6 +4151,8 @@ delete_from_zone() # $1 = [:] $2 = zone while read z hosts; do eval ${z}_hosts=\"$hosts\" done < ${STATEDIR}/zones + + terminator=fatal_error # # Delete any nat table entries for the host(s) # @@ -4457,7 +4163,7 @@ delete_from_zone() # $1 = [:] $2 = zone while read z1 z2 chain; do if [ "$z1" = "$zone" ]; then if [ "$z2" = "$FW" ]; then - qt iptables -D `input_chain $interface` -s $host -j $chain + qt iptables -D `input_chain $interface` -s $host -j $chain else source_chain=`forward_chain $interface` eval dest_hosts=\"\$${z2}_hosts\" @@ -4465,7 +4171,7 @@ delete_from_zone() # $1 = [:] $2 = zone for h in $dest_hosts $delhost; do iface=${h%:*} hosts=${h#*:} - + if [ "$iface" != "$interface" -o "$hosts" != "$host" ]; then qt iptables -D $source_chain -s $host -o $iface -d $hosts -j $chain fi @@ -4476,7 +4182,7 @@ delete_from_zone() # $1 = [:] $2 = zone qt iptables -D OUTPUT -o $interface -d $host -j $chain else eval source_hosts=\"\$${z1}_hosts\" - + for h in $source_hosts; do iface=${h%:*} hosts=${h#*:} @@ -4490,7 +4196,7 @@ delete_from_zone() # $1 = [:] $2 = zone done < ${STATEDIR}/chains echo "$1 removed from zone $2" -} +} # # Determine the value for a parameter that defaults to Yes @@ -4550,13 +4256,17 @@ do_initialize() { PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin # + # Establish termination function + # + terminator=startup_error + # # Clear all configuration variables # version= FW= SUBSYSLOCK= STATEDIR= - ALLOWRELATED= + ALLOWRELATED=Yes LOGRATE= LOGBURST= LOGPARMS= @@ -4573,7 +4283,6 @@ do_initialize() { NAT_BEFORE_RULES= MULTIPORT= DETECT_DNAT_IPADDRS= - MERGE_HOSTS= MUTEX_TIMEOUT= NEWNOTSYN= LOGNEWNOTSYN= @@ -4584,8 +4293,7 @@ do_initialize() { TCP_FLAGS_LOG_LEVEL= RFC1918_LOG_LEVEL= MARK_IN_FORWARD_CHAIN= - OLD_PING_HANDLING= - SHARED_DIR=/usr/lib/shorewall + SHARED_DIR=/usr/share/shorewall FUNCTIONS= VERSION_FILE= @@ -4602,19 +4310,6 @@ do_initialize() { trap "rm -rf $TMP_DIR; my_mutex_off; exit 2" 1 2 3 4 5 6 9 - if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/shorewall.conf ]; then - config=$SHOREWALL_DIR/shorewall.conf - else - config=/etc/shorewall/shorewall.conf - fi - - if [ -f $config ]; then - . $config - else - echo "$config does not exist!" >&2 - exit 2 - fi - FUNCTIONS=$SHARED_DIR/functions if [ -f $FUNCTIONS ]; then @@ -4627,6 +4322,18 @@ do_initialize() { [ -f $VERSION_FILE ] && version=`cat $VERSION_FILE` + run_user_exit params + + config=`find_file shorewall.conf` + + if [ -f $config ]; then + echo "Processing $config..." + . $config + else + echo "$config does not exist!" >&2 + exit 2 + fi + [ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall [ -d $STATEDIR ] || mkdir -p $STATEDIR @@ -4634,6 +4341,8 @@ do_initialize() { [ -z "$FW" ] && FW=fw ALLOWRELATED="`added_param_value_yes ALLOWRELATED $ALLOWRELATED`" + [ -n "$ALLOWRELATED" ] || \ + startup_error "ALLOWRELATED=No is not supported" NAT_ENABLED="`added_param_value_yes NAT_ENABLED $NAT_ENABLED`" MANGLE_ENABLED="`added_param_value_yes MANGLE_ENABLED $MANGLE_ENABLED`" ADD_IP_ALIASES="`added_param_value_yes ADD_IP_ALIASES $ADD_IP_ALIASES`" @@ -4669,12 +4378,14 @@ do_initialize() { NAT_BEFORE_RULES=`added_param_value_yes NAT_BEFORE_RULES $NAT_BEFORE_RULES` MULTIPORT=`added_param_value_no MULTIPORT $MULTIPORT` DETECT_DNAT_IPADDRS=`added_param_value_no DETECT_DNAT_IPADDRS $DETECT_DNAT_IPADDRS` - MERGE_HOSTS=`added_param_value_no MERGE_HOSTS $MERGE_HOSTS` FORWARDPING=`added_param_value_no FORWARDPING $FORWARDPING` + [ -n "$FORWARDPING" ] && \ + startup_error "FORWARDPING=Yes is no longer supported" + NEWNOTSYN=`added_param_value_yes NEWNOTSYN $NEWNOTSYN` maclist_target=reject - + if [ -n "$MACLIST_DISPOSITION" ] ; then case $MACLIST_DISPOSITION in REJECT) @@ -4710,12 +4421,6 @@ do_initialize() { else CLEAR_TC= fi - OLD_PING_HANDLING=`added_param_value_yes OLD_PING_HANDLING $OLD_PING_HANDLING` - - [ -z "$OLD_PING_HANDLING" -a -n "$FORWARDPING" ] && \ - startup_error "FORWARDPING=Yes is incompatible with OLD_PING_HANDLING=No" - - run_user_exit params # # Strip the files that we use often @@ -4754,7 +4459,6 @@ case "$command" in do_initialize my_mutex_on echo -n "Stopping Shorewall..." - determine_zones stop_firewall [ -n "$SUBSYSLOCK" ] && rm -f $SUBSYSLOCK echo "done." @@ -4835,7 +4539,6 @@ case "$command" in do_initialize my_mutex_on echo -n "Clearing Shorewall..." - determine_zones clear_firewall [ -n "$SUBSYSLOCK" ] && rm -f $SUBSYSLOCK echo "done." diff --git a/STABLE/functions b/STABLE/functions index 90ad27b35..c14490ba6 100644 --- a/STABLE/functions +++ b/STABLE/functions @@ -1,12 +1,12 @@ #!/bin/sh # -# Shorewall 1.3 -- /usr/lib/shorewall/functions +# Shorewall 1.4 -- /usr/lib/shorewall/functions # # Suppress all output for a command -# -qt() -{ +# +qt() +{ "$@" >/dev/null 2>&1 } @@ -25,15 +25,30 @@ find_file() # # Replace commas with spaces and echo the result # -separate_list() { +separate_list() { local list local part local newlist + # + # There's been whining about us not catching embedded white space in + # comma-separated lists. This is an attempt to snag some of the cases. + # + # The 'terminator' function will be set by the 'firewall' script to + # either 'startup_error' or 'fatal_error' depending on the command and + # command phase + # + case "$@" in + *,|,*|*,,*|*[[:space:]]*) + [ -n "$terminator" ] && \ + $terminator "Invalid comma-separated list \"$@\"" + echo "Warning -- invalid comma-separated list \"$@\"" >&2 + ;; + esac list="$@" part="${list%%,*}" newlist="$part" - + while [ "x$part" != "x$list" ]; do list="${list#*,}"; part="${list%%,*}"; @@ -69,7 +84,7 @@ find_display() # $1 = zone, $2 = name of the zone file done } -determine_zones() +determine_zones() { local zonefile=`find_file zones` diff --git a/STABLE/hosts b/STABLE/hosts index 9ce4bc3ab..3a390cc58 100644 --- a/STABLE/hosts +++ b/STABLE/hosts @@ -1,5 +1,5 @@ # -# Shorewall 1.3 - /etc/shorewall/hosts +# Shorewall 1.4 - /etc/shorewall/hosts # # WARNING: 90% of Shorewall users don't need to add entries to this # file and 80% of those who try to add such entries get it @@ -18,23 +18,18 @@ # a) The IP address of a host # b) A subnetwork in the form # / -# +# # The interface must be defined in the # /etc/shorewall/interfaces file. # # Examples: # # eth1:192.168.1.3 -# eth2:192.168.2.0/24 +# eth2:192.168.2.0/24 # # OPTIONS - A comma-separated list of options. Currently-defined # options are: # -# routestopped - (Deprecated -- use -# /etc/shorewall/routestopped) -# route messages to and from this -# member when the firewall is in the -# stopped state # maclist - Connection requests from these hosts # are compared against the contents of # /etc/shorewall/maclist. If this option @@ -43,5 +38,5 @@ # Shorewall is started. # # -#ZONE HOST(S) OPTIONS +#ZONE HOST(S) OPTIONS #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE diff --git a/STABLE/init b/STABLE/init index d7bee1d0a..0d4564439 100644 --- a/STABLE/init +++ b/STABLE/init @@ -1,5 +1,5 @@ ############################################################################ -# Shorewall 1.3 -- /etc/shorewall/init +# Shorewall 1.4 -- /etc/shorewall/init # # Add commands below that you want to be executed at the beginning of # a "shorewall start" or "shorewall restart" command. diff --git a/STABLE/init.sh b/STABLE/init.sh index 464e7a75a..70d6ff32e 100644 --- a/STABLE/init.sh +++ b/STABLE/init.sh @@ -1,9 +1,9 @@ #!/bin/sh RCDLINKS="2,S41 3,S41 6,K41" # -# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V1.3 6/14/2002 +# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V1.4 3/14/2003 # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # @@ -13,7 +13,7 @@ RCDLINKS="2,S41 3,S41 6,K41" # Complete documentation is available at http://shorewall.net # # This program is free software; you can redistribute it and/or modify -# it under the terms of Version 2 of the GNU General Public License +# it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, @@ -30,7 +30,7 @@ RCDLINKS="2,S41 3,S41 6,K41" # # Commands are: # -# shorewall start Starts the firewall +# shorewall start Starts the firewall # shorewall restart Restarts the firewall # shorewall stop Stops the firewall # shorewall status Displays firewall status @@ -62,7 +62,7 @@ usage() { command="$1" case "$command" in - + stop|start|restart|status) exec /sbin/shorewall $@ diff --git a/STABLE/install.sh b/STABLE/install.sh index 5429d1406..deb3dec18 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -2,14 +2,14 @@ # # Script to install Shoreline Firewall # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Seawall documentation is available at http://seawall.sourceforge.net # # This program is free software; you can redistribute it and/or modify -# it under the terms of Version 2 of the GNU General Public License +# it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, @@ -24,7 +24,7 @@ # Usage: # # If you are running a distribution that has a directory called /etc/rc.d/init.d or one -# called /etc/init.d or you are running Slackware then simply cd to the directory +# called /etc/init.d or you are running Slackware then simply cd to the directory # containing this script and run it. # # ./install.sh @@ -35,7 +35,7 @@ # ./install.sh /etc/rc.d/scripts # # The default is that the firewall will be started in run levels 2-5 starting at -# position 15 and stopping at position 90. This is correct RedHat/Mandrake, Debian, +# position 15 and stopping at position 90. This is correct RedHat/Mandrake, Debian, # Caldera and Corel. # # If you wish to change that, you can pass -r "". @@ -45,7 +45,7 @@ # # ./install.sh -r "23 15 90" # -# Example 2: You wish to start your firewall only in run level 3, start at position 5 +# Example 2: You wish to start your firewall only in run level 3, start at position 5 # and stop at position 95. # # ./install.sh -r "3 5 95" /etc/rc.d/scripts @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.3.14 +VERSION=1.4.0 usage() # $1 = exit status { @@ -93,6 +93,18 @@ backup_file() # $1 = file to backup fi } +delete_file() # $1 = file to delete +{ + if [ -z "$PREFIX" -a -f $1 -a ! -f ${1}-${VERSION}.bkout ]; then + if (mv $1 ${1}-${VERSION}.bkout); then + echo + echo "$1 moved to ${1}-${VERSION}.bkout" + else + exit 1 + fi + fi +} + modify_rclocal() { if [ -f /etc/rc.d/rc.local ]; then @@ -104,11 +116,11 @@ modify_rclocal() fi else cant_autostart - fi + fi } install_file_with_backup() # $1 = source $2 = target $3 = mode -{ +{ backup_file $2 run_install -o $OWNER -g $GROUP -m $3 $1 ${2} } @@ -170,7 +182,7 @@ while [ $# -gt 0 ] ; do done PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin - + # # Determine where to install the firewall script # @@ -212,7 +224,7 @@ fi # Change to the directory containing this script # cd "`dirname $0`" - + echo "Installing Shorewall Version $VERSION" # @@ -251,20 +263,20 @@ if [ -n "$RUNLEVELS" ]; then fi install_file_with_backup init.temp ${PREFIX}${DEST}/$FIREWALL 0544 - + rm -f init.temp awk.tmp else install_file_with_backup init.sh ${PREFIX}${DEST}/$FIREWALL 0544 fi - + echo echo "Shorewall script installed in ${PREFIX}${DEST}/$FIREWALL" # -# Create /etc/shorewall, /usr/lib/shorewall and /var/shorewall if needed +# Create /etc/shorewall, /usr/share/shorewall and /var/shorewall if needed # mkdir -p ${PREFIX}/etc/shorewall -mkdir -p ${PREFIX}/usr/lib/shorewall +mkdir -p ${PREFIX}/usr/share/shorewall mkdir -p ${PREFIX}/var/lib/shorewall # # Install the config file @@ -294,16 +306,16 @@ if [ -f ${PREFIX}/etc/shorewall/functions ]; then backup_file ${PREFIX}/etc/shorewall/functions rm -f ${PREFIX}/etc/shorewall/functions fi - + if [ -f ${PREFIX}/var/lib/shorewall/functions ]; then backup_file ${PREFIX}/var/lib/shorewall/functions rm -f ${PREFIX}/var/lib/shorewall/functions fi - -install_file_with_backup functions ${PREFIX}/usr/lib/shorewall/functions 0444 + +install_file_with_backup functions ${PREFIX}/usr/share/shorewall/functions 0444 echo -echo "Common functions installed in ${PREFIX}/usr/lib/shorewall/functions" +echo "Common functions installed in ${PREFIX}/usr/share/shorewall/functions" # # Install the common.def file # @@ -311,13 +323,11 @@ install_file_with_backup common.def ${PREFIX}/etc/shorewall/common.def 0444 echo echo "Common rules installed in ${PREFIX}/etc/shorewall/common.def" -# -# Install the icmp.def file -# -install_file_with_backup icmp.def ${PREFIX}/etc/shorewall/icmp.def 0444 -echo -echo "Common ICMP rules installed in ${PREFIX}/etc/shorewall/icmp.def" +# +# Delete the icmp.def file +# +delete_file icmp.def # # Install the policy file @@ -369,13 +379,13 @@ else echo echo "NAT file installed as ${PREFIX}/etc/shorewall/nat" fi -# +# # Install the Parameters file # if [ -f ${PREFIX}/etc/shorewall/params ]; then backup_file /etc/shorewall/params else - run_install -o $OWNER -g $GROUP -m 0600 params ${PREFIX}/etc/shorewall/params + run_install -o $OWNER -g $GROUP -m 0600 params ${PREFIX}/etc/shorewall/params echo echo "Parameter file installed as ${PREFIX}/etc/shorewall/params" fi @@ -528,10 +538,22 @@ else echo "Stopped file installed as ${PREFIX}/etc/shorewall/stopped" fi # +# Install the ECN file +# +if [ -f ${PREFIX}/etc/shorewall/ecn ]; then + backup_file /etc/shorewall/ecn +else + run_install -o $OWNER -g $GROUP -m 0600 ecn ${PREFIX}/etc/shorewall/ecn + echo + echo "ECN file installed as ${PREFIX}/etc/shorewall/ecn" +fi +# # Backup the version file # if [ -z "$PREFIX" ]; then - if [ -f /usr/lib/shorewall/version ]; then + if [ -f /usr/share/shorewall/version ]; then + backup_file /usr/share/shorewall/version + elif [ -f /usr/lib/shorewall/version ]; then backup_file /usr/lib/shorewall/version elif [ -n "$oldversion" ]; then echo $oldversion > /usr/lib/shorewall/version-${VERSION}.bkout @@ -542,10 +564,10 @@ fi # # Create the version file # -echo "$VERSION" > ${PREFIX}/usr/lib/shorewall/version -chmod 644 ${PREFIX}/usr/lib/shorewall/version +echo "$VERSION" > ${PREFIX}/usr/share/shorewall/version +chmod 644 ${PREFIX}/usr/share/shorewall/version # -# Remove and create the symbolic link to the firewall script +# Remove and create the symbolic link to the init script # if [ -z "$PREFIX" ]; then @@ -554,12 +576,13 @@ if [ -z "$PREFIX" ]; then [ -L /usr/lib/shorewall/firewall ] && \ mv -f /usr/lib/shorewall/firewall /usr/lib/shorewall/firewall-${VERSION}.bkout rm -f /usr/lib/shorewall/init - ln -s ${DEST}/${FIREWALL} /usr/lib/shorewall/init + rm -f /usr/share/shorewall/init + ln -s ${DEST}/${FIREWALL} /usr/share/shorewall/init fi # # Install the firewall script # -install_file_with_backup firewall ${PREFIX}/usr/lib/shorewall/firewall 0544 +install_file_with_backup firewall ${PREFIX}/usr/share/shorewall/firewall 0544 if [ -z "$PREFIX" -a -n "$first_install" ]; then if [ -x /sbin/insserv -o -x /usr/sbin/insserv ]; then diff --git a/STABLE/interfaces b/STABLE/interfaces index 29490d9b5..cfc0e2b0e 100644 --- a/STABLE/interfaces +++ b/STABLE/interfaces @@ -1,5 +1,5 @@ # -# Shorewall 1.3 -- Interfaces File +# Shorewall 1.4 -- Interfaces File # # /etc/shorewall/interfaces # @@ -14,7 +14,7 @@ # If the interface serves multiple zones that will be # defined in the /etc/shorewall/hosts file, you should # place "-" in this column. -# +# # INTERFACE Name of interface. Each interface may be listed only # once in this file. You may NOT specify the name of # an alias (e.g., eth0:0) here; see @@ -27,14 +27,14 @@ # column is left black.If the interface has multiple # addresses on multiple subnets then list the broadcast # addresses as a comma-separated list. -# +# # If you use the special value "detect", the firewall # will detect the broadcast address for you. If you # select this option, the interface must be up before # the firewall is started, you must have iproute # installed and the interface must only be associated # with a single subnet. -# +# # If you don't want to give a value for this column but # you want to enter a value in the OPTIONS column, enter # "-" in this column. @@ -46,11 +46,6 @@ # a DHCP server running on the firewall or # you have a static IP but are on a LAN # segment with lots of Laptop DHCP clients. -# routestopped - (Deprecated -- use -# /etc/shorewall/routestopped) -# When the firewall is stopped, allow -# and route traffic to and from this -# interface. # norfc1918 - This interface should not receive # any packets whose source is in one # of the ranges reserved by RFC 1918 @@ -59,9 +54,6 @@ # enabled in shorewall.conf, packets # whose destination addresses are # reserved by RFC 1918 are also rejected. -# multi - This interface has multiple IP -# addresses and you want to be able to -# route between them. # routefilter - turn on kernel route filtering for this # interface (anti-spoofing measure). This # option can also be enabled globally in @@ -87,8 +79,8 @@ # TCP_FLAGS_DISPOSITION after having been # logged according to the setting of # TCP_FLAGS_LOG_LEVEL. -# proxyarp - -# Sets +# proxyarp - +# Sets # /proc/sys/net/ipv4/conf//proxy_arp. # Do NOT use this option if you are # employing Proxy ARP through entries in @@ -96,7 +88,7 @@ # intended soley for use with Proxy ARP # sub-networking as described at: # http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet -# +# # The order in which you list the options is not # significant but the list should have no embedded white # space. @@ -106,21 +98,19 @@ # local subnet is 192.168.1.0/24. The interface gets # it's IP address via DHCP from subnet # 206.191.149.192/27. You have a DMZ with subnet -# 192.168.2.0/24 using eth2. You want to be able to -# access the firewall from the local network when the -# firewall is stopped. +# 192.168.2.0/24 using eth2. # # Your entries for this setup would look like: # # net eth0 206.191.149.223 dhcp -# local eth1 192.168.1.255 routestopped +# local eth1 192.168.1.255 # dmz eth2 192.168.2.255 # # Example 2: The same configuration without specifying broadcast # addresses is: # # net eth0 detect dhcp -# loc eth1 detect routestopped +# loc eth1 detect # dmz eth2 detect # # Example 3: You have a simple dial-in system with no ethernet diff --git a/STABLE/maclist b/STABLE/maclist index 37c61a38f..91b5e0f35 100644 --- a/STABLE/maclist +++ b/STABLE/maclist @@ -1,12 +1,12 @@ # -# Shorewall 1.3 - MAC list file +# Shorewall 1.4 - MAC list file # # /etc/shorewall/maclist # # Columns are: # # INTERFACE Network interface to a host -# +# # MAC MAC address of the host -- you do not need to use # the Shorewall format for MAC addresses here # diff --git a/STABLE/masq b/STABLE/masq index 0b8515619..27826945c 100644 --- a/STABLE/masq +++ b/STABLE/masq @@ -1,5 +1,5 @@ # -# Shorewall 1.3 - Masquerade file +# Shorewall 1.4 - Masquerade file # # /etc/shorewall/masq # @@ -13,8 +13,8 @@ # /etc/shorewall/shorewall.conf, you may add ":" and # a digit to indicate that you want the alias added with # that name (e.g., eth0:0). This will allow the alias to -# be displayed with ifconfig. THAT IS THE ONLY USE FOR -# THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER +# be displayed with ifconfig. THAT IS THE ONLY USE FOR +# THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER # PLACE IN YOUR SHOREWALL CONFIGURATION. # # This may be qualified by adding the character @@ -25,7 +25,7 @@ # a subnet or as an interface. If you give the name of an # interface, you must have iproute installed and the interface # must be up before you start the firewall. -# +# # In order to exclude a subset of the specified SUBNET, you # may append "!" and a comma-separated list of IP addresses # and/or subnets that you wish to exclude. @@ -37,17 +37,17 @@ # # ADDRESS -- (Optional). If you specify an address here, SNAT will be # used and this will be the source address. If -# ADD_SNAT_ALIASES is set to Yes or yes in +# ADD_SNAT_ALIASES is set to Yes or yes in # /etc/shorewall/shorewall.conf then Shorewall # will automatically add this address to the -# INTERFACE named in the first column. +# INTERFACE named in the first column. # # WARNING: Do NOT specify ADD_SNAT_ALIASES=Yes if # the address given in this column is the primary # IP address for the interface in the INTERFACE # column. # -# This column may not contain a DNS Name. +# This column may not contain a DNS Name. # # Example 1: # @@ -83,7 +83,7 @@ # # You want all outgoing traffic from 192.168.1.0/24 through # eth0 to use source address 206.124.146.176 which is NOT the -# primary address of eth0. You want 206.124.146.176 added to +# primary address of eth0. You want 206.124.146.176 added to # be added to eth0 with name eth0:0. # # eth0:0 192.168.1.0/24 206.124.146.176 diff --git a/STABLE/modules b/STABLE/modules index 5bc6278dd..25b62c9e4 100644 --- a/STABLE/modules +++ b/STABLE/modules @@ -1,7 +1,12 @@ ############################################################################## -# Shorewall 1.3 /etc/shorewall/modules +# Shorewall 1.4 /etc/shorewall/modules # # This file loads the modules needed by the firewall. +# +# THE ORDER OF THE COMMANDS BELOW IS IMPORTANT!!!!!! You MUST load in +# dependency order. i.e., if M2 depends on M1 then you must load M1 before +# you load M2. +# loadmodule ip_tables loadmodule iptable_filter diff --git a/STABLE/nat b/STABLE/nat index e791a8052..4c0db0cf7 100644 --- a/STABLE/nat +++ b/STABLE/nat @@ -1,6 +1,6 @@ ############################################################################## # -# Shorewall 1.3 -- Network Address Translation Table +# Shorewall 1.4 -- Network Address Translation Table # # /etc/shorewall/nat # @@ -17,7 +17,7 @@ # column and must not be a DNS Name. # INTERFACE Interface that we want to EXTERNAL address to appear # on. If ADD_IP_ALIASES=Yes in shorewall.conf, you may -# follow the interface name with ":" and a digit to +# follow the interface name with ":" and a digit to # indicate that you want Shorewall to add the alias # with this name (e.g., "eth0:0"). That allows you to # see the alias with ifconfig. THAT IS THE ONLY THING diff --git a/STABLE/params b/STABLE/params index fbea82388..ba53d6446 100644 --- a/STABLE/params +++ b/STABLE/params @@ -1,5 +1,5 @@ # -# Shorewall 1.3 /etc/shorewall/params +# Shorewall 1.4 /etc/shorewall/params # # Assign any variables that you need here. # @@ -11,7 +11,7 @@ # # NET_IF=eth0 # NET_BCAST=130.252.100.255 -# NET_OPTIONS=noping,norfc1918 +# NET_OPTIONS=routefilter,norfc1918 # # Example (/etc/shorewall/interfaces record): # @@ -19,25 +19,7 @@ # # The result will be the same as if the record had been written # -# net eth0 130.252.100.255 noping,norfc1918 +# net eth0 130.252.100.255 routefilter,norfc1918 # -# Variables can be used in the following places in the other configuration -# files: -# -# /etc/shorewall/interfaces: -# /etc/shorewall/hosts -# -# All except the first column. -# -# /etc/shorewall/rules -# -# First column after ":". -# All remaining columns -# -# /etc/shorewall/tunnels -# /etc/shorewall/proxyarp -# /etc/shorewall/nat -# -# All columns ############################################################################## #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE diff --git a/STABLE/policy b/STABLE/policy index 421d05c78..c90d1cdc1 100644 --- a/STABLE/policy +++ b/STABLE/policy @@ -1,5 +1,5 @@ # -# Shorewall 1.3 -- Policy File +# Shorewall 1.4 -- Policy File # # /etc/shorewall/policy # diff --git a/STABLE/proxyarp b/STABLE/proxyarp index f7261543a..81c88a512 100644 --- a/STABLE/proxyarp +++ b/STABLE/proxyarp @@ -1,10 +1,10 @@ ############################################################################## # -# Shorewall 1.3 -- Proxy ARP +# Shorewall 1.4 -- Proxy ARP # # /etc/shorewall/proxyarp # -# This file is used to define Proxy ARP. +# This file is used to define Proxy ARP. # # Columns must be separated by white space and are: # diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index 1770be3ea..b6e048be7 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -1,105 +1,94 @@ -This is a minor release of Shorewall that has a couple of new features. +This is a major release of Shorewall. -New features include: +Function from 1.3 that has been omitted from this version includes: -1) An OLD_PING_HANDLING option has been added to shorewall.conf. When - set to Yes, Shorewall ping handling is as it has always been (see - http://www.shorewall.net/ping.html). +1) The MERGE_HOSTS variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with + MERGE_HOSTS=Yes. - When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and - policies just like any other connection request. The FORWARDPING - option in shorewall.conf is ignored and the 'noping' and - 'filterping' options in /etc/shorewall/interfaces will generate an - error. +2) Interface names of the form : in + /etc/shorewall/interfaces now generate an error. -2) It is now possible to direct Shorewall to create a "label" such as - "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label - instead of just the interface name: +3) Shorewall 1.4 implements behavior consistent with + OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an error + at startup as will specification of the 'noping' or 'filterping' + interface options. - a) In the INTERFACE column of /etc/shorewall/masq - b) In the INTERFACE column of /etc/shorewall/nat +4) The 'routestopped' option in the /etc/shorewall/interfaces and + /etc/shorewall/hosts files is no longer supported and will generate + an error at startup if specified. -3) The ability to name your VLAN interfaces using the $dev.$vid - convention (e.g., "eth0.0") has been restored. This capability was - inadvertently broken in version 1.3.12. +5) The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted. -4) Support has been added for defining OpenVPN tunnels in the - /etc/shorewall/tunnels file. +6) The ALLOWRELATED variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with + ALLOWRELATED=Yes. -5) When an interface name is entered in the SUBNET column of the - /etc/shorewall/masq file, Shorewall previously masqueraded traffic - from only the first subnet defined on that interface. It did not - masquerade traffic from: +7) The 'multi' interface option is no longer supported. Shorewall will + generate rules for sending packets back out the same interface + that they arrived on in two cases: - a) The subnets associated with other addresses on the interface. - b) Subnets accessed through local routers. + a) There is an _explicit_ policy for the source zone to the + destination zone. An explicit policy names both zones and does not + use the 'all' reserved word. - Beginning with Shorewall 1.3.14, if you enter an interface name in - the SUBNET column, shorewall will use the firewall's routing table - to construct the masquerading/SNAT rules. + b) There are one or more rules for traffic for the source zone to + or from the destination zone including rules that use the 'all' + reserved word. Exception: If the source and the destination are + the same zone then the rule must be explicit - it must name the zone + in both the SOURCE and DESTINATION columns. - Example 1 -- This is how it works in 1.3.14. - - [root@gateway test]# cat /etc/shorewall/masq - #INTERFACE SUBNET ADDRESS - eth0 eth2 206.124.146.176 - #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - - [root@gateway test]# ip route show dev eth2 - 192.168.1.0/24 scope link - 192.168.10.0/24 proto kernel scope link src 192.168.10.254 - - [root@gateway test]# ip route show dev eth2 - 192.168.1.0/24 scope link - 192.168.10.0/24 proto kernel scope link src 192.168.10.254 - [root@gateway test]# shorewall start - ... - Masqueraded Subnets and Hosts: - To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176 - To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176 - Processing /etc/shorewall/tos... +Changes for 1.4 include: - When upgrading to Shorewall 1.3.14, if you have multiple local - subnets connected to an interface that is specified in the SUBNET - column of an /etc/shorewall/masq entry, your /etc/shorewall/masq - file will need changing. In most cases, you will simply be able to - remove redundant entries. In some cases though, you might want to change - from using the interface name to listing specific subnetworks if the - change described above will cause masquerading to occur on - subnetworks that you don't wish to masquerade. +1) shorewall.conf has been completely reorganized into logical + sections. - Example 2 -- Suppose that your current config is as follows: - - [root@gateway test]# cat /etc/shorewall/masq - #INTERFACE SUBNET ADDRESS - eth0 eth2 206.124.146.176 - eth0 192.168.10.0/24 206.124.146.176 - #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - - [root@gateway test]# ip route show dev eth2 - 192.168.1.0/24 scope link - 192.168.10.0/24 proto kernel scope link src 192.168.10.254 - [root@gateway test]# +2) LOG is now a valid action for a rule (/etc/shorewall/rules). - In this case, the second entry in /etc/shorewall/masq is no longer - required. +3) The firewall script and version file are now installed in + /usr/share/shorewall. - Example 3 -- What if your current configuration is like this? +4. Late arriving DNS replies are now silently dropped in the common + chain by default. + +5) In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 no + longer unconditionally accepts outbound ICMP packets. So if you want + to 'ping' from the firewall, you will need the appropriate rule or + policy. + +6) CONTINUE is now a valid action for a rule (/etc/shorewall/rules). + +7) 802.11b devices with names of the form wlan now support the + 'maclist' option. + +8) IMPORTANT: Shorewall now REQUIRES the iproute package ('ip' + utility). + +9) Explicit Congestion Notification (ECN - RFC 3168) may now be turned + off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility: + + a) You must be running kernel 2.4.20 + b) You must have applied the patch in + http://www.shorewall/net/pub/shorewall/ecn/patch. + c) You must have iptables 1.2.7a installed. + +10) The /etc/shorewall/params file is now processed first so that + variables may be used in the /etc/shorewall/shorewall.conf file. + +11) Packets with state INVALID are now silently dropped. + +12) Shorewall now gives a more helpful diagnostic when the 'ipchains' + compatibility kernel module is loaded and a 'shorewall start' + command is issued. + +13) The SHARED_DIR variable has been removed from shorewall.conf. This + variable was for use by package maintainers and was not documented + for general use. + +14) Shorewall now ignores 'default' routes when detecting masq'd + networks. - [root@gateway test]# cat /etc/shorewall/masq - #INTERFACE SUBNET ADDRESS - eth0 eth2 206.124.146.176 - #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - - [root@gateway test]# ip route show dev eth2 - 192.168.1.0/24 scope link - 192.168.10.0/24 proto kernel scope link src 192.168.10.254 - [root@gateway test]# - In this case, you would want to change the entry in - /etc/shorewall/masq to: - #INTERFACE SUBNET ADDRESS - eth0 192.168.1.0/24 206.124.146.176 - #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE diff --git a/STABLE/rfc1918 b/STABLE/rfc1918 index 4e6914b86..fdfd1b45c 100644 --- a/STABLE/rfc1918 +++ b/STABLE/rfc1918 @@ -1,5 +1,5 @@ # -# Shorewall 1.3 -- RFC1918 File +# Shorewall 1.4 -- RFC1918 File # # /etc/shorewall/rfc1918 # @@ -25,7 +25,7 @@ 192.0.2.0/24 logdrop # Example addresses 192.168.0.0/16 logdrop # RFC 1918 # -# The following are generated using the Python program found at: +# The following are generated with the help of the Python program found at: # # http://www.shorewall.net/pub/shorewall/contrib/iana_reserved/ # @@ -43,6 +43,8 @@ 39.0.0.0/8 logdrop # Reserved 41.0.0.0/8 logdrop # Reserved 42.0.0.0/8 logdrop # Reserved +49.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98 +50.0.0.0/8 logdrop # JTC - Returned to IANA Mar 98 58.0.0.0/7 logdrop # Reserved 60.0.0.0/8 logdrop # Reserved 70.0.0.0/7 logdrop # Reserved @@ -53,6 +55,8 @@ 96.0.0.0/3 logdrop # Reserved 127.0.0.0/8 logdrop # Loopback 197.0.0.0/8 logdrop # Reserved +198.18.0.0/15 logdrop # Reserved +201.0.0.0/8 logdrop # Reserved - Central & South America 240.0.0.0/4 logdrop # Reserved # # End of generated entries diff --git a/STABLE/routestopped b/STABLE/routestopped index db1459080..55698c986 100644 --- a/STABLE/routestopped +++ b/STABLE/routestopped @@ -1,10 +1,10 @@ ############################################################################## # -# Shorewall 1.3 -- Hosts Accessible when the Firewall is Stopped +# Shorewall 1.4 -- Hosts Accessible when the Firewall is Stopped # # /etc/shorewall/routestopped # -# This file is used to define the hosts that are accessible when the +# This file is used to define the hosts that are accessible when the # firewall is stopped # # Columns must be separated by white space and are: @@ -12,7 +12,7 @@ # INTERFACE - Interface through which host(s) communicate with # the firewall # HOST(S) - (Optional) Comma-separated list of IP/subnet -# addresses. If left empty or supplied as "-", +# If left empty or supplied as "-", # 0.0.0.0/0 is assumed. # # Example: diff --git a/STABLE/rules b/STABLE/rules index 8a6244f55..53bae816c 100644 --- a/STABLE/rules +++ b/STABLE/rules @@ -1,5 +1,5 @@ # -# Shorewall version 1.3 - Rules File +# Shorewall version 1.4 - Rules File # # /etc/shorewall/rules # @@ -24,24 +24,31 @@ # DNAT -- Forward the request to another # system (and optionally another # port). -# DNAT- -- Advanced users only. +# DNAT- -- Advanced users only. # Like DNAT but only generates the # DNAT iptables rule and not # the companion ACCEPT rule. # REDIRECT -- Redirect the request to a local # port on the firewall. +# CONTINUE -- (For experts only). Do not process +# any of the following rules for this +# (source zone,destination zone). If +# The source and/or destination IP +# address falls into a zone defined +# later in /etc/shorewall/zones, this +# connection request will be passed +# to the rules defined for that +# (those) zone(s). # # May optionally be followed by ":" and a syslog log # level (e.g, REJECT:info). This causes the packet to be # logged at the specified level. # -# Beginning with Shorewall version 1.3.12, you may -# also specify ULOG (must be in upper case) as a log level.\ -# This will log to the ULOG target and sent to a separate log -# through use of ulogd +# You may also specify ULOG (must be in upper case) as a +# log level.This will log to the ULOG target for routing +# to a separate log through use of ulogd # (http://www.gnumonks.org/projects/ulogd). # -# # SOURCE Source hosts to which the rule applies. May be a zone # defined in /etc/shorewall/zones, $FW to indicate the # firewall itself, or "all" If the ACTION is DNAT or @@ -90,6 +97,8 @@ # 2. In DNAT rules, only IP addresses are # allowed; no FQDNs or subnet addresses # are permitted. +# 3. You may not specify both an interface and +# an address. # # The port that the server is listening on may be # included and separated from the server's IP address by @@ -106,10 +115,8 @@ # contain the port number on the firewall that the # request should be redirected to. # -# PROTO Protocol - Must be "tcp", "udp", "icmp", a number, -# "all" or "related". If "related", the remainder of the -# entry must be omitted and connection requests that are -# related to existing requests will be accepted. +# PROTO Protocol - Must be "tcp", "udp", "icmp", a number, or +# "all". # # DEST PORT(S) Destination Ports. A comma-separated list of Port # names (from /etc/services), port numbers or port @@ -117,7 +124,7 @@ # interpreted as the destination icmp-type(s). # # A port range is expressed as :. -# +# # This column is ignored if PROTOCOL = all but must be # entered if any of the following ields are supplied. # In that case, it is suggested that this field contain @@ -148,7 +155,7 @@ # Otherwise, a separate rule will be generated for each # port. # -# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT or +# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT or # REDIRECT) If included and different from the IP # address given in the SERVER column, this is an address # on some interface on the firewall and connections to diff --git a/STABLE/shorewall b/STABLE/shorewall index 3a2da0b91..27e60db9b 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -1,8 +1,8 @@ #!/bin/sh # -# Shorewall Packet Filtering Firewall Control Program - V1.3 - 6/14/2002 +# Shorewall Packet Filtering Firewall Control Program - V1.4 - 3/14/2003 # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # @@ -12,7 +12,7 @@ # Shorewall documentation is available at http://shorewall.sourceforge.net # # This program is free software; you can redistribute it and/or modify -# it under the terms of Version 2 of the GNU General Public License +# it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, @@ -23,7 +23,7 @@ # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA -# +# # If an error occurs while starting or restarting the firewall, the # firewall is automatically stopped. # @@ -34,13 +34,13 @@ # # shorewall add [:] zone Adds a host or subnet to a zone # shorewall delete [:] zone Deletes a host or subnet from a zone -# shorewall start Starts the firewall +# shorewall start Starts the firewall # shorewall restart Restarts the firewall # shorewall stop Stops the firewall # shorewall monitor [ refresh-interval ] Repeatedly Displays firewall status # plus the last 20 "interesting" # packets -# shorewall status Displays firewall status +# shorewall status Displays firewall status # shorewall reset Resets iptables packet and # byte counts # shorewall clear Open the floodgates by @@ -75,7 +75,7 @@ # listed address(es) # shorewall reject
          ... Temporarily reject all packets from the # listed address(es) -# shorewall allow
          ... Reenable address(es) previously +# shorewall allow
          ... Reenable address(es) previously # disabled with "drop" or "reject" # shorewall save Save the list of "rejected" and # "dropped" addresses so that it will @@ -84,6 +84,7 @@ # # Display a chain if it exists # + showfirstchain() # $1 = name of chain { awk \ @@ -142,7 +143,7 @@ get_config() { display_chains() { trap "rm -f /tmp/chains-$$; exit 1" 1 2 3 4 5 6 9 - + if [ "$haveawk" = "Yes" ]; then # # Send the output to a temporary file since ash craps if we try to store @@ -170,11 +171,11 @@ display_chains() echo chains=`grep '^Chain.*_[in|fwd]' /tmp/chains-$$ | cut -d' ' -f 2` - + for chain in $chains; do showchain $chain done - + timed_read for zone in $zones; do @@ -242,7 +243,7 @@ display_chains() # Delay $timeout seconds -- if we're running on a recent bash2 then allow # to terminate the delay # -timed_read () +timed_read () { read -t $timeout foo 2> /dev/null @@ -252,7 +253,7 @@ timed_read () # # Display the last $1 packets logged # -packet_log() # $1 = number of messages +packet_log() # $1 = number of messages { local options @@ -334,7 +335,7 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that get_config host=`echo $HOSTNAME | sed 's/\..*$//'` oldrejects=`iptables -L -v -n | grep 'LOG'` - + if [ $1 -lt 0 ]; then let "timeout=- $1" pause="Yes" @@ -347,7 +348,7 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that while true; do display_chains - + clear echo "$banner `date`" echo @@ -361,7 +362,7 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that if [ "$rejects" != "$oldrejects" ]; then oldrejects="$rejects" - + $RING_BELL packet_log 20 @@ -435,7 +436,7 @@ logwatch() # $1 = timeout -- if negative, prompt each time that get_config host=`echo $HOSTNAME | sed 's/\..*$//'` oldrejects=`iptables -L -v -n | grep 'LOG'` - + if [ $1 -lt 0 ]; then timeout=$((- $1)) pause="Yes" @@ -570,24 +571,11 @@ fi [ -n "$SHOREWALL_DIR" ] && export SHOREWALL_DIR PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin -SHARED_DIR=/usr/lib/shorewall MUTEX_TIMEOUT= -if [ -n "$SHOREWALL_DIR" -a -f $SHOREWALL_DIR/shorewall.conf ]; then - config=$SHOREWALL_DIR/shorewall.conf -else - config=/etc/shorewall/shorewall.conf -fi - -if [ -f $config ]; then - . $config -else - echo "$config does not exist!" >&2 - exit 2 -fi - [ -z "${STATEDIR}" ] && STATEDIR=/var/state/shorewall +SHARED_DIR=/usr/share/shorewall FIREWALL=$SHARED_DIR/firewall FUNCTIONS=$SHARED_DIR/functions VERSION_FILE=$SHARED_DIR/version @@ -599,6 +587,15 @@ else exit 2 fi +config=`find_file shorewall.conf` + +if [ -f $config ]; then + . $config +else + echo "$config does not exist!" >&2 + exit 2 +fi + if [ ! -f $FIREWALL ]; then echo "ERROR: Shorewall is not properly installed" if [ -L $FIREWALL ]; then @@ -754,7 +751,7 @@ case "$1" in echo "" echo " HITS PORT SERVICE(S)" - echo " ---- ----- ----------" + echo " ---- ----- ----------" grep 'Shorewall:.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ while read count port ; do # List all services defined for the given port @@ -853,4 +850,4 @@ case "$1" in *) usage 1 ;; -esac +esac diff --git a/STABLE/shorewall.conf b/STABLE/shorewall.conf index b79bb1faf..03d32e069 100644 --- a/STABLE/shorewall.conf +++ b/STABLE/shorewall.conf @@ -1,22 +1,17 @@ ############################################################################## -# /etc/shorewall/shorewall.conf V1.3 - Change the following variables to +# /etc/shorewall/shorewall.conf V1.4 - Change the following variables to # match your setup # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # This file should be placed in /etc/shorewall # # (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) ############################################################################## -# -# You should not have to change the variables in this section -- they are set -# by the packager of your Shorewall distribution -# -SHARED_DIR=/usr/lib/shorewall -# +# L O G G I N G ############################################################################## # -# General note about log levels. Log levels are a method of describing +# General note about log levels. Log levels are a method of describing # to syslog (8) the importance of a message and a number of parameters # in this file have log levels as their value. # @@ -32,72 +27,32 @@ SHARED_DIR=/usr/lib/shorewall # 0 emerg # # For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall -# log messages are generated by NetFilter and are logged using facility +# log messages are generated by NetFilter and are logged using facility # 'kern' and the level that you specifify. If you are unsure of the level # to choose, 6 (info) is a safe bet. You may specify levels by name or by # number. # -# If you have build your kernel with ULOG target support, you may also +# If you have build your kernel with ULOG target support, you may also # specify a log level of ULOG (must be all caps). Rather than log its # messages to syslogd, Shorewall will direct netfilter to log the messages # via the ULOG target which will send them to a process called 'ulogd'. -# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be +# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be # configured to log all Shorewall message to their own log file ################################################################################ # -# PATH - Change this if you want to change the order in which Shorewall -# searches directories for executable files. +# LOG FILE LOCATION # -PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin +# This variable tells the /sbin/shorewall program where to look for Shorewall +# log messages. If not set or set to an empty string (e.g., LOGFILE="") then +# /var/log/messages is assumed. +# +# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to +# look for Shorewall messages.It does NOT control the destination for +# these messages. For information about how to do that, see +# +# http://www.shorewall.net/shorewall_logging.html -# -# NAME OF THE FIREWALL ZONE -# -# Name of the firewall zone -- if not set or if set to an empty string, "fw" -# is assumed. -# -FW=fw - -# -# SUBSYSTEM LOCK FILE -# -# Set this to the name of the lock file expected by your init scripts. For -# RedHat, this should be /var/lock/subsys/shorewall. On Debian, it -# should be /var/state/shorewall. If your init scripts don't use lock files, -# set this to "". -# - -SUBSYSLOCK=/var/lock/subsys/shorewall - -# -# SHOREWALL TEMPORARY STATE DIRECTORY -# -# This is the directory where the firewall maintains state information while -# it is running -# - -STATEDIR=/var/lib/shorewall - -# -# ALLOW RELATED CONNECTIONS -# -# Set this to "yes" or "Yes" if you want to accept all connection requests -# that are related to already established connections. For example, you want -# to accept FTP data connections. If you say "no" here, then to accept -# these connections between particular zones or hosts, you must include -# explicit "related" rules in /etc/shorewall/rules. -# - -ALLOWRELATED=yes - -# -# KERNEL MODULE DIRECTORY -# -# If your netfilter kernel modules are in a directory other than -# /lib/modules/`uname -r`/kernel/net/ipv4/netfilter then specify that -# directory in this variable. Example: MODULESDIR=/etc/modules. - -MODULESDIR= +LOGFILE=/var/log/messages # # LOG RATE LIMITING @@ -132,25 +87,122 @@ LOGBURST= # packets are logged under the 'logunclean' interface option. If the variable # is empty, these packets will still be logged at the 'info' level. # -# See the comment at the top of this file for a description of log levels +# See the comment at the top of this section for a description of log levels # LOGUNCLEAN=info # -# LOG FILE LOCATION +# BLACKLIST LOG LEVEL # -# This variable tells the /sbin/shorewall program where to look for Shorewall -# log messages. If not set or set to an empty string (e.g., LOGFILE="") then -# /var/log/messages is assumed. +# Set this variable to the syslogd level that you want blacklist packets logged +# (beware of DOS attacks resulting from such logging). If not set, no logging +# of blacklist packets occurs. # -# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to -# look for Shorewall messages.It does NOT control the destination for -# these messages. For information about how to do that, see +# See the comment at the top of this section for a description of log levels # -# http://www.shorewall.net/FAQ.htm#faq6 +BLACKLIST_LOGLEVEL= -LOGFILE=/var/log/messages +# +# LOGGING 'New not SYN' rejects +# +# This variable only has an effect when NEWNOTSYN=No (see below). +# +# When a TCP packet that does not have the SYN flag set and the ACK and RST +# flags clear then unless the packet is part of an established connection, +# it will be rejected by the firewall. If you want these rejects logged, +# then set LOGNEWNOTSYN to the syslog log level at which you want them logged. +# +# See the comment at the top of this section for a description of log levels +# +# Example: LOGNEWNOTSYN=debug + + +LOGNEWNOTSYN= + +# +# MAC List Log Level +# +# Specifies the logging level for connection requests that fail MAC +# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then +# such connection requests will not be logged. +# +# See the comment at the top of this section for a description of log levels +# + +MACLIST_LOG_LEVEL=info + +# +# TCP FLAGS Log Level +# +# Specifies the logging level for packets that fail TCP Flags +# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then +# such packets will not be logged. +# +# See the comment at the top of this section for a description of log levels +# + +TCP_FLAGS_LOG_LEVEL=info + +# +# RFC1918 Log Level +# +# Specifies the logging level for packets that fail RFC 1918 +# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then +# RFC1918_LOG_LEVEL=info is assumed. +# +# See the comment at the top of this section for a description of log levels +# + +RFC1918_LOG_LEVEL=info + +################################################################################ +# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S +################################################################################ +# +# PATH - Change this if you want to change the order in which Shorewall +# searches directories for executable files. +# +PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin + +# SUBSYSTEM LOCK FILE +# +# Set this to the name of the lock file expected by your init scripts. For +# RedHat, this should be /var/lock/subsys/shorewall. On Debian, it +# should be /var/state/shorewall. If your init scripts don't use lock files, +# set this to "". +# + +SUBSYSLOCK=/var/lock/subsys/shorewall + +# +# SHOREWALL TEMPORARY STATE DIRECTORY +# +# This is the directory where the firewall maintains state information while +# it is running +# + +STATEDIR=/var/lib/shorewall + +# +# KERNEL MODULE DIRECTORY +# +# If your netfilter kernel modules are in a directory other than +# /lib/modules/`uname -r`/kernel/net/ipv4/netfilter then specify that +# directory in this variable. Example: MODULESDIR=/etc/modules. + +MODULESDIR= + +################################################################################ +# F I R E W A L L O P T I O N S +################################################################################ + +# NAME OF THE FIREWALL ZONE +# +# Name of the firewall zone -- if not set or if set to an empty string, "fw" +# is assumed. +# +FW=fw # # ENABLE NAT SUPPORT @@ -214,24 +266,40 @@ ADD_SNAT_ALIASES=No TC_ENABLED=No # -# BLACKLIST DISPOSITION +# Clear Traffic Shapping/Control # -# Set this variable to the action that you want to perform on packets from -# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty, -# DROP is assumed. +# If this option is set to 'No' then Shorewall won't clear the current +# traffic control rules during [re]start. This setting is intended +# for use by people that prefer to configure traffic shaping when +# the network interfaces come up rather than when the firewall +# is started. If that is what you want to do, set TC_ENABLED=Yes and +# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That +# way, your traffic shaping rules can still use the 'fwmark' +# classifier based on packet marking defined in /etc/shorewall/tcrules. # -BLACKLIST_DISPOSITION=DROP +# If omitted, CLEAR_TC=Yes is assumed. + +CLEAR_TC=Yes # -# BLACKLIST LOG LEVEL +# Mark Packets in the forward chain # -# Set this variable to the syslogd level that you want blacklist packets logged -# (beward of DOS attacks resulting from such logging). If not set, no logging -# of blacklist packets occurs. +# When processing the tcrules file, Shorewall normally marks packets in the +# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set +# this to "Yes". If not specified or if set to the empty value (e.g., +# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. # -# See the comment at the top of this file for a description of log levels +# Marking packets in the FORWARD chain has the advantage that inbound +# packets destined for Masqueraded/SNATed local hosts have had their destination +# address rewritten so they can be marked based on their destination. When +# packets are marked in the PREROUTING chain, packets destined for +# Masqueraded/SNATed local hosts still have a destination address corresponding +# to the firewall's external interface. # -BLACKLIST_LOGLEVEL= +# Note: Older kernels do not support marking packets in the FORWARD chain and +# setting this variable to Yes may cause startup problems. + +MARK_IN_FORWARD_CHAIN=No # # MSS CLAMPING @@ -311,63 +379,30 @@ MULTIPORT=No # DNAT net loc:192.168.1.3 tcp 80 # # it will forward TCP port 80 connections from the net to 192.168.1.3 -# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is +# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is # convenient for two reasons: # # a) If the the network interface has a dynamic IP address, the # firewall configuration will work even when the address # changes. # -# b) It saves having to configure the IP address in the rule +# b) It saves having to configure the IP address in the rule # while still allowing the firewall to be started before the # internet interface is brought up. # # This default behavior can also have a negative effect. If the -# internet interface has more than one IP address then the above -# rule will forward connection requests on all of these addresses; +# internet interface has more than one IP address then the above +# rule will forward connection requests on all of these addresses; # that may not be what is desired. # # By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply # only if the original destination address is the primary IP address of # one of the interfaces associated with the source zone. Note that this # requires all interfaces to the source zone to be up when the firewall -# is [re]started. +# is [re]started. DETECT_DNAT_IPADDRS=No -# -# MERGE HOSTS FILE -# -# The traditional behavior of the /etc/shorewall/hosts file has been that -# if that file has ANY entry for a zone then the zone must be defined -# entirely in the hosts file. This is counter-intuitive and has caused -# people some problems. -# -# By setting MERGE_HOSTS=Yes, a more intuitive behavior of the hosts file -# is enabled. With MERGE_HOSTS=Yes, the zone contents in the hosts file -# are added to the contents described in the /etc/shorewall/interfaces file. -# -# Example: Suppose that we have the following interfaces and hosts files: -# -# Interfaces: -# -# net eth0 -# loc eth1 -# - ppp+ -# -# Hosts: -# -# loc ppp+:192.168.1.0/24 -# wrk ppp+:!192.168.1.0/24 -# -# With MERGE_HOSTS=No, the contents of the 'loc' zone would be just -# ppp+:192.168.1.0/24. With MERGE_HOSTS=Yes, the contents would be -# ppp+:192.168.1.0 and eth1:0.0.0.0/0 -# -# If this variable is not set or is set to the empty value, "No" is assumed. - -MERGE_HOSTS=Yes - # # MUTEX TIMEOUT # @@ -383,36 +418,6 @@ MERGE_HOSTS=Yes MUTEX_TIMEOUT=60 -# -# LOGGING 'New not SYN' rejects -# -# This variable only has an effect when NEWNOTSYN=No (see below). -# -# When a TCP packet that does not have the SYN flag set and the ACK and RST -# flags clear then unless the packet is part of an established connection, -# it will be rejected by the firewall. If you want these rejects logged, -# then set LOGNEWNOTSYN to the syslog log level at which you want them logged. -# -# See the comment at the top of this file for a description of log levels -# -# Example: LOGNEWNOTSYN=debug - - -LOGNEWNOTSYN= - -# -# Old Ping Handling -# -# If this option is set to "Yes" then Shorewall will use its old ping handling -# facility including the FORWARDPING option in this file and the 'noping' and -# 'filterping' interface options. If this option is set to 'No' then ping -# is handled via policy and rules just like any other connection request. -# -# If you are a new Shorewall user DON'T CHANGE THE VALUE OF THIS OPTION AND -# DON'T DELETE IT!!!!!! -# -OLD_PING_HANDLING=No - # # NEWNOTSYN # @@ -427,9 +432,21 @@ OLD_PING_HANDLING=No # Users with a High-availability setup with two firewall's and one acting # as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may # also need to select NEWNOTSYN=Yes. - + NEWNOTSYN=No +################################################################################ +# P A C K E T D I S P O S I T I O N +################################################################################ +# +# BLACKLIST DISPOSITION +# +# Set this variable to the action that you want to perform on packets from +# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty, +# DROP is assumed. +# +BLACKLIST_DISPOSITION=DROP + # # MAC List Disposition # @@ -441,86 +458,14 @@ NEWNOTSYN=No MACLIST_DISPOSITION=REJECT -# -# MAC List Log Level -# -# Specifies the logging level for connection requests that fail MAC -# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then -# such connection requests will not be logged. -# -# See the comment at the top of this file for a description of log levels -# - -MACLIST_LOG_LEVEL=info - # # TCP FLAGS Disposition # -# This variable determins the disposition of packets having an invalid +# This variable determins the disposition of packets having an invalid # combination of TCP flags that are received on interfaces having the # 'tcpflags' option specified in /etc/shorewall/interfaces. If not specified # or specified as empty (TCP_FLAGS_DISPOSITION="") then DROP is assumed. TCP_FLAGS_DISPOSITION=DROP -# -# TCP FLAGS Log Level -# -# Specifies the logging level for packets that fail TCP Flags -# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then -# such packets will not be logged. -# -# See the comment at the top of this file for a description of log levels -# - -TCP_FLAGS_LOG_LEVEL=info - -# -# RFC1918 Log Level -# -# Specifies the logging level for packets that fail RFC 1918 -# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then -# RFC1918_LOG_LEVEL=info is assumed. -# -# See the comment at the top of this file for a description of log levels -# - -RFC1918_LOG_LEVEL=info - -# -# Mark Packets in the forward chain -# -# When processing the tcrules file, Shorewall normally marks packets in the -# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set -# this to "Yes". If not specified or if set to the empty value (e.g., -# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed. -# -# Marking packets in the FORWARD chain has the advantage that inbound -# packets destined for Masqueraded/SNATed local hosts have had their destination -# address rewritten so they can be marked based on their destination. When -# packets are marked in the PREROUTING chain, packets destined for -# Masqueraded/SNATed local hosts still have a destination address corresponding -# to the firewall's external interface. -# -# Note: Older kernels do not support marking packets in the FORWARD chain and -# setting this variable to Yes may cause startup problems. - -MARK_IN_FORWARD_CHAIN=No - -# -# Clear Traffic Shapping/Control -# -# If this option is set to 'No' then Shorewall won't clear the current -# traffic control rules during [re]start. This setting is intended -# for use by people that prefer to configure traffic shaping when -# the network interfaces come up rather than when the firewall -# is started. If that is what you want to do, set TC_ENABLED=Yes and -# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That -# way, your traffic shaping rules can still use the 'fwmark' -# classifier based on packet marking defined in /etc/shorewall/tcrules. -# -# If omitted, CLEAR_TC=Yes is assumed. - -CLEAR_TC=Yes - #LAST LINE -- DO NOT REMOVE diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 2be4d6efe..ea1f9c4ed 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.3.14 +%define version 1.4.0 %define release 1 %define prefix /usr @@ -15,7 +15,7 @@ Source: %{name}-%{version}.tgz URL: http://www.shorewall.net/ BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-root -Requires: iptables +Requires: iptables iproute Conflicts: kernel <= 2.2 %description @@ -48,10 +48,10 @@ if [ $1 -eq 1 ]; then ########################################################################" \ > /etc/shorewall/startup_disabled - if [ -x /sbin/insserv ]; then + if [ -x /sbin/insserv ]; then /sbin/insserv /etc/rc.d/shorewall elif [ -x /sbin/chkconfig ]; then - /sbin/chkconfig --add shorewall; + /sbin/chkconfig --add shorewall; fi fi @@ -68,14 +68,13 @@ if [ $1 = 0 ]; then fi -%files +%files /etc/init.d/shorewall %attr(0700,root,root) %dir /etc/shorewall -%attr(0700,root,root) %dir /usr/lib/shorewall +%attr(0700,root,root) %dir /usr/share/shorewall %attr(0700,root,root) %dir /var/lib/shorewall -%attr(0600,root,root) /usr/lib/shorewall/version +%attr(0600,root,root) /usr/share/shorewall/version %attr(0600,root,root) /etc/shorewall/common.def -%attr(0600,root,root) /etc/shorewall/icmp.def %attr(0600,root,root) %config(noreplace) /etc/shorewall/shorewall.conf %attr(0600,root,root) %config(noreplace) /etc/shorewall/zones %attr(0600,root,root) %config(noreplace) /etc/shorewall/policy @@ -98,15 +97,30 @@ fi %attr(0600,root,root) %config(noreplace) /etc/shorewall/start %attr(0600,root,root) %config(noreplace) /etc/shorewall/stop %attr(0600,root,root) %config(noreplace) /etc/shorewall/stopped +%attr(0600,root,root) %config(noreplace) /etc/shorewall/ecn %attr(0544,root,root) /sbin/shorewall -%attr(0444,root,root) /usr/lib/shorewall/functions -%attr(0544,root,root) /usr/lib/shorewall/firewall +%attr(0444,root,root) /usr/share/shorewall/functions +%attr(0544,root,root) /usr/share/shorewall/firewall %doc documentation %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog -* Fri Feb 07 2003 Tom Eastep -- Changes version to 1.3.14-1 +* Mon Mar 17 2003 Tom Eastep +- Changed version to 1.4.0-1 +* Fri Mar 07 2003 Tom Eastep +- Changed version to 1.4.0-0RC2 +* Wed Mar 05 2003 Tom Eastep +- Changed version to 1.4.0-0RC1 +* Mon Feb 24 2003 Tom Eastep +- Changed version to 1.4.0-0Beta2 +* Sun Feb 23 2003 Tom Eastep +- Add ecn file +* Fri Feb 21 2003 Tom Eastep +- Changes version to 1.4.0-0Beta1 +* Thu Feb 06 2003 Tom Eastep +- Changes version to 1.4.0Alpha1 +- Delete icmp.def +- Move firewall and version to /usr/share/shorewall * Tue Feb 04 2003 Tom Eastep - Changes version to 1.3.14-0RC1 * Tue Jan 28 2003 Tom Eastep @@ -276,7 +290,7 @@ fi - Changed the release to 4 - Added Zones and Functions files * Mon Mar 12 2001 Tom Eastep -- Change ipchains dependency to an iptables dependency and +- Change ipchains dependency to an iptables dependency and changed the release to 3 * Fri Mar 9 2001 Tom Eastep - Add additional files. diff --git a/STABLE/start b/STABLE/start index bd36e8544..7b46073f8 100644 --- a/STABLE/start +++ b/STABLE/start @@ -1,6 +1,6 @@ ############################################################################ -# Shorewall 1.3 -- /etc/shorewall/start +# Shorewall 1.4 -- /etc/shorewall/start # -# Add commands below that you want to be executed after shorewall has +# Add commands below that you want to be executed after shorewall has # been started or restarted. # diff --git a/STABLE/stop b/STABLE/stop index 5f097b037..6f402cfa6 100644 --- a/STABLE/stop +++ b/STABLE/stop @@ -1,5 +1,5 @@ ############################################################################ -# Shorewall 1.3 -- /etc/shorewall/stop +# Shorewall 1.4 -- /etc/shorewall/stop # # Add commands below that you want to be executed at the beginning of a # "shorewall stop" command. diff --git a/STABLE/stopped b/STABLE/stopped index 90afeb3ac..2b5840691 100644 --- a/STABLE/stopped +++ b/STABLE/stopped @@ -1,5 +1,5 @@ ############################################################################ -# Shorewall 1.3 -- /etc/shorewall/stopped +# Shorewall 1.4 -- /etc/shorewall/stopped # # Add commands below that you want to be executed at the completion of a # "shorewall stop" command. diff --git a/STABLE/tcrules b/STABLE/tcrules index 41d23120b..32215538c 100644 --- a/STABLE/tcrules +++ b/STABLE/tcrules @@ -1,5 +1,5 @@ # -# Shorewall version 1.3 - Traffic Control Rules File +# Shorewall version 1.4 - Traffic Control Rules File # # /etc/shorewall/tcrules # @@ -26,10 +26,10 @@ # /etc/shorewall/shorewall.conf. # # SOURCE Source of the packet. A comma-separated list of -# interface names, IP addresses, MAC addresses +# interface names, IP addresses, MAC addresses # and/or subnets. Use $FW if the packet originates on # the firewall in which case the MARK column may NOT -# specify either ":P" or ":F" (marking always occurs +# specify either ":P" or ":F" (marking always occurs # in the OUTPUT chain). # # MAC addresses must be prefixed with "~" and use diff --git a/STABLE/tos b/STABLE/tos index 0254fcdff..60245554e 100644 --- a/STABLE/tos +++ b/STABLE/tos @@ -1,5 +1,5 @@ # -# Shorewall 1.3 -- /etc/shorewall/tos +# Shorewall 1.4 -- /etc/shorewall/tos # # This file defines rules for setting Type Of Service (TOS) # diff --git a/STABLE/tunnel b/STABLE/tunnel index 6fd56fad7..2cb20ca36 100644 --- a/STABLE/tunnel +++ b/STABLE/tunnel @@ -2,12 +2,12 @@ RCDLINKS="2,S45 3,S45 6,K45" ################################################################################ -# Script to create a gre or ipip tunnel -- Shorewall 1.3 +# Script to create a gre or ipip tunnel -- Shorewall 1.4 # # Modified - Steve Cowles 5/9/2000 # Incorporated init {start|stop} syntax and iproute2 usage -# -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # diff --git a/STABLE/tunnels b/STABLE/tunnels index 86747729b..ee45c54b3 100644 --- a/STABLE/tunnels +++ b/STABLE/tunnels @@ -1,5 +1,5 @@ # -# Shorewall 1.3 - /etc/shorewall/tunnels +# Shorewall 1.4 - /etc/shorewall/tunnels # # This file defines IPSEC, GRE, IPIP and OPENVPN tunnels. # @@ -25,7 +25,7 @@ # remote getway has no fixed address (Road Warrior) # then specify the gateway as 0.0.0.0/0. # -# GATEWAY +# GATEWAY # ZONES -- Optional. If the gateway system specified in the third # column is a standalone host then this column should # contain a comma-separated list of the names of the diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index 510f4e14f..b544cfd98 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -2,14 +2,14 @@ # # Script to back uninstall Shoreline Firewall # -# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] # # (c) 2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net) # # Shorewall documentation is available at http://shorewall.sourceforge.net # # This program is free software; you can redistribute it and/or modify -# it under the terms of Version 2 of the GNU General Public License +# it under the terms of Version 2 of the GNU General Public License # as published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.3.14 +VERSION=1.4.0 usage() # $1 = exit status { @@ -35,8 +35,8 @@ usage() # $1 = exit status exit $1 } -qt() -{ +qt() +{ "$@" >/dev/null 2>&1 } @@ -49,7 +49,7 @@ restore_file() # $1 = file to restore else exit 1 fi - fi + fi } remove_file() # $1 = file to restore @@ -108,6 +108,7 @@ fi rm -rf /etc/shorewall rm -rf /usr/lib/shorewall rm -rf /var/lib/shorewall +rm -rf /usr/share/shorewall echo "Shorewall Uninstalled" diff --git a/STABLE/zones b/STABLE/zones index 45f103b73..e9b882473 100644 --- a/STABLE/zones +++ b/STABLE/zones @@ -1,14 +1,14 @@ # -# Shorewall 1.3 /etc/shorewall/zones +# Shorewall 1.4 /etc/shorewall/zones # # This file determines your network zones. Columns are: # -# ZONE Short name of the zone +# ZONE Short name of the zone # DISPLAY Display name of the zone # COMMENTS Comments about the zone # #ZONE DISPLAY COMMENTS -net Net Internet +net Net Internet loc Local Local networks dmz DMZ Demilitarized zone #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE