diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index fd1bb25b3..839d5c6aa 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -2,3589 +2,3610 @@ - + - + - + 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 the 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 configuration -files.

- - -

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

- - -

Example:

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

Example (/etc/shorewall/interfaces record):

- -
	net $NET_IF $NET_BCAST $NET_OPTIONS
- -

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

- -
	net eth0 130.252.100.255 blacklist,norfc1918
- -

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

- - -

/etc/shorewall/zones

- - -

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

- - - - -

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

+

/etc/shorewall/params

+

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

+ + +

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

+ + +

Example:

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

Example (/etc/shorewall/interfaces record):

+ +
	net $NET_IF $NET_BCAST $NET_OPTIONS
+ +

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

+ +
	net eth0 130.252.100.255 blacklist,norfc1918
+ +

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

+ + +

/etc/shorewall/zones

+ + +

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

+ + + + + +

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

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

You may add, delete and modify entries in the /etc/shorewall/zones file + +

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 + 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 + 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 each of your interfaces. + +

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

- + - +

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

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

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

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

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

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

+ +

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

- -
- + +
+ - - - - - - - - - - + + + + + + + + + + - - - + + + - - - + + + +
ZONE INTERFACE BROADCAST OPTIONS
loceth1
ZONE INTERFACE BROADCAST OPTIONS
netppp0192.168.1.255,192.168.12.255
-

+

+
-
+
- -

/etc/shorewall/hosts + +

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

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

+ +

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

- -

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

+ +

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

- +

Columns in this file are:

- + - -
+ +
- +
    -
  1. An IP address (example +
  2. An IP address (example - eth1:192.168.1.3)
  3. -
  4. A subnet in CIDR notation +
  5. A subnet in CIDR notation (example - eth2:192.168.2.0/24)
  6. - +
- +

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

-
+
+ + + + + +
+

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:

+ + +

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

+ + -
- - -

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:

- - -

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

- - - - -

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

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

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

- - - -

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

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

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

- - - -

Nested and Overlapping -Zones

- - - -

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

- - - -

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

- - - -

- /etc/shorewall/policy Configuration.

- + +
-

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

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

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

- - - -

Four policies are defined:

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

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

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

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

+ + + +

Nested and Overlapping Zones

+ + + +

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

+ + + +

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

+ + + +

+ /etc/shorewall/policy Configuration.

+ + +

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

+ + + +

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

+ + + +

Four policies are defined:

+ + + + + + +

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 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. -
  3. DEST - - The name of a destination zone (a zone defined in the 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.
  4. + href="#Conf">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. POLICY - - The default policy for connection requests from the SOURCE - zone to the DESTINATION zone.
  6. +
  7. POLICY + - The default policy for connection requests from the SOURCE + zone to the DESTINATION zone.
  8. -
  9. LOG -LEVEL - Optional. If left empty, no log message is generated -when the policy is applied. Otherwise, this column should contain +
  10. 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.
  11. -
  12. 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.
  13. +
  14. 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.
  15. - +
- -

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

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

+
netallDROPinfo
+
allallREJECTinfo
+
-
+ + + + +

This table may be interpreted as follows:

+ + + -

- The CONTINUE policy

+

WARNING:

-

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

-

/etc/shorewall/zones:

- - -
- +
+ - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - +
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT
+

+
netallDROPinfo
+
loclocREJECTinfo
+
-
+
-

/etc/shorewall/interfaces:

+

+ 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 INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
-
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
-
+ -

/etc/shorewall/hosts:

+

/etc/shorewall/interfaces:

-
- +
+ - + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + - - + +
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0
-
sameth0:206.191.149.197
-
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
+
-
+
-

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

-

/etc/shorewall/policy:

- - -
- +
+ - + - - - - - - - - - - - - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + - + - +
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT
-
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0
+
samallCONTINUE
-
netallDROPinfo
allallREJECTinfo
sameth0:206.191.149.197
+
-
+
-

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

+

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.

-

Partial /etc/shorewall/rules:

+

/etc/shorewall/policy:

-
- + face="Century Gothic, Arial, Helvetica"> + - + - - - - - - - - + + + + + + + + + + + + - - - - - - - - - - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + - + - +
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT
+
...
-

-

-

-

-

-
samallCONTINUE
+
DNATsamloc:192.168.1.3tcpssh-
-
DNATnetloc:192.168.1.5tcpwww-
-
...
-

-

-

-

-

-
netallDROPinfo
allallREJECTinfo
-
+ -

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.

+

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

- -

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:

+ +

Partial /etc/shorewall/rules:

- -
- -

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

- - - -

- /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 such traffic will generate - a warning and will be ignored.
-

- - - -

Entries in the file have the following columns:

- -
+ + +

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 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 + 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
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
DNATnetloc:192.168.1.3tcpssh
-

-
-
- - -

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

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

-
DNATnetloc:192.168.1.3tcpssh
+

+
-
+ - -

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

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

-
REDIRECTloc3128tcpwww -
+
!206.124.146.177
ACCEPTfwnettcpwww
+

+
-
+
- -

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

+ +

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
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
ACCEPTnetdmz:155.186.235.222tcpwww-
+
ACCEPTlocdmz:155.186.235.222tcpwww
+

+
-
+ + + +

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

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

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

+ + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
DNATnetdmz:192.168.2.2tcpftp
+

+
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
+
-
+

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

- + + +
+ + +

passive ports 0.0.0.0/0 65500 65534

-
+
- -

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

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

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.

+ +

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

- +
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - + + + + + + + + + - - - - - - - - - - + + + + + + + + + + - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)
SOURCE
- PORT(S)
ORIGINAL
- DEST
ACTIONSOURCEDEST PROTODEST
+ PORT(S)
SOURCE
+ PORT(S)
ORIGINAL
+ DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-

-

-
ACCEPTloc:~02-00-08-E3-FA-55dmzall
+

+

+
-
- - - Example - 6. You wish to allow access to the SMTP server in your DMZ from - all zones.
- -
- - - - - - - - - - - - - - - - - - - - - - - + - +
ACTION
-
SOURCE
-
DEST
-
PROTO
-
DEST
- PORT(S)
-
SOURCE
- PORT(S)
-
ORIGINAL
- DEST
-
ACCEPT
-
all
-
dmz
-
tcp
-
25
-

-

-
-
- Note: When 'all' is used as a source or destination, -intra-zone traffic is not affected. In this example, if there were -two DMZ interfaces then the above rule would NOT enable SMTP traffic -between hosts on these interfaces.
-
- Example 7 (For advanced users running Shorewall version - 1.3.13 or later). From the internet, you with to forward tcp port - 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in -your DMZ. You also want to allow access from the internet directly to -tcp port 25 on 192.0.2.177.
- -
+
+ + + 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
-
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
+
ACCEPT
+
all
+
dmz
+
tcp
+
25
+

+

+
-
- Using "DNAT-" rather than "DNAT" avoids two extra copies +
+ Note: When 'all' is used as a source or destination, + intra-zone traffic is not affected. In this example, if there were + two DMZ interfaces then the above rule would NOT enable SMTP traffic + between hosts on these interfaces.
+ + Example 7 (For advanced users running Shorewall version + 1.3.13 or later). From the internet, you with to forward tcp port + 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in +your DMZ. You also want to allow access from the internet directly to +tcp port 25 on 192.0.2.177.
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTION
+
SOURCE
+
DEST
+
PROTO
+
DEST
+ PORT(S)
+
SOURCE
+ PORT(S)
+
ORIGINAL
+ DEST
+
DNAT-
+
net
+
dmz:192.0.2.177
+
tcp
+
25
+
0
+
192.0.2.178
+
DNAT-
+
net
+
dmz:192.0.2.177
+
tcp
+
25
+
0
+
192.0.2.179
+
ACCEPT
+
net
+
dmz:192.0.2.177
+
tcp
+
25
+

+

+
+
+ Using "DNAT-" rather than "DNAT" avoids two extra copies of the third rule from being generated.
- -

Look here for information on other services. -

- - - - -

- /etc/shorewall/common

+ +

Look here for information on other services. +

-

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.

+

+ /etc/shorewall/common

- -

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.

+ +

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.

- -

- /etc/shorewall/masq

+ +

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

+ /etc/shorewall/masq

+ + + + +

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

- +

Columns are:

- + - -

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

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

- -

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

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

Example 4: - Same as example 3 - except that you wish - 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 - look at - - http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - - If you decide to use - the technique - described in that - HOWTO, you can set - the proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by - including the - proxyarp option - in the interface's - record in - - /etc/shorewall/interfaces. - When using -Proxy ARP - sub-netting, you do - NOT include - any entries in - /etc/shorewall/proxyarp.

- - - - -

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:

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

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

- - - -

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

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
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24
+
-
+ - -

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.

+ + +

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

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

Example 4: + Same as example 3 + except that you wish + 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 + look at + + http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. + + If you decide to use + the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by + including the + proxyarp option + in the interface's + record in + + /etc/shorewall/interfaces. + When using Proxy + ARP sub-netting, + you do NOT + include + any entries in + /etc/shorewall/proxyarp.

+ + + + +

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:

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

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

-

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 +

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

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

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

- +

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:

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

Look here for additional information and an example. - -

+ +

Look here for additional information and an example. + +

- -

- /etc/shorewall/tunnels

+ +

+ /etc/shorewall/tunnels

- -

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

+ +

The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, + OpenVPN and PPTP + tunnels with end-points on your firewall. To use ipsec, you must + install version 1.9, 1.91 or the current 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 + +

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

Instructions for setting up IPSEC tunnels may + be found here, instructions for IPIP and GRE tunnels are here, instructions for OpenVPN tunnels are here, and + href="OPENVPN.html">instructions for OpenVPN tunnels are here, and instructions for PPTP tunnels are here.

- +

/etc/shorewall/shorewall.conf

- +

This file is used to set the following firewall parameters:

- +
    -
  • 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 +
  • 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, + 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 +
  • +
  • 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="") + 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 +
  • 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, + href="MAC_Validation.html">MAC Verification. The value must be a valid + syslogd log level. If you don't want to log these connection requests, set to the empty value (e.g., MACLIST_LOG_LEVEL="").
    -
  • -
  • NEWNOTSYN - Added in Version 1.3.8
    - When set to "Yes" or "yes", Shorewall will filter - TCP packets that are not part of an established connention and - that are not SYN packets (SYN flag on - ACK flag off). If set to -"No", Shorewall will silently drop such packets. If not set or -set to the empty value (e.g., "NEWNOTSYN="), NEWNOTSYN=No is assumed.
    -
    - If you have a HA setup with failover to another - firewall, you should have NEWNOTSYN=Yes on both firewalls. You - should also select NEWNOTSYN=Yes if you have asymmetric routing.
    -
  • -
  • LOGNEWNOTSYN - Added in Version 1.3.6
    - Beginning with version 1.3.6, Shorewall drops - non-SYN TCP packets that are not part of an existing connection. - If you would like to log these packets, set LOGNEWNOTSYN to - the syslog level at which you - want the packets logged. Example: LOGNEWNOTSYN=ULOG|
    +
  • +
  • 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.

    - Note: Packets logged under this option - are usually the result of broken remote IP stacks rather -than the result of any sort of attempt to breach your firewall.
  • -
  • DETECT_DNAT_ADDRS - - Added in Version 1.3.4
    - If set to "Yes" or "yes", Shorewall will detect the IP address(es) - of the interface(es) to the source zone and will include this (these) - address(es) in DNAT rules as the original destination IP address. - If set to "No" or "no", Shorewall will not detect this (these) address(es) - and any destination IP address will match the DNAT rule. If not specified - or empty, "DETECT_DNAT_ADDRS=Yes" is assumed.
    + 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.
  • -
  • MULTIPORT - Added in Version - 1.3.2
    - If set to "Yes" or "yes", Shorewall will -use the Netfilter multiport facility. In order to use this -facility, your kernel must have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). - When this support is used, Shorewall will generate a single - rule from each record in the /etc/shorewall/rules file that +
  • LOGNEWNOTSYN - Added in Version +1.3.6
    + Beginning with version 1.3.6, Shorewall +drops non-SYN TCP packets that are not part of an existing +connection. If you would like to log these packets, set LOGNEWNOTSYN +to the syslog level at which +you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
    +
    + Note: Packets logged under this option + are usually the result of broken remote IP stacks rather + than the result of any sort of attempt to breach your firewall.
  • +
  • DETECT_DNAT_ADDRS + - Added in Version 1.3.4
    + If set to "Yes" or "yes", Shorewall will detect the IP address(es) + of the interface(es) to the source zone and will include this (these) + address(es) in DNAT rules as the original destination IP address. + If set to "No" or "no", Shorewall will not detect this (these) address(es) + and any destination IP address will match the DNAT rule. If not +specified or empty, "DETECT_DNAT_ADDRS=Yes" is assumed.
    +
  • +
  • MULTIPORT - Added in Version + 1.3.2
    + If set to "Yes" or "yes", Shorewall will +use the Netfilter multiport facility. In order to use this +facility, your kernel must have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). + When this support is used, Shorewall will generate a single + rule from each record in the /etc/shorewall/rules file that meets these criteria:
    - +
      -
    • No port range(s) specified
    • -
    • Specifies 15 or fewer ports
    • +
    • No port range(s) specified
    • +
    • Specifies 15 or fewer ports
    • - +
    - -

    Rules not meeting those criteria will continue to generate an individual + +

    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
    +
  • +
  • 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 +
    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
    +
  • MODULESDIR
    + This parameter specifies the directory + where your kernel netfilter modules may be found. If you + leave the variable empty, Shorewall will supply the value + "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
  • +
  • LOGRATE and LOGBURST
    + These parameters set the match rate + and initial burst size for logged packets. Please see the + iptables man page for a description of the behavior of these + parameters (the iptables option --limit is set by LOGRATE and + --limit-burst is set by LOGBURST). If both parameters are set + empty, no rate-limiting will occur.
    +
    + Example:
    + LOGRATE=10/minute
    + LOGBURST=5
    +
  • +
  • LOGFILE
    - This parameter - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when - processing - the - "show - log", -"monitor", - "status" - and - "hits" - commands. If - not assigned - or if assigned - an empty - value, - /var/log/messages - is assumed.
  • -
  • NAT_ENABLED
    - This parameter determines whether Shorewall - supports NAT operations. NAT operations include:
    -
    - Static NAT
    - Port Forwarding
    - Port Redirection
    - Masquerading
    -
    - If the parameter has no value or has - a value of "Yes" or "yes" then NAT is enabled. If the parameter + This parameter + tells the + /sbin/shorewall + program where + to look for + Shorewall + messages when + processing + the + "show + log", + "monitor", + "status" + and + "hits" + commands. If + not assigned + or if assigned + an empty + value, + /var/log/messages + is +assumed.
  • +
  • NAT_ENABLED
    + This parameter determines whether +Shorewall supports NAT operations. NAT operations include:
    +
    + Static NAT
    + Port Forwarding
    + Port Redirection
    + Masquerading
    +
    + If the parameter has no value or has + a value of "Yes" or "yes" then NAT is enabled. If the parameter has a value of "no" or "No" then NAT is disabled.
    -
  • -
  • MANGLE_ENABLED
    - This parameter determines if packet -mangling is enabled. If the parameter has no value or has -a value of "Yes" or "yes" than packet mangling is enabled. -If the parameter has a value of "no" or "No" then packet mangling - is disabled. If packet mangling is disabled, the /etc/shorewall/tos +
  • +
  • MANGLE_ENABLED
    + This parameter determines if packet + mangling is enabled. If the parameter has no value or +has a value of "Yes" or "yes" than packet mangling is enabled. + If the parameter has a value of "no" or "No" then packet mangling + is disabled. If packet mangling is disabled, the /etc/shorewall/tos file is ignored.
    -
  • -
  • IP_FORWARDING
    - This parameter determines whether Shorewall - enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). - Possible values are:
    -
    - On or on - packet forwarding will - be enabled.
    - Off or off - packet forwarding +
  • +
  • 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.
    + Keep or keep - Shorewall will +neither enable nor disable packet forwarding.
    +
    + If this variable is not set or is +given an empty value (IP_FORWARD="") then IP_FORWARD=On +is assumed.
    +
  • +
  • ADD_IP_ALIASES
    + This parameter determines whether Shorewall + automatically adds the + external address(es) in + /etc/shorewall/nat . If the variable + is set to "Yes" or "yes" then Shorewall automatically adds + these aliases. If it is set to "No" or "no", you must add these + aliases yourself using your distribution's network configuration + tools.

    If this variable is not set or is given - an empty value (IP_FORWARD="") then IP_FORWARD=On is -assumed.
    -
  • -
  • ADD_IP_ALIASES
    - This parameter determines whether Shorewall - automatically adds the - external address(es) in - /etc/shorewall/nat . If the variable - is set to "Yes" or "yes" then Shorewall automatically adds - these aliases. If it is set to "No" or "no", you must add these - aliases yourself using your distribution's network configuration - tools.
    -
    - If this variable is not set or is given - an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes - is assumed.
  • -
  • ADD_SNAT_ALIASES
    - This parameter determines whether Shorewall - automatically adds the SNAT ADDRESS in /etc/shorewall/masq. If the variable is set -to "Yes" or "yes" then Shorewall automatically adds these addresses. -If it is set to "No" or "no", you must add these addresses yourself -using your distribution's network configuration tools.
    -
    - If this variable is not set or is given - an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No - is assumed.
    -
  • -
  • LOGUNCLEAN
    + an empty value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes + is assumed.
  • +
  • ADD_SNAT_ALIASES
    + This parameter determines whether Shorewall + automatically adds the SNAT ADDRESS in /etc/shorewall/masq. If the variable is +set to "Yes" or "yes" then Shorewall automatically adds these +addresses. If it is set to "No" or "no", you must add these addresses + yourself using your distribution's network configuration tools.
    +
    + If this variable is not set or is given + an empty value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No + is assumed.
    +
  • +
  • LOGUNCLEAN
    - 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 + 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 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). + 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
    -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".
  • - + This parameter + enables the + TCP Clamp MSS + to PMTU + feature of + Netfilter and + is usually + required when + your internet + connection + is + through PPPoE + or PPTP. If + set to + "Yes" + or + "yes", + the feature is + enabled. If + left blank or + set to + "No" + or + "no", + the feature is + not enabled. + Note: + This + option + requires + CONFIG_IP_NF_TARGET_TCPMSS + in + your kernel. +
  • ROUTE_FILTER
    + If this parameter is given the value "Yes" + or "yes" then route filtering (anti-spoofing) is enabled + on all network interfaces. The default value is "no".
  • +
