diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index 608264580..5d9b6761e 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -1,2934 +1,2949 @@ - + - + - + 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 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:

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

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

- -

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

- -

Warning 2: 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. - Columns in an entry are:

- - - -

My recommendations concerning options:
-

- - - -

- -

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

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

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

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

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

- -
- - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255
-
-
- -

/etc/shorewall/hosts - Configuration

- -

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

- -

WARNING: The only times that you need entries -in /etc/shorewall/hosts are:
-

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

Columns in this file are:

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

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

-
- - - -
-

routeback (Added in version 1.4.2) - This option causes Shorewall - to set up handling for routing packets sent by this host group back back -to the same group.
-
- maclist - Added in version 1.3.10. If specified, connection - requests from the hosts specified in this entry are subject to - MAC Verification. This option is only - valid for ethernet interfaces.
-

-
- -

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

- -

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

+

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:

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

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

+ +

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

+ +

Warning 2: 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. + Columns in an entry are:

+ + + +

My recommendations concerning options:
+

+ + + +

+ +

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

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

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

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

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

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255
+
+
+ +

/etc/shorewall/hosts + Configuration

+ +

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

+ +

WARNING: The only times that you need +entries in /etc/shorewall/hosts are:
+

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

Columns in this file are:

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

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

+
+ + + +
+

