From 1f72beecc8eab1b9cdab63d6b1cd5ce623132122 Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 5 Aug 2003 18:38:21 +0000 Subject: [PATCH] Shorewall-1.4.6b git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@684 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- STABLE/changelog.txt | 4 + STABLE/documentation/Documentation.htm | 6329 +++++++++-------- STABLE/documentation/FAQ.htm | 2331 +++--- STABLE/documentation/News.htm | 5860 +++++++-------- .../documentation/Shorewall_Squid_Usage.html | 915 ++- .../Shorewall_and_Aliased_Interfaces.html | 1184 +-- .../documentation/Shorewall_index_frame.htm | 169 +- .../documentation/Shorewall_sfindex_frame.htm | 162 +- STABLE/documentation/blacklisting_support.htm | 131 +- STABLE/documentation/download.htm | 344 +- STABLE/documentation/errata.htm | 614 +- STABLE/documentation/images/network.png | Bin 59803 -> 71154 bytes STABLE/documentation/mailing_list.htm | 368 +- STABLE/documentation/myfiles.htm | 319 +- STABLE/documentation/ports.htm | 343 +- STABLE/documentation/quotes.htm | 215 +- .../documentation/seattlefirewall_index.htm | 950 +-- STABLE/documentation/shoreline.htm | 143 +- STABLE/documentation/shorewall_logging.html | 272 +- STABLE/documentation/shorewall_mirrors.htm | 127 +- .../shorewall_quickstart_guide.htm | 562 +- STABLE/documentation/sourceforge_index.htm | 1046 +-- STABLE/documentation/standalone.htm | 698 +- .../starting_and_stopping_shorewall.htm | 564 +- STABLE/documentation/support.htm | 480 +- STABLE/documentation/three-interface.htm | 2047 +++--- STABLE/documentation/two-interface.htm | 1774 ++--- STABLE/fallback.sh | 2 +- STABLE/firewall | 29 +- STABLE/install.sh | 2 +- STABLE/releasenotes.txt | 13 + STABLE/shorewall.spec | 4 +- STABLE/uninstall.sh | 2 +- 33 files changed, 14457 insertions(+), 13546 deletions(-) diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index 4d85fe9cb..e8e4a1b2d 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -56,3 +56,7 @@ Changes since 1.4.5 MANGLE_ENABLED is set before it is tested. 24. Fixed MAC address handling in the SOURCE column of tcrules. + +25. Disabled 'stop' command when startup is disabled. + +26. Fixed adding addresses to ppp interfaces. diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 737efb0d7..e3a05a345 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -2,3482 +2,3603 @@ - + - + - + Shorewall 1.4 Documentation - - + + - + - + - + - - - + + - + + - - + +
+
- +

Shorewall 1.4 Reference

-
- -

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

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:

- + - +

/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 + +

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

- + size="1"> 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.

- + +

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:

- + +

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:

+ - +

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

- + - + - - - - - + + + + + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + - - + +
- ZONE - DISPLAY - COMMENTS
+ ZONE + DISPLAY + COMMENTS
netNetInternet
locLocalLocal - networks
dmzDMZDemilitarized - zone
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.

- + +

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".

- + color="#ff0000"> If you rename or delete a zone, you should perform "shorewall + 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.

- + color="#ff0000">The order of entries in the /etc/shorewall/zones file is + 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 + +

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:

- + - +

My recommendations concerning options:
-

- +

+ - +

- -

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:

- -
- + +

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:

+ +
+ - + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - + +
+ ZONE + INTERFACE + BROADCAST + OPTIONS
neteth0detectdhcp,norfc1918,blacklist
loceth1detect
+
- 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:

- -
- +
+ +

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
netppp0
-
-
-
- -

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

- -
- +
+ +

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
loceth1192.168.1.255,192.168.12.255
-
+ ZONE + INTERFACE + BROADCAST + OPTIONS
loceth1192.168.1.255,192.168.12.255
+
-
- -

/etc/shorewall/hosts - 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: The only times that you need -entries in /etc/shorewall/hosts are:
-

- +
+ +

/etc/shorewall/hosts + 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: The only times that you need entries +in /etc/shorewall/hosts are:
+

+
    -
  1. You have more than one zone connecting through - a single interface; or
    2. -
  2. You have a zone that has multiple subnetworks - that connect through a single interface and you want the Shorewall - box to route traffic between those subnetworks.
    -
    3. - +
  3. You have more than one zone connecting +through a single interface; or
    4. +
  4. You have a zone that has multiple subnetworks + that connect through a single interface and you want the Shorewall + box to route traffic between those subnetworks.
    +
    5. +
- IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN - DON'T TOUCH THIS FILE!! + IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS +THEN DON'T TOUCH THIS FILE!!

Columns in this file are:

- + - -
- + +
+
    -
  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.
-

- -

Warning: If you are running a -version of Shorewall earlier than 1.4.6, only a single host/subnet address -may be specified in an entry in /etc/shorewall/hosts.
-

-
- -
    -
  • OPTIONS - - A comma-separated list of option
    • - -
- -
- -

routeback (Added in version 1.4.2) - This option causes Shorewall - to set up handling for routing packets sent by this host group back - back to the same group.
-
- 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: 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 1:

- -

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/
    • - -
- -

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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- ZONE - INTERFACE - BROADCAST - OPTIONS
neteth0detectdhcp,norfc1918
-eth1192.168.1.127,192.168.1.255
-
-
-
- -

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/25
-
-
- -

Example 2:

- -

Your local interface is eth1 and you have two groups of local hosts that - you want to consider as one zone and you want Shorewall to route - between them:

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

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

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- ZONE - INTERFACE - BROADCAST - OPTIONS
neteth0detectdhcp,norfc1918
loc
- 		eth1192.168.1.127,192.168.1.255
-
-
-
- -

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

- -
- - - - - - - - - - - - - - - - - - - - - - - - -
- ZONE - HOST(S) - OPTIONS
loceth1:192.168.1.0/25
-
loceth1:192.168.1.128/25
-
-
- If you are running Shorewall -1.4.6 or later, your hosts file may look like:
- -
- - - - - - - - - - - - - - - +

Warning: If you are running a + version of Shorewall earlier than 1.4.6, only a single host/subnet address + may be specified in an entry in /etc/shorewall/hosts.
+

+ - - -
- ZONE - HOST(S) - OPTIONS
loceth1:192.168.1.0/25,192.168.1.128/25
-
-
-
- -

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.
    • -
  • NONE - (Added in version 1.4.1) - Shorewall - should not set up any infrastructure for handling traffic from -the SOURCE zone to the DEST zone. When this policy is specified, -the LOG LEVEL and BURST:LIMIT columns -must be left blank.
    -
    • - +
  • 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.

- + +
+ +

routeback (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets sent by this host group + back back to the same group.
+
+ 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: 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 1:

+ +

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/
    • + +
+ +

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

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ ZONE + INTERFACE + BROADCAST + OPTIONS
neteth0detectdhcp,norfc1918
-eth1192.168.1.127,192.168.1.255
+
+
+
+ +

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/25
+
+
+ +

Example 2:

+ +

Your local interface is eth1 and you have two groups of local hosts that + you want to consider as one zone and you want Shorewall to route + between them:

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

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

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ ZONE + INTERFACE + BROADCAST + OPTIONS
neteth0detectdhcp,norfc1918
loc
+ 		eth1192.168.1.127,192.168.1.255
+
+
+
+ +

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

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ ZONE + HOST(S) + OPTIONS
loceth1:192.168.1.0/25
+
loceth1:192.168.1.128/25
+
+
+ If you are running Shorewall + 1.4.6 or later, your hosts file may look like:
+ +
+ + + + + + + + + + + + + + + + + + +
+ ZONE + HOST(S) + OPTIONS
loceth1:192.168.1.0/25,192.168.1.128/25
+
+
+
+ +

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.
    • +
  • NONE - (Added in version 1.4.1) - Shorewall + should not set up any infrastructure for handling traffic from +the SOURCE zone to the DEST zone. When this policy is specified, the + LOG LEVEL and BURST:LIMIT columns + must be left blank.
    +
    • + +
+ +

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. SOURCE - The name of a client + zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall + zone or "all").
    3. -
  3. 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 +
  4. 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.
    5. -
  5. POLICY - The default policy - for connection requests from the SOURCE zone to the DESTINATION - zone.
    6. +
  6. POLICY - The default policy + for connection requests from the SOURCE zone to the DESTINATION + zone.
    7. -
  7. 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.
    8. +
  8. 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.
    9. -
  9. 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.
    10. - +
  10. 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.
    11. +
- -

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

- + +

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

+

The policy file installed by default is as follows:

- +
- - + face="Century Gothic, Arial, Helvetica"> + + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + +
SOURCEDESTPOLICYLOG - LEVELLIMIT:BURST
locallACCEPT
-
-
netallDROPinfo
-
loclocREJECTinfo
-
SOURCEDEST + POLICY + LOG LEVELLIMIT:BURST
locnetACCEPT
+
+
netallDROPinfo
+
allallREJECTinfo
+
-
- +
+ +

This table may be interpreted as follows:

+ + + +

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.

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

IntraZone Traffic

- Shorewall allows a zone to be associated with more -than one interface or with multiple networks that interface through -a single interface. Beginning with Shorewall 1.4.1, Shorewall will -ACCEPT all traffic from a zone to itself provided that there is no -explicit policy governing traffic from that zone to itself (an explicit -policy does not specify "all" in either the SOURCE or DEST column) and -that there are no rules concerning connections from that zone to itself. -If there is an explicit policy or if there are one or more rules, then -traffic within the zone is handled just like traffic between zones is.
- -

Any time that you have multiple interfaces associated with a single zone, - you should ask yourself if you really want traffic routed between - those interfaces. Cases where you might not want that behavior are:
-

- + Shorewall allows a zone to be associated with more + than one interface or with multiple networks that interface through + a single interface. Beginning with Shorewall 1.4.1, Shorewall will + ACCEPT all traffic from a zone to itself provided that there is +no explicit policy governing traffic from that zone to itself (an +explicit policy does not specify "all" in either the SOURCE or DEST +column) and that there are no rules concerning connections from that + zone to itself. If there is an explicit policy or if there are one or +more rules, then traffic within the zone is handled just like traffic + between zones is.
+ +

Any time that you have multiple interfaces associated with a single zone, + you should ask yourself if you really want traffic routed between + those interfaces. Cases where you might not want that behavior are:
+

+
    -
  1. Multiple 'net' interfaces to different ISPs. -You don't want to route traffic from one ISP to the other through -your firewall.
    2. -
  2. Multiple VPN clients. You don't necessarily want - them to all be able to communicate between themselves using your -gateway/router.
    -
    3. - +
  3. Multiple 'net' interfaces to different ISPs. + You don't want to route traffic from one ISP to the other through + your firewall.
    4. +
  4. Multiple VPN clients. You don't necessarily + want them to all be able to communicate between themselves using + your gateway/router.
    +
    5. +
- -

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:

- + +

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
+ ZONE + DISPLAY + COMMENTS
samSamSam's + system at home
netInternetThe + Internet
locLocLocal + Network
-
- +
+

/etc/shorewall/interfaces:

- -
- + +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - - + + + +
- ZONE - INTERFACE - BROADCAST - OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
-
+ ZONE + INTERFACE + BROADCAST + OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
+
-
- +
+

/etc/shorewall/hosts:

- +
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + - - - + + + +
- ZONE - HOST(S) - OPTIONS
neteth0:0.0.0.0/0
-
sameth0:206.191.149.197
-
+ 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 + + +

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:

- +
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + +
- SOURCE - DEST - POLICY - LOG LEVEL
locnetACCEPT
-
samallCONTINUE
-
netallDROPinfo
allallREJECTinfo
+ 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).

- + + +

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:

- +
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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

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

The first rule allows Sam SSH access to the firewall. The second - rule says that any clients from the net zone - with the exception of those in the -'sam' zone should have their -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.

- + + +

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 net zone + with the exception of those in the + 'sam' zone should have their + 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.

+

/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. -
-

- -

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 + +

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. +
+

+ +

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.
-

- +

+

Entries in the file have the following columns:

- + - +

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

- + name="PortForward"> Example 1. You wish to forward all + ssh connection requests from the internet to + local system 192.168.1.3.

+
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - - + + + +
ACTIONSOURCEDEST - PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
DNATnetloc:192.168.1.3tcpssh
-
-
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.

- + + +

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.

+
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + +
ACTIONSOURCEDEST - PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
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.

- + + +

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.

+
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + +
ACTIONSOURCEDEST - PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTnetdmz:155.186.235.222tcpwww-
-
ACCEPTlocdmz:155.186.235.222tcpwww
-
-
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 + + +

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 + 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 + 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 - .

- + .

+
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + - - - + + + +
ACTIONSOURCEDEST - PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
DNATnetdmz:192.168.2.2tcpftp
-
-
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-
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
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:

- -
- +
+ +

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 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.

- -

Example 5. You wish to allow unlimited - DMZ access to the host with MAC address - 02:00:08:E3:FA:55.

- -
+
+

If you are running pure-ftpd, you would include "-p 65500:65534" on + 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.