- -

- /etc/shorewall/modules Configuration

+ +

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

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; if so, then the following command -is executed:

+ +

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:

+ +

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

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 +

+ /etc/shorewall/tos Configuration

+ + + + +

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

- +

Entries in the file have the following columns:

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

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

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

+
-
- -

The /etc/shorewall/tos file that is included with Shorewall contains + +

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

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

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

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

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

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

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

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

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

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

Updated 2/18/2003 - Tom Eastep -

+

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

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

Updated 2/24/2003 - Tom Eastep +

- +

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

+

+



diff --git a/Shorewall-docs/Install.htm b/Shorewall-docs/Install.htm index 9438668ed..da5e76434 100644 --- a/Shorewall-docs/Install.htm +++ b/Shorewall-docs/Install.htm @@ -1,220 +1,188 @@ - + Shorewall Installation - + - + - + - - - + + - - - + + + +
-

Shorewall Installation and +

+

Shorewall Installation and Upgrade

-
- +

Before upgrading, be sure to review the Upgrade Issues

- +

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

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

+

To install Shorewall using the RPM:

- -

If you have RedHat 7.2 and are running iptables version 1.2.3 (at a - shell prompt, type "/sbin/iptables --version"), you must upgrade to version + +

If you have RedHat 7.2 and are running iptables version 1.2.3 (at a + shell prompt, type "/sbin/iptables --version"), you must upgrade to version 1.2.4 either from the RedHat update - site or from the Shorewall Errata page before + href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update + site or from the Shorewall Errata page before attempting to start Shorewall.

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

To install Shorewall using the tarball + +

To install Shorewall using the tarball and install script:

- + - -

To install my version of Shorewall on a fresh Bering -disk, simply replace the "shorwall.lrp" file on the image with the file that -you downloaded. See the two-interface QuickStart + +

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

-

If you already have the Shorewall RPM installed + +

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

- -

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

- + +

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

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

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

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

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

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

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

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

- -

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

- + +

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

+ +

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

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

Configuring Shorewall

- -

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

- + +

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

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

Updated 1/30/2003 - Tom Eastep +

Updated 1/24/2003 - Tom Eastep

- +

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

-
+
+


diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 891e46fa6..f5d18a42e 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -3,7 +3,7 @@ - + Shorewall News @@ -11,612 +11,592 @@ - + - + - + - - - + + - + + - - + +
+
- +

Shorewall News Archive

-
- +

3/14/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.
+ 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 +
+ IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package ('ip' utility).
-
- Function from 1.3 that has been omitted from this version include:
- +
+ 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. -
  3. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
    -
    -
  4. -
  5. 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.
    -
    -
  6. -
  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. -
  9. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer - accepted.
    -
    -
  10. -
  11. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    -
    -
  12. -
  13. The icmp.def file has been removed.
    -
  14. - -
- Changes for 1.4 include:
- -
    -
  1. The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
    -
    -
  2. -
  3. LOG is now a valid action for a rule (/etc/shorewall/rules).
    -
    -
  4. -
  5. The firewall script and version file are now installed in /usr/share/shorewall.
    -
    -
  6. -
  7. Late arriving DNS replies are now silently dropped in the common -chain by default.
    -
    -
  8. -
  9. 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. -
  10. - -
- -

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. -
  3. 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
    -  
  4. -
  5. Support for OpenVPN Tunnels.
    -
    -
  6. -
  7. Support for VLAN devices with names of the form $DEV.$VID (e.g., - eth0.0)
    +
  8. The "check" command is no longer supported.
    +
    +
  9. +
  10. 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.

  11. -
  12. 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.
    -
    -
  13. -
  14. 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
    -
  15. - +
  16. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces + now generate an error.
    +
    +
  17. +
  18. 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.
    +
    +
  19. +
  20. 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.
    +
    +
  21. +
  22. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
    +
    +
  23. +
  24. The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    +
    +
  25. +
  26. The icmp.def file has been removed.
    +
  27. +
- -


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

- -

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

- -

Includes the Beta 2 content plus support for OpenVPN tunnels.

- -

1/28/2003 - Shorewall 1.3.14-Beta2

- -

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

- -

1/25/2003 - Shorewall 1.3.14-Beta1
-

- -

The Beta includes the following changes:
-

- + Changes for 1.4 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. -
  3. 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
    -  
  4. -
  5. When an interface name is entered in the SUBNET column -of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic - from only the first subnet defined on that interface. It did not masquerade - traffic from:
    -  
    -    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
    -
  6. - +
  7. The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
    +
    +
  8. +
  9. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
  10. +
  11. The firewall script and version file are now installed in /usr/share/shorewall.
    +
    +
  12. +
  13. Late arriving DNS replies are now silently dropped in the common + chain by default.
    +
    +
  14. +
  15. 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. +
  16. +
+ +

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. +
  3. 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
    +  
  4. +
  5. Support for OpenVPN Tunnels.
    +
    +
  6. +
  7. Support for VLAN devices with names of the form $DEV.$VID (e.g., + eth0.0)
    +
    +
  8. +
  9. 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.
    +
    +
  10. +
  11. 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
    +
  12. + +
+ +


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

+ +

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

+ +

Includes the Beta 2 content plus support for OpenVPN tunnels.

+ +

1/28/2003 - Shorewall 1.3.14-Beta2

+

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

+ +

1/25/2003 - Shorewall 1.3.14-Beta1
+

+ +

The Beta includes the following changes:
+

+ +
    +
  1. An OLD_PING_HANDLING option has been added to shorewall.conf. + When set to Yes, Shorewall ping handling is as it has always been (see + http://www.shorewall.net/ping.html).
    +
    + When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules + and policies just like any other connection request. The FORWARDPING=Yes + option in shorewall.conf and the 'noping' and 'filterping' options in + /etc/shorewall/interfaces will all generate an error.
    +
    +
  2. +
  3. 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
    +  
  4. +
  5. When an interface name is entered in the SUBNET column +of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic + from only the first subnet defined on that interface. It did not masquerade + traffic from:
    +  
    +    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
    +
  6. + +
+

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

- -

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation. + +

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

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

1/17/2003 - shorewall.net has MOVED 

- +

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

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

+

1/13/2003 - Shorewall 1.3.13
-

- +

+

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

- +

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

1/6/2003 - BURNOUT -

- -

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

- + +

1/6/2003 - BURNOUT +

+ +

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

+

-Tom Eastep
-

- +

+

12/30/2002 - Shorewall Documentation in PDF Format

- -

Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. + +

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

- +

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

- +

+

12/27/2002 - Shorewall 1.3.12 Released

- +

Features include:
-

- +

+
    -
  1. "shorewall refresh" now reloads the traffic shaping +
  2. "shorewall refresh" now reloads the traffic shaping rules (tcrules and tcstart).
  3. -
  4. "shorewall debug [re]start" now turns off debugging - after an error occurs. This places the point of the failure near +
  5. "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.
  6. -
  7. "shorewall [re]start" has been speeded up by more +
  8. "shorewall [re]start" has been speeded up by more than 40% with my configuration. Your milage may vary.
  9. -
  10. 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 +
  11. 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"
  12. -
  13. 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) +
  14. 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.
  15. -
  16. 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 +
  17. 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.
  18. -
  19. 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.
  20. -
  21. 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.
    -
  22. - +
  23. 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.
  24. +
  25. 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.
    +
  26. +
- +

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

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

+ Features include:
+
    -
  1. "shorewall refresh" now reloads the traffic -shaping rules (tcrules and tcstart).
  2. -
  3. "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.
  4. -
  5. "shorewall [re]start" has been speeded up by - more than 40% with my configuration. Your milage may vary.
  6. -
  7. 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"
  8. -
  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 +
  10. "shorewall refresh" now reloads the traffic + shaping rules (tcrules and tcstart).
  11. +
  12. "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.
  13. +
  14. "shorewall [re]start" has been speeded up +by more than 40% with my configuration. Your milage may vary.
  15. +
  16. 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"
  17. +
  18. 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) + href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file.
  19. -
  20. 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 +
  21. 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.
  22. -
  23. 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 +
  24. 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.
  25. - +
- 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 - Multi - Network Firewall (MNF) product. Here is the press +

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

12/7/2002 - Shorewall Support for Mandrake 9.0

- -

Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. - I have installed 9.0 on one of my systems and I am now in a + +

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

- +

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

- - -

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

- -

12/3/2002 - Shorewall 1.3.11a

- -

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

- -

11/24/2002 - Shorewall 1.3.11

- -

In this version:

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

11/14/2002 - Shorewall Documentation in PDF Format

- -

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

- -

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

- -

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

- - -

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

- - -

11/09/2002 - Shorewall 1.3.10

- -

In this version:

- - - -

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

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

10/23/2002 - Shorewall 1.3.10 Beta 1

- In this version:
+

+

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

+ +

12/3/2002 - Shorewall 1.3.11a

+ +

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

+ +

11/24/2002 - Shorewall 1.3.11

+ +

In this version:

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

11/14/2002 - Shorewall Documentation in PDF Format

+ +

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

+ +

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

+ +

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

+ + +

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

+ + +

11/09/2002 - Shorewall 1.3.10

+ +

In this version:

+
  • You may now define the contents of a zone dynamically - with the "shorewall add" -and "shorewall delete" commands. These commands are expected - to be used primarily within 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.
  • +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.
  • + href="MAC_Validation.html"> 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.
  • @@ -626,95 +606,161 @@ 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.
  • - -
- 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/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!
-

9/28/2002 - Shorewall 1.3.9

+

10/23/2002 - Shorewall 1.3.10 Beta 1

+ In this version:
- -

In this version:
-

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

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

- + +

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