routeback (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets sent by this host group back back + to the same group.
+
+ maclist - Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to + MAC Verification. This option is only + valid for ethernet interfaces.
+

+
+ +

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

+ +

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

+

Example 1:

- -

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

- + +

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
-eth1192.168.1.127,192.168.1.255
-
-
-
- -

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

- -

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

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

Example 2:

- -

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

- - - -

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

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

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

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

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

Nested and Overlapping Zones

- -

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

- -

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

- -

/etc/shorewall/policy - Configuration.

- -

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

- -

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

- -

Four policies are defined:

- - - -

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

- -

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

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

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

- -

The policy file installed by default is as follows:

- -
- +
+ - + - - - - - - - - - - - - - - + + + + + + + + + + - - - - - - - - - - - - - - - + + + + + +
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT
-
-
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25
+
netallDROPinfo
-
allallREJECTinfo
-
loc2eth1:192.168.1.128/25
+
-
- -

This table may be interpreted as follows:

- +
+ +

Example 2:

+ +

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

+ - -

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.

- -
+ +

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

+ +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT
-
-
netallDROPinfo
-
loclocREJECTinfo
-
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,norfc1918
loc
+ 		eth1192.168.1.127,192.168.1.255
+
+
-
- -

IntraZone Traffic

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

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

- +
+ +

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

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

Nested and Overlapping +Zones

+ +

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

+ +

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

+ +

/etc/shorewall/policy + Configuration.

+ +

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

+ +

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

+ +

Four policies are defined:

+ + + +

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. Multiple 'net' interfaces to different ISPs. You don't want to route - traffic from one ISP to the other through your firewall.
    2. -
  2. Multiple VPN clients. You don't necessarily want them to all be -able to communicate between themselves using your gateway/router.
    -
    3. - +
  3. + SOURCE - The name of a client zone (a zone defined in +the /etc/shorewall/zones file + , the name of the firewall zone or "all").
    4. +
  4. + DEST - The name of a destination zone (a zone defined +in the /etc/shorewall/zones file , +the name of the firewall zone or "all"). Shorewall +automatically allows all traffic from the firewall to itself so the + name of the firewall zone cannot appear in both +the SOURCE and DEST columns.
    5. +
  5. + POLICY - The default policy for connection requests from + the SOURCE zone to the DESTINATION zone.
    6. +
  6. + 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.
    7. +
  7. 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.
    8. +
- -

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:

- -
+ +

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

+ +

The policy file installed by default is as follows:

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

/etc/shorewall/interfaces:

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

/etc/shorewall/hosts:

- -
- - - - - - - - - - + + + + + + + + + + + + + + - - - - - - - - + + + + + + + + + + + + + + + + + +
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT
+
-
sameth0:206.191.149.197
-
netallDROPinfo
+
allallREJECTinfo
+
-
+
+ +

This table may be interpreted as follows:

+ + + +

WARNING:

+ +

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

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

IntraZone Traffic

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

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.

+

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

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

The CONTINUE + policy

+ +

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

+ +

/etc/shorewall/zones:

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

/etc/shorewall/interfaces:

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

/etc/shorewall/hosts:

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

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

+

/etc/shorewall/policy:

- +
+ face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT
-
samallCONTINUE
-
netallDROPinfo
allallREJECTinfo
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT
+
samallCONTINUE
+
netallDROPinfo
allallREJECTinfo
-
- -

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

- + + +

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

+

Partial /etc/shorewall/rules:

- +
+ face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
...
-
-
-
-
-
-
DNATsamloc:192.168.1.3tcpssh-
-
DNATnetloc:192.168.1.5tcpwww-
-
...
-
-
-
-
-
-
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
...
+
+
+
+
+
+
DNATsamloc:192.168.1.3tcpssh-
+
DNATnetloc:192.168.1.5tcpwww-
+
...
+
+
+
+
+
+
-
- -

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

- -

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

- -
+
+ +

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

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

+
+
+
+
+
+
+
...
+
+
+
+
+
+
DNATnetloc:192.168.1.3tcpssh
-
-
DNATsamfwtcpssh-
+
DNATnet!samloc: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.

- -
+
+ +

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

+ +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
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
REDIRECTloc3128tcpwww -
+ 		!206.124.146.177
ACCEPTfwnettcpwww
+
+
+
+ +

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

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

Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded - DMZ. Your internet interface address is 155.186.235.151 - and you want the FTP server to be accessible from the internet - in addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24 - subnetworks. Note that since the server is in the 192.168.2.0/24 - subnetwork, we can assume that access to the server from that subnet - will not involve the firewall (but see FAQ - 2). Note that unless you have more than one external - 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 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 + - .

- + .

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

- -
+
+ +

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

+ +

passive ports 0.0.0.0/0 65500 65534

-
- -

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

- -

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

- -

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

- + + +

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

+ +

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

+ +

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

+
+ face="Century Gothic, Arial, Helvetica"> - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-
-
-
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
+
+
+
-
+ - Example 6. You wish to allow access to the SMTP server + Example 6. You wish to allow access to the SMTP server in your DMZ from all zones.
- -
+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		all
- 		dmz
- 		tcp
- 		25
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		all
+ 		dmz
+ 		tcp
+ 		25
+
+
+
-
- Note: When 'all' is used as a source or destination, - intra-zone traffic is not affected. In this example, if there - were two DMZ interfaces then the above rule would NOT enable SMTP +
+ 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 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
-
-
-
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 +
+ Using "DNAT-" rather than "DNAT" avoids two extra copies of the third rule from being generated.
- -

Look here for information on other services. -

- + +

Look here for information on other services. +

+

/etc/shorewall/common

- -

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

- -

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

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

+ +

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

- +

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

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

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

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

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

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

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

+ +

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.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24
+
-
- 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 +
+ +

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

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

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

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

Example 4: Same as example 3 except that + you wish 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:

- - - -

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:

- - - -

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
eth0:0192.168.12.0/24206.124.146.177
-
- -

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

-

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

- -

Columns in an entry are:

- - -

Look here for additional information and an example. -

-

- /etc/shorewall/tunnels

+

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:

-

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 in kernel compilation errors.

- -

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

- -

/etc/shorewall/shorewall.conf

- -

This file is used to set the following firewall parameters:

- + +

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 .

+ +

IMPORTANT: If all you want to do + is forward ports to + servers behind your firewall, you + do NOT want to use + static NAT. Port + forwarding can be + accomplished + with simple entries in + the rules + file. Also, in most + cases + Proxy ARP + provides a + superior solution +to static NAT because + the internal systems + are accessed + using the same IP address internally + and externally.

+ +

Columns in an entry are:

+ + + +

Look here for additional information and an example. +

+ +

+ /etc/shorewall/tunnels

+ +

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

+ +

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

+ +

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

+ +

/etc/shorewall/shorewall.conf

+ +

This file is used to set the following firewall parameters:

+ + - +

/etc/shorewall/modules Configuration

- -

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

- -

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

- + +

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

+ +

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

+

The loadmodule function is called as follows:

- -
-

loadmodule <modulename> [ + +

+

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:

- -
-

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 +

+
+ +

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

+
+ +

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

- -
-

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

-
- + +
+

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

+
+

/etc/shorewall/tos Configuration

- -

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

- + +

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:

- + +
  • DEST PORT(S) -- The + destination port or a port range. To indicate all ports, + place a hyphen ("-") in this column.
    • +
  • TOS -- The type of +service. Must be one of the following:
    • -
    -
    + + +
    +

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

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

    +
    -
    - -

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

    - -
    + +

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

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

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

    - +
    + +

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

    +

    /etc/shorewall/blacklist

    - -

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

    - + +

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

    + 
          130.252.100.69
          206.124.146.0/24
    - -

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

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

    - +

    +

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

    - +

    + - -

    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 (Shorewall also has a dynamic blacklist + capability.

    + +

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

    - +

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

    - -

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

    - + +

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

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

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

    - -

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

    - + +

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

    - -
    + +

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

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

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

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

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

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

    Updated 5/9/2003 - Tom Eastep -

    - +
    + +

    Updated 5/18/2003 - Tom Eastep +

    +

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

    -
    -
    -
    -
    -
    +

    diff --git a/Shorewall-docs/Install.htm b/Shorewall-docs/Install.htm index 08a399a6f..beaa34d49 100644 --- a/Shorewall-docs/Install.htm +++ b/Shorewall-docs/Install.htm @@ -1,226 +1,219 @@ - + Shorewall Installation - + - + - + - - - + + - - - + + + +
    -

    Shorewall Installation and +

    +

    Shorewall Installation and Upgrade

    -
    - +

    Before upgrading, be sure to review the Upgrade Issues
    -

    - -
    Before attempting installation, I strongly urge you to -read and print a copy of the Shorewall QuickStart Guide - for the configuration that most closely matches your own.
    -
    - +

    + +
    Before attempting installation, I strongly urge you +to read and print a copy of the Shorewall QuickStart Guide + for the configuration that most closely matches your own.
    +
    +

    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.

    - + - -

    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 - Guide for information about further steps required.

    - -

    If you already have the Shorewall RPM installed + +

    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 and are upgrading to a new version:

    - -

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

    - + +

    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.

    + - -

    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.

    - + +

    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.

    + - If you already have a running Bering + 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 the configuration files to match -your setup. In most cases, the Shorewall - QuickStart Guides contain all of the information you need.

    - - - -

    Updated 4/8/2003 - Tom Eastep -

    - -

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

    -
    -

    -
    -
    -
    -
    -
    +     UNDER CONSTRUCTION...
    + +

    Configuring Shorewall

    + +

    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.

    + + + +

    Updated 4/8/2003 - Tom Eastep +

    + +

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

    diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 67444dce3..ce8c60946 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -13,920 +13,900 @@ - + - + - + - - - + + - + + - - + +
    +
    - + +

    Shorewall News Archive

    -
    - -

    5/10/2003 - Shorewall Mirror in Asia
    -

    - -

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

    - -

    5/8/2003 - Shorewall Mirror in Chile

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

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

    - -

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

    - -

    4/9/2003 - Shorewall 1.4.2
    -

    - -

        Problems Corrected:

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

        New Features:

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

    3/24/2003 - Shorewall 1.4.1

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

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

    5/18/2003 - Shorewall 1.4.3

    - +     Problems Corrected:
    +
      -
    1. When Shorewall 1.4.0 is run under the ash shell (such as on Bering/LEAF), - it can attempt to add ECN disabling rules even if the /etc/shorewall/ecn - file is empty. That problem has been corrected so that ECN disabling rules +
    2. There were several cases where Shorewall would fail to remove a temporary +directory from /tmp. These cases have been corrected.
      3. +
    3. The rules for allowing all traffic via the loopback interface have +been moved to before the rule that drops status=INVALID packets. This insures +that all loopback traffic is allowed even if Netfilter connection tracking +is confused.
      4. +
    +     New Features:
    +     +
      +
    1.  IPV6-IPV4 (6to4) tunnels are now supported in the /etc/shorewall/tunnels +file.
      2. +
    2. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) + by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. Note: You may + not use ULOG with fireparse unless you modify fireparse.
      3. +
    +

    5/10/2003 - Shorewall Mirror in Asia
    +

    + +

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

    + +

    5/8/2003 - Shorewall Mirror in Chile

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

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

    + +

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

    + +

    4/9/2003 - Shorewall 1.4.2
    +

    + +

        Problems Corrected:

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

        New Features:

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

    3/24/2003 - Shorewall 1.4.1

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

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

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

    3/17/2003 - Shorewall 1.4.0

    - Shorewall 1.4 represents - the next step in the evolution of Shorewall. The main thrust of the -initial release is simply to remove the cruft that has accumulated in -Shorewall over time.
    -
    - IMPORTANT: Shorewall 1.4.0 requires the iproute package + 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 +
    + Function from 1.3 that has been omitted from this version include:
    - +
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no longer - supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      2. -
    2. Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate an error.
      -
      -
      3. -
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      4. -
    4. The 'routestopped' option in the /etc/shorewall/interfaces - and /etc/shorewall/hosts files is no longer supported and will generate - an error at startup if specified.
      -
      -
      5. -
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules -is no longer accepted.
      -
      -
      6. -
    6. The ALLOWRELATED variable in shorewall.conf is no longer - supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      -
      -
      7. -
    7. The icmp.def file has been removed.
      -
      8. - -
    - Changes for 1.4 include:
    - -
      -
    1. The /etc/shorewall/shorewall.conf file has been completely - reorganized into logical sections.
      -
      -
      2. -
    2. LOG is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      3. -
    3. The firewall script and version file are now installed - in /usr/share/shorewall.
      -
      -
      4. -
    4. Late arriving DNS replies are now silently dropped in -the common chain by default.
      -
      -
      5. -
    5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall - 1.4 no longer unconditionally accepts outbound ICMP packets. So if -you want to 'ping' from the firewall, you will need the appropriate -rule or policy.
      -
      -
      6. -
    6. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
      -
      -
      7. -
    7. 802.11b devices with names of the form wlan<n> now support - the 'maclist' option.
      -
      -
      8. -
    8. Explicit Congestion Notification (ECN - RFC 3168) may now be - turned off on a host or network basis using the new /etc/shorewall/ecn - file. To use this facility:
      -
      -    a) You must be running kernel 2.4.20
      -    b) You must have applied the patch in
      -    http://www.shorewall/net/pub/shorewall/ecn/patch.
      -    c) You must have iptables 1.2.7a installed.
      -
      -
      9. -
    9. The /etc/shorewall/params file is now processed first so that - variables may be used in the /etc/shorewall/shorewall.conf file.
      -
      -
      10. -
    10. Shorewall now gives a more helpful diagnostic when - the 'ipchains' compatibility kernel module is loaded and a 'shorewall -start' command is issued.
      -
      -
      11. -
    11. The SHARED_DIR variable has been removed from shorewall.conf. - This variable was for use by package maintainers and was not documented - for general use.
      -
      -
      12. -
    12. Shorewall now ignores 'default' routes when detecting masq'd - networks.
      13. - -
    - -

    3/10/2003 - Shoreall 1.3.14a

    - -

    A roleup of the following bug fixes and other updates:

    - - - - - -

    2/8/2003 - Shoreawall 1.3.14

    - -

    New features include

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

      6. -
    6. In /etc/shorewall/tcrules, the MARK value may be optionally - followed by ":" and either 'F' or 'P' to designate that the marking - will occur in the FORWARD or PREROUTING chains respectively. If this -additional specification is omitted, the chain used to mark packets will -be determined by the setting of the MARK_IN_FORWARD_CHAIN option in - shorewall.conf.
      -
      -
      7. -
    7. When an interface name is entered in the SUBNET column - of the /etc/shorewall/masq file, Shorewall previously masqueraded - traffic from only the first subnet defined on that interface. It - did not masquerade traffic from:
      -  
      -    a) The subnets associated with other addresses -on the interface.
      -    b) Subnets accessed through local routers.
      -  
      - Beginning with Shorewall 1.3.14, if you enter an interface - name in the SUBNET column, shorewall will use the firewall's routing - table to construct the masquerading/SNAT rules.
      -  
      - Example 1 -- This is how it works in 1.3.14.
      -   
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
      - - - 
         [root@gateway test]# shorewall start
         ...
         Masqueraded Subnets and Hosts:
             To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
             To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
         Processing /etc/shorewall/tos...
      -  
      - When upgrading to Shorewall 1.3.14, if you have multiple - local subnets connected to an interface that is specified in the - SUBNET column of an /etc/shorewall/masq entry, your /etc/shorewall/masq - file will need changing. In most cases, you will simply be able to remove - redundant entries. In some cases though, you might want to change from - using the interface name to listing specific subnetworks if the change - described above will cause masquerading to occur on subnetworks that you - don't wish to masquerade.
      -  
      - Example 2 -- Suppose that your current config is as - follows:
      -   
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, the second entry in /etc/shorewall/masq - is no longer required.
      -  
      - Example 3 -- What if your current configuration is -like this?
      -  
      - - - 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - - - 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, you would want to change the entry - in  /etc/shorewall/masq to:
      - - - 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      -
      8. - +
    8. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
      9. +
    9. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification + of the 'noping' or 'filterping' interface options.
      +
      +
      10. +
    10. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will generate + an error at startup if specified.
      +
      +
      11. +
    11. The Shorewall 1.2 syntax for DNAT and REDIRECT rules +is no longer accepted.
      +
      +
      12. +
    12. The ALLOWRELATED variable in shorewall.conf is no longer + supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
      +
      13. +
    13. The icmp.def file has been removed.
      +
      14. +
    - -


    - 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. -
    2. It is now possible to direct Shorewall to create - a "label" such as  "eth0:0" for IP addresses that it creates under - ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. This is done by specifying - the label instead of just the interface name:
      -  
      -    a) In the INTERFACE column of /etc/shorewall/masq
      -    b) In the INTERFACE column of /etc/shorewall/nat
      -  
      3. -
    3. When an interface name is entered in the SUBNET - column of the /etc/shorewall/masq file, Shorewall previously masqueraded - traffic from only the first subnet defined on that interface. It -did not masquerade traffic from:
      -  
      -    a) The subnets associated with other addresses +
    4. The /etc/shorewall/shorewall.conf file has been completely + reorganized into logical sections.
      +
      +
      5. +
    5. LOG is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
      6. +
    6. The firewall script and version file are now installed + in /usr/share/shorewall.
      +
      +
      7. +
    7. Late arriving DNS replies are now silently dropped in + the common chain by default.
      +
      +
      8. +
    8. 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.
      +
      +
      9. +
    9. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
      +
      +
      10. +
    10. 802.11b devices with names of the form wlan<n> now support + the 'maclist' option.
      +
      +
      11. +
    11. Explicit Congestion Notification (ECN - RFC 3168) may now +be turned off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility:
      +
      +    a) You must be running kernel 2.4.20
      +    b) You must have applied the patch in
      +    http://www.shorewall/net/pub/shorewall/ecn/patch.
      +    c) You must have iptables 1.2.7a installed.
      +
      +
      12. +
    12. The /etc/shorewall/params file is now processed first so that + variables may be used in the /etc/shorewall/shorewall.conf file.
      +
      +
      13. +
    13. Shorewall now gives a more helpful diagnostic when + the 'ipchains' compatibility kernel module is loaded and a 'shorewall +start' command is issued.
      +
      +
      14. +
    14. The SHARED_DIR variable has been removed from shorewall.conf. + This variable was for use by package maintainers and was not documented + for general use.
      +
      +
      15. +
    15. Shorewall now ignores 'default' routes when detecting masq'd + networks.
      16. + +
    + +

    3/10/2003 - Shoreall 1.3.14a

    + +

    A roleup of the following bug fixes and other updates:

    + + + + + +

    2/8/2003 - Shoreawall 1.3.14

    + +

    New features include

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


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

    + +

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

    + +

    Includes the Beta 2 content plus support for OpenVPN tunnels.

    + +

    1/28/2003 - Shorewall 1.3.14-Beta2

    +

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

    + +

    1/25/2003 - Shorewall 1.3.14-Beta1
    +

    + +

    The Beta includes the following changes:
    +

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

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

    - -

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

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

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

    1/17/2003 - shorewall.net has MOVED 

    - +

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

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

    +

    1/13/2003 - Shorewall 1.3.13
    -

    - +

    +

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

    - +

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

    1/6/2003 - BURNOUT -

    - -

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

    1/6/2003 - BURNOUT +

    + +

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

    - +

    -Tom Eastep
    -

    - +

    +

    12/30/2002 - Shorewall Documentation in PDF Format

    - -

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

    + +

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

    - +

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

    +

    - +

    12/27/2002 - Shorewall 1.3.12 Released

    - +

    Features include:
    -

    - +

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

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

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

    + Features include:
    +
      -
    1. "shorewall refresh" now reloads +
    2. "shorewall refresh" now reloads the traffic shaping rules (tcrules and tcstart).
      3. -
    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 +
    4. "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.
      5. -
    5. "shorewall [re]start" has been speeded - up by more than 40% with my configuration. Your milage may vary.
      6. -
    6. 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"
      7. -
    7. 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. +
    8. "shorewall [re]start" has been +speeded up by more than 40% with my configuration. Your milage +may vary.
      9. +
    9. 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"
      10. +
    10. 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 http://www.gnumonks.org/projects/ulogd) + and log all Shorewall messages to a separate log file.
      11. -
    11. If you are running a kernel that -has a FORWARD chain in the mangle table ("shorewall show mangle" - will show you the chains in the mangle table), you can set -MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for - marking input packets based on their destination even when you -are using Masquerading or SNAT.
      12. -
    12. I have cluttered up the /etc/shorewall - directory with empty 'init', 'start', 'stop' and 'stopped' - files. If you already have a file with one of these names, don't - worry -- the upgrade process won't overwrite your file.
      13. - +
    13. 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.
      14. +
    14. 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.
      15. +
    - 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 +

    + Shorewall is at the center of MandrakeSoft's recently-announced Multi + href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&id_art=250&LANG_=en#GOTO_250">Multi Network Firewall (MNF) product. Here is the press - release.
    + href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press + release.
    - +

    12/7/2002 - Shorewall Support for Mandrake 9.0

    - -

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

    + +

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

    - +

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

    +

    - +

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

    - +

    12/3/2002 - Shorewall 1.3.11a

    - -

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

    + +

    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:

    - + - +

    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

    + +

    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 -

    + +

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

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

    10/9/2002 - Shorewall 1.3.9b

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

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

    +

    - + - -

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

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

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

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

    + A couple of recent + configuration changes at www.shorewall.net had the + negative effect of breaking the Search facility:
    + + +
    1. Mailing List Archive Search was not available.
    2. The Site Search @@ -1043,2012 +1095,2003 @@ and 'version' files and the 'firewall' symbolic link
    3. Only one page of matches was presented.
      4. - - -
    -
    - Hopefully these - problems are now corrected. - -

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

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

    9/18/2002 -  Debian 1.3.8 Packages Available
    -

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

    +

    - + + +

    7/30/2002 - Shorewall 1.3.5b Released

    - +

    This interim release:

    - + +
  • Causes + the firewall script to remove the lock file if it is + killed.
    • +
  • Once +again allows lists in the second column of the + /etc/shorewall/hosts file.
    • +
  • 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 - available at Lorenzo Martignoni reports that the packages are version 1.3.5a and are + available at http://security.dsi.unimi.it/~lorenzo/debian.html.

    - +

    7/27/2002 - Shorewall 1.3.5a Released

    - +

    This interim release restores correct handling of REDIRECT rules.

    - +

    7/26/2002 - Shorewall 1.3.5 Released

    - -

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

    + +

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

    - +

     In this version:

    - + + href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/). + Specifying the proxyarp option for an interface + causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp. +
  • The Samples + have been updated to reflect the new capabilities + in this release.
    • + + +

    7/16/2002 - New Mirror in Argentina

    - -

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

    + +

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

    - +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

    - + +
  • A DETECT_DNAT_ADDRS + option has been added to /etc/shoreall/shorewall.conf. + When this option is selected, DNAT rules only apply when + the destination address is the external interface's + primary IP address.
    • +
  • The QuickStart Guide has + been broken into three guides and has been almost + entirely rewritten.
    • +
  • The Samples + have been updated to reflect the new capabilities + in this release.
    • + + +

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

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

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

    - + +
  • The "hits" + command has been enhanced.
    • + + +

    6/25/2002 - Samples Updated for 1.3.2

    - -

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

    + +

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

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

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

    + +

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

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + - +

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

    - -

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

    + +

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

    - + +
  • Should + be classified as weapons rather than tools.
    • -

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

    + + + +

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

    - -

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

    + +

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

    - +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/2/2002 - Samples Corrected

    - -

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

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

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

    + +

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

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

    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:

    - + - +

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

    + +

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

    - + +
  • Simplified + rule syntax which makes the intent of each rule clearer + 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

    - + - +

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - + + 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 - is now a Shorewall 1.2.11 + +

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

    - +

    4/13/2002 - Shorewall 1.2.11 Available

    - +

    In this version:

    - + - +

    4/13/2002 - Hamburg Mirror now has FTP

    - +

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

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

    - +

    4/12/2002 - New Mirror in Hamburg

    - -

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

    + +

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

    - +

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

    - -

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

    + +

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

    - +

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

    - -

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

    + +

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

    - +

    4/8/2002 - Parameterized Samples Withdrawn

    - +

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

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

    - +

    4/2/2002 - Updated Log Parser

    - -

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

    + +

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

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - -

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

    + +

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

    - +

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

    - + + href="http://packages.debian.org/unstable/net/shorewall.html">Debian + Unstable Distribution. + + +

    3/25/2002 - Log Parser Available

    - +

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

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

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

    - + - +

    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:

    - - - - - - - -

    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:

    - - - - - - -

    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:

    - - - - - - -

    1/28/2002 - Shorewall 1.2.4 Released

    - - - - - - -

    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:

    - - - - - - -

    The following problems were corrected:

    - - - - - -

    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

    - - - - - - -

    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:

    - - - - - - -

    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:

    - - - - - -

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

    - - - -

    In this version:

    - - - - - - -

    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:

    - - - +

    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:

    + + + + + + + +

    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:

    + + + + + + +

    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:

    + + + + + + +

    1/28/2002 - Shorewall 1.2.4 Released

    + + + + + + +

    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:

    + + + + + + +

    The following problems were corrected:

    + + + + + +

    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

    + + + + + + +

    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:

    + + + + + + +

    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:

    + + + + + + +

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

    + + + +

    In this version:

    + + + + + + + +

    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:

    + + + + + + +

    Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 + 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 + +

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

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

    - + - -

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

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

    + + + + +

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

    + - - -

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

    - - - - -

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

    + +

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

    - + - -

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

    + +

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

    - + - -

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

    + +

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

    - + - -

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

    + +

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

    - + - -

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

    + +

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

    - + - -

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

    + +

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

    - + - +

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

    - + - - -

    5/25/2001 - The current version of Shorewall is 1.1.6. 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

    - - - - - -

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

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

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

    + - + +

    5/25/2001 - The current version of Shorewall is 1.1.6. 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

    + + + + + +

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

    + + + + + +

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

    + + + - +

    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:

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

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

    - + - -

    3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix + +

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

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

    + - -

    Updated 5/10/2003 - Tom Eastep -

    + +

    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 5/18/2003 - Tom Eastep +

    + +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    -
    +
    +

    diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index ef4105bdf..c1cbb868b 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -2,372 +2,300 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - - + + - - - - + + + + +
    + - +

    Shorwall Logo - (Shorewall Logo) -

    - + + + - -
    + +
    - +

    Shorewall 1.4 "iptables made easy"
    -
    +
    -

    -
    + +
    +

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

    What is it?

    - -

    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.

    - -

    This program is free software; you can redistribute it and/or modify - it + +

    This program is free software; you can redistribute it and/or modify + it under the terms of Version 2 of the -GNU General Public License as published by the Free Software - Foundation.
    -
    - This - program is distributed in the hope that - it will be useful, but WITHOUT ANY WARRANTY; - without even the implied warranty of MERCHANTABILITY - or FITNESS FOR A PARTICULAR PURPOSE. See -the GNU General Public License for more details.
    -
    - 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

    + href="http://www.gnu.org/licenses/gpl.html">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.
    + +
    + 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

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    + + +

    Running Shorewall on Mandrake with a two-interface setup?

    + If so, almost NOTHING on this site will apply directly to your setup. + If you want to use the documentation that you find here, it is best if you + uninstall what you have and install a setup that matches the documentation + on this site. See the Two-interface QuickStart + Guide for details.
    + +

    Getting Started with Shorewall

    + New to Shorewall? Start by selecting the QuickStart Guide that most closely + match your environment and follow the step by step instructions.
    -


    -Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
    -
    -

    News

    - -

    5/10/2003 - Shorewall Mirror in Asia 5/18/2003 - Shorewall 1.4.3 (New) -
    +

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

    5/8/2003 - Shorewall Mirror in Chile (New) -  

    - +     Problems Corrected:
    +     +
      +
    1. There were several cases where Shorewall would fail to remove + a temporary directory from /tmp. These cases have been corrected.
      2. +
    2. The rules for allowing all traffic via the loopback interface + have been moved to before the rule that drops status=INVALID packets. This + insures that all loopback traffic is allowed even if Netfilter connection + tracking is confused.
      3. + +
    +     New Features:
    +     +
      +
    1.  IPV6-IPV4 (6to4) tunnels are now supported +in the /etc/shorewall/tunnels file.
      2. +
    2. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) + by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. +Note: You may not use ULOG with fireparse unless you modify fireparse.
      3. + +
    + +

    5/10/2003 - Shorewall Mirror in Asia
    +

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

    5/8/2003 - Shorewall Mirror in Chile  

    +

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

    - -

    4/26/2003 - lists.shorewall.net Downtime (New) -

    - +

    + +

    4/26/2003 - lists.shorewall.net Downtime

    + +

    The list server will be down this morning for upgrade to RH9.0.
    -

    - -

    4/21/2003 - Samples updated for Shorewall version 1.4.2 - (New) -

    +

    + +

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

    + + +

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

    + + +

    4/12/2002 - Greater Seattle Linux Users Group Presentation +

    + + +
    This morning, I gave a + Shorewall presentation to GSLUG. The presentation is in + HTML format but was generated from Microsoft PowerPoint and is best viewed + using Internet Explorer (although Konqueror also seems to work reasonably + well as does Opera 7.1.0). Neither Opera 6 nor Netscape work well to +view the presentation.
    +
    + + +

    -

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

    +
    +
      - -

      4/12/2002 - Greater Seattle Linux Users Group Presentation (New) -

      - -
      This morning, I gave a - Shorewall presentation to GSLUG. The presentation is in -HTML format but was generated from Microsoft PowerPoint and is best viewed - using Internet Explorer (although Konqueror also seems to work reasonably - well as does Opera 7.1.0). Neither Opera 6 nor Netscape work well to view - the presentation.
      + +
    - -

    4/9/2003 - Shorewall 1.4.2 (New) -
    -

    - - -

    Problems Corrected:

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

    New Features:

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

    More News

    - + +

    (Leaf Logo) - Jacques - Nilo and Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution - called Bering that + 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.2!!!
    + Congratulations to Jacques and Eric on the recent release of Bering + 1.2!!!
    +

    Donations

    -     		- + +
    -
    - Note:     Search is unavailable Daily 0200-0330 GMT.
    - - + action="http://lists.shorewall.net/cgi-bin/htsearch"> +
    + Note: +     Search is unavailable +Daily 0200-0330 GMT.
    + +

    Quick Search
    -

    -
    - +

    Extended Search

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

    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 5/12/2003 - Tom Eastep -
    -

    + +

    Updated 5/18/2003 - Tom Eastep +
    +
    +

    +
    diff --git a/Shorewall-docs/shorewall_quickstart_guide.htm b/Shorewall-docs/shorewall_quickstart_guide.htm index 480b4ce68..80dde2b5b 100644 --- a/Shorewall-docs/shorewall_quickstart_guide.htm +++ b/Shorewall-docs/shorewall_quickstart_guide.htm @@ -1,295 +1,305 @@ - + - + - + - + Shorewall QuickStart Guide - + - + - - - + + - - - + Version 4.0 + + + +
    - -

    Shorewall QuickStart Guides +

    + +

    Shorewall QuickStart Guides (HOWTO's)
    - Version 4.0

    -
    - -

    With thanks to Richard who reminded me once again that -we must all first walk before we can run.
    - The French Translations are courtesy of Patrice Vetsel
    -

    - + +

    With thanks to Richard who reminded me once again that we +must all first walk before we can run.
    + The French Translations are courtesy of Patrice Vetsel
    +

    +

    The Guides

    - -

    These guides provide step-by-step instructions for configuring Shorewall + +

    These guides provide step-by-step instructions for configuring Shorewall in common firewall setups.

    - +

    The following guides are for users who have a single public IP address:

    - + - -

    The above guides are designed to get your first firewall up and running + +

    The above guides are designed to get your first firewall up and running quickly in the three most common Shorewall configurations.

    - -

    The Shorewall Setup Guide (See - Index Below) outlines the steps necessary to set up a firewall - where there are multiple public IP addresses involved or -if you want to learn more about Shorewall than is explained in + +

    The Shorewall Setup Guide (See + Index Below) outlines the steps necessary to set up a firewall + where there are multiple public IP addresses involved or +if you want to learn more about Shorewall than is explained in the single-address guides above.

    - +
      - +
    - +

    Documentation Index

    - -

    The following documentation covers a variety of topics and supplements - the QuickStart Guides - described above. Please review the appropriate guide before + +

    The following documentation covers a variety of topics and supplements + the QuickStart Guides + described above. Please review the appropriate guide before trying to use this documentation directly.

    - + - +

    If you use one of these guides and have a suggestion for improvement please let me know.

    - -

    Last modified 5/03/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 Thomas M. + +

    Last modified 5/18/2003 - Tom Eastep

    + +

    Copyright 2002, 2003 Thomas M. Eastep
    -

    +

    +



    diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index bb1b38554..c9b8557ed 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -2,374 +2,304 @@ - + Shoreline Firewall (Shorewall) 1.3 - + - + - - + + - - - - + + + + + +
    + - +

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

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

    What is it?

    - -

    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.

    - -

    This program is free software; you can redistribute it and/or modify - it + +

    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.
    + href="http://www.gnu.org/licenses/gpl.html">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 +
    + 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

    + this program; if not, write to the Free Software + Foundation, Inc., 675 Mass Ave, Cambridge, + MA 02139, USA

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    - + + +

    Running Shorewall on Mandrake with a two-interface setup?

    + If so, almost NOTHING on this site will apply directly to your setup. + If you want to use the documentation that you find here, it is best if you + uninstall what you have and install a setup that matches the documentation + on this site. See the Two-interface QuickStart + Guide for details.
    +

    Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
    - -

    News

    - - - -

    5/10/2003 - Shorewall Mirror in Asia (New) -
    -

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

    5/8/2003 - Shorewall Mirror in Chile (New) -  

    - -

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

    - -

    4/26/2003 - lists.shorewall.net Downtime (New) -  

    - -

    The list server will be down this morning for upgrade to RH9.0.
    -

    - -

    4/21/2003 - Samples updated for Shorewall version 1.4.2 (New) -

    - -

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

    + New to Shorewall? Start by selecting the QuickStart Guide that most closely + match your environment and follow the step by step instructions.
    -

    4/12/2002 - Greater Seattle Linux Users Group Presentation (New) -

    +

    News

    + - -
    This morning, I gave a Shorewall presentation to GSLUG. The presentation - is in HTML format but was generated from Microsoft PowerPoint and is -best viewed using Internet Explorer (although Konqueror also seems to -work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape -work well to view the presentation.
    - - -

    4/9/2003 - Shorewall 1.4.2 (New) -
    + +

    5/18/2003 - Shorewall 1.4.3 (New) +
    +

    +     Problems Corrected:
    +     +
      +
    1. There were several cases where Shorewall would fail to remove + a temporary directory from /tmp. These cases have been corrected.
      2. +
    2. The rules for allowing all traffic via the loopback interface + have been moved to before the rule that drops status=INVALID packets. This + insures that all loopback traffic is allowed even if Netfilter connection + tracking is confused.
      3. + +
    +     New Features:
    +     +
      +
    1.  IPV6-IPV4 (6to4) +tunnels are now supported in the /etc/shorewall/tunnels file.
      2. +
    2. Shorewall can now be easily integrated with fireparse (http://www.fireparse.com) + by setting LOGMARKER="fp=" in /etc/shorewall/shorewall.conf. +Note: You may not use ULOG with fireparse unless you modify fireparse.
      3. + +
    + +

    5/10/2003 - Shorewall Mirror in Asia
    +

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

    5/8/2003 - Shorewall Mirror in Chile  

    + +

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

    + +

    4/26/2003 - lists.shorewall.net Downtime  

    + +

    The list server will be down this morning for upgrade to RH9.0.

    + +

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

    - -

        Problems Corrected:

    + +

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

    - -
    + +

    4/12/2002 - Greater Seattle Linux Users Group Presentation +

    - + +
    This morning, I gave a Shorewall presentation to GSLUG. The presentation + is in HTML format but was generated from Microsoft PowerPoint and is + best viewed using Internet Explorer (although Konqueror also seems to + work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape + work well to view the presentation.
    + + +

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

        New Features:

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

    - + - +

    More News

    - + - +

    - + - +

    (Leaf Logo) - 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.2!!!
    + Congratulations to Jacques and Eric on + the recent release of Bering 1.2!!!
    +

    SourceForge Logo -

    - + + - +

    - + - +

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

    - + - +

    Donations

    -     		- +
    - + action="http://lists.shorewall.net/cgi-bin/htsearch"> +


    - Note:     - Search is unavailable Daily 0200-0330 GMT.
    -  

    - + Note: + Search is unavailable Daily 0200-0330 +GMT.
    +  

    +

    Quick Search
    - - +

    - -
    - + + +

    Extended Search

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

    -

    + +

    - -

    Shorewall is free -but if you try it and find it useful, please consider making a donation - to - Starlight + +

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

    -
    - -

    Updated 5/10/2003 - Tom Eastep -
    + +

    Updated 5/18/2003 - Tom Eastep +