+ +

Example 5. You wish to allow unlimited + DMZ access to the host with MAC address + 02:00:08:E3:FA:55.

+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - - + + + +
ACTIONSOURCEDEST - PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-
-
-
ACTIONSOURCEDEST + PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
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
-
-
-
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. Your firewall's - external interface has several IP addresses but you only want to accept - SSH connections on address 206.124.146.176.
- -
- +
+ 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. Your firewall's + external interface has several IP addresses but you only want to accept + SSH connections on address 206.124.146.176.
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - - + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		net
- 		fw:206.124.146.176
- 		tcp
- 		22
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		net
+ 		fw:206.124.146.176
+ 		tcp
+ 		22
+
+
+
-
- Example 8 (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 +
+ Example 8 (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
-
-
-
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.
-
- Example 9 (Shorewall version 1.4.6 or later). You have 9 http - servers behind a Shorewall firewall and you want connection requests to - be distributed among your servers. The servers are 192.168.1.101-192.168.1.109.
-
- -
- +
+ Using "DNAT-" rather than "DNAT" + avoids two extra copies of the third rule from being generated.
+
+ Example 9 (Shorewall version 1.4.6 or later). You have 9 +http servers behind a Shorewall firewall and you want connection requests +to be distributed among your servers. The servers are 192.168.1.101-192.168.1.109.
+
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - - + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
DNAT
- 		net
- 		loc:192.168.1.101-192.168.1.109
- 		tcp
- 		80
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT
+ 		net
+ 		loc:192.168.1.101-192.168.1.109
+ 		tcp
+ 		80
+
+
+
-
- -

Look here for information on other services. -

- +
+ +

Look here for information on other services. +

+

/etc/shorewall/common

- -

Shorewall allows definition of rules that apply between - all zones. By default, these rules - are defined in the file - /etc/shorewall/common.def - but may be modified to - suit individual - requirements. Rather than modify /etc/shorewall/common.def, - you should copy that - file to + +

Shorewall allows definition of rules that apply between + all zones. By default, these rules + are defined in the file + /etc/shorewall/common.def + 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.

- -

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.

- + +

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.

+

/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 - .

- + +

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:

- + - -

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: -

- -
- + +

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: +

+ +
+ - - - - - - - - - - - + + + + + + + + + + + - + + + + +
- INTERFACE - SUBNETADDRESS
eth0192.168.9.0/24
-
+ 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 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.

- -
- +
+ +

Example 4: Same as example 3 except that + you wish to exclude + 192.168.10.44 and 192.168.10.45 +from the SNAT rule.

+ +
+ - - - - - - - - - - - + + + + + + + + + + + - + + - +
- INTERFACE - SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24
-
+ INTERFACE + SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
-
- -

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.

- -
- +
+ 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
eth0192.168.10.0/24206.124.146.176
+ INTERFACE + SUBNETADDRESS
eth0:0192.168.12.0/24206.124.146.177
-
- -

Example 4: Same as example 3 except that - you wish to exclude - 192.168.10.44 and 192.168.10.45 from - the SNAT rule.

- -
- - - - - - - - - - - - - - - - + + +
- 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.
- -
- - - - - - - - - - - - - - - - - -
- 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, - I suggest that you +

+ +

+ /etc/shorewall/proxyarp

+ +

If you want to use proxy ARP on an entire sub-network, + I suggest that you look at - http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - If you decide to use the - technique described in that + 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 + (/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 + 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 enabling -Proxy ARP on a small set -of systems since -you need one -entry in this file for each - system using proxy ARP. Columns - are:

- + href="ProxyARP.htm">Proxy ARP. The file is + typically used for +enabling Proxy ARP on a +small set of systems +since you need +one entry in this file for each + system using proxy ARP. Columns + are:

+ - -

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 + +

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.

- -

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 -take a long while to time out. I personally have had to contact my ISP -and ask them to delete a stale entry in order to restore a system to working -order after changing my proxy ARP settings.

- -

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

- + +

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 take a long +while to time out. I personally have had to contact my ISP and ask them +to delete a stale entry in order to restore a system to working order after +changing my proxy ARP settings.

+ +

Example: You have public IP addresses 155.182.235.0/28. You + configure your 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:

- -
- + +

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:

+ +
+ - - - - - - - - - - - - - + + + + + + + + + + + + + - - - + + + +
- 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.

- -

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. +

+ +

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.

+ +

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.

- -

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

- + +

You might be able to work around this problem using the following + (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 - .

- + +

+ /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 + .

+

IMPORTANT: If all you want to do - is forward ports - to servers behind your firewall, - you do NOT want to use - 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.

- + color="#ff0000"> IMPORTANT: If all you want to do + is forward ports + to servers behind your firewall, + you do NOT want to use + 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.

+

Columns in an entry are:

- + - -

Look here for additional information and an example. -

- -

- /etc/shorewall/tunnels

- -

The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, - OpenVPN, PPTP - and 6to4.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 + +

Look here for additional information and an example. +

+ +

+ /etc/shorewall/tunnels

+ +

The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, + OpenVPN, PPTP + and 6to4.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.

- -

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

- + +

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

+

/etc/shorewall/shorewall.conf

- +

This file is used to set the following firewall parameters:

- +
    -
  • SHOREWALL_SHELL - - Added at version 1.4.6
    - This parameter is used to specify the shell program to be used to interpret - the firewall script (/usr/share/shorewall/firewall). If not specified or - specified as a null value, /bin/sh is assumed.
    -
    • -
  • LOGFORMAT - Added at version 1.4.4.
    - The value of this variable generate the --log-prefix setting -for Shorewall logging rules. It contains a 'printf' formatting template -which accepts three arguments (the chain name, logging rule number (optional) - and the disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - If the LOGFORMAT value contains the substring '%d' then the -logging rule number is calculated and formatted in that position; if -that substring is not included then the rule number is not included. -If not supplied or supplied as empty (LOGFORMAT="") then "Shorewall:%s:%s:" - is assumed.
    -
    - CAUTION: /sbin/shorewall uses the leading part -of the LOGFORMAT string (up to but not including the first '%') to -find log messages in the 'show log', 'status' and 'hits' commands. This -part should not be omitted (the LOGFORMAT should not begin with "%") -and the leading part should be sufficiently unique for /sbin/shorewall -to identify Shorewall messages.
    -
    • -
  • 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 is assumed.
    • -
  • MACLIST_LOG_LEVEL - - Added in Version 1.3.10
    +
  • ADMINISABSENTMINDED + - Added at version 1.4.7
    +The value of this variable affects Shorewall's stopped state. When ADMINISABSENTMINDES=No, +only traffic to/from those addresses listed in /etc/shorewall/routestopped +is accepted when Shorewall is stopped.When ADMINISABSENTMINDED=Yes, in addition +to traffic to/from addresses in /etc/shorewall/routestopped,  connections +that were active when Shorewall stopped continue to work and all new connections +from the firewall system itself are allowed. If this variable is not set +or is given the empty value then ADMINISABSENTMINDED=No is assumed.
    +
    • +
  • SHOREWALL_SHELL - Added at version 1.4.6
    + This parameter is used to specify the shell program to be used to +interpret the firewall script (/usr/share/shorewall/firewall). If not +specified or specified as a null value, /bin/sh is assumed.
    +
    • +
  • LOGFORMAT - Added at version 1.4.4.
    + The value of this variable generate the --log-prefix setting + for Shorewall logging rules. It contains a 'printf' formatting template + which accepts three arguments (the chain name, logging rule number +(optional) and the disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it +as:
    +  
    +        LOGFORMAT="fp=%s:%d a=%s "
    +  
    + If the LOGFORMAT value contains the substring '%d' then the + logging rule number is calculated and formatted in that position; if + that substring is not included then the rule number is not included. + If not supplied or supplied as empty (LOGFORMAT="") then "Shorewall:%s:%s:" + is assumed.
    +
    + CAUTION: /sbin/shorewall uses the leading part + of the LOGFORMAT string (up to but not including the first '%') +to find log messages in the 'show log', 'status' and 'hits' commands. +This part should not be omitted (the LOGFORMAT should not begin with +"%") and the leading part should be sufficiently unique for /sbin/shorewall + to identify Shorewall messages.
    +
    • +
  • 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 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="").
    + href="shorewall_logging.html">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="").
    • -
  • 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.
    +
  • 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="").
    • -
  • LOGNEWNOTSYN - - Added in Version 1.3.6
    - Beginning with -version 1.3.6, Shorewall drops non-SYN TCP packets +
  • 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.
    +
    • +
  • 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 + the syslog level at which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
    -
    - Note: Packets - logged under this option are usually the result +
    + 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 first IP address of the interface to the source zone and -will include this address in DNAT rules as the original destination - IP address. If set to "No" or "no", Shorewall will not detect - this address and any destination IP address will match the - DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" - is assumed.
    -
    • -
  • MULTIPORT - - (Removed in version 1.4.6 -- the value of this parameter is now automatically - detected by Shorewall)
    - 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 +
  • DETECT_DNAT_ADDRS - Added in Version + 1.3.4
    + If set to "Yes" or "yes", Shorewall will +detect the first IP address of the interface to the source +zone and will include this address in DNAT rules as the original +destination IP address. If set to "No" or "no", Shorewall will +not detect this address and any destination IP address will +match the DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" + is assumed.
    +
    • +
  • MULTIPORT + - (Removed in version 1.4.6 -- the value of this parameter is now automatically + detected by Shorewall)
    + 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. + + +

      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
      -       This - parameter - specifies the - name of the - firewall zone. - If not set or - if set to an empty string, - the value "fw" +
      • +
    • 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. -
      • -
    • 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 +
    • 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.
      • +
    • 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 - (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically - detected by Shorewall)
      - 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 - (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically - detected by Shorewall)
      - 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 +
    • NAT_ENABLED + (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically + detected by Shorewall)
      + 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 + (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically + detected by Shorewall)
      + 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). +
      • +
    • 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. RESTRICTION: Shorewall versions before -1.4.6 can only add addresses to the first subnetwork configured on -an interface.
      -
      - 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. RESTRICTION: - Shorewall versions before 1.4.6 can only add addresses to -the first subnetwork configured on an interface.
      -
      - 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 - options. If - LOGUNCLEAN is empty -(LOGUNCLEAN=) then packets selected - by 'dropclean' are - dropped - silently ('logunclean' - packets are - logged - under the 'info' log level). Otherwise, - these packets are logged at - the specified - level (Example: - LOGUNCLEAN=debug).
      • -
    • 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 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 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 - + 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. RESTRICTION: Shorewall + versions before 1.4.6 can only add addresses to the first subnetwork + configured on an interface.
      +
      + 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. + RESTRICTION: Shorewall versions before 1.4.6 can only +add addresses to the first subnetwork configured on an interface.
      +
      + 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 + options. If + LOGUNCLEAN is empty + (LOGUNCLEAN=) then packets + selected by 'dropclean' are + dropped + silently +('logunclean' + packets are + logged under the 'info' log level). + Otherwise, these packets + are logged at the specified + level + (Example: LOGUNCLEAN=debug).
      • +
    • 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 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 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".
      • - +
    • 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).

    - -

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

    - + +

    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).

    + +

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

    +

    The loadmodule function is called as follows:

    - -
    - -

    loadmodule <modulename> [ - <module parameters> ]

    -
    - + +
    + +

    loadmodule <modulename> [ + <module parameters> ]

    +
    +

    where

    - -
    - + +
    +

    <modulename>

    - -
    - -

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

    -
    + +
    + +

    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; +

    +
    + +

    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:

    - -
    - -

    insmod moduledirectory/<modulename>.o <module + +

    + +

    insmod moduledirectory/<modulename>.o <module + 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 compressed + modules and execute the following command:

    + +
    + +

    insmod moduledirectory/<modulename>.o.gz <module 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 compressed - modules and execute the following command:

    - -
    - -

    insmod moduledirectory/<modulename>.o.gz <module - 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 + +

    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 +
    • 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 + href="configuration_file_basics.htm#MAC">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 + 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 +
    • 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:
      • - + 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)

    -
    -
    - -

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

    - -
    - + 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.

    + +
    + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + +
    SOURCEDESTPROTOCOLSOURCE
    - PORT(S)    		DEST - PORT(S)TOS
    allalltcp-ssh16
    allalltcpssh-16
    allalltcp-ftp16
    allalltcpftp-16
    allalltcp-ftp-data8
    allalltcpftp-data-8
    SOURCEDESTPROTOCOLSOURCE
    + PORT(S)    		DEST + PORT(S)TOS
    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.

    - +
    + +

    WARNING: Users have reported that odd routing problems result from + 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:

    - + +

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

    + 
          130.252.100.69
          206.124.146.0/24
    - -

    Packets from - hosts - listed - in the - blacklist file - will be - disposed of - according - to - the value assigned - to - the BLACKLIST_DISPOSITION - and BLACKLIST_LOGLEVEL variables in - /etc/shorewall/shorewall.conf. - Only - packets 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.
    -

    - + +

    Packets from + hosts + listed + in the + blacklist file + will be + disposed of + according + to + the value assigned + to + the BLACKLIST_DISPOSITION + and BLACKLIST_LOGLEVEL variables in + /etc/shorewall/shorewall.conf. + Only + packets 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 +
    • 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").
      -
      • - +
    • 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.

    - -

    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). -

    - + +

    Shorewall also has a dynamic blacklist + 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:

    - + +

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

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

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

    - -

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

    - -
      -
    • 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.
      • - -
    - -

    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.

    - -
    +