+ +

10/9/2002 - Shorewall 1.3.9b

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

10/6/2002 - Shorewall.net now running on RH8.0
+

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

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

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

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

9/28/2002 - Shorewall 1.3.9

+ + +

In this version:
+

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

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

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

+ Brown Paper Bag - A couple of recent configuration - changes at www.shorewall.net broke the Search facility:
+ A couple of recent configuration + changes at www.shorewall.net broke the Search facility:
- -
+ +
- +
    +
  1. Mailing List Archive +Search was not available.
  2. +
  3. The Site Search index + was incomplete
  4. +
  5. Only one page of matches + was presented.
  6. + + + +
+
+ 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. The Site Search index @@ -722,1812 +768,1791 @@ was incomplete
  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. -
  3. The Site Search index -was incomplete
  4. -
  5. Only one page of matches - was presented.
  6. - - +
- Hopefully these problems are -now corrected.
- - -

9/18/2002 -  Debian 1.3.8 Packages Available
-

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

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

- +

8/31/2002 - I'm not available

- -

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

+ +

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

- +

-Tom

- +

8/26/2002 - Shorewall 1.3.7b

- -

This is a role up of the "shorewall refresh" bug fix and the change which + +

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

- +

8/26/2002 - French FTP Mirror is Operational

- +

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

- +

8/25/2002 - Shorewall Mirror in France

- -

Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored + +

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

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

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

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

- +

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

- +

Features in this release include:

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

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

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

- +

8/13/2002 - Documentation in the CVS Repository

- -

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

+ +

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

- +

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

- -

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

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

- -

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

+ +

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

- -

Now there is one place to go to look for issues involved with upgrading + +

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

- +

8/7/2002 - Shorewall 1.3.6