+ + + + +

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

+ +

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

+ +
    +
  • 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.
    • + +
+ +

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.

+ +
+ - - - - - - - - - - - - - + + + + + + + + + + + + + - - - + + + +
INTERFACEHOST(S)
eth2192.168.1.0/24
eth1-
INTERFACEHOST(S)
eth2192.168.1.0/24
eth1-
-
- + +

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

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

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

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

Updated 6/28/2003 - Tom Eastep -

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

Updated 7/31/2003 - Tom Eastep +

+

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

-
-
-
-
+

diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 6413295ba..613b19fc5 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -1,1395 +1,1552 @@ - + + - + + - + + - + + Shorewall FAQ - + - + - - - + + + + - - - + + + + + +
- +
+ +

Shorewall FAQs

-
- +

Looking for Step by Step Configuration Instructions? Check out the QuickStart Guides.
-

- -

PORT FORWARDING
-

- -

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.

+ +

PORT FORWARDING
+

+ +

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.
-

- + but it doesn't work.
+

+

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

- + port forwarding

+

1c. From the internet, I want to connect to port 1022 on my firewall and have the firewall forward the connection to port 22 on local system 192.168.1.3. How do I do that?
-

- +

+

DNS and PORT FORWARDING/NAT
-

- + +

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.

- + 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.

- + 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.

+

NETMEETING/MSN
-

- + +

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

- + or MSN Instant Messenger with Shorewall. + What do I do?

+

OPEN PORTS
-

- + +

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

- + 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!!!!
-

- 4b. I have a port that I can't close no -matter how I change my rules.
-
- 4c. How to I use Shorewall with PortSentry?
- + of my firewall and it showed 100s of ports + as open!!!!
+

+ 4b. I have a port that I can't close + no matter how I change my rules.
+
+ 4c. How to I use Shorewall with PortSentry?
+

CONNECTION PROBLEMS

- +

5. I've installed Shorewall and now - I can't ping through the firewall
-
- 15. My local systems can't see - out to the net

- + I can't ping through the firewall
+
+ 15. My local systems can't see + out to the net
+

+ 29. FTP Doesn't Work
+

LOGGING
-

- + +

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

- + written and how do I change the destination?

+

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

- + 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?
-

- + 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?
-

- + 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.
-

- + in Shorewall log messages so long? I thought MAC addresses + were only 6 bytes in length.
+

+

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

+ all over my console making it unusable!
+

- 17. How do I find out why this -traffic is getting logged?
-
- 21. I see these strange log - entries occasionally; what are they?
- + 17. How do I find out why + this traffic is getting logged?
+
+ 21. I see these strange + log entries occasionally; what are they?
+

STARTING AND STOPPING
-

- + +

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?
-

- + on RedHat I get messages about insmod + failing -- what's wrong?
+

+

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

- + on RedHat I get a message referring me to FAQ #8
+

+

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

- 22. properly at startup?

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

ABOUT SHOREWALL
-

- + +

10. What distributions does - it work with?

- + it work with?

+

11. What features does it support?

- +

12. Is there a GUI?

- +

13. Why do you call it "Shorewall"?

- 23. Why -do you use such ugly fonts on your web site?
-
- 25. How to I tell which version -of Shorewall I am running?
- + 23. Why do you use such ugly fonts on + your web site?
+
+ 25. How to I tell which version + of Shorewall I am running?
+

RFC 1918
-

- + +

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.

- + 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.

- + 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.

+

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
-

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

MISCELLANEOUS
-

- 19. I have added entries - to /etc/shorewall/tcrules but they don't seem - to do anything. Why?
-
- 20. + 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?
-
- 24. How can -I allow conections to let's say the ssh port only - from specific IP Addresses on the internet?
-
- 26. When I try to use any -of the SYN options in nmap on or behind the firewall, I get "operation - not permitted". How can I use nmap with Shorewall?"
-
- 27. I am compiling a new kernel for my -firewall. What should I look out for?
-
- 28. How do I use Shorewall as a Bridging Firewall?
- -
+ to change Shorewall to allow access to my server from the + internet?
+
+ 24. How +can I allow conections to let's say the ssh port +only from specific IP Addresses on the internet?
+
+ 26. When I try to use +any of the SYN options in nmap on or behind the firewall, I get +"operation not permitted". How can I use nmap with Shorewall?"
+
+ 27. I am compiling a new kernel for + my firewall. What should I look out for?
+
+ 28. How do I use Shorewall as a Bridging + Firewall?
+ +

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.

- + 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:

- -
+ 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 - #> -
- 		-
-
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:

- -
+ the rule is:

+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
DNATnetloc:192.168.1.5udp7777 -
- 		-
-
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:
- -
+ 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>
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.
- +
+ 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

- + but it doesn't work +

Answer: That is usually the result of one of three - things:

- + 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).
    • -
  • Your ISP is blocking that particular port inbound.
    -
    • - +
  • 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).
    • +
  • Your ISP is blocking that particular port inbound.
    +
    • +
- +

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

- Answer: To -further diagnose this problem:
- + 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:
    • - +
  • 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.
      +
      • + +
    - +
- +

1c. From the internet, I want - to connect to port 1022 on my firewall and have the firewall forward - the connection to port 22 on local system 192.168.1.3. How do I do -that?

- -
-
+ to connect to port 1022 on my firewall and have the firewall forward + the connection to port 22 on local system 192.168.1.3. How do I do + that? + +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
DNATnet
- 		loc:192.168.1.3:22tcp1022
-
-
-
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATnet
+ 		loc:192.168.1.3:22tcp1022
+
+
+
-
-
- +
+
+

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.

- + (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.

- + - +

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.
-

- + 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.
+

+

If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for those releases.
-

- +

+

If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please - upgrade to Shorewall 1.4.2 or later.
-

- + upgrade to Shorewall 1.4.2 or later.
+

+

Otherwise:
-

- +

+
    - +
- +
    - +
- +
    -
  • In /etc/shorewall/interfaces:
    • - +
  • In /etc/shorewall/interfaces:
    • +
- -
+ +
- - - - - - - - - - - - - + + + + + + + + + + + + + - - + +
ZONE
- 		INTERFACE
- 		BROADCAST
- 		OPTIONS
-
loc
- 		eth1
- 		detect
- 		routeback
-
ZONE
+ 		INTERFACE
+ 		BROADCAST
+ 		OPTIONS
+
loc
+ 		eth1
+ 		detect
+ 		routeback
+
-
- +
+
    - +
- +
    -
  • In /etc/shorewall/rules:
    • - +
  • In /etc/shorewall/rules:
    • +
- -
+ +
- - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
DNAT
- 		locweb:192.168.1.5
- 		tcpwww -
- 		130.151.100.69:192.168.1.254
-
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
DNAT
+ 		locweb:192.168.1.5
+ 		tcpwww -
+ 		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/init:

-
- -
+ 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.
DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. DEST.
DNATlocweb: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.

-
- + 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.

- + 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.

- + 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.

- + 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:

- +

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

- + 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.255
-
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?

- + Messenger with Shorewall. What do I do? +

Answer: There is an H.323 connection - tracking/NAT module that may help with + tracking/NAT module that helps 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?

- + 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 + 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. -

- + 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.

- + 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!!!!

- + 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.
-

- + 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.
+

+

4b. I have a port that I can't close no matter how - I change my rules. 

- I had a rule that allowed telnet from my local network to my firewall; - I removed that rule and restarted Shorewall but my telnet session still - works!!!
-
- Answer:  Rules only govern the establishment of new connections. - Once a connection is established through the firewall it will be usable - until disconnected (tcp) or until it times out (other protocols).  If you - stop telnet and try to establish a new session your firerwall will block - that attempt.
- + I change my rules.  + I had a rule that allowed telnet from my local network to my + firewall; I removed that rule and restarted Shorewall but my telnet + session still works!!!
+
+ Answer:  Rules only govern the establishment of new +connections. Once a connection is established through the firewall +it will be usable until disconnected (tcp) or until it times out (other +protocols).  If you stop telnet and try to establish a new session your +firerwall will block that attempt.
+

4c. How to I use Shorewall with -PortSentry?

- + Here's -a writeup on a nice integration of Shorewall and PortSentry.
- + a writeup on a nice integration of Shorewall and PortSentry.
+

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

- + can't ping through the firewall +

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

- + for "ping",

+

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

- -
+
+ b) +Be sure that the first command in the file is ". /etc/shorewall/common.def"
+ c) +Add the following to /etc/shorewall/common

+ +

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

-
- For a complete description of -Shorewall 'ping' management, see this -page. + -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?

- + 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").

- + 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:

- -
+ 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.
-
- + to a separate file.
+
+

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

- + 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. + http://www.logwatch.org
+ http://gege.org/iptables
+ http://home.regit.org/ulogd-php.html
+

+
+ 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:
- + 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?

- + 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:
- + 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 (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:
- -
+ 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 + 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.
- + 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:
- + 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?

- + 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.

- + 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?

- + I get messages about insmod failing -- what's wrong? +

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

- + 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: -

- -
+

+ +
     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.
-

- + 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 -
- + 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 at startup?

- + properly at startup? +

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

- -
+ I see the following:

+ +
     Processing /etc/shorewall/params ...
     Processing /etc/shorewall/shorewall.conf ...
     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.

- + 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.

- + 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.

- + 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?

- + 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.1SUBNET RETURN
TARGET
192.168.100.1RETURN
-
-
- -
+
+ + +

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:
-

- -
+ 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:
+

+ +
- - - - - - - - - - - - - + - - + + + + + + + + + + + + + + + + + + + + + + + + + +
SUBNET
- 		TARGET
-
192.168.100.1
- 		RETURN
-
192.168.100.2
- 		RETURN
-
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.

-
- + the IP address of your ISPs DHCP server.

+ +

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

- + 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:

- + 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. +
  2. +

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

    -
    3. -
  3. + the IP address of the local firewall +interface.

    +
    4. +
  4. + +

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

    -
    5. -
  5. + file is wrong or missing.

    +
    6. +
  6. + +

    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.

    -
    7. - + user is running a DNS server on the +firewall and hasn't enabled UDP and TCP port +53 from the firewall to the internet.

    + + +
- +

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

- + all over my console making it unusable! +

Answer: If you are running Shorewall version 1.4.4 - or 1.4.4a then check the errata. Otherwise, see - the 'dmesg' man page ("man dmesg"). You must 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.
-

- + or 1.4.4a then check the errata. Otherwise, +see the 'dmesg' man page ("man dmesg"). You must 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:
- + logged? + Answer: + Logging occurs out of a number of chains (as indicated + in the log message) in Shorewall:
+
    -
  1. man1918 - or logdrop - The destination address is - listed in /etc/shorewall/rfc1918 with a logdrop target - -- see /etc/shorewall/rfc1918.
    2. -
  2. rfc1918 - or logdrop - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see man1918 + or logdrop - The destination address +is listed in /etc/shorewall/rfc1918 with a logdrop + target -- see /etc/shorewall/rfc1918.
    3. +
  3. rfc1918 + or logdrop - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
    4. -
  4. 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.
    -
    5. -
  5. <zone1>2<zone2> - - Either you have aall2<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.
    +
    6. +
  6. <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.
    7. -
  7. <interface>_mac - - The packet is being logged under the maclist - interface option.
    -
    8. -
  8. logpkt - - The packet is being logged under the logunclean - interface option.
    9. -
  9. badpkt - - The packet is being logged under the - dropunclean rule + that includes a log level.
    10. +
  10. <interface>_mac + - The packet is being logged under the maclist + interface option.
    +
    11. +
  11. logpkt + - The packet is being logged under the logunclean + interface option.
    12. +
  12. badpkt + - The packet is being logged under the + dropunclean interface option as specified - in the LOGUNCLEAN setting in LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    13. -
  13. blacklst - - The packet is being logged because the source - IP is blacklisted in the +
  14. blacklst + - The packet is being logged because the source + IP is blacklisted in the /etc/shorewall/blacklist file.
    15. -
  15. 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 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.
    16. -
  16. 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.
    17. -
  17. logflags - - The packet is being logged because it failed the checks - implemented by the tcpflags 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.
    18. +
  18. logflags + - The packet is being logged because it failed + the checks implemented by the tcpflags interface option.
    -
    19. - + +
- +

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. + 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.
- + 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 + 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?
-

- -
+ 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.
- +
+ 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.
- + 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.
- + 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.
- + 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:
- + 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
- + I am running?
+ + At the shell prompt, type:
+
+ /sbin/shorewall +version
+

26. When I try to use any of the SYN options - in nmap on or behind the firewall, I get "operation not permitted". How - can I use nmap with Shorewall?"

- Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" - then restart Shorewall.
- + in nmap on or behind the firewall, I get "operation not permitted". +How can I use nmap with Shorewall?" + Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to +"NEWNOTSYN=Yes" then restart Shorewall.
+

27. I'm compiling a new kernel for my firewall. What should I look out for?

- First take a look at the Shorewall kernel configuration - page. You probably also want to be sure that you have selected the -"NAT of local connections (READ HELP)" on the Netfilter Configuration -menu. Otherwise, DNAT rules with your firewall as the source zone won't -work with your new kernel.
- + First take a look at the Shorewall kernel configuration + page. You probably also want to be sure that you have selected the + "NAT of local connections (READ HELP)" on the Netfilter Configuration + menu. Otherwise, DNAT rules with your firewall as the source zone won't + work with your new kernel.
+

28. How do I use Shorewall as a Bridging Firewall?
-

- Basically, you don't. While there are kernel patches that allow you to - route bridge traffic through Netfilter, the environment is so different -from the Layer 3 firewalling environment that very little of Shorewall works. -In fact, so much of Shorewall doesn't work that my official position is that - "Shorewall doesn't work with Layer 2 Bridging".
-
- Last updated 7/9/2003 - Tom Eastep + + Basically, you don't. While there are kernel patches that allow you + to route bridge traffic through Netfilter, the environment is so different + from the Layer 3 firewalling environment that very little of Shorewall +works. In fact, so much of Shorewall doesn't work that my official position +is that "Shorewall doesn't work with Layer 2 Bridging".
+ +

29. FTP Doesn't Work
+

+ See the Shorewall and FTP page.
+
+ Last updated 7/30/2003 - Tom Eastep

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

-
-
-
-
-
-
-
+

diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index 24995aeb4..584928ceb 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -5,7 +5,7 @@ - + Shorewall News @@ -16,28 +16,28 @@ - + - + - + - + - + - + - + - + - +
+ @@ -45,1007 +45,1218 @@ +

Shorewall News Archive

-
- -

7/22/2003 - Shorewall-1.4.6a
-

-Problems Corrected:
- + +

8/5/2003 - Shorewall-1.4.6b
+

+ Problems Corrected since version 1.4.6:
+
    -
  1. Previously, if TC_ENABLED is set to yes in shorewall.conf then Shorewall -would fail to start with the error "ERROR:  Traffic Control requires Mangle"; +
  2. Previously, if TC_ENABLED is set to yes in shorewall.conf then Shorewall +would fail to start with the error "ERROR:  Traffic Control requires Mangle"; that problem has been corrected.
    3. +
  3. Corrected handling of MAC addresses in the SOURCE column of the tcrules +file. Previously, these addresses resulted in an invalid iptables command.
    4. +
  4. The "shorewall stop" command is now disabled when /etc/shorewall/startup_disabled +exists. This prevents people from shooting themselves in the foot prior to +having configured Shorewall.
    5. +
  5. A change introduced in version 1.4.6 caused error messages during "shorewall +[re]start" when ADD_IP_ALIASES=Yes and ip addresses were being added to a +PPP interface; the addresses were successfully added in spite of the messages.
    +   
    + The firewall script has been modified to eliminate the error messages.
    +
-

7/20/2003 - Shorewall-1.4.6
-

- - -
- -

Problems Corrected:
-

- - +

7/31/2003 - Snapshot 1.4.6_20030731

+ +
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+ +

Problems Corrected since version 1.4.6:
+

+
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered start - errors when started using the "service" mechanism has been worked around.
    -
    -
    2. -
  2. Where a list of IP addresses appears in the DEST column of a DNAT[-] - rule, Shorewall incorrectly created multiple DNAT rules in the nat table -(one for each element in the list). Shorewall now correctly creates a -single DNAT rule with multiple "--to-destination" clauses.
    -
    -
    3. -
  3. Corrected a problem in Beta 1 where DNS names containing a "-" - were mis-handled when they appeared in the DEST column of a rule.
    -
    -
    4. -
  4. A number of problems with rule parsing have been corrected. Corrections -involve the handling of "z1!z2" in the SOURCE column as well as lists in -the ORIGINAL DESTINATION column.
    -
    -
    5. -
  5. The message "Adding rules for DHCP" is now suppressed if there are -no DHCP rules to add.
    -
    6. - -
- - -

Migration Issues:
-

- - -
    -
  1. In earlier versions, an undocumented feature allowed entries in -the host file as follows:
    -
    -     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    - This capability was never documented and has been removed in 1.4.6 - to allow entries of the following format:
    -
    -     z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    2. -
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been - removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).
    -
    3. - -
- - -

New Features:
-

- - -
    -
  1. A 'newnotsyn' interface option has been added. This option may - be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No - for packets arriving on the associated interface.
    -
    -
    2. -
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled -for address ranges.
    -
    -
    3. -
  3. Shorewall can now add IP addresses to subnets other than the first - one on an interface.
    -
    -
    4. -
  4. DNAT[-] rules may now be used to load balance (round-robin) over -a set of servers. Servers may be specified in a range of addresses given -as <first address>-<last address>.
    -
    - Example:
    -
    -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    5. -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether -these capabilities are present in the current kernel. The output of the - start, restart and check commands have been enhanced to report the outcome:
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    - Verifying Configuration...
    -
    -
    6. -
  6. Support for the Connection Tracking Match Extension has been added. - This extension is available in recent kernel/iptables releases and allows - for rules which match against elements in netfilter's connection tracking - table. Shorewall automatically detects the availability of this extension - and reports its availability in the output of the start, restart and check - commands.
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    -    Connection Tracking Match: Available
    - Verifying Configuration...
    -
    - If this extension is available, the ruleset generated by Shorewall - is changed in the following ways:
    7. - -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create chains - in the mangle table but will rather do all 'norfc1918' filtering in the -filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; - one in the nat table and one in the filter table. If the Connection Tracking - Match Extension is available, the rule in the filter table is extended -to check that the original destination address was the same as specified - (or defaulted to) in the DNAT rule.
      -
      -
      • - -
    -
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    8. -
  8. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -       ipcalc [ <address> <netmask> | <address>/<vlsm> - ]
    -
    - Examples:
    -
    -       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -          CIDR=192.168.1.0/24
    -          NETMASK=255.255.255.0
    -          NETWORK=192.168.1.0
    -          BROADCAST=192.168.1.255
    -       [root@wookie root]#
    -
    -       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -          CIDR=192.168.1.0/24
    -          NETMASK=255.255.255.0
    -          NETWORK=192.168.1.0
    -          BROADCAST=192.168.1.255
    -       [root@wookie root]#
    -
    - Warning:
    -
    - If your shell only supports 32-bit signed arithmatic (ash or dash), - then the ipcalc command produces incorrect information for IP addresses - 128.0.0.0-1 and for /1 networks. Bash should produce correct information - for all valid IP addresses.
    -
    -
    9. -
  9. An 'iprange' command has been added to /sbin/shorewall. -
    -
    -       iprange <address>-<address>
    -
    - This command decomposes a range of IP addressses into a list of - network and host addresses. The command can be useful if you need to -construct an efficient set of rules that accept connections from a range -of network addresses.
    -
    - Note: If your shell only supports 32-bit signed arithmetic (ash - or dash) then the range may not span 128.0.0.0.
    -
    - Example:
    -
    -       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    -       192.168.1.4/30
    -       192.168.1.8/29
    -       192.168.1.16/28
    -       192.168.1.32/27
    -       192.168.1.64/26
    -       192.168.1.128/25
    -       192.168.2.0/23
    -       192.168.4.0/22
    -       192.168.8.0/22
    -       192.168.12.0/29
    -       192.168.12.8/31
    -       [root@gateway root]#
    -
    -
    10. -
  10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
    -
    - Example:
    -
    -     foo    eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    11. -
  11. The "shorewall check" command now includes the chain name when printing -the applicable policy for each pair of zones.
    -  
    -     Example:
    -  
    -         Policy for dmz to net is REJECT using chain all2all
    -  
    - This means that the policy for connections from the dmz to the internet -is REJECT and the applicable entry in the /etc/shorewall/policy was the all->all - policy.
    -
    -
    12. -
  12. Support for the 2.6 Kernel series has been added.
    -
    13. - -
- -

7/15/2003 - New Mirror in Brazil
-

- Thanks to the folks at securityopensource.org.br, there is now a Shorewall - mirror in Brazil. -

7/15/2003 - Shorewall-1.4.6 RC 1
-

- -

Problems Corrected:
-

- -
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered start - errors when started using the "service" mechanism has been worked around.
    -
    -
    2. -
  2. Where a list of IP addresses appears in the DEST column of a DNAT[-] - rule, Shorewall incorrectly created multiple DNAT rules in the nat table - (one for each element in the list). Shorewall now correctly creates a single - DNAT rule with multiple "--to-destination" clauses.
    -
    -
    3. -
  3. Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a rule.
    -
    -
    4. -
  4. A number of problems with rule parsing have been corrected. Corrections - involve the handling of "z1!z2" in the SOURCE column as well as lists in - the ORIGINAL DESTINATION column.
    +
  5. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was +being tested before it was set.
    6. +
  6. Corrected handling of MAC addresses in the SOURCE column of the tcrules +file. Previously, these addresses resulted in an invalid iptables command.
    7. - +
- -

Migration Issues:
-

- -
    -
  1. In earlier versions, an undocumented feature allowed entries in -the host file as follows:
    -
    -     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    - This capability was never documented and has been removed in 1.4.6 -to allow entries of the following format:
    -
    -     z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    2. -
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been -removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically - detected by Shorewall (see below).
    -
    3. - -
- -

New Features:
-

- -
    -
  1. A 'newnotsyn' interface option has been added. This option may -be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No - for packets arriving on the associated interface.
    -
    -
    2. -
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for -address ranges.
    -
    -
    3. -
  3. Shorewall can now add IP addresses to subnets other than the first - one on an interface.
    -
    -
    4. -
  4. DNAT[-] rules may now be used to load balance (round-robin) over - a set of servers. Servers may be specified in a range of addresses given - as <first address>-<last address>.
    -
    - Example:
    -
    -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    5. -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether these - capabilities are present in the current kernel. The output of the start, - restart and check commands have been enhanced to report the outcome:
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    - Verifying Configuration...
    -
    -
    6. -
  6. Support for the Connection Tracking Match Extension has been added. - This extension is available in recent kernel/iptables releases and allows - for rules which match against elements in netfilter's connection tracking - table. Shorewall automatically detects the availability of this extension - and reports its availability in the output of the start, restart and check - commands.
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    -    Connection Tracking Match: Available
    - Verifying Configuration...
    -
    - If this extension is available, the ruleset generated by Shorewall -is changed in the following ways:
    7. - -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create chains - in the mangle table but will rather do all 'norfc1918' filtering in the - filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; - one in the nat table and one in the filter table. If the Connection Tracking - Match Extension is available, the rule in the filter table is extended to - check that the original destination address was the same as specified (or - defaulted to) in the DNAT rule.
      -
      -
      • - -
    -
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    8. -
  8. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -       ipcalc [ <address> <netmask> | <address>/<vlsm> - ]
    -
    - Examples:
    -
    -       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -          CIDR=192.168.1.0/24
    -          NETMASK=255.255.255.0
    -          NETWORK=192.168.1.0
    -          BROADCAST=192.168.1.255
    -       [root@wookie root]#
    -
    -       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -          CIDR=192.168.1.0/24
    -          NETMASK=255.255.255.0
    -          NETWORK=192.168.1.0
    -          BROADCAST=192.168.1.255
    -       [root@wookie root]#
    -
    - Warning:
    -
    - If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct information -for all valid IP addresses.
    -
    -
    9. -
  9. An 'iprange' command has been added to /sbin/shorewall.
    -
    -       iprange <address>-<address>
    -
    - This command decomposes a range of IP addressses into a list of network - and host addresses. The command can be useful if you need to construct an - efficient set of rules that accept connections from a range of network addresses.
    -
    - Note: If your shell only supports 32-bit signed arithmetic (ash or -dash) then the range may not span 128.0.0.0.
    -
    - Example:
    -
    -       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    -       192.168.1.4/30
    -       192.168.1.8/29
    -       192.168.1.16/28
    -       192.168.1.32/27
    -       192.168.1.64/26
    -       192.168.1.128/25
    -       192.168.2.0/23
    -       192.168.4.0/22
    -       192.168.8.0/22
    -       192.168.12.0/29
    -       192.168.12.8/31
    -       [root@gateway root]#
    -
    -
    10. -
  10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
    -
    - Example:
    -
    -     foo    eth1:192.168.1.0/24,192.168.2.0/24
    11. - -
- -

7/7/2003 - Shorewall-1.4.6 Beta 2

- -

Problems Corrected:
-

- -
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered start - errors when started using the "service" mechanism has been worked around.
    -
    -
    2. -
  2. Where a list of IP addresses appears in the DEST column of a DNAT[-] - rule, Shorewall incorrectly created multiple DNAT rules in the nat table - (one for each element in the list). Shorewall now correctly creates a single - DNAT rule with multiple "--to-destination" clauses.
    -
    -
    3. -
  3. Corrected a problem in Beta 1 where DNS names containing a "-" -were mis-handled when they appeared in the DEST column of a rule.
    -
    4. - -