- +

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

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

    - + +
  • Includes the latest + QuickStart Guides.
  • + + +

    7/29/2002 - New Shorewall Setup Guide Available

    - +

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

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

    - +

    7/28/2002 - Shorewall 1.3.5 Debian Package Available

    - -

    Lorenzo Martignoni reports that the packages are version 1.3.5a and are + +

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

    - +

    7/27/2002 - Shorewall 1.3.5a Released

    - +

    This interim release restores correct handling of REDIRECT rules.

    - +

    7/26/2002 - Shorewall 1.3.5 Released

    - -

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

    + +

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

    - +

     In this version:

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

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

    - +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

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

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

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

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

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

    6/25/2002 - Samples Updated for 1.3.2

    - -

    The comments in the sample configuration files have been updated to reflect + +

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

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

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

    + +

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

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + +
  • A logwatch command has +been added to /sbin/shorewall.
  • +
  • A dynamic blacklist facility + has been added.
  • +
  • Support for the + Netfilter multiport match +function has been added.
  • +
  • The files firewall, + functions and version have been +moved from /etc/shorewall to /var/lib/shorewall.
  • + + +

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

    - -

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

    + +

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

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

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

    + +

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

    - -

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

    + +

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

    - +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/2/2002 - Samples Corrected

    - -

    The 1.3.0 samples configurations had several serious problems that prevented - DNS and SSH from working properly. These problems + +

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

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

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

    + +

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

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

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

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

    + +

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

    - +
      -
    • Support for the /etc/shorewall/whitelist - file has been withdrawn. 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:

    + +

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

    - + - +

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

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

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

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

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + - +

    4/30/2002 - Shorewall Debian News

    - -

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

    + +

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

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

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

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - +
      -
    • Shorewall 1.2.10 +
    • Shorewall 1.2.10 is in the Debian - Testing Branch
    • -
    • Shorewall 1.2.11 + href="http://packages.debian.org/testing/net/shorewall.html">Debian + Testing Branch
    • +
    • Shorewall 1.2.11 is in the Debian - Unstable Branch
    • - - -
    + href="http://packages.debian.org/unstable/net/shorewall.html">Debian + Unstable Branch + + +

    Thanks, Lorenzo!

    - +

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

    - -

    Thanks to Stefan Mohr, there + +

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

    + href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm"> + SuSE RPM available.

    - +

    4/13/2002 - Shorewall 1.2.11 Available

    - +

    In this version:

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

    4/13/2002 - Hamburg Mirror now has FTP

    - +

    Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.  + href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall.  Thanks Stefan!

    - +

    4/12/2002 - New Mirror in Hamburg

    - -

    Thanks to Stefan Mohr, there + +

    Thanks to Stefan Mohr, there is now a mirror of the Shorewall website at http://germany.shorewall.net. + target="_top" href="http://germany.shorewall.net"> 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. + +

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

    - +

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

    - -

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

    + +

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

    - +

    4/8/2002 - Parameterized Samples Withdrawn

    - +

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

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

    - +

    4/2/2002 - Updated Log Parser

    - -

    John Lodge has provided an updated + +

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

    + href="pub/shorewall/parsefw/">CGI-based log parser + with corrected date handling.

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - -

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

    + +

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

    - +

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

    - + +
  • Shorewall 1.2.9 +is now in the Debian + Unstable Distribution.
  • + + +

    3/25/2002 - Log Parser Available

    - +

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

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

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

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - + - - -

    3/1/2002 - 1.2.8 Debian Package is Available

    - - -

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

    - - -

    2/25/2002 - New Two-interface Sample

    - - -

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

    - -

    2/23/2002 - Shorewall 1.2.8 Released

    - - -

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

    - - -

    2/22/2002 - Shorewall 1.2.7 Released

    - - -

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    - - -

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

    - - -

    2/8/2002 - Shorewall 1.2.6 Released

    - - -

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - - -

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

    - - -

    2/1/2002 - Shorewall 1.2.5 Released

    - - -

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

    - - -

    In version 1.2.5:

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

    1/28/2002 - Shorewall 1.2.4 Released

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

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

    - - -

    1/20/2002 - Corrected firewall script available 

    - - -

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

    - - -

    1/19/2002 - Shorewall 1.2.3 Released

    - - -

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

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

    The following problems were corrected:

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

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

    - - -

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

    - - -

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

    - - -

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

    - - -

    1/8/2002 - Shorewall 1.2.2 Released

    - - -

    In version 1.2.2

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

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

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

    See the README file for upgrade instructions.

    - - -

    1/1/2002 - Shorewall Mailing List Moving

    - - -

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

    - - -

    12/31/2001 - Shorewall 1.2.1 Released

    - - -

    In version 1.2.1:

    - - - - - -

    12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist -releasing 1.2 on 12/21/2001

    - - -

    Version 1.2 contains the following new features:

    - - - - - -

    For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current version 1.1.x - users will not be forced into a quick upgrade to 1.2.0 -just to have access to bug fixes.

    - - -

    For those of you who have installed one of the Beta RPMS, you will need - to use the "--oldpackage" option when upgrading -to 1.2.0:

    - - -
    - - -

    rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

    -
    - - -

    12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror in Texas. - This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

    - - -

    11/30/2001 - A new set of the parameterized Sample - Configurations has been released. In this version:

    - - -
      -
    • Ping is now allowed - between the zones.
    • -
    • In the three-interface - configuration, it is now possible to configure the - internet services that are to be available to servers in the - DMZ. 
    • - - -
    - - -

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    - - -

    In this version:

    - - -
      -
    • The spelling of ADD_IP_ALIASES - has been corrected in the shorewall.conf file
    • -
    • The logic for deleting - user-defined chains has been simplified so that it - avoids a bug in the LRP version of the 'cut' utility.
    • -
    • The /var/lib/lrpkg/shorwall.conf - file has been corrected to properly display the -NAT entry in that file.
    • - - -
    - - -

    11/19/2001 - Thanks to Juraj - Ontkanin, there is now a Shorewall mirror - in the Slovak Republic. The website is now mirrored - at http://www.nrg.sk/mirror/shorewall - and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

    - - -

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. - There are three sample configurations:

    - - -
      -
    • One Interface -- for - a standalone system.
    • -
    • Two Interfaces -- -A masquerading firewall.
    • -
    • Three Interfaces -- - A masquerading firewall with DMZ.
    • - -
    +

    3/1/2002 - 1.2.8 Debian Package is Available

    + + +

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

    + + +

    2/25/2002 - New Two-interface Sample

    + + +

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

    + + +

    2/23/2002 - Shorewall 1.2.8 Released

    + + +

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

    + + +

    2/22/2002 - Shorewall 1.2.7 Released

    + + +

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    + + +

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

    + + +

    2/8/2002 - Shorewall 1.2.6 Released

    + + +

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    + + +

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

    + + +

    2/1/2002 - Shorewall 1.2.5 Released

    + + +

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

    + + +

    In version 1.2.5:

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

    1/28/2002 - Shorewall 1.2.4 Released

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

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

    + + +

    1/20/2002 - Corrected firewall script available 

    + + +

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

    + + +

    1/19/2002 - Shorewall 1.2.3 Released

    + + +

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

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

    The following problems were corrected:

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

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

    + + +

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

    + + +

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

    + + +

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

    + + +

    1/8/2002 - Shorewall 1.2.2 Released

    + + +

    In version 1.2.2

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

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

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

    See the README file for upgrade instructions.

    + + +

    1/1/2002 - Shorewall Mailing List Moving

    + + +

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

    + + +

    12/31/2001 - Shorewall 1.2.1 Released

    + + +

    In version 1.2.1:

    + + + + + +

    12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing +1.2 on 12/21/2001

    + + +

    Version 1.2 contains the following new features:

    + + + + + +

    For the next month or so, I will continue to provide corrections to version + 1.1.18 as necessary so that current version 1.1.x + users will not be forced into a quick upgrade to 1.2.0 + just to have access to bug fixes.

    + + +

    For those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading to + 1.2.0:

    + + +
    + + +

    rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm

    +
    + + +

    12/19/2001 - Thanks to Steve + Cowles, there is now a Shorewall mirror in Texas. + This web site is mirrored at http://www.infohiiway.com/shorewall + and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

    + + +

    11/30/2001 - A new set of the parameterized Sample +Configurations has been released. In this version:

    + + +
      +
    • Ping is now allowed + between the zones.
    • +
    • In the three-interface + configuration, it is now possible to configure the + internet services that are to be available to servers in +the DMZ. 
    • + + +
    + + +

    11/20/2001 - The current version of Shorewall is 1.1.18. 

    + + +

    In this version:

    + + +
      +
    • The spelling of ADD_IP_ALIASES + has been corrected in the shorewall.conf file
    • +
    • The logic for deleting + user-defined chains has been simplified so that it + avoids a bug in the LRP version of the 'cut' utility.
    • +
    • The /var/lib/lrpkg/shorwall.conf + file has been corrected to properly display the + NAT entry in that file.
    • + + +
    + + +

    11/19/2001 - Thanks to Juraj + Ontkanin, there is now a Shorewall mirror + in the Slovak Republic. The website is now mirrored + at http://www.nrg.sk/mirror/shorewall + and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.

    + + +

    11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. + There are three sample configurations:

    + + +
      +
    • One Interface -- +for a standalone system.
    • +
    • Two Interfaces -- +A masquerading firewall.
    • +
    • Three Interfaces +-- A masquerading firewall with DMZ.
    • + + +
    + +

    Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 - . See the README file for instructions.

    + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17"> ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 + . See the README file for instructions.

    - -

    11/1/2001 - The current version of Shorewall is 1.1.17.  I intend - this to be the last of the 1.1 Shorewall releases.

    + +

    11/1/2001 - The current version of Shorewall is 1.1.17.  I intend + this to be the last of the 1.1 Shorewall +releases.

    - +

    In this version:

    - + - -

    10/22/2001 - The current version of Shorewall is 1.1.16. In this - version:

    + +

    10/22/2001 - The current version of Shorewall is 1.1.16. In this + version:

    - +
      -
    • A new "shorewall show - connections" command has been added.
    • -
    • In the "shorewall -monitor" output, the currently tracked connections +
    • A new "shorewall +show connections" command has been added.
    • +
    • In the "shorewall +monitor" output, the currently tracked connections are now shown on a separate page.
    • -
    • Prior to this release, - Shorewall unconditionally added the external IP - adddress(es) specified in /etc/shorewall/nat. Beginning -with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be - set to "no" (or "No") to inhibit this behavior. This - allows IP aliases created using your distribution's network - configuration tools to be used in static NAT. 
    • +
    • Prior to this release, + Shorewall unconditionally added the external IP + adddress(es) specified in /etc/shorewall/nat. Beginning + with version 1.1.16, a new parameter (ADD_IP_ALIASES) may be + set to "no" (or "No") to inhibit this behavior. + This allows IP aliases created using your distribution's + network configuration tools to be used in static +NAT. 
    • - +
    - -

    10/15/2001 - The current version of Shorewall is 1.1.15. In this - version:

    + +

    10/15/2001 - The current version of Shorewall is 1.1.15. In this + version:

    + + +
      +
    • Support for nested + zones has been improved. See the documentation for +details
    • +
    • Shorewall now correctly + checks the alternate configuration directory for + the 'zones' file.
    • + + +
    + + +

    10/4/2001 - The current version of Shorewall is 1.1.14. In this + version

      -
    • Support for nested -zones has been improved. See the documentation for details
    • -
    • Shorewall now correctly - checks the alternate configuration directory for - the 'zones' file.
    • - - -
    - - -

    10/4/2001 - The current version of Shorewall is 1.1.14. In this - version

    - - -
      -
    • Shorewall now supports - alternate configuration directories. When an alternate - directory is specified when starting or restarting Shorewall - (e.g., "shorewall -c /etc/testconf restart"), Shorewall - will first look for configuration files in the alternate directory - then in /etc/shorewall. To create an alternate configuration - simply:
      - 1. Create a New Directory
      - 2. Copy to that directory - any of your configuration files that you want to - change.
      - 3. Modify the copied -files as needed.
      - 4. Restart Shorewall -specifying the new directory.
    • -
    • The rules for allowing/disallowing - icmp echo-requests (pings) are now moved after -rules created when processing the rules file. This allows - you to add rules that selectively allow/deny ping based on -source or destination address.
    • -
    • Rules that specify -multiple client ip addresses or subnets no longer cause - startup failures.
    • -
    • Zone names in the +
    • Shorewall now supports + alternate configuration directories. When an +alternate directory is specified when starting or restarting + Shorewall (e.g., "shorewall -c /etc/testconf restart"), + Shorewall will first look for configuration files in the alternate + directory then in /etc/shorewall. To create an alternate +configuration simply:
      + 1. Create a New Directory
      + 2. Copy to that directory + any of your configuration files that you want to + change.
      + 3. Modify the copied + files as needed.
      + 4. Restart Shorewall + specifying the new directory.
    • +
    • The rules for allowing/disallowing + icmp echo-requests (pings) are now moved after + rules created when processing the rules file. This allows + you to add rules that selectively allow/deny ping based +on source or destination address.
    • +
    • Rules that specify + multiple client ip addresses or subnets no longer cause + startup failures.
    • +
    • Zone names in the policy file are now validated against the zones file.
    • -
    • If you have packet mangling support - enabled, the "norfc1918" - interface option now logs and drops any incoming packets - on the interface that have an RFC 1918 destination - address.
    • +
    • If you have packet mangling support + enabled, the "norfc1918" + interface option now logs and drops any incoming packets + on the interface that have an RFC 1918 destination + address.
    • - +
    - -

    9/12/2001 - The current version of Shorewall is 1.1.13. In this + +

    9/12/2001 - The current version of Shorewall is 1.1.13. In this version

    - + - -

    8/28/2001 - The current version of Shorewall is 1.1.12. In this + +

    8/28/2001 - The current version of Shorewall is 1.1.12. In this version

    - +
      -
    • Several columns in -the rules file may now contain comma-separated lists.
    • -
    • Shorewall is now more - rigorous in parsing the options in /etc/shorewall/interfaces.
    • -
    • Complementation using +
    • Several columns in + the rules file may now contain comma-separated lists.
    • +
    • Shorewall is now +more rigorous in parsing the options in /etc/shorewall/interfaces.
    • +
    • Complementation using "!" is now supported in rules.
    • - +
    - -

    7/28/2001 - The current version of Shorewall is 1.1.11. In this + +

    7/28/2001 - The current version of Shorewall is 1.1.11. In this version

    - +
      -
    • A "shorewall refresh" - command has been added to allow for refreshing the - rules associated with the broadcast address on a dynamic - interface. This command should be used in place of "shorewall +
    • A "shorewall refresh" + command has been added to allow for refreshing the + rules associated with the broadcast address on a dynamic + interface. This command should be used in place of "shorewall restart" when the internet interface's IP address changes.
    • -
    • The /etc/shorewall/start - file (if any) is now processed after all temporary - rules have been deleted. This change prevents the accidental - removal of rules added during the processing of that -file.
    • -
    • The "dhcp" interface - option is now applicable to firewall interfaces used - by a DHCP server running on the firewall.
    • -
    • The RPM can now be -built from the .tgz file using "rpm -tb" 
    • +
    • The /etc/shorewall/start + file (if any) is now processed after all temporary + rules have been deleted. This change prevents the accidental + removal of rules added during the processing of that + file.
    • +
    • The "dhcp" interface + option is now applicable to firewall interfaces used + by a DHCP server running on the firewall.
    • +
    • The RPM can now be + built from the .tgz file using "rpm -tb" 
    • - +
    - -

    7/6/2001 - The current version of Shorewall is 1.1.10. In this -version

    + +

    7/6/2001 - The current version of Shorewall is 1.1.10. In this version

    - +
      -
    • Shorewall now enables - Ipv4 Packet Forwarding by default. Packet forwarding - may be disabled by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf. - If you don't want Shorewall to enable or disable -packet forwarding, add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf - file.
    • -
    • The "shorewall hits" - command no longer lists extraneous service names -in its last report.
    • -
    • Erroneous instructions - in the comments at the head of the firewall script - have been corrected.
    • +
    • Shorewall now enables + Ipv4 Packet Forwarding by default. Packet forwarding + may be disabled by specifying IP_FORWARD=Off in /etc/shorewall/shorewall.conf. + If you don't want Shorewall to enable or disable packet + forwarding, add IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf + file.
    • +
    • The "shorewall hits" + command no longer lists extraneous service names + in its last report.
    • +
    • Erroneous instructions + in the comments at the head of the firewall script + have been corrected.
    • - +
    - -

    6/23/2001 - The current version of Shorewall is 1.1.9. In this -version

    + +

    6/23/2001 - The current version of Shorewall is 1.1.9. In this version

    - +
      -
    • The "tunnels" file - really is in the RPM now.
    • -
    • SNAT can now be applied +
    • The "tunnels" file + really is in the RPM now.
    • +
    • SNAT can now be applied to port-forwarded connections.
    • -
    • A bug which would -cause firewall start failures in some dhcp configurations +
    • A bug which would +cause firewall start failures in some dhcp configurations has been fixed.
    • -
    • The firewall script - now issues a message if you have the name of an - interface in the second column in an entry in /etc/shorewall/masq +
    • The firewall script + now issues a message if you have the name of an +interface in the second column in an entry in /etc/shorewall/masq and that interface is not up.
    • -
    • You can now configure - Shorewall so that it doesn't +
    • You can now configure + Shorewall so that it doesn't require the NAT and/or mangle netfilter modules.
    • -
    • Thanks to Alex  Polishchuk, +
    • Thanks to Alex  Polishchuk, the "hits" command from seawall is now in shorewall.
    • -
    • Support for Support for IPIP tunnels has been added.
    • - +
    - -

    6/18/2001 - The current version of Shorewall is 1.1.8. In this -version

    + +

    6/18/2001 - The current version of Shorewall is 1.1.8. In this version

    - + - +

    6/2/2001 - The current version of Shorewall is 1.1.7. In this version

    - +
      -
    • The TOS rules are +
    • The TOS rules are now deleted when the firewall is stopped.
    • -
    • The .rpm will now -install regardless of which version of iptables is - installed.
    • -
    • The .rpm will now +
    • The .rpm will now +install regardless of which version of iptables is + installed.
    • +
    • The .rpm will now install without iproute2 being installed.
    • -
    • The documentation +
    • The documentation has been cleaned up.
    • -
    • The sample configuration - files included in Shorewall have been formatted - to 80 columns for ease of editing on a VGA console.
    • +
    • The sample configuration + files included in Shorewall have been formatted + to 80 columns for ease of editing on a VGA console.
    • - +
    - -

    5/25/2001 - The current version of Shorewall is 1.1.6. In this -version

    + +

    5/25/2001 - The current version of Shorewall is 1.1.6. In this version

    - +
      -
    • You may now rate-limit the -packet log.
    • -
    • Previous versions - of Shorewall have an implementation of Static NAT which -violates the principle of least surprise.  NAT only occurs -for packets arriving at (DNAT) or send from (SNAT) the interface - named in the INTERFACE column of /etc/shorewall/nat. Beginning - with version 1.1.6, NAT effective regardless of which interface - packets come from or are destined to. To get compatibility with - prior versions, I have added a new "ALL "ALL INTERFACES"  column to /etc/shorewall/nat. - By placing "no" or "No" in the new column, the NAT behavior - of prior versions may be retained. 
    • -
    • The treatment of IPSEC Tunnels where the remote -gateway is a standalone system has been improved. Previously, - it was necessary to include an additional rule allowing UDP port -500 traffic to pass through the tunnel. Shorewall will now create - this rule automatically when you place the name of the remote peer's +
    • You may now rate-limit the + packet log.
    • +
    • Previous versions + of Shorewall have an implementation of Static NAT which + violates the principle of least surprise.  NAT only +occurs for packets arriving at (DNAT) or send from (SNAT) +the interface named in the INTERFACE column of /etc/shorewall/nat. +Beginning with version 1.1.6, NAT effective regardless of +which interface packets come from or are destined to. To get +compatibility with prior versions, I have added a new "ALL "ALL INTERFACES"  column to /etc/shorewall/nat. + By placing "no" or "No" in the new column, the NAT behavior + of prior versions may be retained. 
    • +
    • The treatment of + IPSEC Tunnels where the remote + gateway is a standalone system has been improved. Previously, + it was necessary to include an additional rule allowing UDP port +500 traffic to pass through the tunnel. Shorewall will now create + this rule automatically when you place the name of the remote peer's zone in a new GATEWAY ZONE column in /etc/shorewall/tunnels. 
    • - +
    - -

    5/20/2001 - The current version of Shorewall is 1.1.5. In this -version

    + +

    5/20/2001 - The current version of Shorewall is 1.1.5. In this version

    - + - -

    5/10/2001 - The current version of Shorewall is 1.1.4. In this -version

    + +

    5/10/2001 - The current version of Shorewall is 1.1.4. In this version

    - +
      -
    • Accepting RELATED connections - is now optional.
    • -
    • Corrected problem -where if "shorewall start" aborted early (due to -kernel configuration errors for example), superfluous 'sed' +
    • Accepting RELATED connections + is now optional.
    • +
    • Corrected problem +where if "shorewall start" aborted early (due to +kernel configuration errors for example), superfluous 'sed' error messages were reported.
    • -
    • Corrected rules generated +
    • Corrected rules generated for port redirection.
    • -
    • The order in which -iptables kernel modules are loaded has been corrected -(Thanks to Mark Pavlidis). 
    • +
    • The order in which + iptables kernel modules are loaded has been corrected + (Thanks to Mark Pavlidis). 
    • - +
    - -

    4/28/2001 - The current version of Shorewall is 1.1.3. In this -version

    + +

    4/28/2001 - The current version of Shorewall is 1.1.3. In this version

    - +
      -
    • Correct message issued - when Proxy ARP address added (Thanks to Jason Kirtland).
    • -
    • /tmp/shorewallpolicy-$$ - is now removed if there is an error while starting +
    • Correct message issued + when Proxy ARP address added (Thanks to Jason Kirtland).
    • +
    • /tmp/shorewallpolicy-$$ + is now removed if there is an error while starting the firewall.
    • -
    • /etc/shorewall/icmp.def - and /etc/shorewall/common.def are now used to define - the icmpdef and common chains unless overridden by the - presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
    • -
    • In the .lrp, the file - /var/lib/lrpkg/shorwall.conf has been corrected. -An extra space after "/etc/shorwall/policy" has been removed - and "/etc/shorwall/rules" has been added.
    • -
    • When a sub-shell encounters - a fatal error and has stopped the firewall, it now - kills the main shell so that the main shell will not - continue.
    • -
    • A problem has been -corrected where a sub-shell stopped the firewall -and main shell continued resulting in a perplexing error message - referring to "common.so" resulted.
    • -
    • Previously, placing - "-" in the PORT(S) column in /etc/shorewall/rules -resulted in an error message during start. This has been corrected.
    • -
    • The first line of -"install.sh" has been corrected -- I had inadvertently +
    • /etc/shorewall/icmp.def + and /etc/shorewall/common.def are now used to define + the icmpdef and common chains unless overridden by the + presence of /etc/shorewall/icmpdef or /etc/shorewall/common.
    • +
    • In the .lrp, the +file /var/lib/lrpkg/shorwall.conf has been corrected. + An extra space after "/etc/shorwall/policy" has been + removed and "/etc/shorwall/rules" has been added.
    • +
    • When a sub-shell +encounters a fatal error and has stopped the firewall, + it now kills the main shell so that the main shell will + not continue.
    • +
    • A problem has been + corrected where a sub-shell stopped the firewall + and main shell continued resulting in a perplexing error + message referring to "common.so" resulted.
    • +
    • Previously, placing + "-" in the PORT(S) column in /etc/shorewall/rules resulted + in an error message during start. This has been corrected.
    • +
    • The first line of +"install.sh" has been corrected -- I had inadvertently deleted the initial "#".
    • - +
    - -

    4/12/2001 - The current version of Shorewall is 1.1.2. In this -version

    + +

    4/12/2001 - The current version of Shorewall is 1.1.2. In this version

    - +
      -
    • Port redirection now - works again.
    • -
    • The icmpdef and common - chains may now be user-defined.
    • -
    • The firewall no longer - fails to start if "routefilter" is specified for -an interface that isn't started. A warning message is now - issued in this case.
    • -
    • The LRP Version is -renamed "shorwall" for 8,3 MSDOS file system compatibility.
    • -
    • A couple of LRP-specific - problems were corrected.
    • - - -
    +
  • Port redirection +now works again.
  • +
  • The icmpdef and common + chains may now be user-defined.
  • +
  • The firewall no longer + fails to start if "routefilter" is specified for + an interface that isn't started. A warning message is now + issued in this case.
  • +
  • The LRP Version is + renamed "shorwall" for 8,3 MSDOS file system compatibility.
  • +
  • A couple of LRP-specific + problems were corrected.
  • + + +

    4/8/2001 - Shorewall is now affiliated with the Leaf Project -

    +

    - +

    4/5/2001 - The current version of Shorewall is 1.1.1. In this version:

    - +
      -
    • The common chain is - traversed from INPUT, OUTPUT and FORWARD before - logging occurs
    • -
    • The source has been +
    • The common chain +is traversed from INPUT, OUTPUT and FORWARD before + logging occurs
    • +
    • The source has been cleaned up dramatically
    • -
    • DHCP DISCOVER packets - with RFC1918 source addresses no longer generate - log messages. Linux DHCP clients generate such packets and +
    • DHCP DISCOVER packets + with RFC1918 source addresses no longer generate + log messages. Linux DHCP clients generate such packets and it's annoying to see them logged. 
    • - +
    - +

    3/25/2001 - The current version of Shorewall is 1.1.0. In this version:

    - +
      -
    • Log messages now indicate - the packet disposition.
    • -
    • Error messages have +
    • Log messages now +indicate the packet disposition.
    • +
    • Error messages have been improved.
    • -
    • The ability to define - zones consisting of an enumerated set of hosts - and/or subnetworks has been added.
    • -
    • The zone-to-zone chain - matrix is now sparse so that only those chains -that contain meaningful rules are defined.
    • -
    • 240.0.0.0/4 and 169.254.0.0/16 - have been added to the source subnetworks whose packets - are dropped under the norfc1918 interface - option.
    • -
    • Exits are now provided - for executing an user-defined script when a chain - is defined, when the firewall is initialized, when the firewall - is started, when the firewall is stopped and when the - firewall is cleared.
    • -
    • The Linux kernel's -route filtering facility can now be specified -selectively on network interfaces.
    • - - -
    +
  • The ability to define + zones consisting of an enumerated set of hosts + and/or subnetworks has been added.
  • +
  • The zone-to-zone +chain matrix is now sparse so that only those chains + that contain meaningful rules are defined.
  • +
  • 240.0.0.0/4 and 169.254.0.0/16 + have been added to the source subnetworks whose +packets are dropped under the norfc1918 interface + option.
  • +
  • Exits are now provided + for executing an user-defined script when a +chain is defined, when the firewall is initialized, when + the firewall is started, when the firewall is stopped + and when the firewall is cleared.
  • +
  • The Linux kernel's + route filtering facility can now be specified + selectively on network interfaces.
  • + + +

    3/19/2001 - The current version of Shorewall is 1.0.4. This version:

    - +
      -
    • Allows user-defined - zones. Shorewall now has only one pre-defined - zone (fw) with the remaining zones being defined in the new -configuration file /etc/shorewall/zones. The /etc/shorewall/zones - file released in this version provides behavior that - is compatible with Shorewall 1.0.3. 
    • -
    • Adds the ability to - specify logging in entries in the /etc/shorewall/rules +
    • Allows user-defined + zones. Shorewall now has only one pre-defined +zone (fw) with the remaining zones being defined in the new +configuration file /etc/shorewall/zones. The /etc/shorewall/zones + file released in this version provides behavior that + is compatible with Shorewall 1.0.3. 
    • +
    • Adds the ability +to specify logging in entries in the /etc/shorewall/rules file.
    • -
    • Correct handling of - the icmp-def chain so that only ICMP packets are - sent through the chain.
    • -
    • Compresses the output - of "shorewall monitor" if awk is installed. Allows - the command to work if awk isn't installed (although -it's not pretty).
    • - - -
    +
  • Correct handling +of the icmp-def chain so that only ICMP packets are + sent through the chain.
  • +
  • Compresses the output + of "shorewall monitor" if awk is installed. Allows + the command to work if awk isn't installed (although it's + not pretty).
  • -

    3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix - release with no new features.

    + - + +

    3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix + release with no new features.

    + +
      -
    • The PATH variable -in the firewall script now includes /usr/local/bin - and /usr/local/sbin.
    • -
    • DMZ-related chains -are now correctly deleted if the DMZ is deleted.
    • -
    • The interface OPTIONS +
    • The PATH variable +in the firewall script now includes /usr/local/bin + and /usr/local/sbin.
    • +
    • DMZ-related chains + are now correctly deleted if the DMZ is deleted.
    • +
    • The interface OPTIONS for "gw" interfaces are no longer ignored.
    • - +
    - -

    3/8/2001 - The current version of Shorewall is 1.0.2. It supports an - additional "gw" (gateway) zone for tunnels and it - supports IPSEC tunnels with end-points on the firewall. - There is also a .lrp available now.

    + +

    3/8/2001 - The current version of Shorewall is 1.0.2. It supports an + additional "gw" (gateway) zone for tunnels and +it supports IPSEC tunnels with end-points on the firewall. + There is also a .lrp available now.

    - -

    Updated 2/13/2003 - Tom Eastep + +

    Updated 2/13/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +



    diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm index 2ee3e74f0..ad30e3e78 100644 --- a/Shorewall-docs/configuration_file_basics.htm +++ b/Shorewall-docs/configuration_file_basics.htm @@ -1,343 +1,347 @@ - + - + - + - + Configuration File Basics - + - - - + + - - - + + + +
    +
    - +

    Configuration Files

    -
    - -

    Warning: If you copy or edit your - configuration files on a system running Microsoft Windows, you must + +

    Warning: If you copy or edit your + configuration files on a system running Microsoft Windows, you must run them through dos2unix + href="http://www.megaloman.com/%7Ehany/software/hd2u/"> dos2unix before you use them with Shorewall.

    - +

    Files

    - +

    Shorewall's configuration files are in the directory /etc/shorewall.

    - +
      -
    • /etc/shorewall/shorewall.conf - used to set +
    • /etc/shorewall/shorewall.conf - used to set several firewall parameters.
    • -
    • /etc/shorewall/params - use this file to set -shell variables that you will expand in other files.
    • -
    • /etc/shorewall/zones - partition the firewall's +
    • /etc/shorewall/params - use this file to set + shell variables that you will expand in other files.
    • +
    • /etc/shorewall/zones - partition the firewall's view of the world into zones.
    • -
    • /etc/shorewall/policy - establishes firewall -high-level policy.
    • -
    • /etc/shorewall/interfaces - describes the interfaces - on the firewall system.
    • -
    • /etc/shorewall/hosts - allows defining zones -in terms of individual hosts and subnetworks.
    • -
    • /etc/shorewall/masq - directs the firewall where - to use many-to-one (dynamic) Network Address Translation (a.k.a. - Masquerading) and Source Network Address Translation (SNAT).
    • -
    • /etc/shorewall/modules - directs the firewall +
    • /etc/shorewall/policy - establishes firewall + high-level policy.
    • +
    • /etc/shorewall/interfaces - describes the interfaces + on the firewall system.
    • +
    • /etc/shorewall/hosts - allows defining zones + in terms of individual hosts and subnetworks.
    • +
    • /etc/shorewall/masq - directs the firewall +where to use many-to-one (dynamic) Network Address Translation +(a.k.a. Masquerading) and Source Network Address Translation +(SNAT).
    • +
    • /etc/shorewall/modules - directs the firewall to load kernel modules.
    • -
    • /etc/shorewall/rules - defines rules that are +
    • /etc/shorewall/rules - defines rules that are exceptions to the overall policies established in /etc/shorewall/policy.
    • -
    • /etc/shorewall/nat - defines static NAT rules.
    • -
    • /etc/shorewall/proxyarp - defines use of Proxy - ARP.
    • -
    • /etc/shorewall/routestopped (Shorewall 1.3.4 -and later) - defines hosts accessible when Shorewall is stopped.
    • -
    • /etc/shorewall/tcrules - defines marking of +
    • /etc/shorewall/nat - defines static NAT rules.
    • +
    • /etc/shorewall/proxyarp - defines use of Proxy + ARP.
    • +
    • /etc/shorewall/routestopped (Shorewall 1.3.4 + and later) - defines hosts accessible when Shorewall is stopped.
    • +
    • /etc/shorewall/tcrules - defines marking of packets for later use by traffic control/shaping or policy routing.
    • -
    • /etc/shorewall/tos - defines rules for setting - the TOS field in packet headers.
    • -
    • /etc/shorewall/tunnels - defines IPSEC, GRE +
    • /etc/shorewall/tos - defines rules for setting + the TOS field in packet headers.
    • +
    • /etc/shorewall/tunnels - defines IPSEC, GRE and IPIP tunnels with end-points on the firewall system.
    • -
    • /etc/shorewall/blacklist - lists blacklisted -IP/subnet/MAC addresses.
    • -
    • /etc/shorewall/init - commands that you wish to execute at the +
    • /etc/shorewall/blacklist - lists blacklisted + IP/subnet/MAC addresses.
    • +
    • /etc/shorewall/init - commands that you wish to execute at the beginning of a "shorewall start" or "shorewall restart".
    • -
    • /etc/shorewall/start - commands that you wish to execute at the -completion of a "shorewall start" or "shorewall restart"
    • -
    • /etc/shorewall/stop - commands that you wish to execute at the +
    • /etc/shorewall/start - commands that you wish to execute at the + completion of a "shorewall start" or "shorewall restart"
    • +
    • /etc/shorewall/stop - commands that you wish to execute at the beginning of a "shorewall stop".
    • -
    • /etc/shorewall/stopped - commands that you wish to execute at the - completion of a "shorewall stop".
      -
    • - +
    • /etc/shorewall/stopped - commands that you wish to execute at +the completion of a "shorewall stop".
    • +
    • /etc/shorewall/ecn - disable Explicit Congestion Notification (ECN +- RFC 3168) to remote hosts or networks.
      +
    • +
    - +

    Comments

    - -

    You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at - the end of any line, again by delimiting the comment from the rest - of the line with a pound sign.

    - + +

    You may place comments in configuration files by making the first non-whitespace + character a pound sign ("#"). You may also place comments +at the end of any line, again by delimiting the comment from +the rest of the line with a pound sign.

    +

    Examples:

    - +
    # This is a comment
    - +
    ACCEPT	net	fw	tcp	www	#This is an end-of-line comment
    - +

    Line Continuation

    - -

    You may continue lines in the configuration files using the usual backslash + +

    You may continue lines in the configuration files using the usual backslash ("\") followed immediately by a new line character.

    - +

    Example:

    - +
    ACCEPT	net	fw	tcp \
    smtp,www,pop3,imap #Services running on the firewall
    - +

    Using DNS Names

    - -

    - -

    WARNING: I personally recommend strongly against - using DNS names in Shorewall configuration files. If you use DNS names - and you are called out of bed at 2:00AM because Shorewall won't start - as a result of DNS problems then don't say that you were not forewarned. -
    -

    - -

        -Tom
    -

    - -

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall - configuration files may be specified as either IP addresses or DNS - Names.
    -
    - DNS names in iptables rules aren't nearly as useful as they - first appear. When a DNS name appears in a rule, the iptables utility - resolves the name to one or more IP addresses and inserts those -addresses into the rule. So changes in the DNS->IP address relationship - that occur after the firewall has started have absolutely no effect -on the firewall's ruleset.

    - -

    If your firewall rules include DNS names then:

    +

    + +

    WARNING: I personally recommend strongly against + using DNS names in Shorewall configuration files. If you use DNS +names and you are called out of bed at 2:00AM because Shorewall won't +start as a result of DNS problems then don't say that you were not forewarned. +
    +

    + +

        -Tom
    +

    + +

    Beginning with Shorwall 1.3.9, Host addresses in Shorewall + configuration files may be specified as either IP addresses or DNS + Names.
    +
    + DNS names in iptables rules aren't nearly as useful as +they first appear. When a DNS name appears in a rule, the iptables +utility resolves the name to one or more IP addresses and inserts + those addresses into the rule. So changes in the DNS->IP address +relationship that occur after the firewall has started have absolutely +no effect on the firewall's ruleset.

    + +

    If your firewall rules include DNS names then:

    +
      -
    • If your /etc/resolv.conf is wrong then your firewall +
    • If your /etc/resolv.conf is wrong then your firewall won't start.
    • -
    • If your /etc/nsswitch.conf is wrong then your firewall +
    • If your /etc/nsswitch.conf is wrong then your firewall won't start.
    • -
    • If your Name Server(s) is(are) down then your firewall +
    • If your Name Server(s) is(are) down then your firewall won't start.
    • -
    • If your startup scripts try to start your firewall +
    • If your startup scripts try to start your firewall before starting your DNS server then your firewall won't start.
      -
    • -
    • Factors totally outside your control (your ISP's router - is down for example), can prevent your firewall from starting.
    • -
    • You must bring up your network interfaces prior to starting - your firewall.
      -
    • - -
    + +
  • Factors totally outside your control (your ISP's router + is down for example), can prevent your firewall from starting.
  • +
  • You must bring up your network interfaces prior to +starting your firewall.
    +
  • -

    Each DNS name much be fully qualified and include a minumum - of two periods (although one may be trailing). This restriction is - imposed by Shorewall to insure backward compatibility with existing + + +

    Each DNS name much be fully qualified and include a minumum + of two periods (although one may be trailing). This restriction is + imposed by Shorewall to insure backward compatibility with existing configuration files.
    -
    - Examples of valid DNS names:
    -

    - -
      -
    • mail.shorewall.net
    • -
    • shorewall.net. (note the trailing period).
    • - -
    - Examples of invalid DNS names:
    +
    + Examples of valid DNS names:
    +

      -
    • mail (not fully qualified)
    • -
    • shorewall.net (only one period)
    • - -
    - DNS names may not be used as:
    +
  • mail.shorewall.net
  • +
  • shorewall.net. (note the trailing period).
  • -
      -
    • The server address in a DNAT rule (/etc/shorewall/rules - file)
    • -
    • In the ADDRESS column of an entry in /etc/shorewall/masq.
    • -
    • In the /etc/shorewall/nat file.
    • -
    - These restrictions are not imposed by Shorewall simply for - your inconvenience but are rather limitations of iptables.
    - + Examples of invalid DNS names:
    + +
      +
    • mail (not fully qualified)
    • +
    • shorewall.net (only one period)
    • + +
    + DNS names may not be used as:
    + +
      +
    • The server address in a DNAT rule (/etc/shorewall/rules + file)
    • +
    • In the ADDRESS column of an entry in /etc/shorewall/masq.
    • +
    • In the /etc/shorewall/nat file.
    • + +
    + These restrictions are not imposed by Shorewall simply +for your inconvenience but are rather limitations of iptables.
    +

    Complementing an Address or Subnet

    - -

    Where specifying an IP address, a subnet or an interface, you can - precede the item with "!" to specify the complement of the item. For - example, !192.168.1.4 means "any host but 192.168.1.4". There must -be no white space following the "!".

    - + +

    Where specifying an IP address, a subnet or an interface, you can + precede the item with "!" to specify the complement of the item. For + example, !192.168.1.4 means "any host but 192.168.1.4". There must be +no white space following the "!".

    +

    Comma-separated Lists

    - -

    Comma-separated lists are allowed in a number of contexts within the - configuration files. A comma separated list:

    - + +

    Comma-separated lists are allowed in a number of contexts within the + configuration files. A comma separated list:

    +
      -
    • Must not have any embedded white space.
      - Valid: routefilter,dhcp,norfc1918
      - Invalid: routefilter,     dhcp,     norfc1818
    • -
    • If you use line continuation to break a comma-separated - list, the continuation line(s) must begin in column 1 (or +
    • Must not have any embedded white space.
      + Valid: routefilter,dhcp,norfc1918
      + Invalid: routefilter,     dhcp,     norfc1818
    • +
    • If you use line continuation to break a comma-separated + list, the continuation line(s) must begin in column 1 (or there would be embedded white space)
    • -
    • Entries in a comma-separated list may appear -in any order.
    • - +
    • Entries in a comma-separated list may appear + in any order.
    • +
    - +

    Port Numbers/Service Names

    - -

    Unless otherwise specified, when giving a port number you can use - either an integer or a service name from /etc/services.

    - + +

    Unless otherwise specified, when giving a port number you can use + either an integer or a service name from /etc/services.

    +

    Port Ranges

    - -

    If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. For example, - if you want to forward the range of tcp ports 4000 through 4100 to + +

    If you need to specify a range of ports, the proper syntax is <low + port number>:<high port number>. For example, + if you want to forward the range of tcp ports 4000 through 4100 to local host 192.168.1.3, the entry in /etc/shorewall/rules is:
    -

    - +

    +
         DNAT	net	loc:192.168.1.3	tcp	4000:4100
    - If you omit the low port number, a value of zero is assumed; if you omit -the high port number, a value of 65535 is assumed.
    - + If you omit the low port number, a value of zero is assumed; if you omit + the high port number, a value of 65535 is assumed.
    +

    Using Shell Variables

    - -

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

    - + +

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

    +

    It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally + 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=routefilter,norfc1918
    -
    - +
    +


    - Example (/etc/shorewall/interfaces record):

    - + 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 routefilter,norfc1918
    -
    -
    +
    +
    - -

    Variables may be used anywhere in the other configuration + +

    Variables may be used anywhere in the other configuration files.

    - +

    Using MAC Addresses

    - -

    Media Access Control (MAC) addresses can be used to specify packet - source in several of the configuration files. To use this -feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + +

    Media Access Control (MAC) addresses can be used to specify packet + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) included.

    - -

    MAC addresses are 48 bits wide and each Ethernet Controller has a - unique MAC address.
    -
    - In GNU/Linux, MAC addresses are usually written as -a series of 6 hex numbers separated by colons. Example:
    -
    -      [root@gateway root]# ifconfig eth0
    -      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    -      inet addr:206.124.146.176 Bcast:206.124.146.255 - Mask:255.255.255.0
    -      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    -      RX packets:2398102 errors:0 dropped:0 overruns:0 - frame:0
    -      TX packets:3044698 errors:0 dropped:0 overruns:0 - carrier:0
    -      collisions:30394 txqueuelen:100
    -      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 - (1582.8 Mb)
    -      Interrupt:11 Base address:0x1800
    -
    - Because Shorewall uses colons as a separator for address - fields, Shorewall requires MAC addresses to be written in another - way. In Shorewall, MAC addresses begin with a tilde ("~") and -consist of 6 hex numbers separated by hyphens. In Shorewall, the -MAC address in the example above would be written "~02-00-08-E3-FA-55".
    -

    - -

    Note: It is not necessary to use the special Shorewall notation + +

    MAC addresses are 48 bits wide and each Ethernet Controller has a + unique MAC address.
    +
    + In GNU/Linux, MAC addresses are usually written as + a series of 6 hex numbers separated by colons. Example:
    +
    +      [root@gateway root]# ifconfig eth0
    +      eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
    +      inet addr:206.124.146.176 Bcast:206.124.146.255 + Mask:255.255.255.0
    +      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    +      RX packets:2398102 errors:0 dropped:0 overruns:0 + frame:0
    +      TX packets:3044698 errors:0 dropped:0 overruns:0 + carrier:0
    +      collisions:30394 txqueuelen:100
    +      RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 + (1582.8 Mb)
    +      Interrupt:11 Base address:0x1800
    +
    + Because Shorewall uses colons as a separator for +address fields, Shorewall requires MAC addresses to be written +in another way. In Shorewall, MAC addresses begin with a tilde +("~") and consist of 6 hex numbers separated by hyphens. In Shorewall, +the MAC address in the example above would be written "~02-00-08-E3-FA-55".
    +

    + +

    Note: It is not necessary to use the special Shorewall notation in the /etc/shorewall/maclist file.
    -

    - +

    +

    Shorewall Configurations

    - -

    Shorewall allows you to have configuration directories other than /etc/shorewall. - The shorewall start -and restart commands allow you to specify an alternate configuration - directory and Shorewall will use the files in the alternate directory - rather than the corresponding files in /etc/shorewall. The alternate -directory need not contain a complete configuration; those files not -in the alternate directory will be read from /etc/shorewall.

    - -

    This facility permits you to easily create a test or temporary configuration + +

    Shorewall allows you to have configuration directories other than /etc/shorewall. + The shorewall start +and restart commands allow you to specify an alternate configuration + directory and Shorewall will use the files in the alternate directory + rather than the corresponding files in /etc/shorewall. The alternate +directory need not contain a complete configuration; those files not in +the alternate directory will be read from /etc/shorewall.

    + +

    This facility permits you to easily create a test or temporary configuration by:

    - +
      -
    1. copying the files that need modification from - /etc/shorewall to a separate directory;
    2. -
    3. modify those files in the separate directory; +
    4. copying the files that need modification +from /etc/shorewall to a separate directory;
    5. +
    6. modify those files in the separate directory; and
    7. -
    8. specifying the separate directory in a shorewall - start or shorewall restart command (e.g., shorewall -c /etc/testconfig - restart ).
    9. - +
    10. specifying the separate directory in a shorewall + start or shorewall restart command (e.g., shorewall -c +/etc/testconfig restart ).
    11. +
    - -

    Updated 2/7/2003 - Tom Eastep -

    + +

    Updated 2/24/2003 - Tom Eastep +

    - -

    Copyright + +

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

    +

    +



    diff --git a/Shorewall-docs/mailing_list.htm b/Shorewall-docs/mailing_list.htm index 094d29e17..ff74b41a7 100644 --- a/Shorewall-docs/mailing_list.htm +++ b/Shorewall-docs/mailing_list.htm @@ -2,152 +2,156 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - - - - - -
    +
    - +

    Vexira Logo -

    + - - - + +

     

    -
    - + +

    Shorewall Mailing Lists

    -
    + (Postfix Logo) -
    - +
    + -
    - + +
    +

    -
    - Powered by Postfix    

    -
    -
    +
    + Powered by Postfix    

    + + + -

    If you experience problems with any of these lists, please + + + + +

    REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please +read the Shorewall Support +Guide.
    +

    +

    If you experience problems with any of these lists, please let me know

    - +

    Not able to Post Mail to shorewall.net?

    - -

    You can report such problems by sending mail to tom dot eastep - at hp dot com.

    - + +

    You can report such problems by sending mail to tom dot eastep + at hp dot com.

    +

    A Word about SPAM Filters 

    - -

    Before subscribing please read my policy - about list traffic that bounces. Also please note that the mail server - at shorewall.net checks incoming mail:
    -

    - + +

    Before subscribing please read my policy + about list traffic that bounces. Also please note that the mail server + at shorewall.net checks incoming mail:
    +

    +
      -
    1. against Spamassassin - (including Vipul's Razor).
      -
    2. -
    3. to ensure that the sender address is fully qualified.
    4. -
    5. to verify that the sender's domain has an A or MX +
    6. against Spamassassin + (including Vipul's Razor).
      +
    7. +
    8. to ensure that the sender address is fully qualified.
    9. +
    10. to verify that the sender's domain has an A or MX record in DNS.
    11. -
    12. to ensure that the host name in the HELO/EHLO command +
    13. to ensure that the host name in the HELO/EHLO command is a valid fully-qualified DNS name that resolves.
    14. - +
    - +

    Please post in plain text

    - A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net - "for continuous abuse" because it has been my policy to allow HTML in + A growing number of MTAs serving list subscribers are rejecting + all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net + "for continuous abuse" because it has been my policy to allow HTML in list posts!!
    -
    - I think that blocking all HTML is a Draconian way to control spam - and that the ultimate losers here are not the spammers but the list -subscribers whose MTAs are bouncing all shorewall.net mail. As one list -subscriber wrote to me privately "These e-mail admin's need to get a (explitive - deleted) life instead of trying to rid the planet of HTML based e-mail". - Nevertheless, to allow subscribers to receive list posts as must as possible, - I have now configured the list server at shorewall.net to strip all HTML - from outgoing posts. This means that HTML-only posts will be bounced by -the list server.
    - +
    + I think that blocking all HTML is a Draconian way to control +spam and that the ultimate losers here are not the spammers but the +list subscribers whose MTAs are bouncing all shorewall.net mail. As +one list subscriber wrote to me privately "These e-mail admin's need to +get a (explitive deleted) life instead of trying to rid the planet +of HTML based e-mail". Nevertheless, to allow subscribers to receive list +posts as must as possible, I have now configured the list server at shorewall.net +to strip all HTML from outgoing posts. This means that HTML-only posts +will be bounced by the list server.
    +

    Note: The list server limits posts to 120kb.
    -

    - +

    +

    Other Mail Delivery Problems

    - If you find that you are missing an occasional list post, your e-mail - admin may be blocking mail whose Received: headers contain the -names of certain ISPs. Again, I believe that such policies hurt more than -they help but I'm not prepared to go so far as to start stripping Received: - headers to circumvent those policies.
    - + If you find that you are missing an occasional list post, your +e-mail admin may be blocking mail whose Received: headers contain +the names of certain ISPs. Again, I believe that such policies hurt more +than they help but I'm not prepared to go so far as to start stripping Received: + headers to circumvent those policies.
    +

    Mailing Lists Archive Search

    - -
    - -

    Match: - + + + +

    Match: + - Format: - + Format: + - Sort by: - + Sort by: + -
    - Search:

    - + - -

    Please do not try to download the -entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply -won't stand the traffic. If I catch you, you will be blacklisted.
    -

    - + +

    Please do not try to download the entire +Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't +stand the traffic. If I catch you, you will be blacklisted.
    +

    +

    Shorewall CA Certificate

    - If you want to trust X.509 certificates issued by Shoreline + If you want to trust X.509 certificates issued by Shoreline Firewall (such as the one used on my web site), you may download and install my CA certificate - in your browser. If you don't wish to trust my certificates then -you can either use unencrypted access when subscribing to Shorewall -mailing lists or you can use secure access (SSL) and accept the server's -certificate when prompted by your browser.
    - + href="Shorewall_CA_html.html">download and install my CA certificate + in your browser. If you don't wish to trust my certificates then + you can either use unencrypted access when subscribing to Shorewall + mailing lists or you can use secure access (SSL) and accept the server's + certificate when prompted by your browser.
    +

    Shorewall Users Mailing List

    - -

    The Shorewall Users Mailing list provides a way for users - to get answers to questions and to report problems. Information -of general interest to the Shorewall user community is also posted -to this list.

    - -

    Before posting a problem report to this list, please see - the problem reporting - guidelines.

    - -

    To subscribe to the mailing list:
    -

    - - - -

    To post to the list, post to shorewall-users@lists.shorewall.net.

    - -

    The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

    - -

    Note that prior to 1/1/2002, the mailing list was hosted at -Sourceforge. The archives from that list -may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

    - -

    Shorewall Announce Mailing List

    - -

    This list is for announcements of general interest to the - Shorewall community. To subscribe:
    -

    - -

    - - - -


    - The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.

    - -

    Shorewall Development Mailing List

    - -

    The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.

    - + +

    The Shorewall Users Mailing list provides a way for users + to get answers to questions and to report problems. Information + of general interest to the Shorewall user community is also posted + to this list.

    + +

    Before posting a problem report to this list, please see + the problem reporting + guidelines.

    +

    To subscribe to the mailing list:

    - + + +

    To post to the list, post to shorewall-users@lists.shorewall.net.

    + +

    The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.

    + +

    Note that prior to 1/1/2002, the mailing list was hosted +at Sourceforge. The archives from that +list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.

    + +

    Shorewall Announce Mailing List

    + +

    This list is for announcements of general interest to the + Shorewall community. To subscribe:
    +

    + +

    + + + +


    + The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.

    + +

    Shorewall Development Mailing List

    + +

    The Shorewall Development Mailing list provides a forum for + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.

    + +

    To subscribe to the mailing list:
    +

    + + - +

    To post to the list, post to shorewall-devel@lists.shorewall.net

    - +

    The list archives are at http://lists.shorewall.net/pipermail/shorewall-devel.

    - -

    How to Unsubscribe from one of - the Mailing Lists

    - -

    There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists although Mailman 2.1 has attempted to - make this less confusing. To unsubscribe:

    - + +

    How to Unsubscribe from one of + the Mailing Lists

    + +

    There seems to be near-universal confusion about unsubscribing + from Mailman-managed lists although Mailman 2.1 has attempted +to make this less confusing. To unsubscribe:

    +
      -
    • - -

      Follow the same link above that you used to subscribe - to the list.

      -
    • -
    • - -

      Down at the bottom of that page is the following text: - " To unsubscribe from <list name>, get a password - reminder, or change your subscription options enter your subscription - email address:". Enter your email address in the box and -click on the "Unsubscribe or edit options" button.

      -
    • -
    • - -

      There will now be a box where you can enter your password - and click on "Unsubscribe"; if you have forgotten your password, - there is another button that will cause your password to be emailed - to you.

      -
    • - +
    • + +

      Follow the same link above that you used to subscribe + to the list.

      +
    • +
    • + +

      Down at the bottom of that page is the following text: + " To unsubscribe from <list name>, get a +password reminder, or change your subscription options enter +your subscription email address:". Enter your email address + in the box and click on the "Unsubscribe or edit options" button.

      +
    • +
    • + +

      There will now be a box where you can enter your password + and click on "Unsubscribe"; if you have forgotten your password, + there is another button that will cause your password to be emailed + to you.

      +
    • +
    - -
    + +

    Frustrated by having to Rebuild Mailman to use it with Postfix?

    - +

    Check out these instructions

    - -

    Last updated 2/18/2003 - Last updated 2/24/2003 - Tom Eastep

    - -

    Copyright2001, 2002, 2003 Thomas M. Eastep.
    -

    + +

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

    +


    diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index 615479a36..968f18c18 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -6,7 +6,7 @@ - + Shoreline Firewall (Shorewall) 1.4 @@ -15,24 +15,24 @@ - - + - + - + - + - + - + - + - +
    + @@ -42,15 +42,15 @@ - +

    Shorwall Logo - Shorewall - 1.4 - "iptables made - easy"

    + Shorewall 1.4 - "iptables + made easy" @@ -60,43 +60,44 @@ - + + + -
    +
    -
    - +
    - +
    - + - + - + - + - - + - + - +
    + @@ -106,7 +107,7 @@ - +

    What is it?

    @@ -119,7 +120,7 @@ - +

    The Shoreline Firewall, more commonly known as "Shorewall", is a Netfilter (iptables) based firewall that can be used on a dedicated firewall system, a multi-function @@ -135,27 +136,27 @@ - +

    This program is free software; you can redistribute it and/or modify - it under the terms -of Version 2 -of the GNU General Public License as published by the Free Software - Foundation.
    + it under the terms + of Version +2 of the GNU General Public License as published by the Free Software + Foundation.
    -
    +
    - This program is distributed - in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty - of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License - for more details.
    + This program is distributed + in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A +PARTICULAR PURPOSE. See the GNU General Public License + for more details.
    -
    +
    - You should have received a - copy of the GNU General Public License - along with this program; if not, write to the + You should have received +a copy of the GNU General Public License + along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA

    @@ -169,7 +170,7 @@ Ave, Cambridge, MA 02139, USA

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -182,21 +183,21 @@ Ave, Cambridge, MA 02139, USA

    - +

    - Jacques Nilo and - Eric Wolzak have a LEAF (router/firewall/gateway + Jacques Nilo and + Eric Wolzak have a LEAF (router/firewall/gateway on a floppy, CD or compact flash) distribution called - Bering that features Shorewall-1.3.14 - and Kernel-2.4.20. You can find their work at: - http://leaf.sourceforge.net/devel/jnilo
    -

    - + Bering that features Shorewall-1.3.14 + and Kernel-2.4.20. You can find their work at: + http://leaf.sourceforge.net/devel/jnilo
    +

    +

    Congratulations to Jacques and Eric on the recent release of Bering 1.1!!!
    -

    +

    @@ -206,7 +207,7 @@ Ave, Cambridge, MA 02139, USA

    - +

    This is a mirror of the main Shorewall web site at SourceForge (http://shorewall.sf.net)

    @@ -222,7 +223,7 @@ Ave, Cambridge, MA 02139, USA

    - +

    News

    @@ -235,7 +236,7 @@ Ave, Cambridge, MA 02139, USA

    - +

    @@ -245,108 +246,114 @@ Ave, Cambridge, MA 02139, USA

    - +

    3/14/2003 - Shorewall 1.4.0 (New) -

    +

    +

    - Shorewall 1.4 represents the next step in the evolution of Shorewall. -The main thrust of the initial release is simply to remove the cruft that -has accumulated in Shorewall over time.
    - IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package -('ip' utility).
    -
    -Function from 1.3 that has been omitted from this version include:
    - + 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. +
    2. The "check" command is no longer supported.
      +
      +
    3. +
    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. +
    6. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
    7. +
    8. 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.
      +
      +
    9. +
    10. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will generate + an error at startup if specified.
      +
      +
    11. +
    12. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is +no longer accepted.
      +
      +
    13. +
    14. The ALLOWRELATED variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.

    15. -
    16. Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate an error.
      -
      -
    17. -
    18. 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.
      -
      -
    19. -
    20. 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.
      -
      -
    21. -
    22. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no - longer accepted.
      -
      -
    23. -
    24. The ALLOWRELATED variable in shorewall.conf is no longer -supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
    25. -
    26. The icmp.def file has been removed.
      -
      -
    27. -
    28. The 'multi' interface option is no longer supported. - Shorewall will generate rules for sending packets back out the same interface -that they arrived on in two cases:
    29. - +
    30. The icmp.def file has been removed.
      +
      +
    31. +
    32. The 'multi' interface option is no longer supported. +  Shorewall will generate rules for sending packets back out the same interface + that they arrived on in two cases:
    33. +
    - +
      -
    • There is an explicit policy for the source zone to or -from the destination zone. An explicit policy names both zones and does not -use the 'all' reserved word.
    • -
    • There are one or more rules for traffic for the source zone -to or from the destination zone including rules that use the 'all' reserved -word. Exception: if the source zone and destination zone are the same then -the rule must be explicit - it must name the zone in both the SOURCE and DESTINATION -columns.
      -
    • - +
    • There is an explicit policy for the source zone to +or from the destination zone. An explicit policy names both zones and does +not use the 'all' reserved word.
    • +
    • There are one or more rules for traffic for the source zone + to or from the destination zone including rules that use the 'all' reserved + word. Exception: if the source zone and destination zone are the same then + the rule must be explicit - it must name the zone in both the SOURCE and +DESTINATION columns.
      +
    • +
    - +
      - +
    - Changes for 1.4 include:
    - + Changes for 1.4 include:
    +
      -
    1. The /etc/shorewall/shorewall.conf file has been completely - reorganized into logical sections.
      -
      -
    2. -
    3. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
    4. -
    5. The firewall script and version file are now installed in -/usr/share/shorewall.
      -
      -
    6. -
    7. Late arriving DNS replies are now silently dropped in the -common chain by default.
      -
      -
    8. -
    9. 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.
      -
      -
    10. -
    11. 802.11b devices with names of the form wlan<n> -now support the 'maclist' option.
      -
    12. - +
    13. The /etc/shorewall/shorewall.conf file has been completely + reorganized into logical sections.
      +
      +
    14. +
    15. LOG is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
    16. +
    17. The firewall script and version file are now installed +in /usr/share/shorewall.
      +
      +
    18. +
    19. Late arriving DNS replies are now silently dropped in the + common chain by default.
      +
      +
    20. +
    21. 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.
      +
      +
    22. +
    23. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
      +
    24. +
    - +
      - + +
    @@ -354,7 +361,7 @@ now support the 'maclist' option.
    - +

    More News

    @@ -367,43 +374,43 @@ now support the 'maclist' option.
    - +

    Donations

    -
    M
    -
    + -
    + - + - + - + - + - + - + - +
    @@ -413,12 +420,12 @@ now support the 'maclist' option.
    - +

    -  

    +  

    @@ -429,33 +436,35 @@ now support the 'maclist' option.
    - +

    Shorewall is free but if you try it and find it useful, please consider making a donation - to Starlight Children's Foundation. Thanks!

    -
    - +

    Updated 2/18/2003 - Tom Eastep -
    -

    +
    +

    +
    +

    diff --git a/Shorewall-docs/shoreline.htm b/Shorewall-docs/shoreline.htm index 93cc0f007..079f75bd1 100644 --- a/Shorewall-docs/shoreline.htm +++ b/Shorewall-docs/shoreline.htm @@ -1,124 +1,125 @@ - + About the Shorewall Author - + - - + + - + - - - + + - - - + + + +
    - +
    +

    Tom Eastep

    -
    - +

    Tom on the PCT - 1991 -

    - +

    +

    Tarry & Tom -- August 2002
    -
    -

    - +
    +

    + - -

    I am currently a member of the design team for the next-generation - operating system from the NonStop Enterprise Division of HP.

    - -

    I became interested in Internet Security when I established a home office - in 1999 and had DSL service installed in our home. I investigated - ipchains and developed the scripts which are now collectively known -as Seattle Firewall. -Expanding on what I learned from Seattle Firewall, I then designed -and wrote Shorewall.

    - -

    I telework from our home in Shoreline, - Washington where I live with my wife Tarry.

    - -

    Our current home network consists of:

    +
  • Tandem Computers, Incorporated + (now part of the The New HP) 1980 +- present
  • +
  • Married 1969 - no children.
  • + + +

    I am currently a member of the design team for the next-generation + operating system from the NonStop Enterprise Division of HP.

    + +

    I became interested in Internet Security when I established a home office + in 1999 and had DSL service installed in our home. I investigated + ipchains and developed the scripts which are now collectively known as + Seattle Firewall. Expanding + on what I learned from Seattle Firewall, I then designed and +wrote Shorewall.

    + +

    I telework from our home in Shoreline, + Washington where I live with my wife Tarry.

    + +

    Our current home network consists of:

    +
      -
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & -20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. +
    • 1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB & +20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Serves as a PPTP server for Road Warrior access. Dual boots Mandrake 9.0.
    • -
    • Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) - NIC - My personal Linux System which runs Samba configured as -a WINS server. This system also has VMware installed and can run -both Debian Woody and Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip) + NIC - My personal Linux System which runs Samba configured as a + WINS server. This system also has VMware installed and can run both + Debian Woody and SuSE 8.1 in virtual machines.
    • -
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  - - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd), +
    • K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC  + - Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd), DNS server (Bind 9).
    • -
    • PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 -LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.4.0 -Alpha 2  and a DHCP server.
    • -
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC - -My wife's personal system.
    • -
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard - EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main - work system.
    • - +
    • PII/233, RH8.0, Kernel 2.4.20, 256MB MB RAM, 2GB SCSI + HD - 3 LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall + 1.4.0 and a DHCP server.
    • +
    • Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC +- My wife's personal system.
    • +
    • PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard + EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My +main work system.
    • +
    - +

    All of our other systems are made by Compaq (part of the new HP).. All of our Tulip NICs are Netgear FA310TXs.

    - +

    - - - - Powered by Mandrake - Protected by ShorewallProtected by Shorewall -

    - -

    Last updated 2/18/2003 -

    + +

    Last updated 2/23/2003 - Tom Eastep

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


    diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 9d4a61df0..aa2eb2ce9 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -6,7 +6,7 @@ - + Shoreline Firewall (Shorewall) 1.4 @@ -15,25 +15,25 @@ - + + - + - + - + - - + + - - - + + +
    + @@ -43,14 +43,14 @@ - +

    Shorwall Logo - Shorewall 1.4 - "iptables + Shorewall 1.4 - "iptables made easy"

    @@ -63,35 +63,35 @@ - + -
    - -
    + +
    -
    +
    - + - + - + - + - + - - - + + +
    + @@ -102,7 +102,7 @@ - +

    What is it?

    @@ -115,12 +115,13 @@ - -

    The Shoreline Firewall, more commonly known as  "Shorewall", is - a Netfilter (iptables) - based firewall that can be used on a dedicated firewall system, - a multi-function gateway/router/server or on a standalone GNU/Linux - system.

    + + +

    The Shoreline Firewall, more commonly known as  "Shorewall", is + a Netfilter (iptables) + based firewall that can be used on a dedicated firewall system, + a multi-function gateway/router/server or on a standalone +GNU/Linux system.

    @@ -132,29 +133,30 @@ - -

    This program is free software; you can redistribute it and/or modify - it under the terms - of Version - 2 of the GNU General Public License as published by the Free Software - Foundation.
    -
    +

    This program is free software; you can redistribute it and/or modify + it under the terms + of Version + 2 of the GNU General Public License as published by the Free Software + Foundation.
    - This program is distributed - in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A - PARTICULAR PURPOSE. See the GNU General Public License +
    + + This program is distributed + in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR +A PARTICULAR PURPOSE. See the GNU General Public License for more details.
    -
    +
    + + You should have received + a copy of the GNU General Public License + along with this program; if not, write to + the Free Software Foundation, Inc., 675 Mass + Ave, Cambridge, MA 02139, USA

    - You should have received - a copy of the GNU General Public License - along with this program; if not, write to - the Free Software Foundation, Inc., 675 -Mass Ave, Cambridge, MA 02139, USA

    @@ -166,7 +168,6 @@ Mass Ave, Cambridge, MA 02139, USA

    -

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -180,25 +181,25 @@ Mass Ave, Cambridge, MA 02139, USA

    - +

    - Jacques Nilo - and Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution - called Bering that features - Shorewall-1.3.14 and Kernel-2.4.20. You can find - their work at: Jacques Nilo + and Eric Wolzak have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.3.14 and Kernel-2.4.20. You can find + their work at: http://leaf.sourceforge.net/devel/jnilo

    - - + + - Congratulations to Jacques and Eric -on the recent release of Bering 1.1!!!
    - + Congratulations to Jacques and Eric + on the recent release of Bering 1.1!!!
    +

    News

    @@ -214,102 +215,105 @@ on the recent release of Bering 1.1!!!
    - +

    3/14/2003 - Shorewall 1.4.0 (New) -

    - Shorewall 1.4 represents the -next step in the evolution of Shorewall. The main thrust of the initial release - is simply to remove the cruft that has accumulated in Shorewall over time. -
    - IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package +

    + 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:
    - +
    + 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. -
    3. Interface names of the form <device>:<integer> +
    4. The "check" command is no longer supported.
      +
      +
    5. +
    6. 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.
      +
      +
    7. +
    8. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces now generate an error.
      -
      -
    9. -
    10. 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.
      -
      -
    11. -
    12. The 'routestopped' option in the /etc/shorewall/interfaces - and /etc/shorewall/hosts files is no longer supported and will generate +
      +
    13. +
    14. 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.
      +
      +
    15. +
    16. 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.
      -
      -
    17. -
    18. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no - longer accepted.
      -
      -
    19. -
    20. The ALLOWRELATED variable in shorewall.conf is no longer +
      +
    21. +
    22. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is +no longer accepted.
      +
      +
    23. +
    24. The ALLOWRELATED variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
      +
    25. +
    26. The icmp.def file has been removed.

    27. -
    28. The icmp.def file has been removed.
      -
      -
    29. -
    30. The 'multi' interface option is no longer supported. - Shorewall will generate rules for sending packets back out the same interface -that they arrived on in two cases:
    31. - +
    32. The 'multi' interface option is no longer supported. +  Shorewall will generate rules for sending packets back out the same interface + that they arrived on in two cases:
    33. +
    - +
      -
    • There is an explicit policy for the source zone to or -from the destination zone. An explicit policy names both zones and does not -use the 'all' reserved word.
    • -
    • There are one or more rules for traffic for the source zone -to or from the destination zone including rules that use the 'all' reserved -word. Exception: if the source zone and destination zone are the same then -the rule must be explicit - it must name the zone in both the SOURCE and DESTINATION -columns.
    • - +
    • There is an explicit policy for the source zone to or + from the destination zone. An explicit policy names both zones and does +not use the 'all' reserved word.
    • +
    • There are one or more rules for traffic for the source zone +to or from the destination zone including rules that use the 'all' reserved + word. Exception: if the source zone and destination zone are the same then + the rule must be explicit - it must name the zone in both the SOURCE and +DESTINATION columns.
    • +
    - +
      - +
    - Changes for 1.4 include:
    - + Changes for 1.4 include:
    +
      -
    1. The /etc/shorewall/shorewall.conf file has been completely +
    2. The /etc/shorewall/shorewall.conf file has been completely reorganized into logical sections.
      -
      -
    3. -
    4. LOG and CONTINUE are now a valid actions for a rule (/etc/shorewall/rules).
      -
      -
    5. -
    6. The firewall script and version file are now installed in -/usr/share/shorewall.
      -
      -
    7. -
    8. Late arriving DNS replies are now silently dropped in the -common chain by default.
      -
      -
    9. -
    10. In addition to behaving like OLD_PING_HANDLING=No, Shorewall - 1.4 no longer unconditionally accepts outbound ICMP packets. So if you want +
      +
    11. +
    12. LOG and CONTINUE are now a valid actions for a rule (/etc/shorewall/rules).
      +
      +
    13. +
    14. The firewall script and version file are now installed in + /usr/share/shorewall.
      +
      +
    15. +
    16. Late arriving DNS replies are now silently dropped in the + common chain by default.
      +
      +
    17. +
    18. 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.
      -
      -
    19. -
    20. 802.11b devices with names of the form wlan<n> +
      +
    21. +
    22. 802.11b devices with names of the form wlan<n> now support the 'maclist' option.
      -
      -
    23. - +
      + +
    - +

    - + @@ -318,7 +322,7 @@ now support the 'maclist' option.
    - +
      @@ -327,16 +331,16 @@ now support the 'maclist' option.
      - -
    - - - - - - - + + + + + + + + +

    More News

    @@ -350,31 +354,31 @@ now support the 'maclist' option.
    - +

    - +

    SourceForge Logo -

    + - +

    - +

    This site is hosted by the generous folks at SourceForge.net

    @@ -382,97 +386,97 @@ now support the 'maclist' option.
    - + +

    Donations

    -

    -
    -
    - -
    - - - - - - - - - - -
    - - - - - - - - - - -

    - -

    - - - - - - - + + -

    Shorewall is free but -if you try it and find it useful, please consider making a donation - to Starlight Children's -Foundation. Thanks!

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

    + +

    + + + + + + + + + + + + +

    Shorewall is free +but if you try it and find it useful, please consider making a donation + to Starlight +Children's Foundation. Thanks!

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

    Updated 2/18/2003 - Tom Eastep - -
    -

    -
    + +

    Updated 2/24/2003 - Tom Eastep + +
    +

    diff --git a/Shorewall-docs/starting_and_stopping_shorewall.htm b/Shorewall-docs/starting_and_stopping_shorewall.htm index c3d8cf4e1..b369cde57 100644 --- a/Shorewall-docs/starting_and_stopping_shorewall.htm +++ b/Shorewall-docs/starting_and_stopping_shorewall.htm @@ -1,13 +1,13 @@ - + - + - + - + Starting and Stopping Shorewall @@ -15,39 +15,39 @@ - + - - + + - + - + - - + +
    + - +

    Starting/Stopping and Monitoring - the Firewall

    + the Firewall -
    - +

    If you have a permanent internet connection such as DSL or Cable, - I recommend that you start the firewall automatically at boot. Once - you have installed "firewall" in your init.d directory, simply type - "chkconfig --add firewall". This will start the firewall in run - levels 2-5 and stop it in run levels 1 and 6. If you want to configure - your firewall differently from this default, you can use the "--level" - option in chkconfig (see "man chkconfig") or using your favorite - graphical run-level editor.

    + I recommend that you start the firewall automatically at boot. +Once you have installed "firewall" in your init.d directory, simply +type "chkconfig --add firewall". This will start the firewall +in run levels 2-5 and stop it in run levels 1 and 6. If you want +to configure your firewall differently from this default, you can +use the "--level" option in chkconfig (see "man chkconfig") or using +your favorite graphical run-level editor.

    @@ -55,275 +55,273 @@ - +

    Important Notes:
    -

    - +

    +
      -
    1. Shorewall startup is disabled by default. Once you have configured - your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. - Note: Users of the .deb package must edit /etc/default/shorewall and +
    2. Shorewall startup is disabled by default. Once you have configured + your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. + Note: Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
      -
    3. -
    4. If you use dialup, you may want to start the firewall in - your /etc/ppp/ip-up.local script. I recommend just placing "shorewall - restart" in that script.
    5. - + +
    6. If you use dialup, you may want to start the firewall + in your /etc/ppp/ip-up.local script. I recommend just placing "shorewall + restart" in that script.
    7. +
    - +

    - +

    You can manually start and stop Shoreline Firewall using the "shorewall" - shell program:

    + shell program:

    - +
      -
    • shorewall start - starts the firewall
    • -
    • shorewall stop - stops the firewall
    • -
    • shorewall restart - stops the firewall (if it's - running) and then starts it again
    • -
    • shorewall reset - reset the packet and byte counters - in the firewall
    • -
    • shorewall clear - remove all rules and chains - installed by Shoreline Firewall
    • -
    • shorewall refresh - refresh the rules involving the broadcast - addresses of firewall interfaces and the black and white lists.
    • - +
    • shorewall start - starts the firewall
    • +
    • shorewall stop - stops the firewall
    • +
    • shorewall restart - stops the firewall (if it's + running) and then starts it again
    • +
    • shorewall reset - reset the packet and byte counters + in the firewall
    • +
    • shorewall clear - remove all rules and chains + installed by Shoreline Firewall
    • +
    • shorewall refresh - refresh the rules involving the broadcast + addresses of firewall interfaces, the black list, traffic control rules and ECN control rules.
    • +
    - If you include the keyword debug as the first argument, then a -shell trace of the command is produced as in:
    - + If you include the keyword debug as the first argument, then +a shell trace of the command is produced as in:
    +
    	shorewall debug start 2> /tmp/trace
    - +

    The above command would trace the 'start' command and place the trace information in the file /tmp/trace
    -

    - +

    +

    The Shorewall State Diagram is shown at the - bottom of this page.
    -

    - + bottom of this page.
    +

    +

    The "shorewall" program may also be used to monitor the firewall.

    - +
      -
    • shorewall status - produce a verbose report about the firewall - (iptables -L -n -v)
    • -
    • shorewall show chain - produce a verbose report about - chain (iptables -L chain -n -v)
    • -
    • shorewall show nat - produce a verbose report about the nat - table (iptables -t nat -L -n -v)
    • -
    • shorewall show tos - produce a verbose report about the mangle - table (iptables -t mangle -L -n -v)
    • -
    • shorewall show log - display the last 20 packet log entries.
    • -
    • shorewall show connections - displays the IP connections -currently being tracked by the firewall.
    • -
    • shorewall - show - tc - displays information - about the traffic control/shaping configuration.
    • -
    • shorewall monitor [ delay ] - Continuously display the firewall - status, last 20 log entries and nat. When the log entry display - changes, an audible alarm is sounded.
    • -
    • shorewall hits - Produces several reports about the Shorewall - packet log messages in the current /var/log/messages file.
    • -
    • shorewall version - Displays the installed version number.
    • -
    • shorewall check - Performs a cursory validation - of the zones, interfaces, hosts, rules and policy files. The "check" command does not parse and validate - the generated iptables commands so even though the "check" command - completes successfully, the configuration may fail to start. See the - recommended way to make configuration changes described below. -
    • -
    • shorewall try configuration-directory [ timeout - ] - Restart shorewall using the specified configuration and if an -error occurs or if the timeout option is given and the new configuration +
    • shorewall status - produce a verbose report about the firewall + (iptables -L -n -v)
    • +
    • shorewall show chain - produce a verbose report +about chain (iptables -L chain -n -v)
    • +
    • shorewall show nat - produce a verbose report about the +nat table (iptables -t nat -L -n -v)
    • +
    • shorewall show tos - produce a verbose report about the +mangle table (iptables -t mangle -L -n -v)
    • +
    • shorewall show log - display the last 20 packet log entries.
    • +
    • shorewall show connections - displays the IP connections + currently being tracked by the firewall.
    • +
    • shorewall + show + tc - displays +information about the traffic control/shaping configuration.
    • +
    • shorewall monitor [ delay ] - Continuously display the +firewall status, last 20 log entries and nat. When the log +entry display changes, an audible alarm is sounded.
    • +
    • shorewall hits - Produces several reports about the Shorewall + packet log messages in the current /var/log/messages file.
    • +
    • shorewall version - Displays the installed version +number.
    • +
    • shorewall try configuration-directory [ timeout + ] - Restart shorewall using the specified configuration and if an + error occurs or if the timeout option is given and the new configuration has been up for that many seconds then shorewall is restarted using the standard configuration.
    • -
    • shorewall deny, shorewall reject, shorewall accept and shorewall - save implement dynamic blacklisting.
    • -
    • shorewall logwatch (added in version 1.3.2) - Monitors the - LOGFILE and produces an audible alarm when new - Shorewall messages are logged.
    • - +
    • shorewall deny, shorewall reject, shorewall accept and +shorewall save implement dynamic +blacklisting.
    • +
    • shorewall logwatch (added in version 1.3.2) - Monitors +the LOGFILE and produces an audible alarm when +new Shorewall messages are logged.
    • +
    - Finally, the "shorewall" program may be used to dynamically alter the - contents of a zone.
    - + Finally, the "shorewall" program may be used to dynamically alter +the contents of a zone.
    +
      -
    • shorewall add interface[:host] zone - Adds - the specified interface (and host if included) to the specified zone.
    • -
    • shorewall delete interface[:host] zone - -Deletes the specified interface (and host if included) from the specified -zone.
    • - +
    • shorewall add interface[:host] zone - +Adds the specified interface (and host if included) to the specified zone.
    • +
    • shorewall delete interface[:host] zone - + Deletes the specified interface (and host if included) from the specified + zone.
    • +
    - +
    Examples:
    - +
    shorewall add ipsec0:192.0.2.24 vpn1 - -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
    - shorewall delete ipsec0:192.0.2.24 vpn1 - -- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1
    + -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
    + shorewall delete ipsec0:192.0.2.24 vpn1 + -- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1
    +
    - - -

    The shorewall start, shorewall restart, shorewall check  and - shorewall try commands allow you to specify which The shorewall start, shorewall restart, and shorewall +try commands allow you to specify which Shorewall configuration - to use:

    + to use:

    - +
    - -

    shorewall [ -c configuration-directory ] {start|restart|check}
    - shorewall try configuration-directory

    -
    + +

    shorewall [ -c configuration-directory ] {start|restart}
    + shorewall try configuration-directory

    + - +

    If a configuration-directory is specified, each time that Shorewall - is going to use a file in /etc/shorewall it will first look in the configuration-directory - . If the file is present in the configuration-directory, that - file will be used; otherwise, the file in /etc/shorewall will be used.

    + is going to use a file in /etc/shorewall it will first look in the configuration-directory + . If the file is present in the configuration-directory, that + file will be used; otherwise, the file in /etc/shorewall will be used.

    - +

    When changing the configuration of a production firewall, I recommend - the following:

    + the following:

    - +
      -
    • mkdir /etc/test
    • +
    • mkdir /etc/test
    • -
    • cd /etc/test
    • +
    • cd /etc/test
    • -
    • <copy any files that you need to change from /etc/shorewall - to . and change them here>
    • +
    • <copy any files that you need to change from +/etc/shorewall to . and change them here>
    • -
    • shorewall -c . check
    • -
    • <correct any errors found by check and check again>
    • - -
    • /sbin/shorewall try .
    • - +
    • /sbin/shorewall +try .
    • +
    - +

    If the configuration starts but doesn't work, just "shorewall restart" - to restore the old configuration. If the new configuration fails to -start, the "try" command will automatically start the old one for you.

    + to restore the old configuration. If the new configuration fails to + start, the "try" command will automatically start the old one for you.

    - +

    When the new configuration works then just

    - +
      -
    • cp * /etc/shorewall
    • +
    • cp * /etc/shorewall
    • -
    • cd
    • +
    • cd
    • -
    • rm -rf /etc/test
    • - +
    • rm -rf /etc/test
    • +
    - +

    The Shorewall State Diargram is depicted below.
    -

    - +

    +
    (State Diagram) -
    -
    - +
    + +

     
    -

    - You will note that the commands that result in state transitions use -the word "firewall" rather than "shorewall". That is because the actual transitions - are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall on - Debian); /sbin/shorewall runs 'firewall" according to the following table:
    -
    - +

    + You will note that the commands that result in state transitions use + the word "firewall" rather than "shorewall". That is because the actual +transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall +on Debian); /sbin/shorewall runs 'firewall" according to the following table:
    +
    + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    shorewall start
    -
    firewall start
    -
    shorewall stop
    -
    firewall stop
    -
    shorewall restart
    -
    firewall restart
    -
    shorewall add
    -
    firewall add
    -
    shorewall delete
    -
    firewall delete
    -
    shorewall refresh
    -
    firewall refresh
    -
    shorewall try
    -
    firewall -c <new configuration> restart
    - If unsuccessful then firewall start (standard configuration)
    - If timeout then firewall restart (standard configuration)
    -
    shorewall start
    +
    firewall start
    +
    shorewall stop
    +
    firewall stop
    +
    shorewall restart
    +
    firewall restart
    +
    shorewall add
    +
    firewall add
    +
    shorewall delete
    +
    firewall delete
    +
    shorewall refresh
    +
    firewall refresh
    +
    shorewall try
    +
    firewall -c <new configuration> restart
    + If unsuccessful then firewall start (standard configuration)
    + If timeout then firewall restart (standard configuration)
    +
    -
    - +
    +

    Updated 2/10/2003 - Tom Eastep -

    +

    - +

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

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

    -
    +
    +
    +