- +

Migration Issues:

- +
    -
  1. In earlier versions, an undocumented feature allowed entries in - the host file as follows:
    -
    -     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    -
    - This capability was never documented and has been removed in 1.4.6 to - allow entries of the following format:
    -
    -     z   eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    2. -
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been - removed from /etc/shorewall/shorewall.conf. These capabilities are now -automatically detected by Shorewall (see below).
    -
    3. - +
  3. Once you have installed this version of Shorewall, you must restart +Shorewall before you may use the 'drop', 'reject', 'allow' or 'save' commands.
    4. +
  4. To maintain strict compatibility with previous versions, current +uses of "shorewall drop" and "shorewall reject" should be replaced with "shorewall + dropall" and "shorewall rejectall"
    5. +
- -

New Features:
-

- + +

New Features:
+

+
    -
  1. A 'newnotsyn' interface option has been added. This option may -be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No - for packets arriving on the associated interface.
    -
    -
    2. -
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for -address ranges.
    -
    -
    3. -
  3. Shorewall can now add IP addresses to subnets other than the first - one on an interface.
    -
    -
    4. -
  4. DNAT[-] rules may now be used to load balance (round-robin) over - a set of servers. Servers may be specified in a range of addresses given - as <first address>-<last address>.
    -
    - Example:
    -
    -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    -
    5. -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options - have been removed and have been replaced by code that detects whether these - capabilities are present in the current kernel. The output of the start, - restart and check commands have been enhanced to report the outcome:
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    - Verifying Configuration...
    -
    -
    6. -
  6. Support for the Connection Tracking Match Extension has been added. - This extension is available in recent kernel/iptables releases and allows - for rules which match against elements in netfilter's connection tracking - table. Shorewall automatically detects the availability of this extension - and reports its availability in the output of the start, restart and check - commands.
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    -    Connection Tracking Match: Available
    - Verifying Configuration...
    -
    - If this extension is available, the ruleset generated by Shorewall -is changed in the following ways:
    7. - -
      -
    • To handle 'norfc1918' filtering, Shorewall will not create chains - in the mangle table but will rather do all 'norfc1918' filtering in the - filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; - one in the nat table and one in the filter table. If the Connection Tracking - Match Extension is available, the rule in the filter table is extended to - check that the original destination address was the same as specified (or - defaulted to) in the DNAT rule.
      +
    • Shorewall now creates a dynamic blacklisting chain for each interface +defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use +the routing table to determine which of these chains is to be used for blacklisting +the specified IP address(es).

      -
      • - -
    -
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    -
    8. -
  8. An 'ipcalc' command has been added to /sbin/shorewall.
    -
    -       ipcalc [ <address> <netmask> | <address>/<vlsm> - ]
    -
    - Examples:
    -
    -       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    -          CIDR=192.168.1.0/24
    -          NETMASK=255.255.255.0
    -          NETWORK=192.168.1.0
    -          BROADCAST=192.168.1.255
    -       [root@wookie root]#
    -
    -       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    -          CIDR=192.168.1.0/24
    -          NETMASK=255.255.255.0
    -          NETWORK=192.168.1.0
    -          BROADCAST=192.168.1.255
    -       [root@wookie root]#
    -
    - Warning:
    -
    - If your shell only supports 32-bit signed arithmatic (ash or dash), -then the ipcalc command produces incorrect information for IP addresses -128.0.0.0-1 and for /1 networks. Bash should produce correct information -for all valid IP addresses.
    -
    -
    9. -
  9. An 'iprange' command has been added to /sbin/shorewall.
    -
    -       iprange <address>-<address>
    -
    - This command decomposes a range of IP addressses into a list of network - and host addresses. The command can be useful if you need to construct -an efficient set of rules that accept connections from a range of network -addresses.
    -
    - Note: If your shell only supports 32-bit signed arithmetic (ash or dash) - then the range may not span 128.0.0.0.
    -
    - Example:
    -
    -       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    -       192.168.1.4/30
    -       192.168.1.8/29
    -       192.168.1.16/28
    -       192.168.1.32/27
    -       192.168.1.64/26
    -       192.168.1.128/25
    -       192.168.2.0/23
    -       192.168.4.0/22
    -       192.168.8.0/22
    -       192.168.12.0/29
    -       192.168.12.8/31
    -       [root@gateway root]#
    -
    -
    10. -
  10. A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.
    -
    - Example:
    -
    -     foo    eth1:192.168.1.0/24,192.168.2.0/24
    -
    -
    11. - + Two new commands ('dropall' and 'rejectall') have been introduced that +do what 'drop' and 'reject' used to do; namely, when an address is blacklisted + using these new commands, it will be blacklisted on all of your firewall's + interfaces. +
  11. Thanks to Steve Herber, the 'help' command can now give command-specific + help (e.g., shorewall help <command>).
    12. +
  12. A new option "ADMINISABSENTMINDED" has been added to /etc/shorewall/shorewall.conf. + This option has a default value of "No" for existing users which causes +Shorewall's 'stopped' state  to continue as it has been; namely, in the +stopped state only traffic to/from hosts listed in /etc/shorewall/routestopped +is accepted.
    +
    + With ADMINISABSENTMINDED=Yes (the default for new installs), in addition + to traffic to/from the hosts listed in /etc/shorewall/routestopped, Shorewall + will allow:
    +
    +    a) All traffic originating from the firewall itself; and
    +    b) All traffic that is part of or related to an already-existing connection.
    +
    +  In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop" entered +through an ssh session will not kill the session.
    +
    +  Note though that even with ADMINISABSENTMINDED=Yes, it is still possible +for people to shoot themselves in the foot.
    +
    +  Example:
    +
    +  /etc/shorewall/nat:
    +
    +      206.124.146.178    eth0:0    192.168.1.5   
    +
    +  /etc/shorewall/rules:
    +
    +    ACCEPT    net    loc:192.168.1.5    tcp    22
    +    ACCEPT    loc    fw        tcp    22
    +
    + From a remote system, I ssh to 206.124.146.178 which establishes an SSH +connection with local system 192.168.1.5. I then create a second SSH connection +from that computer to the firewall and confidently type "shorewall stop". +As part of its stop processing, Shorewall removes eth0:0 which kills my SSH +connection to 192.168.1.5!!!
    13. +
+ +

7/27/2003 - Snapshot 1.4.6_20030727

+ +
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+ Problems Corrected since version 1.4.6
+ +
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was +being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the tcrules + file. Previously, these addresses resulted in an invalid iptables command.
    +
    3. + +
+ Migration Issues:
+ +
    +
  1. Once you have installed this version of Shorewall, you must restart + Shorewall before you may use the 'drop', 'reject', 'allow' or 'save' commands.
    2. +
  2. To maintain strict compatibility with previous versions, current +uses of "shorewall drop" and "shorewall reject" should be replaced with +"shorewall dropall" and "shorewall rejectall"
    3. + +
+ New Features:
+ +
    +
  1. Shorewall now creates a dynamic blacklisting chain for each interface + defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use + the routing table to determine which of these chains is to be used for blacklisting + the specified IP address(es).
    +
    + Two new commands ('dropall' and 'rejectall') have been introduced that +do what 'drop' and 'reject' used to do; namely, when an address is blacklisted + using these new commands, it will be blacklisted on all of your firewall's + interfaces.
    2. +
  2. Thanks to Steve Herber, the 'help' command can now give command-specific + help (e.g., shorewall help <command>).
    +
    3. + +
+ +

7/26/2003 - Snapshot 1.4.6_20030726

+ +
+

http://shorewall.net/pub/shorewall/Snapshots/
+ ftp://shorewall.net/pub/shorewall/Snapshots/

+
+ +

Problems Corrected since version 1.4.6:
+

+ +
    +
  1. Corrected problem in 1.4.6 where the MANGLE_ENABLED variable was +being tested before it was set.
    2. +
  2. Corrected handling of MAC addresses in the SOURCE column of the +tcrules file. Previously, these addresses resulted in an invalid iptables +command.
    +
    3. + +
+ +

Migration Issues:
+

+ +
    +
  1. Once you have installed this version of Shorewall, you must restart + Shorewall before you may use the 'drop', 'reject', 'allow' or 'save' commands.
    2. +
  2. To maintain strict compatibility with previous versions, current +uses of "shorewall drop" and "shorewall reject" should be replaced with "shorewall + dropall" and "shorewall rejectall"
    3. + +
+ +

New Features:
+

+ Shorewall now creates a dynamic blacklisting chain for each interface +defined in /etc/shorewall/interfaces. The 'drop' and 'reject' commands use +the routing table to determine which of these chains is to be used for blacklisting +the specified IP address(es).
+
+ Two new commands ('dropall' and 'rejectall') have been introduced that + do what 'drop' and 'reject' used to do; namely, when an address is blacklisted + using these new commands, it will be blacklisted on all of your firewall's + interfaces. +

7/22/2003 - Shorewall-1.4.6a
+

+ Problems Corrected:
-

7/4/2003 - Shorewall-1.4.6 Beta 1

- +
    +
  1. Previously, if TC_ENABLED is set to yes in shorewall.conf then +Shorewall would fail to start with the error "ERROR:  Traffic Control requires +Mangle"; that problem has been corrected.
    2. + +
+ +

7/20/2003 - Shorewall-1.4.6
+

+ + +
+ +

Problems Corrected:
-

+

+
    -
  1. A problem seen on RH7.3 systems where Shorewall encountered -start errors when started using the "service" mechanism has been worked -around.
    -
    -
    2. -
  2. Where a list of IP addresses appears in the DEST column of a -DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the -nat table (one for each element in the list). Shorewall now correctly creates -a single DNAT rule with multiple "--to-destination" clauses.
    -
    3. - +
  3. A problem seen on RH7.3 systems where Shorewall encountered + start errors when started using the "service" mechanism has been worked + around.
    +
    +
    4. +
  4. Where a list of IP addresses appears in the DEST column of +a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in + the nat table (one for each element in the list). Shorewall now correctly + creates a single DNAT rule with multiple "--to-destination" clauses.
    +
    +
    5. +
  5. Corrected a problem in Beta 1 where DNS names containing a +"-" were mis-handled when they appeared in the DEST column of a rule.
    +
    +
    6. +
  6. A number of problems with rule parsing have been corrected. + Corrections involve the handling of "z1!z2" in the SOURCE column as well + as lists in the ORIGINAL DESTINATION column.
    +
    +
    7. +
  7. The message "Adding rules for DHCP" is now suppressed if there +are no DHCP rules to add.
    +
    8. +
+ +

Migration Issues:
+

+ + +
    +
  1. In earlier versions, an undocumented feature allowed entries + in the host file as follows:
    +
    +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    +
    + This capability was never documented and has been removed +in 1.4.6 to allow entries of the following format:
    +
    +     z   eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    2. +
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have +been removed from /etc/shorewall/shorewall.conf. These capabilities are + now automatically detected by Shorewall (see below).
    +
    3. + +
+ +

New Features:
-

+

+
    -
  1. A 'newnotsyn' interface option has been added. This option may - be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No - for packets arriving on the associated interface.
    -
    -
    2. -
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq - to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for -address ranges.
    -
    -
    3. -
  3. Shorewall can now add IP addresses to subnets other than the -first one on an interface.
    -
    -
    4. -
  4. DNAT[-] rules may now be used to load balance (round-robin) -over a set of servers. Up to 256 servers may be specified in a range of -addresses given as <first address>-<last address>.
    -
    - Example:
    -
    -     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    -
    - Note that this capability has previously been available using a combination - of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable - for load-balancing over a large number of servers (> 16) since specifying - a range in the DNAT rule causes one filter table ACCEPT rule to be generated - for each IP address in the range.
    -
    -
    5. -
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration -options have been removed and have been replaced by code that detects -whether these capabilities are present in the current kernel. The output -of the start, restart and check commands have been enhanced to report the -outcome:
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    - Verifying Configuration...
    -
    -
    6. -
  6. Support for the Connection Tracking Match Extension has been -added. This extension is available in recent kernel/iptables releases and -allows for rules which match against elements in netfilter's connection -tracking table. Shorewall automatically detects the availability of this -extension and reports its availability in the output of the start, restart -and check commands.
    -
    - Shorewall has detected the following iptables/netfilter capabilities:
    -    NAT: Available
    -    Packet Mangling: Available
    -    Multi-port Match: Available
    -    Connection Tracking Match: Available
    - Verifying Configuration...
    -
    - If this extension is available, the ruleset generated by Shorewall -is changed in the following ways:
    7. - -
      - -
    - +
  7. A 'newnotsyn' interface option has been added. This option +may be specified in /etc/shorewall/interfaces and overrides the setting + NEWNOTSYN=No for packets arriving on the associated interface.
    +
    +
    8. +
  8. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled + for address ranges.
    +
    +
    9. +
  9. Shorewall can now add IP addresses to subnets other than the + first one on an interface.
    +
    +
    10. +
  10. DNAT[-] rules may now be used to load balance (round-robin) + over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    +
    11. +
  11. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration + options have been removed and have been replaced by code that detects + whether these capabilities are present in the current kernel. The output + of the start, restart and check commands have been enhanced to report +the outcome:
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
    12. +
  12. Support for the Connection Tracking Match Extension has been + added. This extension is available in recent kernel/iptables releases + and allows for rules which match against elements in netfilter's connection + tracking table. Shorewall automatically detects the availability of +this extension and reports its availability in the output of the start, +restart and check commands.
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by +Shorewall is changed in the following ways:
    13. +
      -
    • To handle 'norfc1918' filtering, Shorewall will not create -chains in the mangle table but will rather do all 'norfc1918' filtering -in the filter table (rfc1918 chain).
      • -
    • Recall that Shorewall DNAT rules generate two netfilter rules; - one in the nat table and one in the filter table. If the Connection Tracking - Match Extension is available, the rule in the filter table is extended to - check that the original destination address was the same as specified (or - defaulted to) in the DNAT rule.
      -
      -
      • - +
    • To handle 'norfc1918' filtering, Shorewall will not create + chains in the mangle table but will rather do all 'norfc1918' filtering + in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter rules; + one in the nat table and one in the filter table. If the Connection + Tracking Match Extension is available, the rule in the filter table is +extended to check that the original destination address was the same as + specified (or defaulted to) in the DNAT rule.
      +
      +
      • +
    -
  13. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) - may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    -
    14. - +
  14. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
    +
    15. +
  15. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
    +
    + Examples:
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    + Warning:
    +
    + If your shell only supports 32-bit signed arithmatic (ash +or dash), then the ipcalc command produces incorrect information for +IP addresses 128.0.0.0-1 and for /1 networks. Bash should produce correct + information for all valid IP addresses.
    +
    +
    16. +
  16. An 'iprange' command has been added to /sbin/shorewall. +
    +
    +       iprange <address>-<address>
    +
    + This command decomposes a range of IP addressses into a list + of network and host addresses. The command can be useful if you need + to construct an efficient set of rules that accept connections from a +range of network addresses.
    +
    + Note: If your shell only supports 32-bit signed arithmetic +(ash or dash) then the range may not span 128.0.0.0.
    +
    + Example:
    +
    +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    +       192.168.1.4/30
    +       192.168.1.8/29
    +       192.168.1.16/28
    +       192.168.1.32/27
    +       192.168.1.64/26
    +       192.168.1.128/25
    +       192.168.2.0/23
    +       192.168.4.0/22
    +       192.168.8.0/22
    +       192.168.12.0/29
    +       192.168.12.8/31
    +       [root@gateway root]#
    +
    +
    17. +
  17. A list of host/net addresses is now allowed in an entry in +/etc/shorewall/hosts.
    +
    + Example:
    +
    +     foo    eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    18. +
  18. The "shorewall check" command now includes the chain name when +printing the applicable policy for each pair of zones.
    +  
    +     Example:
    +  
    +         Policy for dmz to net is REJECT using chain all2all
    +  
    + This means that the policy for connections from the dmz to the internet + is REJECT and the applicable entry in the /etc/shorewall/policy was the +all->all policy.
    +
    +
    19. +
  19. Support for the 2.6 Kernel series has been added.
    +
    20. +
- -

6/17/2003 - Shorewall-1.4.5

- -

Problems Corrected:
-

- + +

7/15/2003 - New Mirror in Brazil
+

+ Thanks to the folks at securityopensource.org.br, there is now a Shorewall + mirror in Brazil. +

7/15/2003 - Shorewall-1.4.6 RC 1
+

+ +

Problems Corrected:
+

+
    -
  1. The command "shorewall debug try <directory>" now correctly - traces the attempt.
    2. -
  2. The INCLUDE directive now works properly in the zones file; -previously, INCLUDE in that file was ignored.
    3. -
  3. /etc/shorewall/routestopped records with an empty second column - are no longer ignored.
    +
  4. A problem seen on RH7.3 systems where Shorewall encountered +start errors when started using the "service" mechanism has been worked +around.
    +
    +
    5. +
  5. Where a list of IP addresses appears in the DEST column of +a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now correctly +creates a single DNAT rule with multiple "--to-destination" clauses.
    +
    6. +
  6. Corrected a problem in Beta 1 where DNS names containing a +"-" were mis-handled when they appeared in the DEST column of a rule.
    +
    +
    7. +
  7. A number of problems with rule parsing have been corrected. +Corrections involve the handling of "z1!z2" in the SOURCE column as well +as lists in the ORIGINAL DESTINATION column.
    +
- -

New Features:
-

- + +

Migration Issues:
+

+
    -
  1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may - now contain a list of addresses. If the list begins with "!' then the rule - will take effect only if the original destination address in the connection - request does not match any of the addresses listed.
    2. +
  2. In earlier versions, an undocumented feature allowed entries + in the host file as follows:
    +
    +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    +
    + This capability was never documented and has been removed in 1.4.6 + to allow entries of the following format:
    +
    +     z   eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    3. +
  3. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have +been removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
    +
    4. + +
+ +

New Features:
+

+ +
    +
  1. A 'newnotsyn' interface option has been added. This option +may be specified in /etc/shorewall/interfaces and overrides the setting +NEWNOTSYN=No for packets arriving on the associated interface.
    +
    +
    2. +
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for + address ranges.
    +
    +
    3. +
  3. Shorewall can now add IP addresses to subnets other than the + first one on an interface.
    +
    +
    4. +
  4. DNAT[-] rules may now be used to load balance (round-robin) +over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    +
    5. +
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration +options have been removed and have been replaced by code that detects +whether these capabilities are present in the current kernel. The output +of the start, restart and check commands have been enhanced to report the +outcome:
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
    6. +
  6. Support for the Connection Tracking Match Extension has been + added. This extension is available in recent kernel/iptables releases + and allows for rules which match against elements in netfilter's connection + tracking table. Shorewall automatically detects the availability of +this extension and reports its availability in the output of the start, +restart and check commands.
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways:
    7. + +
      +
    • To handle 'norfc1918' filtering, Shorewall will not create + chains in the mangle table but will rather do all 'norfc1918' filtering + in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter rules; + one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table is +extended to check that the original destination address was the same as +specified (or defaulted to) in the DNAT rule.
      +
      +
      • + +
    +
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
    +
    8. +
  8. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
    +
    + Examples:
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    + Warning:
    +
    + If your shell only supports 32-bit signed arithmatic (ash or dash), + then the ipcalc command produces incorrect information for IP addresses + 128.0.0.0-1 and for /1 networks. Bash should produce correct information + for all valid IP addresses.
    +
    +
    9. +
  9. An 'iprange' command has been added to /sbin/shorewall.
    +
    +       iprange <address>-<address>
    +
    + This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need to construct + an efficient set of rules that accept connections from a range of network + addresses.
    +
    + Note: If your shell only supports 32-bit signed arithmetic (ash +or dash) then the range may not span 128.0.0.0.
    +
    + Example:
    +
    +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    +       192.168.1.4/30
    +       192.168.1.8/29
    +       192.168.1.16/28
    +       192.168.1.32/27
    +       192.168.1.64/26
    +       192.168.1.128/25
    +       192.168.2.0/23
    +       192.168.4.0/22
    +       192.168.8.0/22
    +       192.168.12.0/29
    +       192.168.12.8/31
    +       [root@gateway root]#
    +
    +
    10. +
  10. A list of host/net addresses is now allowed in an entry in +/etc/shorewall/hosts.
    +
    + Example:
    +
    +     foo    eth1:192.168.1.0/24,192.168.2.0/24
-

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

- -

The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and - iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems - have been encountered with this set of software. The Shorewall version - is 1.4.4b plus the accumulated changes for 1.4.5.
-

- -

6/8/2003 - Updated Samples

- -

Thanks to Francesca Smith, the samples have been updated to Shorewall -version 1.4.4.

- -

5/29/2003 - Shorewall-1.4.4b

+

7/7/2003 - Shorewall-1.4.6 Beta 2

-

Groan -- This version corrects a problem whereby the --log-level was not - being set when logging via syslog. The most commonly reported symptom - was that Shorewall messages were being written to the console even though - console logging was correctly configured per FAQ 16.
+

Problems Corrected:

-

5/27/2003 - Shorewall-1.4.4a

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has - pointed out that the code in 1.4.4 restricts the length of short zone - names to 4 characters. I've produced version 1.4.4a that restores the - previous 5-character limit by conditionally omitting the log rule number - when the LOGFORMAT doesn't contain '%d'.
- -

5/23/2003 - Shorewall-1.4.4

- I apologize for the rapid-fire releases but since there is -a potential configuration change required to go from 1.4.3a to 1.4.4, - I decided to make it a full release rather than just a bug-fix release. -
+
    +
  1. A problem seen on RH7.3 systems where Shorewall encountered + start errors when started using the "service" mechanism has been worked + around.

    -     Problems corrected:
    +
    2. +
  2. Where a list of IP addresses appears in the DEST column of +a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in +the nat table (one for each element in the list). Shorewall now correctly +creates a single DNAT rule with multiple "--to-destination" clauses.
    +
    +
    3. +
  3. Corrected a problem in Beta 1 where DNS names containing a +"-" were mis-handled when they appeared in the DEST column of a rule.
    +
    4. + +
+ +

Migration Issues:
+

+ +
    +
  1. In earlier versions, an undocumented feature allowed entries + in the host file as follows:
    +
    +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
    +
    + This capability was never documented and has been removed in 1.4.6 + to allow entries of the following format:
    +
    +     z   eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    2. +
  2. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have +been removed from /etc/shorewall/shorewall.conf. These capabilities are +now automatically detected by Shorewall (see below).
    +
    3. + +
+ +

New Features:
+

+ +
    +
  1. A 'newnotsyn' interface option has been added. This option +may be specified in /etc/shorewall/interfaces and overrides the setting +NEWNOTSYN=No for packets arriving on the associated interface.
    +
    +
    2. +
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for + address ranges.
    +
    +
    3. +
  3. Shorewall can now add IP addresses to subnets other than the + first one on an interface.
    +
    +
    4. +
  4. DNAT[-] rules may now be used to load balance (round-robin) + over a set of servers. Servers may be specified in a range of addresses + given as <first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    +
    5. +
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration + options have been removed and have been replaced by code that detects + whether these capabilities are present in the current kernel. The output + of the start, restart and check commands have been enhanced to report +the outcome:
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
    6. +
  6. Support for the Connection Tracking Match Extension has been + added. This extension is available in recent kernel/iptables releases + and allows for rules which match against elements in netfilter's connection + tracking table. Shorewall automatically detects the availability of this + extension and reports its availability in the output of the start, restart + and check commands.
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways:
    7. + +
      +
    • To handle 'norfc1918' filtering, Shorewall will not create + chains in the mangle table but will rather do all 'norfc1918' filtering + in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter +rules; one in the nat table and one in the filter table. If the Connection +Tracking Match Extension is available, the rule in the filter table is +extended to check that the original destination address was the same as +specified (or defaulted to) in the DNAT rule.
      +
      +
      • + +
    +
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
    +
    8. +
  8. An 'ipcalc' command has been added to /sbin/shorewall.
    +
    +       ipcalc [ <address> <netmask> | <address>/<vlsm> + ]
    +
    + Examples:
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0/24
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    +       [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0
    +          CIDR=192.168.1.0/24
    +          NETMASK=255.255.255.0
    +          NETWORK=192.168.1.0
    +          BROADCAST=192.168.1.255
    +       [root@wookie root]#
    +
    + Warning:
    +
    + If your shell only supports 32-bit signed arithmatic (ash or dash), + then the ipcalc command produces incorrect information for IP addresses + 128.0.0.0-1 and for /1 networks. Bash should produce correct information + for all valid IP addresses.
    +
    +
    9. +
  9. An 'iprange' command has been added to /sbin/shorewall.
    +
    +       iprange <address>-<address>
    +
    + This command decomposes a range of IP addressses into a list of +network and host addresses. The command can be useful if you need to +construct an efficient set of rules that accept connections from a range +of network addresses.
    +
    + Note: If your shell only supports 32-bit signed arithmetic (ash +or dash) then the range may not span 128.0.0.0.
    +
    + Example:
    +
    +       [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9
    +       192.168.1.4/30
    +       192.168.1.8/29
    +       192.168.1.16/28
    +       192.168.1.32/27
    +       192.168.1.64/26
    +       192.168.1.128/25
    +       192.168.2.0/23
    +       192.168.4.0/22
    +       192.168.8.0/22
    +       192.168.12.0/29
    +       192.168.12.8/31
    +       [root@gateway root]#
    +
    +
    10. +
  10. A list of host/net addresses is now allowed in an entry in +/etc/shorewall/hosts.
    +
    + Example:
    +
    +     foo    eth1:192.168.1.0/24,192.168.2.0/24
    +
    +
    11. + +
+ +

7/4/2003 - Shorewall-1.4.6 Beta 1

+ +

Problems Corrected:
+

+ +
    +
  1. A problem seen on RH7.3 systems where Shorewall encountered + start errors when started using the "service" mechanism has been worked + around.
    +
    +
    2. +
  2. Where a list of IP addresses appears in the DEST column +of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules +in the nat table (one for each element in the list). Shorewall now correctly +creates a single DNAT rule with multiple "--to-destination" clauses.
    +
    3. + +
+ +

New Features:
+

+ +
    +
  1. A 'newnotsyn' interface option has been added. This option + may be specified in /etc/shorewall/interfaces and overrides the setting + NEWNOTSYN=No for packets arriving on the associated interface.
    +
    +
    2. +
  2. The means for specifying a range of IP addresses in /etc/shorewall/masq + to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for + address ranges.
    +
    +
    3. +
  3. Shorewall can now add IP addresses to subnets other than +the first one on an interface.
    +
    +
    4. +
  4. DNAT[-] rules may now be used to load balance (round-robin) + over a set of servers. Up to 256 servers may be specified in a range +of addresses given as <first address>-<last address>.
    +
    + Example:
    +
    +     DNAT net loc:192.168.10.2-192.168.10.5 tcp 80
    +
    + Note that this capability has previously been available using +a combination of a DNAT- rule and one or more ACCEPT rules. That technique + is still preferable for load-balancing over a large number of servers +(> 16) since specifying a range in the DNAT rule causes one filter +table ACCEPT rule to be generated for each IP address in the range.
    +
    +
    5. +
  5. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration + options have been removed and have been replaced by code that detects + whether these capabilities are present in the current kernel. The output + of the start, restart and check commands have been enhanced to report +the outcome:
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    + Verifying Configuration...
    +
    +
    6. +
  6. Support for the Connection Tracking Match Extension has +been added. This extension is available in recent kernel/iptables releases + and allows for rules which match against elements in netfilter's connection + tracking table. Shorewall automatically detects the availability of this + extension and reports its availability in the output of the start, restart + and check commands.
    +
    + Shorewall has detected the following iptables/netfilter capabilities:
    +    NAT: Available
    +    Packet Mangling: Available
    +    Multi-port Match: Available
    +    Connection Tracking Match: Available
    + Verifying Configuration...
    +
    + If this extension is available, the ruleset generated by Shorewall + is changed in the following ways:
    7. + +
      + +
    + +
      +
    • To handle 'norfc1918' filtering, Shorewall will not create + chains in the mangle table but will rather do all 'norfc1918' filtering + in the filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter + rules; one in the nat table and one in the filter table. If the Connection + Tracking Match Extension is available, the rule in the filter table is + extended to check that the original destination address was the same as + specified (or defaulted to) in the DNAT rule.
      +
      +
      • + +
    +
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
    8. + +
+ +

6/17/2003 - Shorewall-1.4.5

+ +

Problems Corrected:
+

+ +
    +
  1. The command "shorewall debug try <directory>" now +correctly traces the attempt.
    2. +
  2. The INCLUDE directive now works properly in the zones file; + previously, INCLUDE in that file was ignored.
    3. +
  3. /etc/shorewall/routestopped records with an empty second + column are no longer ignored.
    +
    4. + +
+ +

New Features:
+

+ +
    +
  1. The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule + may now contain a list of addresses. If the list begins with "!' then + the rule will take effect only if the original destination address in +the connection request does not match any of the addresses listed.
    2. + +
+ +

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8

+ +

The firewall at shorewall.net has been upgraded to the 2.4.21 kernel and + iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems + have been encountered with this set of software. The Shorewall version + is 1.4.4b plus the accumulated changes for 1.4.5.
+

+ +

6/8/2003 - Updated Samples

+ +

Thanks to Francesca Smith, the samples have been updated to Shorewall +version 1.4.4.

+ +

5/29/2003 - Shorewall-1.4.4b

+

Groan -- This version corrects a problem whereby the --log-level was not + being set when logging via syslog. The most commonly reported symptom + was that Shorewall messages were being written to the console even though + console logging was correctly configured per FAQ 16.
+

+ +

5/27/2003 - Shorewall-1.4.4a

+ The Fireparse --log-prefix fiasco continues. Tuomo Soini + has pointed out that the code in 1.4.4 restricts the length of short + zone names to 4 characters. I've produced version 1.4.4a that restores + the previous 5-character limit by conditionally omitting the log +rule number when the LOGFORMAT doesn't contain '%d'.
+ +

5/23/2003 - Shorewall-1.4.4

+ I apologize for the rapid-fire releases but since there + is a potential configuration change required to go from 1.4.3a to + 1.4.4, I decided to make it a full release rather than just a bug-fix + release.
+
+     Problems corrected:
+
None.
-
-     New Features:
- + +     New Features:
+
    -
  1. A REDIRECT- rule target has been added. This target -behaves for REDIRECT in the same way as DNAT- does for DNAT in that -the Netfilter nat table REDIRECT rule is added but not the companion -filter table ACCEPT rule.
    -
    -
    2. -
  2. The LOGMARKER variable has been renamed LOGFORMAT and - has been changed to a 'printf' formatting template which accepts three - arguments (the chain name, logging rule number and the disposition). - To use LOGFORMAT with fireparse (A REDIRECT- rule target has been added. This target + behaves for REDIRECT in the same way as DNAT- does for DNAT in that + the Netfilter nat table REDIRECT rule is added but not the companion + filter table ACCEPT rule.
    +
    +
    3. +
  3. The LOGMARKER variable has been renamed LOGFORMAT + and has been changed to a 'printf' formatting template which accepts + three arguments (the chain name, logging rule number and the disposition). + To use LOGFORMAT with fireparse (http://www.fireparse.com), set it - as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - CAUTION: /sbin/shorewall uses the leading part -of the LOGFORMAT string (up to but not including the first '%') to -find log messages in the 'show log', 'status' and 'hits' commands. This -part should not be omitted (the LOGFORMAT should not begin with "%") -and the leading part should be sufficiently unique for /sbin/shorewall -to identify Shorewall messages.
    -
    -
    4. -
  4. When logging is specified on a DNAT[-] or REDIRECT[-] - rule, the logging now takes place in the nat table rather than in -the filter table. This way, only those connections that actually undergo - DNAT or redirection will be logged.
    -
    5. - + as:
    +  
    +        LOGFORMAT="fp=%s:%d a=%s "
    +  
    + CAUTION: /sbin/shorewall uses the leading part + of the LOGFORMAT string (up to but not including the first '%') +to find log messages in the 'show log', 'status' and 'hits' commands. +This part should not be omitted (the LOGFORMAT should not begin with +"%") and the leading part should be sufficiently unique for /sbin/shorewall + to identify Shorewall messages.
    +
    + +
  5. When logging is specified on a DNAT[-] or REDIRECT[-] + rule, the logging now takes place in the nat table rather than in + the filter table. This way, only those connections that actually +undergo DNAT or redirection will be logged.
    +
    6. +
- +

5/20/2003 - Shorewall-1.4.3a
-

- This version primarily corrects the documentation included - in the .tgz and in the .rpm. In addition:
- +

+ This version primarily corrects the documentation included + in the .tgz and in the .rpm. In addition:
+
    -
  1. (This change is in 1.4.3 but is not documented) If -you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will -return reject replies as follows:
    -    a) tcp - RST
    -    b) udp - ICMP port unreachable
    -    c) icmp - ICMP host unreachable
    -    d) Otherwise - ICMP host prohibited
    - If you are running earlier software, Shorewall will follow - it's traditional convention:
    -    a) tcp - RST
    -    b) Otherwise - ICMP port unreachable
    2. -
  2. UDP port 135 is now silently dropped in the common.def - chain. Remember that this chain is traversed just before a DROP or - REJECT policy is enforced.
    -
    3. - -
- -

5/18/2003 - Shorewall 1.4.3
-

-     Problems Corrected:
- -
    -
  1. There were several cases where Shorewall would fail - to remove a temporary directory from /tmp. These cases have been corrected.
    2. -
  2. The rules for allowing all traffic via the loopback - interface have been moved to before the rule that drops status=INVALID - packets. This insures that all loopback traffic is allowed even if -Netfilter connection tracking is confused.
    3. - -
-     New Features:
- -
    -
  1.  IPV6-IPV4 (6to4) tunnels are now supported in the - /etc/shorewall/tunnels file.
    2. -
  2. You may now change the leading portion -of the --log-prefix used by Shorewall using the LOGMARKER variable -in shorewall.conf. By default, "Shorewall:" is used.
    -
    3. - -
- -

5/10/2003 - Shorewall Mirror in Asia
-

- -

Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
-

- -

5/8/2003 - Shorewall Mirror in Chile

- Thanks to Darcy Ganga, there is now an HTTP mirror - in Santiago Chile. -

4/21/2003 - Samples updated for Shorewall version 1.4.2

+
  • (This change is in 1.4.3 but is not documented) + If you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall + will return reject replies as follows:
    +    a) tcp - RST
    +    b) udp - ICMP port unreachable
    +    c) icmp - ICMP host unreachable
    +    d) Otherwise - ICMP host prohibited
    + If you are running earlier software, Shorewall will +follow it's traditional convention:
    +    a) tcp - RST
    +    b) Otherwise - ICMP port unreachable
    • +
  • UDP port 135 is now silently dropped in the common.def + chain. Remember that this chain is traversed just before a DROP +or REJECT policy is enforced.
    +
    • + + +

    5/18/2003 - Shorewall 1.4.3
    +

    +     Problems Corrected:
    +     +
      +
    1. There were several cases where Shorewall would + fail to remove a temporary directory from /tmp. These cases have +been corrected.
      2. +
    2. The rules for allowing all traffic via the loopback + interface have been moved to before the rule that drops status=INVALID + packets. This insures that all loopback traffic is allowed even if + Netfilter connection tracking is confused.
      3. + +
    +     New Features:
    +     +
      +
    1.  IPV6-IPV4 (6to4) tunnels are now supported in + the /etc/shorewall/tunnels file.
      2. +
    2. You may now change the leading portion + of the --log-prefix used by Shorewall using the LOGMARKER variable + in shorewall.conf. By default, "Shorewall:" is used.
      +
      3. + +
    + +

    5/10/2003 - Shorewall Mirror in Asia
    +

    + +

    Ed Greshko has established a mirror in Taiwan -- Thanks Ed!
    +

    + +

    5/8/2003 - Shorewall Mirror in Chile

    + Thanks to Darcy Ganga, there is now an HTTP + mirror in Santiago Chile. +

    4/21/2003 - Samples updated for Shorewall version 1.4.2

    +

    Thanks to Francesca Smith, the sample configurations are now upgraded to Shorewall version 1.4.2.

    - +

    4/9/2003 - Shorewall 1.4.2
    -

    - +

    +

        Problems Corrected:

    - +
    - +
      -
    1. TCP connection requests rejected out of the - common chain are now properly rejected with TCP RST; - previously, some of these requests were rejected with an ICMP port-unreachable - response.
      2. -
    2. 'traceroute -I' from behind the firewall previously - timed out on the first hop (e.g., to the firewall). This has been - worked around.
      3. +
    3. TCP connection requests rejected out of + the common chain are now properly rejected with +TCP RST; previously, some of these requests were rejected with +an ICMP port-unreachable response.
      4. +
    4. 'traceroute -I' from behind the firewall + previously timed out on the first hop (e.g., to the firewall). + This has been worked around.
      5. - +
    -
    - + +

        New Features:

    - + +
      -
    1. Where an entry in the/etc/shorewall/hosts file - specifies a particular host or network, Shorewall now creates an - intermediate chain for handling input from the related zone. This - can substantially reduce the number of rules traversed by connections - requests from such zones.
      +
    2. Where an entry in the/etc/shorewall/hosts + file specifies a particular host or network, Shorewall now creates + an intermediate chain for handling input from the related zone. + This can substantially reduce the number of rules traversed by connections + requests from such zones.
      +
      +
      3. +
    3. Any file may include an INCLUDE directive. + An INCLUDE directive consists of the word INCLUDE followed by +a file name and causes the contents of the named file to be logically + included into the file containing the INCLUDE. File names given in + an INCLUDE directive are assumed to reside in /etc/shorewall or +in an alternate configuration directory if one has been specified +for the command.
      +  
      +    Examples:
      +    shorewall/params.mgmt:
      +    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
      +    TIME_SERVERS=4.4.4.4
      +    BACKUP_SERVERS=5.5.5.5
      +    ----- end params.mgmt -----
      +  
      +  
      +    shorewall/params:
      +    # Shorewall 1.3 /etc/shorewall/params
      +    [..]
      +    #######################################
      +  
      +    INCLUDE params.mgmt   
      +  
      +    # params unique to this host here
      +    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS +ONE - DO NOT REMOVE
      +    ----- end params -----
      +  
      +  
      +    shorewall/rules.mgmt:
      +    ACCEPT net:$MGMT_SERVERS          $FW    +tcp    22
      +    ACCEPT $FW          net:$TIME_SERVERS    +udp    123
      +    ACCEPT $FW          net:$BACKUP_SERVERS  +tcp    22
      +    ----- end rules.mgmt -----
      +  
      +    shorewall/rules:
      +    # Shorewall version 1.3 - Rules File
      +    [..]
      +    #######################################
      +  
      +    INCLUDE rules.mgmt    
      +  
      +    # rules unique to this host here
      +    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS + ONE -- DO NOT REMOVE
      +    ----- end rules -----
      +  
      + INCLUDE's may be nested to a level of 3 -- further + nested INCLUDE directives are ignored with a warning message.

      +
      4. +
    4. Routing traffic from an interface back out + that interface continues to be a problem. While I firmly believe + that this should never happen, people continue to want to do it. + To limit the damage that such nonsense produces, I have added a +new 'routeback' option in /etc/shorewall/interfaces and /etc/shorewall/hosts. + When used in /etc/shorewall/interfaces, the 'ZONE' column may not + contain '-'; in other words, 'routeback' can't be used as an option + for a multi-zone interface. The 'routeback' option CAN be specified + however on individual group entries in /etc/shorewall/hosts.
      +  
      + The 'routeback' option is similar to the old +'multi' option with two exceptions:
      +  
      +    a) The option pertains to a particular zone,interface,address + tuple.
      +  
      +    b) The option only created infrastructure +to pass traffic from (zone,interface,address) tuples back to themselves + (the 'multi' option affected all (zone,interface,address) tuples + associated with the given 'interface').
      +  
      + See the 'Upgrade + Issues' for information about how this new option may affect + your configuration.
      5. -
    5. Any file may include an INCLUDE directive. An - INCLUDE directive consists of the word INCLUDE followed by a file - name and causes the contents of the named file to be logically included - into the file containing the INCLUDE. File names given in an INCLUDE - directive are assumed to reside in /etc/shorewall or in an alternate - configuration directory if one has been specified for the command. -
      -  
      -    Examples:
      -    shorewall/params.mgmt:
      -    MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
      -    TIME_SERVERS=4.4.4.4
      -    BACKUP_SERVERS=5.5.5.5
      -    ----- end params.mgmt -----
      -  
      -  
      -    shorewall/params:
      -    # Shorewall 1.3 /etc/shorewall/params
      -    [..]
      -    #######################################
      -  
      -    INCLUDE params.mgmt   
      -  
      -    # params unique to this host here
      -    #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -- DO NOT REMOVE
      -    ----- end params -----
      -  
      -  
      -    shorewall/rules.mgmt:
      -    ACCEPT net:$MGMT_SERVERS          $FW    tcp    - 22
      -    ACCEPT $FW          net:$TIME_SERVERS    udp    - 123
      -    ACCEPT $FW          net:$BACKUP_SERVERS  tcp    - 22
      -    ----- end rules.mgmt -----
      -  
      -    shorewall/rules:
      -    # Shorewall version 1.3 - Rules File
      -    [..]
      -    #######################################
      -  
      -    INCLUDE rules.mgmt    
      -  
      -    # rules unique to this host here
      -    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE - -- DO NOT REMOVE
      -    ----- end rules -----
      -  
      - INCLUDE's may be nested to a level of 3 -- further - nested INCLUDE directives are ignored with a warning message.
      -
      -
      6. -
    6. Routing traffic from an interface back out that - interface continues to be a problem. While I firmly believe that - this should never happen, people continue to want to do it. To -limit the damage that such nonsense produces, I have added a new -'routeback' option in /etc/shorewall/interfaces and /etc/shorewall/hosts. - When used in /etc/shorewall/interfaces, the 'ZONE' column may not -contain '-'; in other words, 'routeback' can't be used as an option -for a multi-zone interface. The 'routeback' option CAN be specified - however on individual group entries in /etc/shorewall/hosts.
      -  
      - The 'routeback' option is similar to the old 'multi' - option with two exceptions:
      -  
      -    a) The option pertains to a particular zone,interface,address - tuple.
      -  
      -    b) The option only created infrastructure to -pass traffic from (zone,interface,address) tuples back to themselves - (the 'multi' option affected all (zone,interface,address) tuples - associated with the given 'interface').
      -  
      - See the 'Upgrade Issues' - for information about how this new option may affect your configuration.
      -
      7. - +
    - +

    3/24/2003 - Shorewall 1.4.1

    - + @@ -1065,1068 +1276,974 @@ pass traffic from (zone,interface,address) tuples back to themselves - +

    This release follows up on 1.4.0. It corrects a problem introduced in 1.4.0 and removes additional warts.
    -
    - Problems Corrected:
    -

    - +
    + Problems Corrected:
    +

    +
      -
    1. When Shorewall 1.4.0 is run under the ash shell - (such as on Bering/LEAF), it can attempt to add ECN disabling rules - even if the /etc/shorewall/ecn file is empty. That problem has been - corrected so that ECN disabling rules are only added if there are - entries in /etc/shorewall/ecn.
      2. - +
    2. When Shorewall 1.4.0 is run under the ash + shell (such as on Bering/LEAF), it can attempt to add ECN disabling + rules even if the /etc/shorewall/ecn file is empty. That problem + has been corrected so that ECN disabling rules are only added if + there are entries in /etc/shorewall/ecn.
      3. +
    - New Features:
    - + New Features:
    +
    Note: In the list that follows, the term group refers to a particular network or subnetwork (which may be 0.0.0.0/0 or it may be a host address) accessed through a particular interface. Examples:
    - +
    eth0:0.0.0.0/0
    - eth2:192.168.1.0/24
    - eth3:192.0.2.123
    -
    - You can use the "shorewall check" command to see -the groups associated with each of your zones.
    -
    - + eth2:192.168.1.0/24
    + eth3:192.0.2.123
    + + You can use the "shorewall check" command to +see the groups associated with each of your zones.
    + +
      -
    1. Beginning with Shorewall 1.4.1, if a zone Z -comprises more than one group then if there is no explicit -Z to Z policy and there are no rules governing traffic from Z to Z -then Shorewall will permit all traffic between the groups in the -zone.
      2. -
    2. Beginning with Shorewall 1.4.1, Shorewall will - never create rules to handle traffic from a group to itself.
      3. -
    3. A NONE policy is introduced in 1.4.1. When -a policy of NONE is specified from Z1 to Z2:
      4. - +
    4. Beginning with Shorewall 1.4.1, if a zone + Z comprises more than one group then if there is no explicit + Z to Z policy and there are no rules governing traffic from Z to + Z then Shorewall will permit all traffic between the groups in the + zone.
      5. +
    5. Beginning with Shorewall 1.4.1, Shorewall + will never create rules to handle traffic from a group to itself.
      6. +
    6. A NONE policy is introduced in 1.4.1. When + a policy of NONE is specified from Z1 to Z2:
      7. +
    - +
      -
    • There may be no rules created that govern connections - from Z1 to Z2.
      • -
    • Shorewall will not create any infrastructure - to handle traffic from Z1 to Z2.
      • - +
    • There may be no rules created that govern + connections from Z1 to Z2.
      • +
    • Shorewall will not create any infrastructure + to handle traffic from Z1 to Z2.
      • +
    - See the upgrade issues - for a discussion of how these changes may affect your configuration. - + See the upgrade + issues for a discussion of how these changes may affect +your configuration.

    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:
    - -
      -
    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. 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/10/2003 - Shoreall 1.3.14a

    - -

    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 - 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)
      -
      -
      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

    + 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:
    -

    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.
      -   
      +
    4. 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.
      +
      +
      5. +
    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. Shorewall 1.4 behavior is the same + as 1.3 with ALLOWRELATED=Yes.
      +
      +
      10. +
    10. The icmp.def file has been removed.
      +
      11. + +
    + 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. 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/10/2003 - Shoreall 1.3.14a

    + +

    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 - 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)
      +
      +
      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:
      -   
      +  
      + 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
      -
      7. + - +
    + +


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

    + -

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

    +

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

    - -

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

    + +

    Includes the Beta 2 content plus support for OpenVPN tunnels.

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

    1/17/2003 - shorewall.net has MOVED 

    + +

    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

    + +     ftp://slovakia.shorewall.net/mirror/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.
    -

    +

    - +

    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 in /etc/shorewall/tcrules.
      -
      -
      4. -
    4. 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.
      -
      5. +
    5. 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,....
      +
      +
      6. +
    6. The 'shorewall check' + command now prints out the applicable policy between + each pair of zones.
      +
      +
      7. +
    7. 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.
      +
      +
      8. +
    8. 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.
      +
      9. - +
    - +

    1/6/2003 - BURNOUT

    - +

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

    + 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

    + 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. I have added a new -RFC1918_LOG_LEVEL variable to 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. + 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.
      + - +
    - +

    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.
    +

    + 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 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 "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 +
    11. 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.
      12. -
    12. 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.
      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. - +
    - You may download the - Beta from:
    + 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

    + Shorewall is +at the center of MandrakeSoft's recently-announced +    Multi - Network Firewall (MNF) product. Here is the - product. Here is +the press - release.
    + 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.

    + 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.

    + 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 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
      • +
    • 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

    + 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:

    - +
      -
    • You -may now define the contents - of a zone dynamically with the 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
      • + "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
      • - +
    - +

    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:
    + In + this version:
    - + - You may - download the Beta from:
    + 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/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.
    +

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

    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
    - -

    - - Brown Paper Bag - - 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.

    + +

    10/9/2002 - Shorewall 1.3.9b

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

    9/16/2002 - Shorewall 1.3.8

    + +

    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

    @@ -2138,758 +2255,879 @@ at Debian.
      -
    • 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).
      • +
    • DNS Names + are now allowed in Shorewall config files (although I recommend + against using them).
      • -
    • 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:
      • +
    • 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
    + +

    + + Brown Paper Bag + + 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 a policy for za to zb; + or
        • -
      • There is at least one rule for za to - zb.
        • +
      • 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).

    + (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.

    - +

    -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.

    + 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.

    + 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 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 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 released -

    +

    - +

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

    + 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.
      • +
    • 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 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.
      • +
    • 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
      • +
    • Shorewall now works with iptables 1.2.7
      • -
    • The documentation and web site no longer - uses FrontPage themes.
      • +
    • 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.

    + 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.

    - +

    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.

    + 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

    - +

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

    + 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:

    - +
      -
    • The latest The latest QuickStart Guides including the Shorewall Setup Guide.
      • -
    • Shorewall will now DROP TCP packets that - are not part of or related to an existing connection - and that are not SYN packets. These "New not SYN" - packets may be optionally logged by setting the LOGNEWNOTSYN - option in /etc/shorewall/shorewall.conf.
      • +
    • Shorewall will now DROP TCP packets + that are not part of or related to an existing + connection and that are not SYN packets. These "New + not SYN" packets may be optionally logged by setting + the LOGNEWNOTSYN option in /etc/shorewall/shorewall.conf.
      • -
    • The processing of "New not SYN" packets - may be extended by commands in the new newnotsyn extension script.
      • +
    • The processing of "New not SYN" packets + may be extended by commands in the new + newnotsyn extension + script.
      • - +
    - +

    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.

    + 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 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.

    - +

     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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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 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.
      • + 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.
      • +
    • 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!!!

    + 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.
      • +
    • 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 An /etc/shorewall/stopped extension script has been - added. This script is invoked after Shorewall - has stopped.
      • + 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.
      • +
    • 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 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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 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 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.
      • +
    • 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.

    + 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.

    - +

    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:

    - +
      -
    • Ignore robot.txt files.
      • +
    • Ignore robot.txt files.
      • -
    • Recursively copy everything that they find.
      • +
    • Recursively copy everything that they + find.
      • -
    • Should be classified as weapons rather -than tools.
      • +
    • 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.

    + 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. -

    + 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 - 1.3.1 samples.

    + 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:

    - +
      -
    • Corrects a serious problem with "all - <zone> CONTINUE" policies. This - problem is present in all versions of Shorewall that - support the CONTINUE policy. These previous versions - optimized away the "all2<zone>" - chain and replaced it with the "all2all" chain with the usual - result that a policy of REJECT was enforced rather than the -intended CONTINUE policy.
      • +
    • Corrects a serious problem with "all + <zone> CONTINUE" policies. + This problem is present in all versions of Shorewall + that support the CONTINUE policy. These previous + versions optimized away the "all2<zone>" + chain and replaced it with the "all2all" chain with +the usual result that a policy of REJECT was enforced rather + than the intended CONTINUE policy.
      • -
    • Adds an /etc/shorewall/rfc1918 - file for defining the exact behavior of theAdds an /etc/shorewall/rfc1918 + file for defining the exact behavior of the 'norfc1918' interface option.
      • - +
    - +

    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:

    - +
      -
    • 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:

    - +
      -
    • Support for the /etc/shorewall/whitelist - file has been withdrawn. If you need whitelisting, - see these - instructions.
      • +
    • 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:

    - +
      -
    • 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.
      • +
    • 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.
      • +
    • 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 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 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:

    + features:

    - +
      -
    • Simplified rule syntax which makes the - intent of each rule clearer and hopefully makes - Shorewall easier to learn.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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 .

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

    - +
      -
    • The 'try' command works again
      • +
    • The 'try' command works again
      • -
    • There is now a single RPM that also works - with SuSE.
      • +
    • 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.

    + 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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!

    + 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.

    - +

    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.

    + 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.

    + 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.

    + 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.

    - +

    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 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.

    + 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.

    + John.

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

    - + - +

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - +