diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index c7d295e72..fd1bb25b3 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -2,3571 +2,3590 @@ - + - + - + Shorewall 1.4 Documentation - - + + - + - + - + - - - + + - + + - - + +
+
- +

Shorewall 1.4 Reference

-
- -

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

- +

Components

- +

Shorewall consists of the following components:

- + - -

/etc/shorewall/params

- - -

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

- - -

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

- - -

Example:

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

Example (/etc/shorewall/interfaces record):

- -
	net $NET_IF $NET_BCAST $NET_OPTIONS
- -

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

- -
	net eth0 130.252.100.255 blacklist,norfc1918
- -

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

- - -

/etc/shorewall/zones

- - -

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

- - - - -

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

+

/etc/shorewall/params

+

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

+ + +

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

+ + +

Example:

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

Example (/etc/shorewall/interfaces record):

+ +
	net $NET_IF $NET_BCAST $NET_OPTIONS
+ +

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

+ +
	net eth0 130.252.100.255 blacklist,norfc1918
+ +

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

+ + +

/etc/shorewall/zones

+ + +

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

+ + + + + +

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

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

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

+ +

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

- +

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

+ color="#ff0000"> If you rename or delete a zone, you should perform "shorewall + stop; shorewall start" to install the change rather than +"shorewall restart".

- +

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

+ color="#ff0000">The order of entries in the /etc/shorewall/zones file is + significant in some cases.

- +

/etc/shorewall/interfaces

- -

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

- + +

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:

+

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

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

+ +

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

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

+
+
-
+
- -

/etc/shorewall/hosts - Configuration

+ +

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

- -

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

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

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

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

+ +

Columns in this file are:

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

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

-
+
+ + + + + +
+

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

+
+ + +

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

+ + +

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

+ + + + +

Example:

+ + +

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

+ + -
- - -

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

-
- - -

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

- - -

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

- - - - -

Example:

- - -

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

- - - - -

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

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

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

- - -

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

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

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

- - - -

Nested and Overlapping Zones

- - - -

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

- - - -

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

- - - -

- /etc/shorewall/policy Configuration.

- + +
-

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

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

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

+ + - -

Four policies are defined:

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

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

+

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

+ + + +

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

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

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

+ + + +

Nested and Overlapping +Zones

+ + + +

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

+ + + +

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

+ + + +

+ /etc/shorewall/policy Configuration.

+ + +

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

+ + + +

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

+ + + +

Four policies are defined:

+ + + +

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

+ + +

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

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

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

+ +

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

- +

The policy file installed by default is as follows:

- +
- - + face="Century Gothic, Arial, Helvetica"> + + - - - - - - - - - - - - - + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT
-
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT
+
-
netallDROPinfo
-
allallREJECTinfo
-
-
- - - -

This table may be interpreted as follows:

- - - - - -

WARNING:

- - -

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

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

+
netallDROPinfo
+
allallREJECTinfo
+
-
+ + + + +

This table may be interpreted as follows:

+ + + -

- The CONTINUE policy

+

WARNING:

-

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

+

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

-

/etc/shorewall/zones:

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

/etc/shorewall/interfaces:

+

+ The CONTINUE policy

+ + +

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

+ + +

/etc/shorewall/zones:

- - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + - + - +
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
-
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
-
+ -

/etc/shorewall/hosts:

+

/etc/shorewall/interfaces:

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

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

+

/etc/shorewall/hosts:

-

/etc/shorewall/policy:

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

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

+

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

-

Partial /etc/shorewall/rules:

+

/etc/shorewall/policy:

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

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

+

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

+ + +

Partial /etc/shorewall/rules:

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

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

-
-
-
-
-
-
-
...
-
-
-
-
-
-

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

+ +

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

+ +

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

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

+ +

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

+

- +

Entries in the file have the following columns:

- + - +

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

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

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

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

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

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

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

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

+ +

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

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

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

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

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

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

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

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

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

- + + +
+ + +

passive ports 0.0.0.0/0 65500 65534

-
+
- -

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

+ +

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.

+ +

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

- -

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

+ +

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

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

Look here for information on other services. -

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

- /etc/shorewall/common

+ + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.178
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.179
+
ACCEPT
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+
+
+
+
+ Using "DNAT-" rather than "DNAT" avoids two extra copies +of the third rule from being generated.
+ +

Look here for information on other services. +

-

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

+

+ /etc/shorewall/common

- -

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

+ +

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

- -

- /etc/shorewall/masq

+ +

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

- -

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

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

- +

Columns are:

- + - -

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

+ +

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

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

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

- - +
- + - + - - - - - - - - - - + + + + + + + + + + - + - +
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24
-
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24
+
-
+ - -

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

+ +

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

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

+ + +

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

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

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

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

+ /etc/shorewall/proxyarp

+ + + + +

If you want to + use proxy ARP on an + entire sub-network, + I suggest that you + look at + + http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. + + If you decide to use + the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by + including the + proxyarp option + in the interface's + record in + + /etc/shorewall/interfaces. + When using +Proxy ARP + sub-netting, you do + NOT include + any entries in + /etc/shorewall/proxyarp.

+ + + + +

The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is + typically used for + enabling Proxy ARP + on a small set of + systems since you + need one entry + in + this file for each + system using proxy + ARP. Columns are:

+ + + +

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

-

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

- -

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

+

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.

- -

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:

- + +

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

+ - - -

Look here for additional information and an example. - -

- - - -

- /etc/shorewall/tunnels

- - - -

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

- - - - -

- /etc/shorewall/modules Configuration

+ +

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:

+ +
- -

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

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

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

- - - - -

The loadmodule function is called as follows:

- - - - -
- -

loadmodule - <modulename> - [ <module parameters> ]

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

- -

where

+ +

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

+ + + + + + +

+ /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 loadmodule function is called as follows:

+ + + + +
+

loadmodule + <modulename> + [ <module parameters> ]

+
+ + + + +

where

+ + + + +
+ + + +

<modulename>

- -
+ +
-

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

-
+ +

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

+
- +

<module parameters>

- -
+ +
- +

Optional parameters to the insmod utility.

-
-
+
+
- -

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

+ +

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

- -
+ +
- -

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

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

+
+ + + + +

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

+ + + + +
+ + + + +

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

-
- - - - -

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

- - - - -
- - - - -

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

-
- - - - -

- /etc/shorewall/tos Configuration

+
-

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

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

- +

Entries in the file have the following columns:

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

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

-
-
- - - -

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

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

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

+
+
+ + + +

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

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

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

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

Packets + from + hosts + listed + in + + the + blacklist + file + will + be - the - blacklist - file - will + disposed + of + according + to + the -be - disposed - of - according - to - the + value + assigned + to + the BLACKLIST_DISPOSITION + + and BLACKLIST_LOGLEVEL variables - value - assigned - to - the BLACKLIST_DISPOSITION + in + /etc/shorewall/shorewall.conf. + Only + packets + + arriving + on + interfaces + that + have - and BLACKLIST_LOGLEVEL variables + the + 'blacklist' + option + + in + /etc/shorewall/interfaces + are + checked - 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 + 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.

+ +

Shorewall also has a dynamic blacklist + capability.

- -

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

- +

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

- -

This file lists the subnets affected by the norfc1918 - 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: - - -
      - -
    • RETURN - Process the packet - normally thru the rules and policies.
      • - -
    • DROP - Silently drop the - packet.
      • - -
    • logdrop - Log then drop -the packet -- see the RFC1918_LOG_LEVEL parameter -above.
      • - - - - -
    - -
    • - -
- - - - - -

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

- - - - - -

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

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

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

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

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: + + +
      + +
    • RETURN - Process the packet + normally thru the rules and policies.
      • + +
    • DROP - Silently drop the + packet.
      • + +
    • logdrop - Log then drop + the packet -- see the RFC1918_LOG_LEVEL parameter + above.
      • + + + + +
    + +
    • + +
+ + + + + +

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

+ + + + + +

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

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

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

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

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

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

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

Updated 2/18/2003 - Tom Eastep

- +

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

+

+


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

GRE and IPIP Tunnels

-
+ + + + + +
+

GRE and IPIP Tunnels

+
-

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

-

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

-

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

+ +

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

+ +

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

+ +

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

+

Bridging two Masqueraded Networks

+

Suppose that we have the following situation:

-

-

-

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

-

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

-

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

+

+ +

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

+ +

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

+ +

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

+

Example:

-
-

tunnel_type=gre

-
-

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

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

tunnel_type=gre

-

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

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

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

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

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

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

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

-

In the tunnel script on system A:

-
-

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

-
-

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

+ +

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

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

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

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

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

+ +

In the tunnel script on system A:

+ +
+

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

+
+ +

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

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

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

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

And in the tunnel script on system B:

-
+ +

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

-
-

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

- -

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

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

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

-

Updated 8/22/2002 - Tom -Eastep

-

Copyright -© 2001, 2002 Thomas M. Eastep.

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

+
+ +

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

+ +

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

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

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

+ +

Updated 2/22/2003 - Tom Eastep +

+ +

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

+
- diff --git a/Shorewall-docs/MAC_Validation.html b/Shorewall-docs/MAC_Validation.html index 76184b5cc..f0ea5b7b7 100644 --- a/Shorewall-docs/MAC_Validation.html +++ b/Shorewall-docs/MAC_Validation.html @@ -2,109 +2,111 @@ MAC Verification - + - + - + - - - + + - - - + +
+ + + +
- +
+

MAC Verification
-

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

Example 1: Here are my files:

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

Example 2: Router in Local Zone

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

Updated 2/18/2002 - Tom Eastep + This entry accomodates traffic from the router itself (192.168.1.253) + and from the second LAN segment (192.168.2.0/24). Remember that all traffic + being sent to my firewall from the 192.168.2.0/24 segment will be forwarded + by the router so that traffic's MAC address will be that of the router +(00:06:43:45:C6:15) and not that of the host sending the traffic. + +

Updated 2/21/2002 - Tom Eastep

- -

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

+ +

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

+

diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 35e3ef5b0..891e46fa6 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -3,7 +3,7 @@ - + Shorewall News @@ -11,607 +11,570 @@ - + - + - + - - - + + - + + - - + +
+
- +

Shorewall News Archive

-
- +

3/14/2003 - Shorewall 1.4.0

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

2/8/2003 - Shoreawall 1.3.14

- -

New features include

- -
    -
  1. An OLD_PING_HANDLING option has been added to shorewall.conf. -When set to Yes, Shorewall ping handling is as it has always been (see -http://www.shorewall.net/ping.html).
    -
    - When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules - and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options in - /etc/shorewall/interfaces will all generate an error.
    -
    -
    2. -
  2. It is now possible to direct Shorewall to create a "label" such - as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
    -  
    -    a) In the INTERFACE column of /etc/shorewall/masq
    -    b) In the INTERFACE column of /etc/shorewall/nat
    -  
    3. -
  3. Support for OpenVPN Tunnels.
    -
    -
    4. -
  4. Support for VLAN devices with names of the form $DEV.$VID (e.g., - eth0.0)
    +
  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 +
  7. Interface names of the form <device>:<integer> in /etc/shorewall/interfaces + now generate an error.
    +
    +
    8. +
  8. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification + of the 'noping' or 'filterping' interface options.
    +
    +
    9. +
  9. 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.
    +
    +
    10. +
  10. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
    +
    +
    11. +
  11. The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
    +
    +
    12. +
  12. The icmp.def file has been removed.
    +
    13. + +
+ Changes for 1.4 include:
+ +
    +
  1. The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
    +
    +
    2. +
  2. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    3. +
  3. The firewall script and version file are now installed in /usr/share/shorewall.
    +
    +
    4. +
  4. Late arriving DNS replies are now silently dropped in the common +chain by default.
    +
    +
    5. +
  5. In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 +no longer unconditionally accepts outbound ICMP packets. So if you want to +'ping' from the firewall, you will need the appropriate rule or policy. +
    6. + +
+ +

2/8/2003 - Shoreawall 1.3.14

+ +

New features include

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


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


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

+ +

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

+ +

Includes the Beta 2 content plus support for OpenVPN tunnels.

+ +

1/28/2003 - Shorewall 1.3.14-Beta2

+

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

+ +

1/25/2003 - Shorewall 1.3.14-Beta1
+

+ +

The Beta includes the following changes:
+

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

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

- -

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

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

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

1/17/2003 - shorewall.net has MOVED 

- +

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

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

+

1/13/2003 - Shorewall 1.3.13
-

- +

+

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

- +

+
    -
  1. A new 'DNAT-' action has been added for entries in the - /etc/shorewall/rules file. DNAT- is intended for advanced users who - wish to minimize the number of rules that connection requests must traverse.
    -
    - A Shorewall DNAT rule actually generates two iptables rules: - a header rewriting rule in the 'nat' table and an ACCEPT rule in the - 'filter' table. A DNAT- rule only generates the first of these rules. - This is handy when you have several DNAT rules that would generate the - same ACCEPT rule.
    -
    -    Here are three rules from my previous rules file:
    -
    -         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178
    -         DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...
    -
    -    These three rules ended up generating _three_ copies of
    -
    -          ACCEPT net  dmz:206.124.146.177 tcp smtp
    -
    -    By writing the rules this way, I end up with only one copy - of the ACCEPT rule.
    -
    -         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178
    -         DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179
    -         ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....
    -
    -
    2. -
  2. The 'shorewall check' command now prints out the applicable +
  3. 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,....
    +
    +
    4. +
  4. The 'shorewall check' command now prints out the applicable policy between each pair of zones.
    -
    -
    5. -
  5. 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.
    -
    -
    6. -
  6. 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.
    -
    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 page in "shorewall - monitor"
    5. -
  5. ULOG (must be all caps) is now accepted as a valid - syslog level and causes the subject packets to be logged using -the ULOG target rather than the LOG target. This allows you to run -ulogd (available from http://www.gnumonks.org/projects/ulogd) - and log all Shorewall messages to a separate log file.
    6. -
  6. If you are running a kernel that has a FORWARD chain - in the mangle table ("shorewall show mangle" will show you the -chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes -in shorewall.conf. This allows for - marking input packets based on their destination even when you are -using Masquerading or SNAT.
    7. -
  7. I have cluttered up the /etc/shorewall directory -with empty 'init', 'start', 'stop' and 'stopped' files. If you -already have a file with one of these names, don't worry -- the upgrade -process won't overwrite your file.
    8. -
  8. I have added a new RFC1918_LOG_LEVEL variable to - shorewall.conf. This variable specifies - the syslog level at which packets are logged as a result of entries - in the /etc/shorewall/rfc1918 file. Previously, these packets were -always logged at the 'info' level.
    -
    9. - -
- -

12/20/2002 - Shorewall 1.3.12 Beta 3
-

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

-

12/20/2002 - Shorewall 1.3.12 Beta 2

- -

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

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

12/20/2002 - Shorewall 1.3.12 Beta 3
+

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

12/20/2002 - Shorewall 1.3.12 Beta 2

+ +

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

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

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

- Shorewall is at the center of MandrakeSoft's recently-announced - Multi +

+ Shorewall is at the center of MandrakeSoft's recently-announced + 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.

- -

11/24/2002 - Shorewall 1.3.11

- -

In this version:

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

11/14/2002 - Shorewall Documentation in PDF Format

- -

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

- -

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

- -

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

- - -

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

- - -

11/09/2002 - Shorewall 1.3.10

- -

In this version:

- - - -

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

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

10/23/2002 - Shorewall 1.3.10 Beta 1

- In this version:
+

+

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

+ +

12/3/2002 - Shorewall 1.3.11a

+ +

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

+ +

11/24/2002 - Shorewall 1.3.11

+ +

In this version:

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

11/14/2002 - Shorewall Documentation in PDF Format

+ +

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

+ +

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

+ +

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

+ + +

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

+ + +

11/09/2002 - Shorewall 1.3.10

+ +

In this version:

+
  • You may now define the contents of a zone dynamically - with the "shorewall add" -and "shorewall delete" commands. These commands are expected - to be used primarily within FreeS/Wan updown -scripts.
    • + href="IPSEC.htm#Dynamic">define the contents of a zone dynamically + with the "shorewall add" + and "shorewall delete" commands. These commands are expected + to be used primarily within FreeS/Wan updown scripts.
  • Shorewall can now do MAC verification on ethernet segments. - You can specify the set of allowed MAC addresses on the segment - and you can optionally tie each MAC address to one or more IP - addresses.
    • + href="MAC_Validation.html"> MAC verification on ethernet +segments. You can specify the set of allowed MAC addresses on the +segment and you can optionally tie each MAC address to one or more +IP addresses.
  • PPTP Servers and Clients running on the firewall system may now be defined in the /etc/shorewall/tunnels file.
    • @@ -621,95 +584,159 @@ on the firewall system may now be defined in theThe PATH used by Shorewall may now be specified in /etc/shorewall/shorewall.conf.
  • The main firewall script is now /usr/lib/shorewall/firewall. - The script in /etc/init.d/shorewall is very small and uses - /sbin/shorewall to do the real work. This change makes custom - distributions such as for Debian and for Gentoo easier to manage - since it is /etc/init.d/shorewall that tends to have distribution-dependent - code.
    • - -
- You may download the Beta from:
- - - -

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

- - -

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

- -

10/9/2002 - Shorewall 1.3.9b

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

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

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

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

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

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

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

9/28/2002 - Shorewall 1.3.9

+

10/23/2002 - Shorewall 1.3.10 Beta 1

+ In this version:
- -

In this version:
-

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

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

- + +

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

+ +

10/9/2002 - Shorewall 1.3.9b

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

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

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

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

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

9/28/2002 - Shorewall 1.3.9

+ + +

In this version:
+

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

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

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

- + Brown Paper Bag - A couple of recent configuration + 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 index @@ -717,1799 +744,1791 @@ was incomplete
  3. Only one page of matches was presented.
    4. - - -
-
- Hopefully these problems are - now corrected. -

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

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

9/18/2002 -  Debian 1.3.8 Packages Available
-

- +

9/18/2002 -  Debian 1.3.8 Packages Available
+

+ +

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

- +

9/16/2002 - Shorewall 1.3.8

- +

In this version:
-

+

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

    9/11/2002 - Debian 1.3.7c Packages Available

    - +

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

    - +

    9/2/2002 - Shorewall 1.3.7c

    - -

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

    + +

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

    - +

    8/31/2002 - I'm not available

    - -

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

    + +

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

    - +

    -Tom

    - +

    8/26/2002 - Shorewall 1.3.7b

    - -

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

    + +

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

    - +

    8/26/2002 - French FTP Mirror is Operational

    - +

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

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

    - +

    8/25/2002 - Shorewall Mirror in France

    - -

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

    - +

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

    - -

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

    - -

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

    +

    - -

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

    + +

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

    - +

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

    - +

    Features in this release include:

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

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

    + +

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

    - +

    8/13/2002 - Documentation in the CVS Repository

    - -

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

    + +

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

    - +

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

    - -

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

    + +

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

    - -

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

    + +

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

    - -

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

    + +

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

    - +

    8/7/2002 - Shorewall 1.3.6

    - +

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

    - + +
  • The processing of +"New not SYN" packets may be extended by commands in + the new newnotsyn extension + script.
    • +
+ +

7/30/2002 - Shorewall 1.3.5b Released

- +

This interim release:

- +
    -
  • Causes the firewall +
  • Causes the firewall script to remove the lock file if it is killed.
    • -
  • Once again allows +
  • Once again allows lists in the second column of the /etc/shorewall/hosts file.
    • -
  • Includes the latest +
  • 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:

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

    7/16/2002 - New Mirror in Argentina

    - -

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

    + +

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

    - +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

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

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

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

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

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

    6/25/2002 - Samples Updated for 1.3.2

    - -

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

    + +

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

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/19/2002 - Documentation Available in PDF Format

    - -

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

    + +

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

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + +
  • The files firewall, + functions and version have been + moved from /etc/shorewall to /var/lib/shorewall.
    • + + +

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

    - -

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

    + +

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

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

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

    + - -

    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.

    + +

    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.

    + +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/2/2002 - Samples Corrected

    - -

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

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

    - + - +

    5/29/2002 - Shorewall 1.3.0 Released

    - -

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

    + +

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

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

    5/23/2002 - Shorewall 1.3 RC1 Available

    - -

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

    + +

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

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

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - -

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

    + +

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

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

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - -

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

    + +

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

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

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + - +

    4/30/2002 - Shorewall Debian News

    - -

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

    + +

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

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

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

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - + +
  • Shorewall 1.2.10 +is in the Debian + Testing Branch
    • +
  • Shorewall 1.2.11 +is in the 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:

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

    4/13/2002 - Hamburg Mirror now has FTP

    - +

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

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

    - +

    4/12/2002 - New Mirror in Hamburg

    - -

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

    + +

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

    - +

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

    - -

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

    + +

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

    - +

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

    - -

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

    + +

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

    - +

    4/8/2002 - Parameterized Samples Withdrawn

    - +

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

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

    - +

    4/2/2002 - Updated Log Parser

    - -

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

    + +

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

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - -

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

    + +

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

    - +

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

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

    3/25/2002 - Log Parser Available

    - +

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

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

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

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

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - + - - -

    3/1/2002 - 1.2.8 Debian Package is Available

    - - -

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

    - - -

    2/25/2002 - New Two-interface Sample

    - - -

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

    - -

    2/23/2002 - Shorewall 1.2.8 Released

    - - -

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

    - - -

    2/22/2002 - Shorewall 1.2.7 Released

    - - -

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    - - -

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

    - - -

    2/8/2002 - Shorewall 1.2.6 Released

    - - -

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    - - -

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

    - - -

    2/1/2002 - Shorewall 1.2.5 Released

    - - -

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

    - - -

    In version 1.2.5:

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

    1/28/2002 - Shorewall 1.2.4 Released

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

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

    - - -

    1/20/2002 - Corrected firewall script available 

    - - -

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

    - - -

    1/19/2002 - Shorewall 1.2.3 Released

    - - -

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

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

    The following problems were corrected:

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

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

    - - -

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

    - - -

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

    - - -

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

    - - -

    1/8/2002 - Shorewall 1.2.2 Released

    - - -

    In version 1.2.2

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

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

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

    See the README file for upgrade instructions.

    - - -

    1/1/2002 - Shorewall Mailing List Moving

    - - -

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

    - - -

    12/31/2001 - Shorewall 1.2.1 Released

    - - -

    In version 1.2.1:

    - - - - - -

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

    - - -

    Version 1.2 contains the following new features:

    - - - - - -

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

    - - -

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

    - - -
    - - -

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

    -
    - - -

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

    - - -

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

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

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

    - - -

    In this version:

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

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

    - - -

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

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

    3/1/2002 - 1.2.8 Debian Package is Available

    + + +

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

    + + +

    2/25/2002 - New Two-interface Sample

    + + +

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

    + + +

    2/23/2002 - Shorewall 1.2.8 Released

    + + +

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

    + + +

    2/22/2002 - Shorewall 1.2.7 Released

    + + +

    In this version:

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

    2/18/2002 - 1.2.6 Debian Package is Available

    + + +

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

    + + +

    2/8/2002 - Shorewall 1.2.6 Released

    + + +

    In this version:

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

    2/4/2002 - Shorewall 1.2.5 Debian Package Available

    + + +

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

    + + +

    2/1/2002 - Shorewall 1.2.5 Released

    + + +

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

    + + +

    In version 1.2.5:

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

    1/28/2002 - Shorewall 1.2.4 Released

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

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

    + + +

    1/20/2002 - Corrected firewall script available 

    + + +

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

    + + +

    1/19/2002 - Shorewall 1.2.3 Released

    + + +

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

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

    The following problems were corrected:

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

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

    + + +

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

    + + +

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

    + + +

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

    + + +

    1/8/2002 - Shorewall 1.2.2 Released

    + + +

    In version 1.2.2

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

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

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

    See the README file for upgrade instructions.

    + + +

    1/1/2002 - Shorewall Mailing List Moving

    + + +

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

    + + +

    12/31/2001 - Shorewall 1.2.1 Released

    + + +

    In version 1.2.1:

    + + + + + +

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

    + + +

    Version 1.2 contains the following new features:

    + + + + + +

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

    + + +

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

    + + +
    + + +

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

    +
    + + +

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

    + + +

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

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

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

    + + +

    In this version:

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

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

    + + +

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

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

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

    - -

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

    + +

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

    - +

    In this version:

    - + - -

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

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

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

    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:

    - +
      -
    • Support for nested +
    • Support for nested zones has been improved. See the documentation for -details
      • -
    • Shorewall now correctly - checks the alternate configuration directory for - the 'zones' file.
      • + href="Documentation.htm#Nested"> the documentation for details +
    • Shorewall now correctly + checks the alternate configuration directory for + the 'zones' file.
      • - +
    - -

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

    + +

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

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

    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

    - +
      -
    • Shell variables can -now be used to parameterize Shorewall rules.
      • -
    • The second column in - the hosts file may now contain a comma-separated - list.
      -
      - Example:
      -     sea    eth0:130.252.100.0/24,206.191.149.0/24
      • -
    • Handling of multi-zone +
    • Shell variables can + now be used to parameterize Shorewall rules.
      • +
    • The second column +in the hosts file may now contain a comma-separated + list.
      +
      + Example:
      +     sea    eth0:130.252.100.0/24,206.191.149.0/24
      • +
    • Handling of multi-zone interfaces has been improved. See the documentation for the /etc/shorewall/interfaces - file.
      • + href="Documentation.htm#Interfaces">documentation for the /etc/shorewall/interfaces + file. - +
    - -

    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

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

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

    + +

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

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

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

    + +

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

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

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

    + +

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

    - + - -

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

    + +

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

    - + - +

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

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

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

    + +

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

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

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

    + +

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

    - + - -

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

    + +

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

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

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

    + +

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

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

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

    + - + +

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

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

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

    +

    - +

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

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

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

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

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

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

    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.

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

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

    - -

    Updated 2/13/2003 - Tom Eastep -

    + +

    Updated 2/13/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +



    diff --git a/Shorewall-docs/Shorewall_Squid_Usage.html b/Shorewall-docs/Shorewall_Squid_Usage.html index 814a48dcd..b7023024e 100644 --- a/Shorewall-docs/Shorewall_Squid_Usage.html +++ b/Shorewall-docs/Shorewall_Squid_Usage.html @@ -2,371 +2,331 @@ Shorewall Squid Usage - + - + - + - - - + - + - - - - +
    + + + +
    +
    -
    -
    +     		Using Shorewall with Squid
    -     		+ -
    -
    -
    - This page covers Shorewall configuration to use with Squid running as a Transparent +
    + This page covers Shorewall configuration to use with Squid running as a Transparent Proxy. 
    -
    -
    + Caution -     Please observe the following general requirements:
    -
    - -     In all cases, Squid should be configured to run +     Please observe the following general requirements:
    +
    + +     In all cases, Squid should be configured to run as a transparent proxy as described at http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
    -
    -     -     The following instructions mention the files /etc/shorewall/start - and /etc/shorewall/init -- if you don't have those files, siimply create - them.
    -
    - -     When the Squid server is in the DMZ zone or in - the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts - file entries. That is because the packets being routed to the Squid server - still have their original destination IP addresses.
    -
    - -     You must have iproute2 (ip utility) installed - on your firewall.
    -
    - -     You must have iptables installed on your Squid +
    +     +     The following instructions mention the files +/etc/shorewall/start and /etc/shorewall/init -- if you don't have those +files, siimply create them.
    +
    + +     When the Squid server is in the DMZ zone or +in the local zone, that zone must be defined ONLY by its interface -- no +/etc/shorewall/hosts file entries. That is because the packets being routed +to the Squid server still have their original destination IP addresses.
    +
    + +     You must have iptables installed on your Squid server.
    -
    - -     You must have NAT and MANGLE enabled in your +
    + +     You must have NAT and MANGLE enabled in your /etc/shorewall/conf file
    -
    -         NAT_ENABLED=Yes
    -             MANGLE_ENABLED=Yes
    -
    - Three different configurations are covered:
    - +
    +         NAT_ENABLED=Yes
    +             MANGLE_ENABLED=Yes
    +
    + Three different configurations are covered:
    +
      -
    1. Squid running on +
    2. Squid running on the Firewall.
      3. -
    3. Squid running in the -local network
      4. -
    4. Squid running in the DMZ
      5. - +
    5. Squid running in the + local network
      6. +
    6. Squid running in the +DMZ
      7. +
    - +

    Squid Running on the Firewall

    - You want to redirect all local www connection requests EXCEPT - those to your own - http server (206.124.146.177) - to a Squid transparent - proxy running on the firewall and listening on port 3128. Squid - will of course require access to remote web servers.
    -
    - In /etc/shorewall/rules:
    -
    + You want to redirect all local www connection requests EXCEPT + those to your own + http server (206.124.146.177) + to a Squid transparent + proxy running on the firewall and listening on port 3128. Squid + will of course require access to remote web servers.
    +
    + In /etc/shorewall/rules:
    +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDEST PROTODEST
    + PORT(S)    		SOURCE
    + PORT(S)    		ORIGINAL
    + DEST
    REDIRECTloc3128tcpwww -
    +     		!206.124.146.177
    ACCEPTfwnettcpwww
    +
    +
    +
    +
    + +

    Squid Running in the local network

    + You want to redirect all local www connection requests to a Squid + transparent proxy + running in your local zone at 192.168.1.3 and listening on port 3128. + Your local interface is eth1. There may also be a web server running on +192.168.1.3. It is assumed that web access is already enabled from the local +zone to the internet.
    + +

    WARNING: This setup may conflict with + other aspects of your gateway including but not limited to traffic shaping + and route redirection. For that reason, I don't recommend it.
    +

    + +
      +
    • On your firewall system, issue the following command
      +
      • + +
    + +
    + 
    echo 202 www.out >> /etc/iproute2/rt_tables
    +
    + +
      +
    • In /etc/shorewall/init, put:
      +
      • + +
    + +
    + 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.168.1.3 dev eth1 table www.out
    	ip route flush cache
    	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    fi
    +
    + +
      +
    • In /etc/shorewall/rules:
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      ACCEPT
      +       		locloc
      +       		tcpwww
      +
      +
      +
      +
      • +
    • Alternativfely, you can have the following policy:
      +
      + + + + + + + + + + + + + + + + + + + +
      SOURCE
      +       		DESTINATION
      +       		POLICY
      +       		LOG LEVEL
      +       		BURST PARAMETERS
      +
      loc
      +       		loc
      +       		ACCEPT
      +
      +
      +
      +
      +
      • +
    • In /etc/shorewall/start add:
      +
      • + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDEST PROTODEST
    - PORT(S)    		SOURCE
    - PORT(S)    		ORIGINAL
    - DEST
    REDIRECTloc3128tcpwww -
    -     		!206.124.146.177
    ACCEPTfwnettcpwww
    -
    -
    -
    + 
    iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
    -

    Squid Running in the local network

    - You want to redirect all local www connection requests to a Squid - transparent proxy -running in your local zone at 192.168.1.3 and listening on port 3128. - Your local interface is eth1. There may also be a web server running on -192.168.1.3. It is assumed that web access is already enabled from the local -zone to the internet.
    - -

    WARNING: This setup may conflict with - other aspects of your gateway including but not limited to traffic shaping - and route redirection. For that reason, I don't recommend it.
    -

    -
      -
    • On your firewall system, issue the following command
      -
      • - -
    - -
    - 
    echo 202 www.out >> /etc/iproute2/rt_tables
    -
    - -
      -
    • In /etc/shorewall/init, put:
      -
      • - -
    - -
    - 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.168.1.3 dev eth1 table www.out
    	ip route flush cache
    	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
    fi
    -
    - -
      -
    • In /etc/shorewall/rules:
      -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ACCEPT
      -       		locloc
      -       		tcpwww
      -
      -
      -
      -
      • -
    • Alternativfely, you can have the following policy:
      -
      - - - - - - - - - - - - - - - - - - - -
      SOURCE
      -       		DESTINATION
      -       		POLICY
      -       		LOG LEVEL
      -       		BURST PARAMETERS
      -
      loc
      -       		loc
      -       		ACCEPT
      -
      -
      -
      -
      -
      • -
    • In /etc/shorewall/start add:
      -
      • - -
    - -
    - 
    iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
    -
    - -
      -
    • On 192.168.1.3, arrange for the following command to be executed - after networking has come up
      - +
    • On 192.168.1.3, arrange for the following command to be executed + after networking has come up
      + 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      -
      • - + +
    - -
    If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
    -
    -
    +
    If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
    +
    + +
    - + 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables start
    -
    - +
    +
    - +

    Squid Running in the DMZ (This is what I do)

    - You have a single Linux system in your DMZ with IP address 192.0.2.177. - You want to run both a web server and Squid on that system. Your DMZ interface - is eth1 and your local interface is eth2.
    - + You have a single Linux system in your DMZ with IP address 192.0.2.177. + You want to run both a web server and Squid on that system. Your DMZ interface + is eth1 and your local interface is eth2.
    +
      -
    • On your firewall system, issue the following command
      -
      • - +
    • On your firewall system, issue the following command
      +
      • +
    - -
    + +
    echo 202 www.out >> /etc/iproute2/rt_tables
    -
    - +
    +
      -
    • In /etc/shorewall/init, put:
      -
      • +
    • In /etc/shorewall/init, put:
      +
      • + +
    + +
    + 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.0.2.177 dev eth1 table www.out
    	ip route flush cache
    fi
    +
    + +
      +
    •  Do one of the following:
      +
      + A) In /etc/shorewall/start add
      +
    - -
    - 
    if [ -z "`ip rule list | grep www.out`" ] ; then
    	ip rule add fwmark 202 table www.out
    	ip route add default via 192.0.2.177 dev eth1 table www.out
    	ip route flush cache
    fi
    -
    - -
      -
    •  Do one of the following:
      -
      - A) In /etc/shorewall/start add
      -
      • - -
    - -
    + +
    	iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
    -
    - -
    B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf -and add the following entry in /etc/shorewall/tcrules:
    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - - -
    MARK
    -     		SOURCE
    -     		DESTINATION
    -     		PROTOCOL
    -     		PORT
    -     		CLIENT PORT
    -
    202
    -     		eth2
    -     		0.0.0.0/0
    -     		tcp
    -     		80
    -     		-
    -
    -
    - C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
    -
    - +
    + +
    B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf + and add the following entry in /etc/shorewall/tcrules:
    +
    +
    @@ -386,7 +346,7 @@ and add the following entry in /etc/shorewall/tcrules:
    - @@ -403,90 +363,130 @@ and add the following entry in /etc/shorewall/tcrules:
    202:P
    +     		202
    		 eth2
    -
    -
    - + C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
    + + +
    +
    + + + + + + + + + + + + + + + + + + + + +
    MARK
    +     		SOURCE
    +     		DESTINATION
    +     		PROTOCOL
    +     		PORT
    +     		CLIENT PORT
    +
    202:P
    +     		eth2
    +     		0.0.0.0/0
    +     		tcp
    +     		80
    +     		-
    +
    +
    +
    +
    +
      -
    • In /etc/shorewall/rules, you will need:
      • - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - -
    ACTION
    -     		SOURCE
    -     		DEST
    -     		PROTO
    -     		DEST
    - PORT(S)
    -     		CLIENT
    - PORT(2)
    -     		ORIGINAL
    - DEST
    -
    ACCEPT
    -     		dmz
    -     		net
    -     		tcp
    -     		80
    -
    -
    -
    -
    -
    - -
      -
    • On 192.0.2.177 (your Web/Squid server), arrange for the following - command to be executed after networking has come up
      - - 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      -
      • +
    • In /etc/shorewall/rules, you will need:
    - -
    If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
    -
    - +
    + + + + + + + + + + + + + + + + + + + + + + +
    ACTION
    +     		SOURCE
    +     		DEST
    +     		PROTO
    +     		DEST
    + PORT(S)
    +     		CLIENT
    + PORT(2)
    +     		ORIGINAL
    + DEST
    +
    ACCEPT
    +     		dmz
    +     		net
    +     		tcp
    +     		80
    +
    +
    +
    +
    +
    + +
      +
    • On 192.0.2.177 (your Web/Squid server), arrange for the following + command to be executed after networking has come up
      + + 
      iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128
      +
      • + +
    + +
    If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
    +
    + +
    - + 
    iptables-save > /etc/sysconfig/iptables
    chkconfig --level 35 iptables start
    -
    - + +
    - -

    Updated 1/23/2003 - Tom Eastep + +

    Updated 2/21/2003 - Tom Eastep

    - Copyright © 2003 Thomas M. Eastep.
    -
    -
    -
    +
    +
    +
    +



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

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

    + Shorewall + 1.4 - "iptables made + easy" + + + + + + + + + + + + +
    + +
    + + + + +
    + +
    + + + + + + + + - - - - - - - - - - -
    @@ -60,52 +107,6 @@ - - -
    - -
    - - - - -
    - -
    - - - - - - - - + - - + - - + +
    - - - - - - - - - -

    What is it?

    @@ -118,11 +119,11 @@ - -

    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.

    @@ -134,29 +135,29 @@ firewall that can be used on a dedicated firewall system, a multi-functio - -

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

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

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

    @@ -168,7 +169,7 @@ copy of the GNU General Public License - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -181,20 +182,21 @@ copy of the GNU General Public License - +

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

    -

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

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

    + +

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

    @@ -204,9 +206,9 @@ Bering 1.1!!!
    - -

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

    + +

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

    @@ -220,7 +222,7 @@ Bering 1.1!!!
    - +

    News

    @@ -232,7 +234,8 @@ Bering 1.1!!!
    - + +

    @@ -242,102 +245,108 @@ Bering 1.1!!!
    - +

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

    - +

    +

    - Shorewall 1.4 represents the next step in the evolution of Shorewall. -The main thrust of the initial release is simply to remove the cruft that + 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.
    - Function from 1.3 that has been omitted from this version include:
    - + IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package +('ip' utility).
    +
    +Function from 1.3 that has been omitted from this version include:
    +
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      2. -
    2. Interface names of the form <device>:<integer> -in /etc/shorewall/interfaces now generate an error.
      -
      -
      3. -
    3. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
      -
      -
      4. -
    4. The 'routestopped' option in the /etc/shorewall/interfaces -and /etc/shorewall/hosts files is no longer supported and will generate an -error at startup if specified.
      -
      -
      5. -
    5. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no -longer accepted.
      -
      -
      6. -
    6. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
    7. 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.
      +
      +
      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. -
    14. The icmp.def file has been removed.
      -
      -
      15. -
    15. The 'multi' interface option is no longer supported. - Shorewall will generate rules for sending packets back out the same interface +
    16. The 'multi' interface option is no longer supported. + Shorewall will generate rules for sending packets back out the same interface that they arrived on in two cases:
      17. +
    - +
      -
    • There is an explicit policy for the source zone to or -from the destination zone. An explicit policy names both zones and does not +
    • There is an explicit policy for the source zone to or +from the destination zone. An explicit policy names both zones and does not use the 'all' reserved word.
      • -
    • There are one or more rules for traffic for the source zone to -or from the destination zone including rules that use the 'all' reserved -word. Exception: if the source zone and destination zone are the same then -the rule must be explicit - it must name the zone in both the SOURCE and -DESTINATION columns.
      -
      • +
    • There are one or more rules for traffic for the source zone +to or from the destination zone including rules that use the 'all' reserved +word. Exception: if the source zone and destination zone are the same then +the rule must be explicit - it must name the zone in both the SOURCE and DESTINATION +columns.
      +
      • +
    +
      - +
    - Changes for 1.4 include:
    - + Changes for 1.4 include:
    +
      -
    1. The /etc/shorewall/shorewall.conf file has been completely -reorganized into logical sections.
      -
      -
      2. -
    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 +
    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 +
      +
      8. +
    8. Late arriving DNS replies are now silently dropped in the common chain by default.
      -
      -
      9. -
    9. In addition to behaving like OLD_PING_HANDLING=No, Shorewall -1.4 no longer unconditionally accepts outbound ICMP packets. So if you want - to 'ping' from the firewall, you will need the appropriate rule or policy.
      -
      -
      10. -
    10. 802.11b devices with names of the form wlan<n> now -support the 'maclist' option.
      -
      11. - +
      + +
    11. 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.
      +
      +
      12. +
    12. 802.11b devices with names of the form wlan<n> +now support the 'maclist' option.
      +
      13. +
    - +
      - +
    @@ -345,7 +354,7 @@ support the 'maclist' option.
    - +

    More News

    @@ -358,44 +367,44 @@ support the 'maclist' option.
    - +

    Donations

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

    -  

    +  

    @@ -420,32 +429,33 @@ support the 'maclist' option.
    - -

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

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

    + href="http://www.starlight.org">Starlight Children's +Foundation. Thanks!

    -
    - -

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

    + +

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

    +
    diff --git a/Shorewall-docs/shorewall_prerequisites.htm b/Shorewall-docs/shorewall_prerequisites.htm index cf7e0e9b7..b66ccc400 100644 --- a/Shorewall-docs/shorewall_prerequisites.htm +++ b/Shorewall-docs/shorewall_prerequisites.htm @@ -1,68 +1,68 @@ - + - + - + - + Shorewall Prerequisites - + - - - + + - - - + + + +
    +

    Shorewall Requirements

    -
    -
    -Shorewall Requires:
    - +
    + Shorewall Requires:
    +
      -
    • A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6. - Check here for kernel configuration -information. If you are looking for a firewall for use with 2.2 -kernels, see the Seattle Firewall - site .
      • -
    • iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The - buggy iptables version 1.2.3 is included in RedHat 7.2 and you should -upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4 +
    • A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6. + Check here for kernel configuration information. + If you are looking for a firewall for use with 2.2 kernels, see the Seattle Firewall site + .
      • +
    • iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The + buggy iptables version 1.2.3 is included in RedHat 7.2 and you should +upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4 is available from RedHat + href="http://www.redhat.com/support/errata/RHSA-2001-144.html">from RedHat and in the Shorewall Errata.
      • -
    • Some features require iproute ("ip" utility). The iproute package - is included with most distributions but may not be installed by default. - The official download site is ftp://ftp.inr.ac.ru/ip-routing. -
      • -
    • A Bourne shell or derivative such as bash or ash. This shell must -have correct support for variable expansion formats ${variable%pattern - }, ${variable%%pattern}, ${variable#pattern - } and ${variable##pattern}.
      • -
    • The firewall monitoring display is greatly improved if you have +
    • Iproute ("ip" utility). The iproute package is included with +most distributions but may not be installed by default. The official +download site is ftp://ftp.inr.ac.ru/ip-routing. +
      • +
    • A Bourne shell or derivative such as bash or ash. This shell must + have correct support for variable expansion formats ${variable%pattern + }, ${variable%%pattern}, ${variable#pattern + } and ${variable##pattern}.
      • +
    • The firewall monitoring display is greatly improved if you have awk (gawk) installed.
      • - +
    - -

    Last updated 11/10/2002 - Last updated 2/21/2003 - Tom Eastep

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    -
    + size="2">Copyright     © 2001, 2002, 2003 Thomas M. Eastep.

    +
    +


    diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm index 1e30cdea6..bb9699d0d 100644 --- a/Shorewall-docs/shorewall_setup_guide.htm +++ b/Shorewall-docs/shorewall_setup_guide.htm @@ -1,2517 +1,2518 @@ - + - + - + - + Shorewall Setup Guide - + - +

    Shorewall Setup Guide

    - +

    1.0 Introduction
    - 2.0 Shorewall Concepts
    - 3.0 Network Interfaces
    - 4.0 Addressing, Subnets and Routing

    - -
    + 2.0 Shorewall Concepts
    + 3.0 Network Interfaces
    + 4.0 Addressing, Subnets and Routing

    + +

    4.1 IP Addresses
    - 4.2 Subnets
    - 4.3 Routing
    - 4.4 Address Resolution Protocol
    - 4.5 RFC 1918

    -
    - + 4.2 Subnets
    + 4.3 Routing
    + 4.4 Address Resolution Protocol
    + 4.5 RFC 1918

    +
    +

    5.0 Setting up your Network

    - -
    + +

    5.1 Routed
    - 5.2 Non-routed

    - -
    + 5.2 Non-routed

    + +

    5.2.1 SNAT
    - 5.2.2 DNAT
    - 5.2.3 Proxy ARP
    - 5.2.4 Static NAT

    -
    - + 5.2.2 DNAT
    + 5.2.3 Proxy ARP
    + 5.2.4 Static NAT

    +
    +

    5.3 Rules
    - 5.4 Odds and Ends

    -
    - + 5.4 Odds and Ends

    +
    +

    6.0 DNS
    - 7.0 Starting and Stopping the Firewall

    - + 7.0 Starting and Stopping the Firewall

    +

    1.0 Introduction

    - -

    This guide is intended for users who are setting up Shorewall in an environment - where a set of public IP addresses must be managed or who want to know + +

    This guide is intended for users who are setting up Shorewall in an environment + where a set of public IP addresses must be managed or who want to know more about Shorewall than is contained in the single-address guides. Because - the range of possible applications is so broad, the Guide will give you + href="shorewall_quickstart_guide.htm">single-address guides. Because + the range of possible applications is so broad, the Guide will give you general guidelines and will point you to other resources as necessary.

    - +

    -     If you run LEAF Bering, your Shorewall configuration is NOT what - I release -- I suggest that you consider installing a stock Shorewall lrp - from the shorewall.net site before you proceed.

    - -

    This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell - if this package is installed by the presence of an ip program on - your firewall system. As root, you can use the 'which' command to check - for this program:

    - +     If you run LEAF Bering, your Shorewall configuration is NOT what + I release -- I suggest that you consider installing a stock Shorewall +lrp from the shorewall.net site before you proceed.

    + +

    Shorewall requires that the iproute/iproute2 package be installed (on + RedHat, the package is called iproute). You can tell if +this package is installed by the presence of an ip program on your + firewall system. As root, you can use the 'which' command to check for +this program:

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are flagged + +

    I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are flagged with - .

    - + .

    +

    -     If you edit your configuration files on a Windows system, you -must save them as Unix files if your editor supports that option or you -must run them through dos2unix before trying to use them with Shorewall. -Similarly, if you copy a configuration file from your Windows hard drive -to a floppy disk, you must run dos2unix against the copy before using -it with Shorewall.

    - +     If you edit your configuration files on a Windows system, you +must save them as Unix files if your editor supports that option or you +must run them through dos2unix before trying to use them with Shorewall. +Similarly, if you copy a configuration file from your Windows hard drive +to a floppy disk, you must run dos2unix against the copy before using it +with Shorewall.

    + - +

    2.0 Shorewall Concepts

    - -

    The configuration files for Shorewall are contained in the directory /etc/shorewall --- for most setups, you will only need to deal with a few of these as described -in this guide. Skeleton files are created during the Shorewall Installation Process.

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions + +

    The configuration files for Shorewall are contained in the directory +/etc/shorewall -- for most setups, you will only need to deal with a few +of these as described in this guide. Skeleton files are created during the +Shorewall Installation Process.

    + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions and some contain default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the default installation, the following zone -names are used:

    - + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the default installation, the following zone names + are used:

    + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    - -

    Zones are defined in the /etc/shorewall/zones + +

    Zones are defined in the /etc/shorewall/zones file.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw but that may be changed in -the /etc/shorewall/shorewall.conf -file. In this guide, the default name (fw) will be used.

    - -

    With the exception of fw, Shorewall attaches absolutely no meaning - to zone names. Zones are entirely what YOU make of them. That means that - you should not expect Shorewall to do something special "because this + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw but that may be changed in the + /etc/shorewall/shorewall.conf + file. In this guide, the default name (fw) will be used.

    + +

    With the exception of fw, Shorewall attaches absolutely no meaning + to zone names. Zones are entirely what YOU make of them. That means that + you should not expect Shorewall to do something special "because this is the internet zone" or "because that is the DMZ".

    - +

    -     Edit the /etc/shorewall/zones file and make any changes necessary.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed +     Edit the /etc/shorewall/zones file and make any changes necessary.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed in terms of zones.

    - + - -

    Shorewall is built on top of the Netfilter + +

    Shorewall is built on top of the Netfilter kernel facility. Netfilter implements a connection - tracking function that allows what is often referred to as stateful - inspection of packets. This stateful property allows firewall rules - to be defined in terms of connections rather than in terms of + href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html">connection + tracking function that allows what is often referred to as stateful + inspection of packets. This stateful property allows firewall rules + to be defined in terms of connections rather than in terms of packets. With Shorewall, you:

    - +
      -
    1. Identify the source zone.
      2. -
    2. Identify the destination zone.
      3. -
    3. If the POLICY from the client's zone to the server's -zone is what you want for this client/server pair, you need do nothing +
    4. Identify the source zone.
      5. +
    5. Identify the destination zone.
      6. +
    6. If the POLICY from the client's zone to the server's + zone is what you want for this client/server pair, you need do nothing further.
      7. -
    7. If the POLICY is not what you want, then you must add - a rule. That rule is expressed in terms of the client's zone and +
    8. If the POLICY is not what you want, then you must add + a rule. That rule is expressed in terms of the client's zone and the server's zone.
      9. - +
    - -

    Just because connections of a particular type are allowed from zone -A to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed - from zone A to zone B. It rather means that you can -have a proxy running on the firewall that accepts a connection from -zone A and then establishes its own separate connection from the firewall -to zone B.

    - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  + +

    Just because connections of a particular type are allowed from zone A +to the firewall and are also allowed from the firewall to zone B DOES NOT mean that these connections are allowed + from zone A to zone B. It rather means that you can have + a proxy running on the firewall that accepts a connection from zone +A and then establishes its own separate connection from the firewall to +zone B.

    + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  the request is first checked against the rules in /etc/shorewall/common.def.

    - +

    The default /etc/shorewall/policy file has the following policies:

    - -
    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network to the -internet
      2. -
    2. drop (ignore) all connection requests from the internet to your - firewall or local network and log a message at the info level - (here is a description of log levels).
      3. -
    3. reject all other connection requests and log a message at the - info level. When a request is rejected, the firewall will - return an RST (if the protocol is TCP) or an ICMP port-unreachable -packet for other protocols.
      4. - +
    4. allow all connection requests from your local network to the + internet
      5. +
    5. drop (ignore) all connection requests from the internet to +your firewall or local network and log a message at the info +level (here is a description of log +levels).
      6. +
    6. reject all other connection requests and log a message at the + info level. When a request is rejected, the firewall will + return an RST (if the protocol is TCP) or an ICMP port-unreachable packet + for other protocols.
      7. +
    - +

    -     At this point, edit your /etc/shorewall/policy and make any changes - that you wish.

    - +     At this point, edit your /etc/shorewall/policy and make any changes + that you wish.

    +

    3.0 Network Interfaces

    - -

    For the remainder of this guide, we'll refer to the following - diagram. While it may not look like your own network, it can be used -to illustrate the important aspects of Shorewall configuration.

    - + +

    For the remainder of this guide, we'll refer to the following + diagram. While it may not look like your own network, it can be used to + illustrate the important aspects of Shorewall configuration.

    +

    In this diagram:

    - +
      -
    • The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used - to isolate your internet-accessible servers from your local systems so - that if one of those servers is compromised, you still have the firewall +
    • The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is +used to isolate your internet-accessible servers from your local systems +so that if one of those servers is compromised, you still have the firewall between the compromised system and your local systems.
      • -
    • The Local Zone consists of systems Local 1, Local 2 and Local +
    • The Local Zone consists of systems Local 1, Local 2 and Local 3.
      • -
    • All systems from the ISP outward comprise the Internet Zone. -
      • - +
    • All systems from the ISP outward comprise the Internet Zone. +
      • +
    - +

    -

    - -

    The simplest way to define zones is to simply associate the - zone name (previously defined in /etc/shorewall/zones) with a network -interface. This is done in the /etc/shorewall/interfaces +

    + +

    The simplest way to define zones is to simply associate the + zone name (previously defined in /etc/shorewall/zones) with a network +interface. This is done in the /etc/shorewall/interfaces file.

    - -

    The firewall illustrated above has three network interfaces. - Where Internet connectivity is through a cable or DSL "Modem", the External - Interface will be the Ethernet adapter that is connected to that -"Modem" (e.g., eth0)  unless you connect via Point-to-Point - Protocol over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External -Interface will be a ppp interface (e.g., ppp0). If you connect -via a regular modem, your External Interface will also be ppp0. -If you connect using ISDN, you external interface will be ippp0.

    - + +

    The firewall illustrated above has three network interfaces. + Where Internet connectivity is through a cable or DSL "Modem", the External + Interface will be the Ethernet adapter that is connected to that "Modem" + (e.g., eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External +Interface will be a ppp interface (e.g., ppp0). If you connect via +a regular modem, your External Interface will also be ppp0. If +you connect using ISDN, you external interface will be ippp0.

    +

    -     If your external interface is ppp0 or ippp0 then -you will want to set CLAMPMSS=yes in -/etc/shorewall/shorewall.conf.

    - -

    Your Local Interface will be an Ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local computers - will be connected to the same switch (note: If you have only a single -local system, you can connect the firewall directly to the computer using +     If your external interface is ppp0 or ippp0 then + you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    + +

    Your Local Interface will be an Ethernet adapter (eth0, + eth1 or eth2) and will be connected to a hub or switch. Your local computers + will be connected to the same switch (note: If you have only a single +local system, you can connect the firewall directly to the computer using a cross-over cable).

    - -

    Your DMZ Interface will also be an Ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ - computers will be connected to the same switch (note: If you have only -a single DMZ system, you can connect the firewall directly to the computer + +

    Your DMZ Interface will also be an Ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ + computers will be connected to the same switch (note: If you have only +a single DMZ system, you can connect the firewall directly to the computer using a cross-over cable).

    - +

    - Do not connect more than one interface to the same hub or -switch (even for testing). It won't work the way that you expect it to -and you will end up confused and believing that Linux networking doesn't + Do not connect more than one interface to the same hub or +switch (even for testing). It won't work the way that you expect it to +and you will end up confused and believing that Linux networking doesn't work at all.

    - +

    For the remainder of this Guide, we will assume that:

    - +
      -
    • +

    • The external interface is eth0.

      -
      • -
    • +
      • +

    • The Local interface is eth1.

      -
      • -
    • +
      • +

    • The DMZ interface is eth2.

      -
      • - + +
    - -

    The Shorewall default configuration does not define the contents - of any zone. To define the above configuration using the /etc/shorewall/interfaces + +

    The Shorewall default configuration does not define the contents + of any zone. To define the above configuration using the /etc/shorewall/interfaces file, that file would might contain:

    - -
    + +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918
    loceth1detect 
    dmzeth2detect 
    neteth0detectnorfc1918
    loceth1detect 
    dmzeth2detect 
    -
    - +
    +

    -     Edit the /etc/shorewall/interfaces file and define the network -interfaces on your firewall and associate each interface with a zone. If -you have a zone that is interfaced through more than one interface, simply -include one entry for each interface and repeat the zone name as many times -as necessary.

    - +     Edit the /etc/shorewall/interfaces file and define the network + interfaces on your firewall and associate each interface with a zone. +If you have a zone that is interfaced through more than one interface, +simply include one entry for each interface and repeat the zone name as +many times as necessary.

    +

    Example:

    - -
    + +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918
    loceth1detect 
    loceth2detectdhcp
    neteth0detectnorfc1918
    loceth1detect 
    loceth2detectdhcp
    -
    - -
    -

    When you have more than one interface to a zone, you will +

    + +
    +

    When you have more than one interface to a zone, you will usually want a policy that permits intra-zone traffic:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    loclocACCEPT  
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    loclocACCEPT  
    -
    -
    - + + +

    -     You may define more complicated zones using the /etc/shorewall/hosts file but in most +     You may define more complicated zones using the /etc/shorewall/hosts file but in most cases, that isn't necessary.

    - +

    4.0 Addressing, Subnets and Routing

    - -

    Normally, your ISP will assign you a set of Public - IP addresses. You will configure your firewall's external interface to -use one of those addresses permanently and you will then have to decide -how you are going to use the rest of your addresses. Before we tackle that + +

    Normally, your ISP will assign you a set of Public + IP addresses. You will configure your firewall's external interface to +use one of those addresses permanently and you will then have to decide +how you are going to use the rest of your addresses. Before we tackle that question though, some background is in order.

    - -

    If you are thoroughly familiar with IP addressing and routing, + +

    If you are thoroughly familiar with IP addressing and routing, you may go to the next section.

    - -

    The following discussion barely scratches the surface of -addressing and routing. If you are interested in learning more about this -subject, I highly recommend "IP Fundamentals: What Everyone Needs to -Know about Addressing & Routing", Thomas A. Maufer, Prentice-Hall, - 1999, ISBN 0-13-975483-0.

    - + +

    The following discussion barely scratches the surface of addressing +and routing. If you are interested in learning more about this subject, +I highly recommend "IP Fundamentals: What Everyone Needs to Know about +Addressing & Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN +0-13-975483-0.

    +

    4.1 IP Addresses

    - -

    IP version 4 (IPv4) addresses are 32-bit numbers. - The notation w.x.y.z refers to an address where the high-order byte has - value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 + +

    IP version 4 (IPv4) addresses are 32-bit numbers. + The notation w.x.y.z refers to an address where the high-order byte has + value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 and express it in hexadecimal, we get:

    - -
    + +

    C0.00.02.0E

    -
    - +
    +

    or looking at it as a 32-bit integer

    - -
    + +

    C000020E

    -
    - +
    +

    4.2 Subnets

    - -

    You will still hear the terms "Class A network", "Class B - network" and "Class C network". In the early days of IP, networks only - came in three sizes (there were also Class D networks but they were used + +

    You will still hear the terms "Class A network", "Class B + network" and "Class C network". In the early days of IP, networks only + came in three sizes (there were also Class D networks but they were used differently):

    - -
    + +

    Class A - netmask 255.0.0.0, size = 2 ** 24

    - +

    Class B - netmask 255.255.0.0, size = 2 ** 16

    - +

    Class C - netmask 255.255.255.0, size = 256

    -
    - -

    The class of a network was uniquely determined by the value - of the high order byte of its address so you could look at an IP address - and immediately determine the associated netmask. The netmask -is a number that when logically ANDed with an address isolates the network - number; the remainder of the address is the host number. For - example, in the Class C address 192.0.2.14, the network number is hex -C00002 and the host number is hex 0E.

    - -

    As the internet grew, it became clear that such a gross partitioning -of the 32-bit address space was going to be very limiting (early on, large -corporations and universities were assigned their own class A network!). -After some false starts, the current technique of subnetting these -networks into smaller subnetworks evolved; that technique is referred -to as Classless InterDomain Routing (CIDR). Today, any system that - you are likely to work with will understand CIDR and Class-based networking +

    + +

    The class of a network was uniquely determined by the value + of the high order byte of its address so you could look at an IP address + and immediately determine the associated netmask. The netmask is + a number that when logically ANDed with an address isolates the network + number; the remainder of the address is the host number. For + example, in the Class C address 192.0.2.14, the network number is hex C00002 + and the host number is hex 0E.

    + +

    As the internet grew, it became clear that such a gross +partitioning of the 32-bit address space was going to be very limiting (early + on, large corporations and universities were assigned their own class A + network!). After some false starts, the current technique of subnetting + these networks into smaller subnetworks evolved; that technique is +referred to as Classless InterDomain Routing (CIDR). Today, any system +that you are likely to work with will understand CIDR and Class-based networking is largely a thing of the past.

    - -

    A subnetwork (often referred to as a subnet) is + +

    A subnetwork (often referred to as a subnet) is a contiguous set of IP addresses such that:

    - +
      -
    1. +

    2. The number of addresses in the set is a power of 2; and

      -
      3. -
    3. -

      The first address in the set is a multiple of the set +

      4. +
    4. +

      The first address in the set is a multiple of the set size.

      -
      5. -
    5. -

      The first address in the subnet is reserved and is referred +

      6. +
    6. +

      The first address in the subnet is reserved and is referred to as the subnet address.

      -
      7. -
    7. -

      The last address in the subnet is reserved as the subnet's +

      8. +
    8. +

      The last address in the subnet is reserved as the subnet's broadcast address.

      -
      9. - + +
    - -

    As you can see by this definition, in each subnet of size - n there are (n - 2) usable addresses (addresses that -can be assigned to hosts). The first and last address in the subnet -are used for the subnet address and subnet broadcast address respectively. -Consequently, small subnetworks are more wasteful of IP addresses than + +

    As you can see by this definition, in each subnet of size + n there are (n - 2) usable addresses (addresses that can + be assigned to hosts). The first and last address in the subnet are +used for the subnet address and subnet broadcast address respectively. +Consequently, small subnetworks are more wasteful of IP addresses than are large ones.

    - -

    Since n is a power of two, we can easily calculate - the Natural Logarithm (log2) of n. For the more -common subnet sizes, the size and its natural logarithm are given in the + +

    Since n is a power of two, we can easily calculate + the Natural Logarithm (log2) of n. For the more +common subnet sizes, the size and its natural logarithm are given in the following table:

    - -
    + +
    - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    nlog2 n(32 - log2 n)
    nlog2 n(32 - log2 n)
    8329
    16428
    32527
    64626
    128725
    256824
    512923
    10241022
    20481121
    40961220
    81921319
    163841418
    327681517
    655361616
    8329
    16428
    32527
    64626
    128725
    256824
    512923
    10241022
    20481121
    40961220
    81921319
    163841418
    327681517
    655361616
    -
    - -

    You will notice that the above table also contains a column - for (32 - log2 n). That number is the Variable Length Subnet - Mask for a network of size n. From the above table, we can +

    + +

    You will notice that the above table also contains a column + for (32 - log2 n). That number is the Variable Length Subnet + Mask for a network of size n. From the above table, we can derive the following one which is a little easier to use.

    - -
    + +
    - + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Size of SubnetVLSMSubnet Mask
    Size of SubnetVLSMSubnet Mask
    8/29255.255.255.248
    16/28255.255.255.240
    32/27255.255.255.224
    64/26255.255.255.192
    128/25255.255.255.128
    256/24255.255.255.0
    512/23255.255.254.0
    1024/22255.255.252.0
    2048/21255.255.248.0
    4096/20255.255.240.0
    8192/19255.255.224.0
    16384/18255.255.192.0
    32768/17255.255.128.0
    65536/16255.255.0.0
    2 ** 24/8255.0.0.0
    8/29255.255.255.248
    16/28255.255.255.240
    32/27255.255.255.224
    64/26255.255.255.192
    128/25255.255.255.128
    256/24255.255.255.0
    512/23255.255.254.0
    1024/22255.255.252.0
    2048/21255.255.248.0
    4096/20255.255.240.0
    8192/19255.255.224.0
    16384/18255.255.192.0
    32768/17255.255.128.0
    65536/16255.255.0.0
    2 ** 24/8255.0.0.0
    -
    - -

    Notice that the VLSM is written with a slash ("/") -- you - will often hear a subnet of size 64 referred to as a "slash 26" subnet +

    + +

    Notice that the VLSM is written with a slash ("/") -- you + will often hear a subnet of size 64 referred to as a "slash 26" subnet and one of size 8 referred to as a "slash 29".

    - -

    The subnet's mask (also referred to as its netmask) is - simply a 32-bit number with the first "VLSM" bits set to one and the - remaining bits set to zero. For example, for a subnet of size 64, the + +

    The subnet's mask (also referred to as its netmask) is + simply a 32-bit number with the first "VLSM" bits set to one and the + remaining bits set to zero. For example, for a subnet of size 64, the subnet mask has 26 leading one bits:

    - -
    -

    11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 + +

    +

    11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192

    -
    - -

    The subnet mask has the property that if you logically AND - the subnet mask with an address in the subnet, the result is the subnet - address. Just as important, if you logically AND the subnet mask with - an address outside the subnet, the result is NOT the subnet address. -As we will see below, this property of subnet masks is very useful in +

    + +

    The subnet mask has the property that if you logically AND + the subnet mask with an address in the subnet, the result is the subnet + address. Just as important, if you logically AND the subnet mask with + an address outside the subnet, the result is NOT the subnet address. +As we will see below, this property of subnet masks is very useful in routing.

    - -

    For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork -as "a.b.c.d/v" using CIDR Notation. 

    - + +

    For a subnetwork whose address is a.b.c.d and whose + Variable Length Subnet Mask is /v, we denote the subnetwork as + "a.b.c.d/v" using CIDR Notation. 

    +

    Example:

    - -
    + +
    - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    Subnet:10.10.10.0 - 10.10.10.127
    Subnet Size:128
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.127
    CIDR Notation:10.10.10.0/25
    Subnet:10.10.10.0 - 10.10.10.127
    Subnet Size:128
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.127
    CIDR Notation:10.10.10.0/25
    -
    - -

    There are two degenerate subnets that need mentioning; namely, +

    + +

    There are two degenerate subnets that need mentioning; namely, the subnet with one member and the subnet with 2 ** 32 members.

    - -
    + +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
    Size of SubnetworkVLSM LengthSubnet MaskCIDR Notation
    132255.255.255.255a.b.c.d/32
    2 ** 3200.0.0.00.0.0.0/0
    132255.255.255.255a.b.c.d/32
    2 ** 3200.0.0.00.0.0.0/0
    -
    - -

    So any address a.b.c.d may also be written a.b.c.d/32 - and the set of all possible IP addresses is written 0.0.0.0/0.

    - -

    Later in this guide, you will see the notation a.b.c.d/v - used to describe the ip configuration of a network interface (the 'ip' - utility also uses this syntax). This simply means that the interface is - configured with ip address a.b.c.d and with the netmask that corresponds - to VLSM /v.

    - -

    Example: 192.0.2.65/29

    - -

        The interface is configured with IP address 192.0.2.65 - and netmask 255.255.255.248.

    - -

    4.3 Routing

    - -

    One of the purposes of subnetting is that it forms the basis - for routing. Here's the routing table on my firewall:

    - -
    -
    - 
    [root@gateway root]# netstat -nr
    Kernel IP routing table
    Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
    192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
    206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
    206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
    192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
    192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
    192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
    206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
    192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
    127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
    0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
    [root@gateway root]#
    -
    -
    - -

    The device texas is a GRE tunnel to a peer site in - the Dallas, Texas area.
    -
    - The first three routes are host routes since they indicate -how to get to a single host. In the 'netstat' output this can be seen -by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the -Flags column. The remainder are 'net' routes since they tell the kernel -how to route packets to a subnetwork. The last route is the default - route and the gateway mentioned in that route is called the default - gateway.

    - -

    When the kernel is trying to send a packet to IP address -A, it starts at the top of the routing table and:

    - -
      -
    • -

      A is logically ANDed with the 'Genmask' value -in the table entry.

      -
      • -
    • -

      The result is compared with the 'Destination' value in - the table entry.

      -
      • -
    • -

      If the result and the 'Destination' value are the same, - then:

      - -
        -
      • -

        If the 'Gateway' column is non-zero, the packet is - sent to the gateway over the interface named in the 'Iface' column.

        -
        • -
      • -

        Otherwise, the packet is sent directly to A over - the interface named in the 'iface' column.

        -
        • - -
      -
      • -
    • -

      Otherwise, the above steps are repeated on the next entry - in the table.

      -
      • - -
    - -

    Since the default route matches any IP address (A -land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing -table entries are sent to the default gateway which is usually a -router at your ISP.

    - -

    Lets take an example. Suppose that we want to route a packet - to 192.168.1.5. That address clearly doesn't match any of the host routes - in the table but if we logically and that address with 255.255.255.0, -the result is 192.168.1.0 which matches this routing table entry:

    - -
    -
    - 
    192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
    -
    +
    + +

    So any address a.b.c.d may also be written a.b.c.d/32 + and the set of all possible IP addresses is written 0.0.0.0/0.

    + +

    Later in this guide, you will see the notation a.b.c.d/v + used to describe the ip configuration of a network interface (the 'ip' + utility also uses this syntax). This simply means that the interface is + configured with ip address a.b.c.d and with the netmask that corresponds + to VLSM /v.

    + +

    Example: 192.0.2.65/29

    + +

        The interface is configured with IP address 192.0.2.65 + and netmask 255.255.255.248.

    + +

    4.3 Routing

    + +

    One of the purposes of subnetting is that it forms the basis + for routing. Here's the routing table on my firewall:

    + +
    +
    + 
    [root@gateway root]# netstat -nr
    Kernel IP routing table
    Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
    192.168.9.1 	0.0.0.0 	255.255.255.255 UH    40  0         0 texas
    206.124.146.177 0.0.0.0 	255.255.255.255 UH    40  0         0 eth1
    206.124.146.180 0.0.0.0 	255.255.255.255 UH    40  0         0 eth3
    192.168.3.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth3
    192.168.2.0 	0.0.0.0 	255.255.255.0   U     40  0         0 eth1
    192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
    206.124.146.0 	0.0.0.0 	255.255.255.0 	U     40  0         0 eth0
    192.168.9.0     192.0.2.223 	255.255.255.0 	UG    40  0         0 texas
    127.0.0.0 	0.0.0.0 	255.0.0.0 	U     40  0         0 lo
    0.0.0.0 	206.124.146.254 0.0.0.0 	UG    40  0         0 eth0
    [root@gateway root]#
    +
    +
    + +

    The device texas is a GRE tunnel to a peer site in + the Dallas, Texas area.
    +
    + The first three routes are host routes since they indicate +how to get to a single host. In the 'netstat' output this can be seen +by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags +column. The remainder are 'net' routes since they tell the kernel how +to route packets to a subnetwork. The last route is the default route +and the gateway mentioned in that route is called the default gateway.

    + +

    When the kernel is trying to send a packet to IP address A, + it starts at the top of the routing table and:

    -

    So to route a packet to 192.168.1.5, the packet is sent directly over -eth2.

    - - -

    One more thing needs to be emphasized -- all outgoing packet - are sent using the routing table and reply packets are not a special -case. There seems to be a common mis-conception whereby people think -that request packets are like salmon and contain a genetic code that -is magically transferred to reply packets so that the replies follow -the reverse route taken by the request. That isn't the case; the replies -may take a totally different route back to the client than was taken by -the requests -- they are totally independent.

    - -

    4.4 Address Resolution Protocol

    - -

    When sending packets over Ethernet, IP addresses aren't used. - Rather Ethernet addressing is based on Media Access Control (MAC) - addresses. Each Ethernet device has it's own unique  MAC address which - is burned into a PROM on the device during manufacture. You can obtain -the MAC of an Ethernet device using the 'ip' utility:

    - -
    -
    - 
    [root@gateway root]# ip addr show eth0
    2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
    link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
    inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
    inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
    inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
    [root@gateway root]#
    -
    -
    - -
    -

    As you can see from the above output, the MAC is 6 bytes -(48 bits) wide. A card's MAC is usually also printed on a label attached -to the card itself.

    -
    - -
    -

    Because IP uses IP addresses and Ethernet uses MAC addresses, - a mechanism is required to translate an IP address into a MAC address; - that is the purpose of the Address Resolution Protocol (ARP). - Here is ARP in action:

    -
    - -
    -
    -
    - 
    [root@gateway root]# tcpdump -nei eth2 arp
    tcpdump: listening on eth2
    09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
    09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

    2 packets received by filter
    0 packets dropped by kernel
    [root@gateway root]#
    -
    -
    -
    - -

    In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants - to know the MAC of the device with IP address 192.168.1.19. The system - having that IP address is responding that the MAC address of the device - with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

    - -

    In order to avoid having to exchange ARP information each - time that an IP packet is to be sent, systems maintain an ARP cache - of IP<->MAC correspondences. You can see the ARP cache on your -system (including your Windows system) using the 'arp' command:

    - -
    -
    - 
    [root@gateway root]# arp -na
    ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
    ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
    ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
    ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
    ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
    -
    -
    - -

    The leading question marks are a result of my having specified - the 'n' option (Windows 'arp' doesn't allow that option) which causes -the 'arp' program to forego IP->DNS name translation. Had I not given -that option, the question marks would have been replaced with the FQDN -corresponding to each IP address. Notice that the last entry in the table -records the information we saw using tcpdump above.

    - -

    4.5 RFC 1918

    - -

    IP addresses are allocated by the Internet Assigned Number Authority (IANA) - who delegates allocations on a geographic basis to Regional Internet - Registries (RIRs). For example, allocation for the Americas and for - sub-Sahara Africa is delegated to the American - Registry for Internet Numbers (ARIN). These RIRs may in turn -delegate to national registries. Most of us don't deal with these registrars -but rather get our IP addresses from our ISP.

    - -

    It's a fact of life that most of us can't afford as many -Public IP addresses as we have devices to assign them to so we end up making -use of Private IP addresses. RFC 1918 reserves several IP address -ranges for this purpose:

    - -
    -
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -
    -

    The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. This is -understandable given that anyone can select any of these addresses -for their private use.

    -
    - -
    -

    When selecting addresses from these ranges, there's a couple - of things to keep in mind:

    -
    - -
      -
    • -

      As the IPv4 address space becomes depleted, more and -more organizations (including ISPs) are beginning to use RFC 1918 addresses - in their infrastructure.

      -
      • -
    • -

      You don't want to use addresses that are being used by - your ISP or by another organization with whom you want to establish - a VPN relationship.

      -
      • - +
    • +

      A is logically ANDed with the 'Genmask' value in +the table entry.

      +
      • +
    • +

      The result is compared with the 'Destination' value in + the table entry.

      +
      • +
    • +

      If the result and the 'Destination' value are the same, + then:

      + +
        +
      • + +

        If the 'Gateway' column is non-zero, the packet is + sent to the gateway over the interface named in the 'Iface' column.

        +
        • +
      • + +

        Otherwise, the packet is sent directly to A over + the interface named in the 'iface' column.

        +
        • + +
      +
      • +
    • +

      Otherwise, the above steps are repeated on the next entry + in the table.

      +
      • +
    + +

    Since the default route matches any IP address (A land + 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table + entries are sent to the default gateway which is usually a router +at your ISP.

    + +

    Lets take an example. Suppose that we want to route a packet + to 192.168.1.5. That address clearly doesn't match any of the host routes + in the table but if we logically and that address with 255.255.255.0, +the result is 192.168.1.0 which matches this routing table entry:

    + +
    +
    + 
    192.168.1.0     0.0.0.0 	255.255.255.0 	U     40  0         0 eth2
    +
    + +

    So to route a packet to 192.168.1.5, the packet is sent directly over eth2.

    + +

    One more thing needs to be emphasized -- all outgoing packet + are sent using the routing table and reply packets are not a special case. + There seems to be a common mis-conception whereby people think that request + packets are like salmon and contain a genetic code that is magically +transferred to reply packets so that the replies follow the reverse route +taken by the request. That isn't the case; the replies may take a totally +different route back to the client than was taken by the requests -- they +are totally independent.

    + +

    4.4 Address Resolution Protocol

    + +

    When sending packets over Ethernet, IP addresses aren't used. + Rather Ethernet addressing is based on Media Access Control (MAC) + addresses. Each Ethernet device has it's own unique  MAC address which + is burned into a PROM on the device during manufacture. You can obtain +the MAC of an Ethernet device using the 'ip' utility:

    + +
    +
    + 
    [root@gateway root]# ip addr show eth0
    2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
    link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
    inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
    inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
    inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
    [root@gateway root]#
    +
    +
    + +
    +

    As you can see from the above output, the MAC is 6 bytes (48 + bits) wide. A card's MAC is usually also printed on a label attached to +the card itself.

    +
    + +
    +

    Because IP uses IP addresses and Ethernet uses MAC addresses, + a mechanism is required to translate an IP address into a MAC address; + that is the purpose of the Address Resolution Protocol (ARP). + Here is ARP in action:

    +
    + +
    +
    +
    + 
    [root@gateway root]# tcpdump -nei eth2 arp
    tcpdump: listening on eth2
    09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
    09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

    2 packets received by filter
    0 packets dropped by kernel
    [root@gateway root]#
    +
    +
    +
    + +

    In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants + to know the MAC of the device with IP address 192.168.1.19. The system + having that IP address is responding that the MAC address of the device + with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.

    + +

    In order to avoid having to exchange ARP information each + time that an IP packet is to be sent, systems maintain an ARP cache + of IP<->MAC correspondences. You can see the ARP cache on your system + (including your Windows system) using the 'arp' command:

    + +
    +
    + 
    [root@gateway root]# arp -na
    ? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
    ? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
    ? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
    ? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
    ? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
    +
    +
    + +

    The leading question marks are a result of my having specified + the 'n' option (Windows 'arp' doesn't allow that option) which causes +the 'arp' program to forego IP->DNS name translation. Had I not given +that option, the question marks would have been replaced with the FQDN +corresponding to each IP address. Notice that the last entry in the table +records the information we saw using tcpdump above.

    + +

    4.5 RFC 1918

    + +

    IP addresses are allocated by the Internet Assigned Number Authority (IANA) + who delegates allocations on a geographic basis to Regional Internet + Registries (RIRs). For example, allocation for the Americas and for + sub-Sahara Africa is delegated to the American + Registry for Internet Numbers (ARIN). These RIRs may in turn delegate + to national registries. Most of us don't deal with these registrars but + rather get our IP addresses from our ISP.

    + +

    It's a fact of life that most of us can't afford as many Public + IP addresses as we have devices to assign them to so we end up making use +of Private IP addresses. RFC 1918 reserves several IP address ranges +for this purpose:

    + +
    +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    +
    + +
    +

    The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. This is understandable + given that anyone can select any of these addresses for their private + use.

    +
    + +
    +

    When selecting addresses from these ranges, there's a couple + of things to keep in mind:

    +
    + +
    +
      +
    • +

      As the IPv4 address space becomes depleted, more and more + organizations (including ISPs) are beginning to use RFC 1918 addresses + in their infrastructure.

      +
      • +
    • +

      You don't want to use addresses that are being used by + your ISP or by another organization with whom you want to establish + a VPN relationship.

      +
      • -
      -

      So it's a good idea to check with your ISP to see if they - are using (or are planning to use) private addresses before you decide +

    +
    + +
    +

    So it's a good idea to check with your ISP to see if they + are using (or are planning to use) private addresses before you decide the addresses that you are going to use.

    -
    - -
    +
    + +

    5.0 Setting up your Network

    -
    - -
    -

    The choice of how to set up your network depends primarily - on how many Public IP addresses you have vs. how many addressable entities - you have in your network. Regardless of how many addresses you have, +

    + +
    +

    The choice of how to set up your network depends primarily + on how many Public IP addresses you have vs. how many addressable entities + you have in your network. Regardless of how many addresses you have, your ISP will handle that set of addresses in one of two ways:

    -
    - -
    -
      -
    1. -

      Routed - Traffic to any of your addresses will - be routed through a single gateway address. This will generally - only be done if your ISP has assigned you a complete subnet (/29 or -larger). In this case, you will assign the gateway address as the IP -address of your firewall/router's external interface.

      -
      2. -
    2. -

      Non-routed - Your ISP will send traffic to each - of your addresses directly.

      -
      3. - -
    + +
    +
      +
    1. +

      Routed - Traffic to any of your addresses will + be routed through a single gateway address. This will generally + only be done if your ISP has assigned you a complete subnet (/29 or +larger). In this case, you will assign the gateway address as the IP +address of your firewall/router's external interface.

      +
      2. +
    2. +

      Non-routed - Your ISP will send traffic to each + of your addresses directly.

      +
      3. -
      -

      In the subsections that follow, we'll look at each of these +

    +
    + +
    +

    In the subsections that follow, we'll look at each of these separately.
    -

    - +

    +

    Before we begin, there is one thing for you to check:

    - +

    -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
    -

    - +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
    +

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • - +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • +
    -
    - -
    -

    5.1 Routed

    - -
    -

    Let's assume that your ISP has assigned you the subnet - 192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses - 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address - is 192.0.2.65. Your ISP has also told you that you should use a netmask - of 255.255.255.0 (so your /28 is part of a larger /24). With this many - IP addresses, you are able to subnet your /28 into two /29's and set + +

    +

    5.1 Routed

    +
    + +
    +

    Let's assume that your ISP has assigned you the subnet +192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses + 192.0.2.64 - 192.0.2.79 and that your firewall's external IP address + is 192.0.2.65. Your ISP has also told you that you should use a netmask + of 255.255.255.0 (so your /28 is part of a larger /24). With this many + IP addresses, you are able to subnet your /28 into two /29's and set up your network as shown in the following diagram.

    -
    - -
    +
    + +

    -

    -
    - -
    -

    Here, the DMZ comprises the subnet 192.0.2.64/29 and the -Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ -would be configured to 192.0.2.66 and the default gateway for hosts in -the local network would be 192.0.2.73.

    -
    - -
    -

    Notice that this arrangement is rather wasteful of public - IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet -addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses -and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router. -Nevertheless, it shows how subnetting can work and if we were dealing -with a /24 rather than a /28 network, the use of 6 IP addresses out -of 256 would be justified because of the simplicity of the setup.

    -
    - -
    -

    The astute reader may have noticed that the Firewall/Router's - external interface is actually part of the DMZ subnet (192.0.2.64/29). - What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The +

    +
    + +
    +

    Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local + network is 192.0.2.72/29. The default gateway for hosts in the DMZ would +be configured to 192.0.2.66 and the default gateway for hosts in the local + network would be 192.0.2.73.

    +
    + +
    +

    Notice that this arrangement is rather wasteful of public + IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet +addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and +192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router. +Nevertheless, it shows how subnetting can work and if we were dealing +with a /24 rather than a /28 network, the use of 6 IP addresses out of +256 would be justified because of the simplicity of the setup.

    +
    + +
    +

    The astute reader may have noticed that the Firewall/Router's + external interface is actually part of the DMZ subnet (192.0.2.64/29). + What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The routing table on DMZ 1 will look like this:

    -
    - -
    -
    +
    + +
    +
    Kernel IP routing table
    Destination 	Gateway 	Genmask 	Flags MSS Window irtt Iface
    192.0.2.64 	0.0.0.0 	255.255.255.248 U     40  0         0 eth0
    0.0.0.0 	192.0.2.66	0.0.0.0 	UG    40  0         0 eth0
    -
    -
    - -
    -

    This means that DMZ 1 will send an ARP "who-has 192.0.2.65" - request and no device on the DMZ Ethernet segment has that IP address. - Oddly enough, the firewall will respond to the request with the MAC -address of its DMZ Interface!! DMZ 1 can then send Ethernet frames -addressed to that MAC address and the frames will be received (correctly) + +

    + +
    +

    This means that DMZ 1 will send an ARP "who-has 192.0.2.65" + request and no device on the DMZ Ethernet segment has that IP address. + Oddly enough, the firewall will respond to the request with the MAC +address of its DMZ Interface!! DMZ 1 can then send Ethernet frames +addressed to that MAC address and the frames will be received (correctly) by the firewall/router.

    -
    - -
    -

    It is this rather unexpected ARP behavior on the part of -the Linux Kernel that prompts the warning earlier in this guide regarding -the connecting of multiple firewall/router interfaces to the same hub -or switch. When an ARP request for one of the firewall/router's IP addresses -is sent by another system connected to the hub/switch, all of the firewall's - interfaces that connect to the hub/switch can respond! It is then a +

    + +
    +

    It is this rather unexpected ARP behavior on the part of the + Linux Kernel that prompts the warning earlier in this guide regarding the + connecting of multiple firewall/router interfaces to the same hub or switch. + When an ARP request for one of the firewall/router's IP addresses is sent +by another system connected to the hub/switch, all of the firewall's + interfaces that connect to the hub/switch can respond! It is then a race as to which "here-is" response reaches the sender first.

    -
    - -
    +
    + +

    5.2 Non-routed

    -
    - -
    -

    If you have the above situation but it is non-routed, -you can configure your network exactly as described above with one additional - twist; simply specify the "proxyarp" option on all three firewall interfaces +

    + +
    +

    If you have the above situation but it is non-routed, you +can configure your network exactly as described above with one additional + twist; simply specify the "proxyarp" option on all three firewall interfaces in the /etc/shorewall/interfaces file.

    -
    - -
    -

    Most of us don't have the luxury of having enough public -IP addresses to set up our networks as shown in the preceding example -(even if the setup is routed).

    -
    - -
    -

    For the remainder of this section, assume that your ISP - has assigned you IP addresses 192.0.2.176-180 and has told you to use +

    + +
    +

    Most of us don't have the luxury of having enough public IP + addresses to set up our networks as shown in the preceding example (even +if the setup is routed).

    +
    + +
    +

    For the remainder of this section, assume that your ISP + has assigned you IP addresses 192.0.2.176-180 and has told you to use netmask 255.255.255.0 and default gateway 192.0.2.254.

    -
    - -
    -

    Clearly, that set of addresses doesn't comprise a subnetwork - and there aren't enough addresses for all of the network interfaces. - There are four different techniques that can be used to work around -this problem.

    -
    - -
    +
    + +
    +

    Clearly, that set of addresses doesn't comprise a subnetwork + and there aren't enough addresses for all of the network interfaces. + There are four different techniques that can be used to work around this + problem.

    +
    + +
      -
    • -

      Source Network Address Translation (SNAT). -

      -
      • -
    • -

      Destination Network Address Translation (DNAT) +

    • +

      Source Network Address Translation (SNAT). +

      +
      • +
    • +

      Destination Network Address Translation (DNAT) also known as Port Forwarding.

      -
      • -
    • +
      • +

    • Proxy ARP.

      -
      • -
    • -

      Network Address Translation (NAT) also referred +

      • +
    • +

      Network Address Translation (NAT) also referred to as Static NAT.

      -
      • - + +
    +
    + +
    +

    Often a combination of these techniques is used. Each of these + will be discussed in the sections that follow.

    - -
    -

    Often a combination of these techniques is used. Each of -these will be discussed in the sections that follow.

    -
    - -
    + +

     5.2.1 SNAT

    +
    + +
    +

    With SNAT, an internal LAN segment is configured using RFC + 1918 addresses. When a host A on this internal segment initiates + a connection to host B on the internet, the firewall/router rewrites + the IP header in the request to use one of your public IP addresses +as the source address. When B responds and the response is received + by the firewall, the firewall changes the destination address back +to the RFC 1918 address of A and forwards the response back to +A.

    - -
    -

    With SNAT, an internal LAN segment is configured using RFC - 1918 addresses. When a host A on this internal segment initiates - a connection to host B on the internet, the firewall/router -rewrites the IP header in the request to use one of your public IP -addresses as the source address. When B responds and the response -is received by the firewall, the firewall changes the destination address -back to the RFC 1918 address of A and forwards the response back -to A.

    -
    - -
    -

    Let's suppose that you decide to use SNAT on your local zone - and use public address 192.0.2.176 as both your firewall's external -IP address and the source IP address of internet requests sent from -that zone.

    -
    - -
    + +
    +

    Let's suppose that you decide to use SNAT on your local zone + and use public address 192.0.2.176 as both your firewall's external +IP address and the source IP address of internet requests sent from that + zone.

    +
    + +

    -

    -
    - -
    The local zone has been subnetted as 192.168.201.0/29 + +
    + +
    The local zone has been subnetted as 192.168.201.0/29 (netmask 255.255.255.248).
    - +
     
    - +
    -     The systems in the local zone would be configured with a default - gateway of 192.168.201.1 (the IP address of the firewall's local interface).
    - +     The systems in the local zone would be configured with a default + gateway of 192.168.201.1 (the IP address of the firewall's local interface).
    +
     
    - +
    -     SNAT is configured in Shorewall using the /etc/shorewall/masq file.
    - -
    -
    + +
    +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    +
    +
    + +
    +

    This example used the normal technique of assigning the same + public IP address for the firewall external interface and for SNAT. +If you wanted to use a different IP address, you would either have to +use your distributions network configuration tools to add that IP address + to the external interface or you could set ADD_SNAT_ALIASES=Yes in + /etc/shorewall/shorewall.conf and Shorewall will add the address for you.

    - -
    -

    This example used the normal technique of assigning the same - public IP address for the firewall external interface and for SNAT. -If you wanted to use a different IP address, you would either have to -use your distributions network configuration tools to add that IP address - to the external interface or you could set ADD_SNAT_ALIASES=Yes in - /etc/shorewall/shorewall.conf and Shorewall will add the address for you.

    -
    - -
    + +

    5.2.2 DNAT

    -
    - -
    -

    When SNAT is used, it is impossible for hosts on the internet - to initiate a connection to one of the internal systems since those -systems do not have a public IP address. DNAT provides a way to allow +

    + +
    +

    When SNAT is used, it is impossible for hosts on the internet + to initiate a connection to one of the internal systems since those +systems do not have a public IP address. DNAT provides a way to allow selected connections from the internet.

    -
    - -
    +
    + +

    -      Suppose that your daughter wants to run a web server on her -system "Local 3". You could allow connections to the internet to her -server by adding the following entry in /etc/shorewall/rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    DNATnetloc:192.168.201.4tcpwww-192.0.2.176
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    DNATnetloc:192.168.201.4tcpwww-192.0.2.176
    -
    -
    - -
    -

    If one of your daughter's friends at address A wants + +

    + +
    +

    If one of your daughter's friends at address A wants to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external - IP address) and the firewall will rewrite the destination IP address - to 192.168.201.4 (your daughter's system) and forward the request. When - your daughter's server responds, the firewall will rewrite the source + href="http://192.0.2.176"> http://192.0.2.176 (the firewall's external + IP address) and the firewall will rewrite the destination IP address + to 192.168.201.4 (your daughter's system) and forward the request. When + your daughter's server responds, the firewall will rewrite the source address back to 192.0.2.176 and send the response back to A.

    -
    - -
    -

    This example used the firewall's external IP address for -DNAT. You can use another of your public IP addresses but Shorewall will -not add that address to the firewall's external interface for you.

    -
    - -
    +
    + +
    +

    This example used the firewall's external IP address for DNAT. + You can use another of your public IP addresses but Shorewall will not +add that address to the firewall's external interface for you.

    +
    + +

    5.2.3 Proxy ARP

    -
    - -
    +
    + +

    The idea behind proxy ARP is that:

    -
    - -
    -
      -
    • -

      A host H behind your firewall is assigned one -of your public IP addresses (A) and is assigned the same netmask - (M) as the firewall's external interface.

      -
      • -
    • -

      The firewall responds to ARP "who has" requests for A. -

      -
      • -
    • -

      When H issues an ARP "who has" request for an -address in the subnetwork defined by A and M, the firewall -will respond (with the MAC if the firewall interface to H).

      -
      • - -
    + +
    +
      +
    • +

      A host H behind your firewall is assigned one of +your public IP addresses (A) and is assigned the same netmask + (M) as the firewall's external interface.

      +
      • +
    • +

      The firewall responds to ARP "who has" requests for A. +

      +
      • +
    • +

      When H issues an ARP "who has" request for an address + in the subnetwork defined by A and M, the firewall will +respond (with the MAC if the firewall interface to H).

      +
      • -
      -

      Let suppose that we decide to use Proxy ARP on the DMZ in +

    +
    + +
    +

    Let suppose that we decide to use Proxy ARP on the DMZ in our example network.

    -
    - -
    +
    + +

    -

    -
    - -
    Here, we've assigned the IP addresses 192.0.2.177 to - system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned - an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface - on the firewall. That address and netmask isn't relevant - just be sure +

    +
    + +
    Here, we've assigned the IP addresses 192.0.2.177 to + system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned + an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface + on the firewall. That address and netmask isn't relevant - just be sure it doesn't overlap another subnet that you've defined.
    - +
     
    - +
    -     The Shorewall configuration of Proxy ARP is done using the - /etc/shorewall/proxyarp file.
    - -
    -
    +     The Shorewall configuration of Proxy ARP is done using the + /etc/shorewall/proxyarp file.
    + +
    +
    - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    -

    Because the HAVE ROUTE column contains No, Shorewall will + +

    + +
    +

    Because the HAVE ROUTE column contains No, Shorewall will add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
    -

    - -

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured - to have the IP addresses shown but should have the same default gateway -as the firewall itself -- namely 192.0.2.254.
    -

    -
    - -
    +

    + +

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured + to have the IP addresses shown but should have the same default gateway as + the firewall itself -- namely 192.0.2.254.
    +

    +
    + +

    -
    - -
    -
    -

    A word of warning is in order here. ISPs typically configure - their routers with a long ARP cache timeout. If you move a system from - parallel to your firewall to behind your firewall with Proxy ARP, it will - probably be HOURS before that system can communicate with the internet. - There are a couple of things that you can try:
    -

    +
    +
    +
    +

    A word of warning is in order here. ISPs typically configure + their routers with a long ARP cache timeout. If you move a system from + parallel to your firewall to behind your firewall with Proxy ARP, it +will probably be HOURS before that system can communicate with the internet. + There are a couple of things that you can try:
    +

    +
      -
    1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP Illustrated, - Vol 1 reveals that a
      -
      - "gratuitous" ARP packet should cause the ISP's router to refresh their -ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the -MAC address for its own IP; in addition to ensuring that the IP address isn't - a duplicate,...
      +
    2. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP +Illustrated, Vol 1 reveals that a

      - "if the host sending the gratuitous ARP has just changed its hardware -address..., this packet causes any other host...that has an entry in its -cache for the old hardware address to update its ARP cache entry accordingly."
      -
      - Which is, of course, exactly what you want to do when you switch a host - from being exposed to the Internet to behind Shorewall using proxy ARP (or - static NAT for that matter). Happily enough, recent versions of Redhat's -iputils package include "arping", whose "-U" flag does just that:
      -
      -     arping -U -I <net if> <newly proxied - IP>
      -     arping -U -I eth0 66.58.99.83 # for example
      -
      - Stevens goes on to mention that not all systems respond correctly to -gratuitous ARPs, but googling for "arping -U" seems to support the idea + "gratuitous" ARP packet should cause the ISP's router to refresh their + ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the + MAC address for its own IP; in addition to ensuring that the IP address +isn't a duplicate,...
      +
      + "if the host sending the gratuitous ARP has just changed its hardware + address..., this packet causes any other host...that has an entry in its + cache for the old hardware address to update its ARP cache entry accordingly."
      +
      + Which is, of course, exactly what you want to do when you switch a host + from being exposed to the Internet to behind Shorewall using proxy ARP + (or static NAT for that matter). Happily enough, recent versions of Redhat's + iputils package include "arping", whose "-U" flag does just that:
      +
      +     arping -U -I <net if> <newly proxied + IP>
      +     arping -U -I eth0 66.58.99.83 # for example
      +
      + Stevens goes on to mention that not all systems respond correctly to +gratuitous ARPs, but googling for "arping -U" seems to support the idea that it works most of the time.
      -
      -
      3. -
    3. You can call your ISP and ask them to purge the stale ARP cache - entry but many either can't or won't purge individual entries.
      4. - +
      + +
    4. You can call your ISP and ask them to purge the stale ARP cache + entry but many either can't or won't purge individual entries.
      5. +
    - You can determine if your ISP's gateway ARP cache is stale using ping - and tcpdump. Suppose that we suspect that the gateway router has a stale - ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:
    - -
    + You can determine if your ISP's gateway ARP cache is stale using +ping and tcpdump. Suppose that we suspect that the gateway router has +a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump +as follows:
    + +
    	tcpdump -nei eth0 icmp
    +
    + +
    +

    Now from 130.252.100.19, ping the ISP's gateway (which we + will assume is 130.252.100.254):

    - -
    -

    Now from 130.252.100.19, ping the ISP's gateway (which we - will assume is 130.252.100.254):

    -
    - -
    + +
    	ping 130.252.100.254
    -
    -
    - -
    +
    +
    + +

    We can now observe the tcpdump output:

    -
    - -
    +
    + +
    	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
    	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
    +
    + +
    +

    Notice that the source MAC address in the echo request is + different from the destination MAC address in the echo reply!! In this + case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 + was the MAC address of DMZ 1. In other words, the gateway's ARP cache + still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the + firewall's eth0.

    - -
    -

    Notice that the source MAC address in the echo request is - different from the destination MAC address in the echo reply!! In this - case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57 - was the MAC address of DMZ 1. In other words, the gateway's ARP cache - still associates 192.0.2.177 with the NIC in DMZ 1 rather than with -the firewall's eth0.

    -
    - -
    + +

    5.2.4 Static NAT

    +
    + +
    +

    With static NAT, you assign local systems RFC 1918 addresses + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT (Source Network Address + Translation) occurs and on incoming connections DNAT (Destination Network + Address Translation) occurs. Let's go back to our earlier example involving + your daughter's web server running on system Local 3.

    - -
    -

    With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public - IP addresses. For outgoing connections SNAT (Source Network Address -Translation) occurs and on incoming connections DNAT (Destination Network -Address Translation) occurs. Let's go back to our earlier example involving -your daughter's web server running on system Local 3.

    -
    - -
    + +

    -

    -
    - -
    -

    Recall that in this setup, the local network is using SNAT - and is sharing the firewall external IP (192.0.2.176) for outbound -connections. This is done with the following entry in /etc/shorewall/masq:

    -
    - -
    -
    +

    +
    + +
    +

    Recall that in this setup, the local network is using SNAT + and is sharing the firewall external IP (192.0.2.176) for outbound connections. + This is done with the following entry in /etc/shorewall/masq:

    +
    + +
    +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    -     Suppose now that you have decided to give your daughter her -own IP address (192.0.2.179) for both inbound and outbound connections. +     Suppose now that you have decided to give your daughter her +own IP address (192.0.2.179) for both inbound and outbound connections. You would do that by adding an entry in /etc/shorewall/nat.

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    -

    With this entry in place, you daughter has her own IP address + +

    + +
    +

    With this entry in place, you daughter has her own IP address and the other two local systems share the firewall's IP address.

    -
    - -
    +
    + +

    -     Once the relationship between 192.0.2.179 and 192.168.201.4 -is established by the nat file entry above, it is no longer appropriate - to use a DNAT rule for you daughter's web server -- you would rather -just use an ACCEPT rule:

    -
    - -
    -
    +     Once the relationship between 192.0.2.179 and 192.168.201.4 +is established by the nat file entry above, it is no longer appropriate + to use a DNAT rule for you daughter's web server -- you would rather + just use an ACCEPT rule:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    -
    -
    - -
    + +
    + +

    5.3 Rules

    -
    - -
    +
    + +

    -     With the default policies, your local systems (Local 1-3) can - access any servers on the internet and the DMZ can't access any other +     With the default policies, your local systems (Local 1-3) can + access any servers on the internet and the DMZ can't access any other host (including the firewall). With the exception of DNAT rules which cause address translation and allow - the translated connection request to pass through the firewall, the -way to allow connection requests through your firewall is to use ACCEPT + href="#DNAT">DNAT rules which cause address translation and allow + the translated connection request to pass through the firewall, the way + to allow connection requests through your firewall is to use ACCEPT rules.

    -
    - -
    -

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't +

    + +
    +

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't used in this section, they won't be shown

    -
    - -
    +
    + +

    You probably want to allow ping between your zones:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    -
    -
    - -
    -

    Let's suppose that you run mail and pop3 servers on DMZ 2 + +

    + +
    +

    Let's suppose that you run mail and pop3 servers on DMZ 2 and a Web Server on DMZ 1. The rules that you would need are:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    -
    + +
    + +
    +

    If you run a public DNS server on 192.0.2.177, you would need + to add the following rules:

    - -
    -

    If you run a public DNS server on 192.0.2.177, you would -need to add the following rules:

    -
    - -
    -
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    -
    -
    - -
    -

    You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which through +

    +
    + +
    +

    You probably want some way to communicate with your firewall + and DMZ systems from the local network -- I recommend SSH which through its scp utility can also do publishing and software update distribution.

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    5.4 Odds and Ends

    +
    + +
    +

    The above discussion reflects my personal preference for using + Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I +prefer to use NAT only in cases where a system that is part of an RFC 1918 +subnet needs to have it's own public IP. 

    - -
    -

    The above discussion reflects my personal preference for -using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. -I prefer to use NAT only in cases where a system that is part of an RFC -1918 subnet needs to have it's own public IP. 

    -
    - -
    + +

    -     If you haven't already, it would be a good idea to browse through - /etc/shorewall/shorewall.conf just - to see if there is anything there that might be of interest. You might - also want to look at the other configuration files that you haven't -touched yet just to get a feel for the other things that Shorewall can +     If you haven't already, it would be a good idea to browse through + /etc/shorewall/shorewall.conf just + to see if there is anything there that might be of interest. You might + also want to look at the other configuration files that you haven't +touched yet just to get a feel for the other things that Shorewall can do.

    -
    - -
    -

    In case you haven't been keeping score, here's the final -set of configuration files for our sample network. Only those that were -modified from the original installation are shown.

    -
    - -
    -

    /etc/shorewall/interfaces (The "options" will be very -site-specific).

    -
    - -
    -
    +
    + +
    +

    In case you haven't been keeping score, here's the final set + of configuration files for our sample network. Only those that were modified + from the original installation are shown.

    +
    + +
    +

    /etc/shorewall/interfaces (The "options" will be very site-specific).

    +
    + +
    +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    -
    -
    - -
    -

    The setup described here requires that your network interfaces - be brought up before Shorewall can start. This opens a short window -during which you have no firewall protection. If you replace 'detect' -with the actual broadcast addresses in the entries above, you can bring + +

    + +
    +

    The setup described here requires that your network interfaces + be brought up before Shorewall can start. This opens a short window +during which you have no firewall protection. If you replace 'detect' +with the actual broadcast addresses in the entries above, you can bring up Shorewall before you bring up your network interfaces.

    -
    - -
    -
    +
    + +
    +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    -
    -
    - -
    + +
    + +

    /etc/shorewall/masq - Local subnet

    -
    - -
    -
    +
    + +
    +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    /etc/shorewall/proxyarp - DMZ

    -
    - -
    -
    +
    + +
    +
    - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    + +
    + +

    /etc/shorewall/nat- Daughter's System

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    + +
    + +

    /etc/shorewall/rules

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    6.0 DNS

    -
    - -
    -

    Given the collection of RFC 1918 and public addresses in -this setup, it only makes sense to have separate internal and external -DNS servers. You can combine the two into a single BIND 9 server using -Views. If you are not interested in Bind 9 views, you can + +

    - -
    -

    Suppose that your domain is foobar.net and you want the two - DMZ systems named www.foobar.net and mail.foobar.net and you want the - three local systems named "winken.foobar.net, blinken.foobar.net and -nod.foobar.net. You want your firewall to be known as firewall.foobar.net -externally and it's interface to the local network to be know as gateway.foobar.net - and its interface to the dmz as dmz.foobar.net. Let's have the DNS server +

    + +
    +

    Suppose that your domain is foobar.net and you want the two + DMZ systems named www.foobar.net and mail.foobar.net and you want the + three local systems named "winken.foobar.net, blinken.foobar.net and +nod.foobar.net. You want your firewall to be known as firewall.foobar.net +externally and it's interface to the local network to be know as gateway.foobar.net + and its interface to the dmz as dmz.foobar.net. Let's have the DNS server on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    -
    - -
    +
    + +

    The /etc/named.conf file would look like this:

    -
    - -
    -
    -
    +
    + +
    +
    + 
    options {
    	directory "/var/named";
    	listen-on { 127.0.0.1 ; 192.0.2.177; };
    };

    logging {
    	channel xfer-log {
    		file "/var/log/named/bind-xfer.log";
    		print-category yes;
    		print-severity yes;
    		print-time yes;
    		severity info;
    	};
    	category xfer-in { xfer-log; };
    	category xfer-out { xfer-log; };
    	category notify { xfer-log; };
    };
    -
    - -
    +
    + + 
    #
    # This is the view presented to our internal systems
    #

    view "internal" {
    	#
    	# These are the clients that see this view
    	#
    	match-clients { 192.168.201.0/29;
    			192.168.202.0/29;
    			127.0.0/24;
    			192.0.2.176/32; 
    			192.0.2.178/32;
    			192.0.2.179/32;
    			192.0.2.180/32; };
    	#
    	# If this server can't complete the request, it should use outside
    	# servers to do so
    	#
    	recursion yes;

    	zone "." in {
    		type hint;
    		file "int/root.cache";
    	};

    	zone "foobar.net" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.foobar";
    	};

    	zone "0.0.127.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.127.0.0";	
    	};

    	zone "201.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.201";
    	};

    	zone "202.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.202";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.176";
    	};
     (or status NAT for that matter)
    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.206.124.146.179";
    	};

    };
    #
    # This is the view that we present to the outside world
    #
    view "external" {
    	match-clients { any; };
    	#
    	# If we can't answer the query, we tell the client so
    	#
    	recursion no;

    	zone "foobar.net" in {
    		type master;
    		notify yes;
    		allow-update {none; };
    		allow-transfer { <secondary NS IP>; };
    		file "ext/db.foobar";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
     		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.176";
    	};

    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.179";
    	};
    };
    -
    -
    -
    - -
    -

    Here are the files in /var/named (those not shown are usually +

    +
    +
    + +
    +

    Here are the files in /var/named (those not shown are usually included in your bind disbribution).

    - -

    db.192.0.2.176 - This is the reverse zone for the firewall's + +

    db.192.0.2.176 - This is the reverse zone for the firewall's external interface

    - -
    + +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
    ; Filename: db.192.0.2.176
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
    -
    -
    - -
    -
    db.192.0.2.177 - This is the reverse zone for the www/DNS - server -
    +
    +
    + +
    +
    db.192.0.2.177 - This is the reverse zone for the www/DNS + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
    ; Filename: db.192.0.2.177
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
    -
    -
    -
    - -
    -
    db.192.0.2.178 - This is the reverse zone for the mail - server -
    +
    +
    +
    + +
    +
    db.192.0.2.178 - This is the reverse zone for the mail + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
    ; Filename: db.192.0.2.178
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
    -
    -
    -
    - -
    -
    db.192.0.2.179 - This is the reverse zone for daughter's - web server's public IP -
    +
    +
    +
    + +
    +
    db.192.0.2.179 - This is the reverse zone for daughter's + web server's public IP +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
    ; Filename: db.192.0.2.179
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
    -
    -
    -
    - -
    + +
    +
    + +

    int/db.127.0.0 - The reverse zone for localhost

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
    ; Filename: db.127.0.0
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    				2001092901 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR	localhost.foobar.net.
    -
    -
    - -
    -

    int/db.192.168.201 - Reverse zone for the local net. This + +

    + +
    +

    int/db.192.168.201 - Reverse zone for the local net. This is only shown to internal clients

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
    ; Filename: db.192.168.201
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR 	gateway.foobar.net.
    2	86400		IN PTR	winken.foobar.net.
    3	86400		IN PTR	blinken.foobar.net.
    4	86400		IN PTR	nod.foobar.net.
    -
    + +
    + +
    +

    int/db.192.168.202 - Reverse zone for the firewall's DMZ + interface

    - -
    -

    int/db.192.168.202 - Reverse zone for the firewall's DMZ - interface

    -
    - -
    -
    -
    + +
    +
    + 
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
    ; Filename: db.192.168.202
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @		604800	IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1 		86400 IN PTR	dmz.foobar.net.
    -
    -
    -
    - -
    +
    +
    +
    + +

    int/db.foobar - Forward zone for use by internal clients.

    -
    - -
    -
    +
    + +
    +
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002071501 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; foobar.net Nameserver Records (NS)
    ;############################################################
    @ 		604800	IN NS	ns1.foobar.net.

    ;############################################################
    ; Foobar.net Office Records (ADDRESS)
    ;############################################################
    localhost	86400 	IN A 	127.0.0.1

    firewall	86400	IN A	192.0.2.176
    www		86400	IN A	192.0.2.177
    ns1 		86400	IN A 	192.0.2.177
    www		86400	IN A	192.0.2.177

    gateway		86400	IN A 	192.168.201.1
    winken		86400	IN A 	192.168.201.2
    blinken		86400	IN A	192.168.201.3
    nod		86400	IN A	192.168.201.4
    -
    -
    - -
    + +
    + +

    ext/db.foobar - Forward zone for external clients

    -
    - -
    -
    -
    +
    + +
    +
    + 
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002052901 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; Foobar.net Nameserver Records (NS)
    ;############################################################
    @		86400	IN NS	ns1.foobar.net.
    @		86400	IN NS	<secondary NS>.
    ;############################################################
    ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
    ;############################################################
    localhost	86400	IN A	127.0.0.1
    ;
    ; The firewall itself
    ;
    firewall	86400	IN A	192.0.2.176
    ;
    ; The DMZ
    ;
    ns1		86400	IN A	192.0.2.177
    www		86400	IN A	192.0.2.177
    mail		86400	IN A	192.0.2.178
    ;
    ; The Local Network
    ;
    nod		86400	IN A	192.0.2.179

    ;############################################################
    ; Current Aliases for foobar.net (CNAME)
    ;############################################################

    ;############################################################
    ; foobar.net MX Records (MAIL EXCHANGER)
    ;############################################################
    foobar.net.	86400	IN A	192.0.2.177
    		86400 	IN MX 0 mail.foobar.net.
    		86400	IN MX 1 <backup MX>.
    -
    -
    -
    - -
    -

    7.0 Starting and Stopping +

    +
    +
    + +
    +

    7.0 Starting and Stopping Your Firewall

    -
    - -
    -

    The installation procedure configures +

    + +
    +

    The installation procedure configures your system to start Shorewall at system boot.

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing +

    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter configuration, use "shorewall clear".

    -
    - -
    +
    + +

    -     Edit the /etc/shorewall/routestopped file and configure those - systems that you want to be able to access the firewall when it is -stopped.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have +     Edit the /etc/shorewall/routestopped file and configure those + systems that you want to be able to access the firewall when it is stopped.

    +
    + +
    +

    WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

    -
    - -

    Last updated 2/18/2003 - + +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 - Thomas M. Eastep

    -
    + +

    Copyright 2002, 2003 + Thomas M. Eastep

    +
    +



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

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

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

    What is it?

    @@ -115,11 +115,11 @@ - -

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

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

    @@ -132,29 +132,29 @@ - -

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

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

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

    @@ -166,7 +166,7 @@ A PARTICULAR PURPOSE. See the GNU General Public License - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -180,24 +180,25 @@ A PARTICULAR PURPOSE. See the GNU General Public License - +

    - 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 + Congratulations to Jacques and Eric on the recent release of Bering 1.1!!!
    +

    News

    @@ -213,97 +214,102 @@ on the recent release of Bering 1.1!!!
    - +

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

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

    + 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.
    - Function from 1.3 that has been omitted from this version include:
    - + IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package +('ip' utility).
    +
    + Function from 1.3 that has been omitted from this version include:
    +
      -
    1. The MERGE_HOSTS variable in shorewall.conf is no longer supported. +
    2. The MERGE_HOSTS variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
      -
      -
      3. -
    3. Interface names of the form <device>:<integer> -in /etc/shorewall/interfaces now generate an error.
      -
      -
      4. -
    4. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification +
      +
      5. +
    5. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
      +
      +
      6. +
    6. Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification of the 'noping' or 'filterping' interface options.
      -
      -
      7. -
    7. The 'routestopped' option in the /etc/shorewall/interfaces -and /etc/shorewall/hosts files is no longer supported and will generate an -error at startup if specified.
      -
      -
      8. -
    8. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no -longer accepted.
      -
      -
      9. -
    9. The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
      +
      10. +
    10. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will generate +an error at startup if specified.
      +
      +
      11. +
    11. The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no + longer accepted.
      +
      +
      12. +
    12. The ALLOWRELATED variable in shorewall.conf is no longer +supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      +
      +
      13. +
    13. The icmp.def file has been removed.

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

    - + @@ -312,7 +318,7 @@ support the 'maclist' option.
    - +
      @@ -321,16 +327,16 @@ support the 'maclist' option.
      - -
    - - - - - - - + + + + + + + + +

    More News

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

    - +

    SourceForge Logo -

    + - +

    - +

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

    @@ -376,44 +382,44 @@ support the 'maclist' option.
    - +

    Donations

    -
    -
    -
    +
    -
    +
    - + - + - + - + - + - - + +
    + @@ -423,12 +429,12 @@ support the 'maclist' option.
    - +

    -

    +

    @@ -440,32 +446,33 @@ support the 'maclist' option.
    - -

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

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

    + href="http://www.starlight.org">Starlight Children's +Foundation. Thanks!

    -
    - -

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

    + +

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

    +
    diff --git a/Shorewall-docs/standalone.htm b/Shorewall-docs/standalone.htm index da3d40560..1029c35e2 100644 --- a/Shorewall-docs/standalone.htm +++ b/Shorewall-docs/standalone.htm @@ -1,425 +1,425 @@ - + - + - + - + Standalone Firewall - + - - - + + - - - + + + +
    +

    Standalone Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up Shorewall on a standalone Linux system is very - easy if you understand the basics and follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in one of its most common configurations:

    - + +

    Setting up Shorewall on a standalone Linux system is very + easy if you understand the basics and follow the documentation.

    + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its most common configurations:

    +
      -
    • Linux system
      • -
    • Single external IP address
      • -
    • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
      • - +
    • Linux system
      • +
    • Single external IP address
      • +
    • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
      • +
    - -

    This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell -if this package is installed by the presence of an ip program on -your firewall system. As root, you can use the 'which' command to check -for this program:

    - + +

    Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can tell + if this package is installed by the presence of an ip program on + your firewall system. As root, you can use the 'which' command to check + for this program:

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you read through the guide first to familiarize yourself - with what's involved then go back through it again making your configuration - changes.  Points at which configuration changes are recommended are flagged - with - .

    +

    I recommend that you read through the guide first to familiarize yourself + with what's involved then go back through it again making your configuration + changes.  Points at which configuration changes are recommended are flagged + with + .

    +

    -     If you edit your configuration files on a Windows system, you must - save them as Unix files if your editor supports that option or you must - run them through dos2unix before trying to use them. Similarly, if you -copy a configuration file from your Windows hard drive to a floppy disk, -you must run dos2unix against the copy before using it with Shorewall.

    - +     If you edit your configuration files on a Windows system, you +must save them as Unix files if your editor supports that option or you +must run them through dos2unix before trying to use them. Similarly, if +you copy a configuration file from your Windows hard drive to a floppy +disk, you must run dos2unix against the copy before using it with Shorewall.

    + - +

    Shorewall Concepts

    - +

    -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you only need to deal with a few of - these as described in this guide. After you have installed Shorewall, download the one-interface sample, - un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall - (they will replace files with the same names that were placed in /etc/shorewall + href="/pub/shorewall/LATEST.samples/one-interface.tgz">one-interface sample, + un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall during Shorewall installation).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the one-interface sample configuration, only one - zone is defined:

    - + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration instructions + and default entries.

    + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the one-interface sample configuration, only +one zone is defined:

    + - + + + + + - - - - - - - - - + + + + +
    NameDescription
    NameDescription
    netThe Internet
    netThe Internet
    - +

    Shorewall zones are defined in /etc/shorewall/zones.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

    + - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file -matches the connection request then the first policy in /etc/shorewall/policy -that matches the request is applied. If that policy is REJECT or DROP  -the request is first checked against the rules in /etc/shorewall/common (the -samples provide that file for you).

    - -

    The /etc/shorewall/policy file included with the one-interface sample has -the following policies:

    - -
    + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that file + matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or DROP  + the request is first checked against the rules in /etc/shorewall/common +(the samples provide that file for you).

    + +

    The /etc/shorewall/policy file included with the one-interface sample +has the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
    fwnetACCEPT  
    netall
    -     		DROPinfo 
    allallREJECTinfo 
    fwnetACCEPT  
    netall
    +     		DROPinfo 
    allallREJECTinfo 
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from the firewall to the internet
      2. -
    2. drop (ignore) all connection requests from the internet to your - firewall
      3. -
    3. reject all other connection requests (Shorewall requires this -catchall policy).
      4. - +
    4. allow all connection requests from the firewall to the internet
      5. +
    5. drop (ignore) all connection requests from the internet to your + firewall
      6. +
    6. reject all other connection requests (Shorewall requires this + catchall policy).
      7. +
    - -

    At this point, edit your /etc/shorewall/policy and make any changes that - you wish.

    - + +

    At this point, edit your /etc/shorewall/policy and make any changes that + you wish.

    +

    External Interface

    - -

    The firewall has a single network interface. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter (eth0) that is connected to that "Modem"  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point Tunneling - Protocol (PPTP) in which case the External Interface will be - a ppp0. If you connect via a regular modem, your External Interface - will also be ppp0. If you connect using ISDN, your external interface - will be ippp0.

    - + +

    The firewall has a single network interface. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter (eth0) that is connected to that +"Modem"  unless you connect via Point-to-Point +Protocol over Ethernet (PPPoE) or Point-to-Point +Tunneling Protocol (PPTP) in which case the External +Interface will be a ppp0. If you connect via a regular modem, your +External Interface will also be ppp0. If you connect using ISDN, +your external interface will be ippp0.

    +

    -     The Shorewall one-interface sample configuration assumes that the - external interface is eth0. If your configuration is different, -you will have to modify the sample /etc/shorewall/interfaces file accordingly. - While you are there, you may wish to review the list of options that are - specified for the interface. Some hints:

    - +     The Shorewall one-interface sample configuration assumes that +the external interface is eth0. If your configuration is different, + you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that +are specified for the interface. Some hints:

    +
      -
    • -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

      -
      • -
    • -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the option - list.

      -
      • - +
    • +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

      +
      • +
    • +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the +option list.

      +
      • +
    - -
    + +

    IP Addresses

    -
    - -
    -

    RFC 1918 reserves several Private IP address ranges - for use in private networks:

    - -
    +
    + +
    +

    RFC 1918 reserves several Private IP address ranges + for use in private networks:

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -

    These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs - are assigning these addresses then using Network Address Translation - to rewrite packet headers when forwarding to/from the internet.

    - +
    + +

    These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, ISPs + are assigning these addresses then using Network Address Translation + to rewrite packet headers when forwarding to/from the internet.

    +

    -      Before starting Shorewall, you should look at the IP address -of your external interface and if it is one of the above ranges, you should - remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

    -
    - -
    -

    Enabling other Connections

    +      Before starting Shorewall, you should look at the IP address + of your external interface and if it is one of the above ranges, you +should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

    - -
    -

    If you wish to enable connections from the internet to your - firewall, the general format is:

    -
    - -
    -
    + +
    +

    Enabling other Connections

    +
    + +
    +

    If you wish to enable connections from the internet to your + firewall, the general format is:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfw<protocol><port>  
    -
    +
    +
    + +
    +

    Example - You want to run a Web Server and a POP3 Server +on your firewall system:

    - -
    -

    Example - You want to run a Web Server and a POP3 Server on -your firewall system:

    -
    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80  
    ACCEPTnetfwtcp110  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80  
    ACCEPTnetfwtcp110  
    -
    +
    +
    + +
    +

    If you don't know what port and protocol a particular +application uses, see here.

    - -
    -

    If you don't know what port and protocol a particular application -uses, see here.

    -
    - -
    -

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want - shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    +
    +
    + +

    -     At this point, edit /etc/shorewall/rules to add other connections - as desired.

    -
    - -
    -

    Starting and Stopping Your Firewall

    +     At this point, edit /etc/shorewall/rules to add other connections + as desired.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure configures - your system to start Shorewall at system boot but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file -/etc/shorewall/startup_disabled.
    -

    - -

    IMPORTANT: Users of the .deb - package must edit /etc/default/shorewall and set 'startup=1'.
    -

    -
    +     The installation procedure configures + your system to start Shorewall at system boot but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
    +

    -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, routing - is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have - added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall - try" command.

    -
    - -

    Last updated 1/26/2003 - IMPORTANT: Users of the .deb + package must edit /etc/default/shorewall and set 'startup=1'.
    +

    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, routing + is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

    +
    + +
    +

    WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have + added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

    +
    + +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep

    -
    +
    +



    diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm index 2d1310098..976cb8b33 100644 --- a/Shorewall-docs/three-interface.htm +++ b/Shorewall-docs/three-interface.htm @@ -1,1215 +1,1222 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
    - +
    +

    Three-Interface Firewall

    -
    - +

    Version 2.0.1

    - -

    Setting up a Linux system as a firewall for a small network - with DMZ is a fairly straight-forward task if you understand the basics - and follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in one of its more popular configurations:

    - + +

    Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the +basics and follow the documentation.

    + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in one of its more popular configurations:

    +
      -
    • Linux system used as a firewall/router for a small local +
    • Linux system used as a firewall/router for a small local network.
      • -
    • Single public IP address.
      • -
    • DMZ connected to a separate ethernet interface.
      • -
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, - dial-up, ...
      • - +
    • Single public IP address.
      • +
    • DMZ connected to a separate ethernet interface.
      • +
    • Connection through DSL, Cable Modem, ISDN, Frame Relay, + dial-up, ...
      • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - -

    This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can tell - if this package is installed by the presence of an ip program - on your firewall system. As root, you can use the 'which' command to -check for this program:

    - -
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are -flagged with - . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo)

    + +

    Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can +tell if this package is installed by the presence of an ip program + on your firewall system. As root, you can use the 'which' command to + check for this program:

    + +
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    +

    I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are + flagged with + . Configuration notes that are unique to LEAF/Bering are marked with (LEAF Logo) +

    +

    -     If you edit your configuration files on a Windows system, - you must save them as Unix files if your editor supports that option - or you must run them through dos2unix before trying to use them. Similarly, - if you copy a configuration file from your Windows hard drive to a floppy - disk, you must run dos2unix against the copy before using it with Shorewall.

    - +     If you edit your configuration files on a Windows system, + you must save them as Unix files if your editor supports that option + or you must run them through dos2unix before trying to use them. Similarly, + if you copy a configuration file from your Windows hard drive to a +floppy disk, you must run dos2unix against the copy before using it with +Shorewall.

    + - +

    Shorewall Concepts

    - +

    -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you will only need to deal with a -few of these as described in this guide. After you have installed Shorewall, download the three-interface - sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy - the files to /etc/shorewall (the files will replace files with the same - names that were placed in /etc/shorewall when Shorewall was installed).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the three-interface sample configuration, the - following zone names are used:

    - + href="/pub/shorewall/LATEST.samples/three-interfaces.tgz">three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy + the files to /etc/shorewall (the files will replace files with the +same names that were placed in /etc/shorewall when Shorewall was installed)    .

    + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration +instructions and default entries.

    + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, +the following zone names are used:

    + - + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    netThe Internet
    locYour Local Network
    dmzDemilitarized Zone
    - +

    Zone names are defined in /etc/shorewall/zones.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

    +
      -
    • You express your default policy for connections from +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies in the +
    • You define exceptions to those default policies in the /etc/shorewall/rules file.
      • - +
    - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that file - matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or DROP  - the request is first checked against the rules in /etc/shorewall/common - (the samples provide that file for you).

    - -

    The /etc/shorewall/policy file included with the three-interface sample - has the following policies:

    - -
    + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that +file matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or +DROP  the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

    + +

    The /etc/shorewall/policy file included with the three-interface sample + has the following policies:

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -
    -

    In the three-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

    - - - - - - - - - - - - - - - - - - - - -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    -
    - -

    The above policy will:

    - -
      -
    1. allow all connection requests from your local network -to the internet
      2. -
    2. drop (ignore) all connection requests from the internet - to your firewall or local network
      3. -
    3. optionally accept all connection requests from the firewall - to the internet (if you uncomment the additional policy)
      4. -
    4. reject all other connection requests.
      5. - -
    - -

    -     At this point, edit your /etc/shorewall/policy file and -make any changes that you wish.

    - -

    Network Interfaces

    - -

    -

    - -

    The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., - eth0)  unless you connect via Point-to-Point - Protocol over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect via - a regular modem, your External Interface will also be ppp0. If -you connect using ISDN, you external interface will be ippp0.

    - -

    -     If your external interface is ppp0 or ippp0 then - you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    - -

    Your Local Interface will be an ethernet adapter (eth0, - eth1 or eth2) and will be connected to a hub or switch. Your local -computers will be connected to the same switch (note: If you have only -a single local system, you can connect the firewall directly to the computer -using a cross-over cable).

    - -

    Your DMZ Interface will also be an ethernet adapter - (eth0, eth1 or eth2) and will be connected to a hub or switch. Your - DMZ computers will be connected to the same switch (note: If you have - only a single DMZ system, you can connect the firewall directly to the - computer using a cross-over cable).

    - -

    - Do not connect more than one interface to the same -hub or switch (even for testing). It won't work the way that you expect - it to and you will end up confused and believing that Shorewall doesn't - work at all.

    - -

    -     The Shorewall three-interface sample configuration assumes - that the external interface is eth0, the local interface is eth1 - and the DMZ interface is eth2. If your configuration is -different, you will have to modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the list - of options that are specified for the interfaces. Some hints:

    - -
      -
    • - -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

      -
      • -
    • - -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the - option list.

      -
      • - -
    - -

    IP Addresses

    - -

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you -a single Public IP address. This address may be assigned via the - Dynamic Host Configuration Protocol (DHCP) or as part of establishing - your connection when you dial in (standard modem) or establish your PPP - connection. In rare cases, your ISP may assign you a static IP -address; that means that you configure your firewall's external interface - to use that address permanently. Regardless of how the address is - assigned, it will be shared by all of your systems when you access the -Internet. You will have to assign your own addresses for your internal network -(the local and DMZ Interfaces on your firewall plus your other computers). -RFC 1918 reserves several Private IP address ranges for this purpose:

    - -
    -
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -
    -

    -     Before starting Shorewall, you should look at the IP -address of your external interface and if it is one of the above -ranges, you should remove the 'norfc1918' option from the external -interface's entry in /etc/shorewall/interfaces.

    -
    - -
    -

    You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another - subnet. For our purposes, we can consider a subnet to consists of -a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a -Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved -as the Subnet Address and x.y.z.255 is reserved as the Subnet -Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive "1" bits from - the left of the subnet mask.

    -
    - -
    -

    Example sub-network:

    -
    - -
    -
    - - - - - - + - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + - - -
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    -
    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above example) - or the last usable address (10.10.10.254).

    -
    - -
    -

    One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

    -
    - -
    -

    -     Your local computers (Local Computers 1 & 2) should - be configured with their default gateway set to the IP address - of the firewall's internal interface and your DMZ computers ( DMZ -Computers 1 & 2) should be configured with their default gateway -set to the IP address of the firewall's DMZ interface.  

    -
    - -

    The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning - more about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    The remainder of this quide will assume that you have configured - your network as shown here:

    - -

    -

    - -

    The default gateway for the DMZ computers would be 10.10.11.254 - and the default gateway for the Local computers would be 10.10.10.254.
    -

    - -

    -     WARNING: Your ISP  might assign -your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 -subnet then you will need to select a DIFFERENT RFC 1918 subnet for your -local network and if it is in the 10.10.11.0/24 subnet then you will need -to select a different RFC 1918 subnet for your DMZ.
    -

    - -

    IP Masquerading (SNAT)

    - -

    The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one - of your local systems (let's assume local computer 1) sends a connection - request to an internet host, the firewall must perform Network Address - Translation (NAT). The firewall rewrites the source address in the - packet to be the address of the firewall's external interface; in other - words, the firewall makes it look as if the firewall itself is initiating - the connection.  This is necessary so that the destination host will be - able to route return packets back to the firewall (remember that packets - whose destination address is reserved by RFC 1918 can't be routed accross - the internet). When the firewall receives a return packet, it rewrites - the destination address back to 10.10.10.1 and forwards the packet on - to local computer 1.

    - -

    On Linux systems, the above process is often referred to as - IP Masquerading and you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

    - -
      -
    • - -

      Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
      • -
    • -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

      -
      • - -
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

    - -

    -     If your external firewall interface is eth0, your -local interface eth1 and your DMZ interface is eth2 then -you do not need to modify the file provided with the sample. Otherwise, -edit /etc/shorewall/masq and change it to match your configuration.

    - -

    -     If your external IP is static, you can enter it in the -third column in the /etc/shorewall/masq entry if you like although -your firewall will work fine if you leave that column empty. Entering -your static IP in column 3 makes
    - processing outgoing packets a little more efficient.
    -

    - -

    -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
    -

    - -
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • - -
    - -

    Port Forwarding (DNAT)

    - -

    One of your goals will be to run one or more servers on your - DMZ computers. Because these computers have RFC-1918 addresses, it is - not possible for clients on the internet to connect directly to them. - It is rather necessary for those clients to address their connection -requests to your firewall who rewrites the destination address to the -address of your server and forwards the packet to that server. When your -server responds, the firewall automatically performs SNAT to rewrite -the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure -port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>  
    -
    - -

    If you don't specify the <server port>, it is assumed to be -the same as <port>.

    - -

    Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    -
    - -

    A couple of important points to keep in mind:

    - -
      -
    • When you are connecting to your server from your local - systems, you must use the server's internal IP address (10.10.11.2).
      • -
    • Many ISPs block incoming connection requests to port -80. If you have problems connecting to your web server, try the -following rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your - external IP).
      • - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    -
    - -

    If you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can - replace the loc->dmz rule above with:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    - -

    If you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows -(assume that your external interface is eth0):

    - -
      -
    1. Include the following in /etc/shorewall/params:
      -
      - ETH0_IP=`find_interface_address eth0`
      -  
      2. -
    2. Make your loc->dmz rule:
      3. - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    - -

    If you want to access your server from the DMZ using your external IP -address, see FAQ 2a.

    - -

    -     At this point, add the DNAT and ACCEPT rules for your servers. -

    - -

    Domain Name Server (DNS)

    - -

    Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver - will be automatically configured (e.g., the /etc/resolv.conf file will - be written). Alternatively, your ISP may have given you the IP address - of a pair of DNS name servers for you to manually configure as -your primary and secondary name servers. It is your responsibility - to configure the resolver in your internal systems. You can take one -of two approaches:

    - -
      -
    • - -

      You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers -or if those addresses are available on their web site, you can configure - your internal systems to use those addresses. If that information -isn't available, look in /etc/resolv.conf on your firewall system -- -the name servers are given in "nameserver" records in that file.

      -
      • -
    • - -

      -     You can configure a Caching Name Server on your - firewall or in your DMZ. Red Hat has an RPM for a caching name - server (which also requires the 'bind' RPM) and for Bering users, - there is dnscache.lrp. If you take this approach, you configure your - internal systems to use the caching name server as their primary (and - only) name server. You use the internal IP address of the firewall -(10.10.10.254 in the example above) for the name server address if -you choose to run the name server on your firewall. To allow your local -systems to talk to your caching name server, you must open port 53 -(both UDP and TCP) from the local network to the server; you do that -by adding the rules in /etc/shorewall/rules.

      -
      • - -
    - -
    -

    If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    -

    -
    - -
    -
    -

    Run name server on DMZ computer 1

    +
    + +
    +

    In the three-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

    - + id="AutoNumber3"> + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + - - + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    fwnetACCEPT  
    -
    -
    +
    + +

    The above policy will:

    + +
      +
    1. allow all connection requests from your local network + to the internet
      2. +
    2. drop (ignore) all connection requests from the internet + to your firewall or local network
      3. +
    3. optionally accept all connection requests from the firewall + to the internet (if you uncomment the additional policy)
      4. +
    4. reject all other connection requests.
      5. + +
    + +

    +     At this point, edit your /etc/shorewall/policy file and + make any changes that you wish.

    + +

    Network Interfaces

    + +

    +

    + +

    The firewall has three network interfaces. Where Internet + connectivity is through a cable or DSL "Modem", the External Interface + will be the ethernet adapter that is connected to that "Modem" (e.g., + eth0)  unless you connect via Point-to-Point + Protocol over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect +via a regular modem, your External Interface will also be ppp0. +If you connect using ISDN, you external interface will be ippp0.

    + +

    +     If your external interface is ppp0 or ippp0 +then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    + +

    Your Local Interface will be an ethernet adapter (eth0, + eth1 or eth2) and will be connected to a hub or switch. Your local + computers will be connected to the same switch (note: If you have +only a single local system, you can connect the firewall directly to +the computer using a cross-over cable).

    + +

    Your DMZ Interface will also be an ethernet adapter + (eth0, eth1 or eth2) and will be connected to a hub or switch. Your + DMZ computers will be connected to the same switch (note: If you have + only a single DMZ system, you can connect the firewall directly to the + computer using a cross-over cable).

    + +

    + Do not connect more than one interface to the same +hub or switch (even for testing). It won't work the way that you expect + it to and you will end up confused and believing that Shorewall doesn't + work at all.

    + +

    +     The Shorewall three-interface sample configuration assumes + that the external interface is eth0, the local interface is +eth1 and the DMZ interface is eth2. If your configuration +is different, you will have to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list + of options that are specified for the interfaces. Some hints:

    + +
      +
    • + +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

      +
      • +
    • + +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from +the option list.

      +
      • -
      +
    + +

    IP Addresses

    + +

    Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via +the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. Regardless of how the address +is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses for your internal +network (the local and DMZ Interfaces on your firewall plus your other +computers). RFC 1918 reserves several Private IP address ranges for +this purpose:

    + +
    +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    +
    + +
    +

    +     Before starting Shorewall, you should look at the IP +address of your external interface and if it is one of the above +ranges, you should remove the 'norfc1918' option from the external +interface's entry in /etc/shorewall/interfaces.

    +
    + +
    +

    You will want to assign your local addresses from one + sub-network or subnet and your DMZ addresses from another + subnet. For our purposes, we can consider a subnet to consists of +a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a +Subnet Mask of 255.255.255.0. The address x.y.z.0 is reserved as + the Subnet Address and x.y.z.255 is reserved as the Subnet +Broadcast Address. In Shorewall, a subnet is described using Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive "1" bits from + the left of the subnet mask.

    +
    + +
    +

    Example sub-network:

    +
    + +
    +
    + + + + + + + + + + + + + + + + + + + + + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    +
    +
    + +
    +

    It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above +example) or the last usable address (10.10.10.254).

    +
    + +
    +

    One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

    +
    + +
    +

    +     Your local computers (Local Computers 1 & 2) should + be configured with their default gateway set to the IP address + of the firewall's internal interface and your DMZ computers ( DMZ + Computers 1 & 2) should be configured with their default gateway + set to the IP address of the firewall's DMZ interface.  

    +
    + +

    The foregoing short discussion barely scratches the surface + regarding subnetting and routing. If you are interested in learning + more about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", +Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    The remainder of this quide will assume that you have configured + your network as shown here:

    + +

    +

    + +

    The default gateway for the DMZ computers would be 10.10.11.254 + and the default gateway for the Local computers would be 10.10.10.254.
    +

    + +

    +     WARNING: Your ISP  might assign + your external interface an RFC 1918 address. If that address is in the +10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918 +subnet for your local network and if it is in the 10.10.11.0/24 subnet then +you will need to select a different RFC 1918 subnet for your DMZ.
    +

    + +

    IP Masquerading (SNAT)

    + +

    The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When one + of your local systems (let's assume local computer 1) sends a connection + request to an internet host, the firewall must perform Network Address + Translation (NAT). The firewall rewrites the source address in +the packet to be the address of the firewall's external interface; in +other words, the firewall makes it look as if the firewall itself is +initiating the connection.  This is necessary so that the destination +host will be able to route return packets back to the firewall (remember +that packets whose destination address is reserved by RFC 1918 can't + be routed accross the internet). When the firewall receives a return +packet, it rewrites the destination address back to 10.10.10.1 and +forwards the packet on to local computer 1.

    + +

    On Linux systems, the above process is often referred to +as IP Masquerading and you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

    + +
      +
    • + +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

      +
      • +
    • + +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

      +
      • + +
    + +

    In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

    + +

    +     If your external firewall interface is eth0, your + local interface eth1 and your DMZ interface is eth2 +then you do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change it to match your configuration.

    + +

    +     If your external IP is static, you can enter it in the +third column in the /etc/shorewall/masq entry if you like although +your firewall will work fine if you leave that column empty. Entering +your static IP in column 3 makes
    + processing outgoing packets a little more efficient.
    +

    + +

    +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
    +

    + +
      +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • + +
    + +

    Port Forwarding (DNAT)

    + +

    One of your goals will be to run one or more servers on your + DMZ computers. Because these computers have RFC-1918 addresses, it +is not possible for clients on the internet to connect directly to +them. It is rather necessary for those clients to address their connection + requests to your firewall who rewrites the destination address to the + address of your server and forwards the packet to that server. When your + server responds, the firewall automatically performs SNAT to rewrite + the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

    + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server + port>]<protocol><port>  
    +
    + +

    If you don't specify the <server port>, it is assumed to +be the same as <port>.

    + +

    Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
    ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
    +
    + +

    A couple of important points to keep in mind:

    + +
      +
    • When you are connecting to your server from your local + systems, you must use the server's internal IP address (10.10.11.2).
      • +
    • Many ISPs block incoming connection requests to port +80. If you have problems connecting to your web server, try the following + rule and try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
      • + +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000  
    +
    + +

    If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you +can replace the loc->dmz rule above with:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    +
    + +

    If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows + (assume that your external interface is eth0):

    + +
      +
    1. Include the following in /etc/shorewall/params:
      +
      + ETH0_IP=`find_interface_address eth0`
      +  
      2. +
    2. Make your loc->dmz rule:
      3. + +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    +     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    +
    + +

    If you want to access your server from the DMZ using your external IP + address, see FAQ 2a.

    + +

    +     At this point, add the DNAT and ACCEPT rules for your +servers.

    + +

    Domain Name Server (DNS)

    + +

    Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver + will be automatically configured (e.g., the /etc/resolv.conf file +will be written). Alternatively, your ISP may have given you the IP +address of a pair of DNS name servers for you to manually configure +as your primary and secondary name servers. It is your responsibility + to configure the resolver in your internal systems. You can take one + of two approaches:

    + +
      +
    • + +

      You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system +-- the name servers are given in "nameserver" records in that file. +

      +
      • +
    • + +

      +     You can configure a Caching Name Server on your + firewall or in your DMZ. Red Hat has an RPM for a caching +name server (which also requires the 'bind' RPM) and for Bering +users, there is dnscache.lrp. If you take this approach, you configure +your internal systems to use the caching name server as their primary +(and only) name server. You use the internal IP address of the firewall +(10.10.10.254 in the example above) for the name server address if +you choose to run the name server on your firewall. To allow your local +systems to talk to your caching name server, you must open port 53 +(both UDP and TCP) from the local network to the server; you do that +by adding the rules in /etc/shorewall/rules.

      +
      • + +
    + +
    +

    If you run the name server on the firewall: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTdmzfwtcp53  
    ACCEPTdmzfwudp53  
    +

    +
    + +
    +
    +

    Run name server on DMZ computer 1

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53  
    ACCEPTlocdmz:10.10.11.1udp53  
    ACCEPTfwdmz:10.10.10.1tcp53  
    ACCEPTfwdmz:10.10.10.1udp53  
    +
    +
    + +

    Other Connections

    -
    - -
    +
    + +

    The three-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53  
    ACCEPTfwnettcp53  
    -
    + +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy +allowing all connections from the firewall to the internet.

    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

    -
    - -
    + +

    The sample also includes:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACCEPTlocdmztcp22  
    -
    + +
    + +
    +

    That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers + from your local systems.

    - -
    -

    That rule allows you to run an SSH server on your firewall - and in each of your DMZ systems and to connect to those servers - from your local systems.

    -
    - -
    -

    If you wish to enable other connections between your systems, - the general format is:

    -
    - -
    -
    + +
    +

    If you wish to enable other connections between your systems, + the general format is:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    +
    +
    + +
    +

    Example - You want to run a publicly-available DNS server + on your firewall system:

    - -
    -

    Example - You want to run a publicly-available DNS server - on your firewall system:

    -
    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
    -
    +
    +
    + +
    +

    Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

    - -
    -

    Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

    -
    - -
    -

    If you don't know what port and protocol a particular application -uses, look here.

    -
    - -
    -

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you - want shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    + +
    +

    If you don't know what port and protocol a particular +application uses, look here.

    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you + want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    +
    +
    + +

    +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     Bering users will want to add the following two rules to be compatible with Jacques's Shorewall configuration.
    -

    -
    -
    +

    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    -     		fwudp
    -     		53
    -     		#Allow DNS Cache towork
    -
    ACCEPTlocfwtcp80#Allow weblet to work
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    +     		fwudp
    +     		53
    +     		#Allow DNS Cache towork
    +
    ACCEPTlocfwtcp80#Allow weblet to work
    +
    -
    -
    +
    +
    +

    -     Now modify /etc/shorewall/rules to add or remove other +     Now modify /etc/shorewall/rules to add or remove other connections as required.

    -
    - -
    -

    Starting and Stopping Your Firewall

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure configures - your system to start Shorewall at system boot  but beginning with Shorewall - version 1.3.9 startup is disabled so that your system won't try to start - Shorewall before configuration is complete. Once you have completed configuration - of your firewall, you can enable Shorewall startup by removing the file +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall + version 1.3.9 startup is disabled so that your system won't try to start + Shorewall before configuration is complete. Once you have completed configuration + of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
    -

    - +

    +

    IMPORTANT: Users of the .deb package must edit /etc/default/shorewall + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
    -

    +

    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" +command. If you want to totally remove any trace of Shorewall from +your Netfilter configuration, use "shorewall clear".

    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

    -
    - -
    + +

    -     The three-interface sample assumes that you want to enable - routing to/from eth1 (your local network) and eth2 (DMZ) - when Shorewall is stopped. If these two interfaces don't connect -to your local network and DMZ or if you want to enable a different +     The three-interface sample assumes that you want to enable + routing to/from eth1 (your local network) and eth2 (DMZ) + when Shorewall is stopped. If these two interfaces don't connect +to your local network and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped accordingly.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you -have added an entry for the IP address that you are connected from -to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the + +

    - -

    Last updated 1/30/2003 - + +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep

    -
    +
    +



    diff --git a/Shorewall-docs/three-interface_fr.html b/Shorewall-docs/three-interface_fr.html index 1b35fce45..7fed307fa 100755 --- a/Shorewall-docs/three-interface_fr.html +++ b/Shorewall-docs/three-interface_fr.html @@ -1,1073 +1,1208 @@ + + + + Three-Interface Firewall - + + - - - + + - - + + + +
    +

    Three-Interface Firewall

    -
    +

    Version 2.0.1 Française

    +

    Notes du traducteur :
    -Je ne prétends pas être un vrai traducteur dans le sens ou mon travail -n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à -une traduction exacte du texte, mais plutôt à en faire une version -française intelligible par tous (et par moi). Les termes techniques sont -la plupart du temps conservés sous leur forme originale et mis entre -parenthèses car vous pouvez les retrouver dans le reste des -documentations ainsi que dans les fichiers de configuration. N?hésitez -pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM -pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP -pour son formidable outil et sa disponibilité).

    + Je ne prétends pas être un vrai traducteur dans le sens ou mon travail n?est +pas des plus précis (loin de là...). Je ne me suis pas attaché à une traduction +exacte du texte, mais plutôt à en faire une version française intelligible +par tous (et par moi). Les termes techniques sont la plupart du temps conservés +sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver +dans le reste des documentations ainsi que dans les fichiers de configuration. +N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM pour +sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour son +formidable outil et sa disponibilité).

    +


    -Mettre en place un système linux en tant que firewall pour un petit -réseau contenant une DMZ est une chose assez simple à réaliser si vous -comprenez les bases et suivez cette documentation.

    -

    Ce guide ne prétend pas vous mettre au courant de toutes les -possibilités de Shorewall. Il se focalise sur les besoins pour -configurer Shorewall dans une de ses utilisations les plus populaire :

    + Mettre en place un système linux en tant que firewall pour un petit réseau +contenant une DMZ est une chose assez simple à réaliser si vous comprenez +les bases et suivez cette documentation.

    + +

    Ce guide ne prétend pas vous mettre au courant de toutes les possibilités +de Shorewall. Il se focalise sur les besoins pour configurer Shorewall dans +une de ses utilisations les plus populaire :

    +
      -
    • Un système Linux utilisé en tant que firewall/routeur pour un -petit réseau local.
      • -
    • Une seule adresse IP publique.
      • -
    • Une DMZ connectée sur une interface Ethernet séparée.
      • -
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame -Relay, RTC, ...
      • +
    • Un système Linux utilisé en tant que firewall/routeur pour un petit +réseau local.
      • +
    • Une seule adresse IP publique.
      • +
    • Une DMZ connectée sur une interface Ethernet séparée.
      • +
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame Relay, +RTC, ...
      • +
    +

    Voici le schéma d'une installation typique.

    +

    -

    Ce guide suppose que vous avez le paquet iproute/iproute2 -d'installé. Vous pouvez voir si le paquet est installé en vérifiant la -présence du programme ip sur votre système de firewall. Sous root, -utilisez la commande 'which' pour rechercher le programme :

    + height="635"> +

    + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du programme +ip sur votre système de firewall. Sous root, utilisez la commande 'which' +pour rechercher le programme :

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    -

    Je vous recommande dans un premier temps de parcourir tout le guide -pour vous familiariser avec ce qu'il va se passer, et de revenir au -début en effectuant le changements dans votre configuration. Les points -où, les changements dans la configuration sont recommandées, sont -signalés par une

    -

    Si -vous éditez vos fichiers de configuration sur un système Windows, vous -devez les sauver comme des fichiers Unix si votre éditeur offre cette -option sinon vous devez les faire passer par dos2unix avant d'essayer de -les utiliser. De la même manière, si vous copiez un fichier de -configuration depuis votre disque dur Windows vers une disquette, vous -devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall.

    + +

    Je vous recommande dans un premier temps de parcourir tout le guide pour +vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant +le changements dans votre configuration. Les points où, les changements dans +la configuration sont recommandées, sont signalés par une +

    + +

    + Si vous éditez vos fichiers de configuration sur un système Windows, vous +devez les sauver comme des fichiers Unix si votre éditeur offre cette option +sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser. +De la même manière, si vous copiez un fichier de configuration depuis votre +disque dur Windows vers une disquette, vous devez lancer dos2unix sur la +copie avant de l'utiliser avec Shorewall.

    + +

    Les Concepts de Shorewall

    +

    Les fichiers de configuration pour Shorewall sont situés dans -le répertoire /etc/shorewall -- pour de simples paramétrages, vous -n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce -guide. Après avoir installé Shorewall, téléchargez -la configuration d'exemple three-interface -sample, un-tarez la (tar -zxvf three-interfaces.tgz) et -copiez les fichiers vers /etc/shorewall (Ils remplaceront les fichiers -de même nom déjà existant dans /etc/shorewall installés lors de -l'installation de Shorewall).

    -

    En même temps que chacun des fichiers est présenté, je vous suggère -de jeter un oeil à ceux qui se trouvent réellement sur votre système -- -chacun des fichiers contient des instructions de configuration -détaillées et des entrées par défaut.

    -

    Shorewall voit le réseau où il tourne comme composé par un ensemble -de zones. Dans les fichiers de configuration fournis pour trois -interfaces, trois zones sont définies :

    + alt=""> + Les fichiers de configuration pour Shorewall sont situés dans le répertoire + /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec +quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration +d'exemple three-interface +sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez +les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même +nom déjà existant dans /etc/shorewall installés lors de l'installation de +Shorewall).

    + +

    En même temps que chacun des fichiers est présenté, je vous suggère de +jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun +des fichiers contient des instructions de configuration détaillées et des +entrées par défaut.

    + +

    Shorewall voit le réseau où il tourne comme composé par un ensemble de +zones. Dans les fichiers de configuration fournis pour trois interfaces, +trois zones sont définies :

    + - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    +

    Les noms de zone sont définis dans /etc/shorewall/zones.

    -

    Shorewall reconnaît aussi le système de firewall comme sa propre -zone - par défaut, le firewall lui même est connu en tant que fw.

    -

    Les règles concernant le trafic à autoriser ou à interdire sont -exprimées en utilisant les termes de zones.

    + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone +- par défaut, le firewall lui même est connu en tant que fw.

    + +

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées +en utilisant les termes de zones.

    +
      -
    • Vous exprimez les politiques par défaut pour les connexions d'une -zone à une autre dans le fichier -/etc/shorewall/policy .
      • -
    • Vous définissez les exceptions à ces règles de politiques par -défaut dans le fichier /etc/shorewall/rules.
      • +
    • Vous exprimez les politiques par défaut pour les connexions d'une zone +à une autre dans le fichier /etc/shorewall/policy + .
      • +
    • Vous définissez les exceptions à ces règles de politiques par défaut +dans le fichier /etc/shorewall/rules.
      • +
    -

    Pour chacune des demandes de connexion entrantes dans le firewall, -les demandes sont en premier lieu comparées par rapport au fichier -/etc/shorewall/rules. Si aucune des règles dans ce fichier ne -correspondent, alors la première politique dans /etc/shorewall/policy -qui y correspond est appliquée. Si cette politique est REJECT ou DROP la -requête est alors comparée par rapport aux règles contenues dans -/etc/shorewall/common (l'archive d'exemple vous fournit ce fichier).

    -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive -three-interface sample a les politiques suivantes :

    -
    + +

    Pour chacune des demandes de connexion entrantes dans le firewall, les +demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. +Si aucune des règles dans ce fichier ne correspondent, alors la première +politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette +politique est REJECT ou DROP la requête est alors comparée par rapport aux +règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit +ce fichier).

    + +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface +sample a les politiques suivantes :

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT
    -
    -
    netallDROPinfo
    -
    allallREJECTinfo
    -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT
    +
    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    -
    -

    Dans l'archive three-interface, la ligne suivante est existante -mais elle est commentée. Si vous souhaitez que votre système de firewall -puisse avoir un accès complet aux serveurs sur Internet, décommentez la.

    +
    + +
    +

    Dans l'archive three-interface, la ligne suivante est existante mais +elle est commentée. Si vous souhaitez que votre système de firewall puisse +avoir un accès complet aux serveurs sur Internet, décommentez la.

    + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    -
    -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    +
    +
    -
    +
    +

    Les politiques précédentes vont :

    +
      -
    1. permettre toutes demandes de connexion depuis le firewall vers -l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet -vers votre firewall ou vers votre réseau local
      3. -
    3. Facultativement accepter toutes les demandes de connexion depuis -votre firewall et vers Internet (si vous decommentez la politique -précédente)
      4. -
    4. reject (rejeter) toutes les autres demandes de connexion.
      5. +
    5. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      6. +
    6. drop (ignorer) toutes les demandes de connexion depuis l'Internet vers +votre firewall ou vers votre réseau local
      7. +
    7. Facultativement accepter toutes les demandes de connexion depuis votre +firewall et vers Internet (si vous decommentez la politique précédente)
      8. +
    8. reject (rejeter) toutes les autres demandes de connexion.
      9. +
    -

    A -ce point, éditez votre /etc/shorewall/policy et faites y les changements + +

    +A ce point, éditez votre /etc/shorewall/policy et faites y les changements que vous désire

    +

    Les Interfaces Réseau

    +

    -

    Le firewall a trois interfaces de réseau. Lorsque la -connexion Internet passe par le câble ou par un ROUTEUR (pas un simple -modem) ADSL (non USB), l'interface vers l'extérieur (External Interface) -sera l'adaptateur sur lequel est connecté le routeur (e.g., eth0) à -moins que vous ne vous connectiez par Point-to-PointProtocol -overEthernet (PPPoE) ou par Point-to-PointTunneling Protocol (PPTP), -dans ce cas l'interface extérieure sera une interface de type ppp (e.g., -ppp0). Si vous vous connectez par un simple modem (RTC), votre interface -extérieure sera aussi ppp0. Si votre connexion passe par Numéris -(ISDN), votre interface extérieure sera ippp0.

    + height="635"> +

    + +

    Le firewall a trois interfaces de réseau. Lorsque la connexion +Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL +(non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur +sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous +connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling +Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de +type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), +votre interface extérieure sera aussi ppp0. Si votre connexion passe par +Numéris (ISDN), votre interface extérieure sera ippp0.

    +

    Si votre interface vers l'extérieur est ppp0 ou ippp0 -alors vous mettrez CLAMPMSS=yes dans -/etc/shorewall/shorewall.conf.

    -

    Votre Interface locale sera un adaptateur -Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un -switch. Vos ordinateurs locaux seront connectés à ce même switch (note : -si vous n'avez qu'un seul ordinateur en local, vous pouvez le connecter -directement au firewall par un câble croisé).

    -

    Votre interface DMZ sera aussi un adaptateur -Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. -Vos ordinateurs appartenant à la DMZ seront connectés à ce même switch -(note : si vous n'avez qu'un seul ordinateur dans la DMZ, vous pouvez -le connecter directement au firewall par un câble croisé).

    + height="13"> + Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez +CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    + +

    Votre Interface locale sera un adaptateur Ethernet +(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs +locaux seront connectés à ce même switch (note : si vous n'avez qu'un seul +ordinateur en local, vous pouvez le connecter directement au firewall par +un câble croisé).

    + +

    Votre interface DMZ sera aussi un adaptateur Ethernet +(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs +appartenant à la DMZ seront connectés à ce même switch (note : si vous n'avez +qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au +firewall par un câble croisé).

    +

    Ne connectez pas l'interface interne et -externe sur le même hub ou switch (même pour tester). Cela ne -fonctionnera pas et ne croyez pas que ce soit shorewall qui ne marche -pas.

    + width="60" height="60"> + Ne connectez pas l'interface interne et externe sur le même hub +ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que +ce soit shorewall qui ne marche pas.

    +

    L'exemple de configuration de Shorewall pour trois -interfaces suppose que l'interface externe est eth0, l'interface -locale est eth1 et que la DMZ est sur l'interface eth2. -Si votre configuration diffère, vous devrez modifier le fichier -d'exemple /etc/shorewall/interfaces en conséquence. Tant que vous y -êtes, vous pourriez parcourir la liste des options qui sont spécifiées -pour les interfaces. Quelques trucs :

    + height="13"> + L'exemple de configuration de Shorewall pour trois interfaces suppose que +l'interface externe est eth0, l'interface locale est eth1 +et que la DMZ est sur l'interface eth2. Si votre configuration diffère, +vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. +Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont +spécifiées pour les interfaces. Quelques trucs :

    +
      -
    • -

      Si votre interface externe est ppp0 ou ippp0, vous -pouvez remplacer le "detect" dans la seconde colonne par un "-".

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 ou -bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" -de la liste d'option.

      -
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0, vous pouvez +remplacer le "detect" dans la seconde colonne par un "-".

      +
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 ou bien +si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la +liste d'option.

      +
      • +
    +

    Adresses IP

    -

    Avant d'aller plus loin, nous devons dire quelques mots -au sujet du Protocole d'adresse Internet (IP). Normalement, votre -fournisseur Internet (ISP) vous assignera une seule adresse IP (single -Public IP address). Cette adresse peut être assignée par le Dynamic Host -Configuration Protocol (DHCP) ou lors de l'établissement de votre -connexion lorsque vous vous connectez (modem standard) ou établissez -votre connexion PPP. Dans de rares cas , votre provider peu vous -assigner une adresse statique (staticIP address); cela signifie que vous -configurez votre interface externe sur votre firewall afin d'utiliser -cette adresse de manière permanente. Une fois votre adresse externe -assignée, elle va être partagée par tout vos systèmes lors de l'accès à -Internet. Vous devrez assigner vos propres adresses à votre réseau -local (votre interface interne sur le firewall ainsi que les autres -ordinateurs). La RFC 1918 réserve plusieurs plages d'IP (Private IP -address ranges) à cette fin :

    -
    + +

    Avant d'aller plus loin, nous devons dire quelques mots au +sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur +Internet (ISP) vous assignera une seule adresse IP (single Public IP address). +Cette adresse peut être assignée par le Dynamic Host Configuration Protocol +(DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez +(modem standard) ou établissez votre connexion PPP. Dans de rares cas , votre +provider peu vous assigner une adresse statique (staticIP address); cela +signifie que vous configurez votre interface externe sur votre firewall afin +d'utiliser cette adresse de manière permanente. Une fois votre adresse externe +assignée, elle va être partagée par tout vos systèmes lors de l'accès à Internet. +Vous devrez assigner vos propres adresses à votre réseau local (votre interface +interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918 réserve +plusieurs plages d'IP (Private IP address ranges) à cette fin :

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    -
    +
    + +

    Avant de lancer Shorewall, vous devriez regarder l'adresse -de votre interface externe et si elle est comprise dans une des plages -précédentes, vous devriez enlever l'option 'norfc1918' dans le fichier -/etc/shorewall/interfaces.

    -
    -
    -

    Vous devrez assigner les adresses locales à un -sous-réseau (sub-network ou subnet) et les adresse pour -la DMZ à un autre sous-réseau. Pour ce faire, nous pouvons considérer -qu'un sous-réseau consiste en une plage d'adresse x.y.z.0 à x.y.z.255. -Chacun des sous-réseaux possèdera une masque (Subnet Mask) de -255.255.255.0. L'adresse x.y.z.0 est réservée comme l'adresse du -sous-réseau (Subnet Address) et x.y.z.255 est réservée en -tant qu'adresse de broadcast du sous-réseau (Subnet Broadcast Address). -Sous Shorewall, un sous-réseau est décrit/désigné en utilisant la -notation Classless -InterDomain Routing(CIDR) qui consiste en l'adresse du -sous-réseau suivie par "/24". Le "24" se réfère au nombre de bits "1" -consécutifs dans la partie gauche du masque de sous-réseau.

    -
    -
    + height="13"> + Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface +externe et si elle est comprise dans une des plages précédentes, vous devriez +enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    +
    + +
    +

    Vous devrez assigner les adresses locales à un sous-réseau +(sub-network ou subnet) et les adresse pour la DMZ à un autre +sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste +en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera +une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 est +réservée comme l'adresse du sous-réseau (Subnet Address) et x.y.z.255 + est réservée en tant qu'adresse de broadcast du sous-réseau (Subnet Broadcast +Address). Sous Shorewall, un sous-réseau est décrit/désigné en utilisant +la notation Classless InterDomain +Routing(CIDR) qui consiste en l'adresse du sous-réseau suivie par +"/24". Le "24" se réfère au nombre de bits "1" consécutifs dans la partie +gauche du masque de sous-réseau.

    +
    + +

    Exemple de sous-réseau (subnet) :

    -
    -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    Plage:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Plage:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    -
    -

    Il est de convention d'assigner à l'interface interne -la première adresse utilisable dans le sous-réseau (10.10.10.1 dans -l'exemple précédent) ou la dernière utilisable (10.10.10.254).

    -
    -
    -

    L'un des buts d'un sous-réseau est de permettre à tous -les ordinateurs dans le sous-réseau de savoir avec quels autres -ordinateurs ils peuvent communiquer directement. Pour communiquer avec -des systèmes en dehors du sous-réseau, les ordinateurs envoient des -paquets à travers le gateway (routeur).

    -
    -
    + +
    + +
    +

    Il est de convention d'assigner à l'interface interne la +première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple +précédent) ou la dernière utilisable (10.10.10.254).

    +
    + +
    +

    L'un des buts d'un sous-réseau est de permettre à tous les +ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils +peuvent communiquer directement. Pour communiquer avec des systèmes en dehors +du sous-réseau, les ordinateurs envoient des paquets à travers le gateway +(routeur).

    +
    + +

    Vos ordinateurs locaux (ordinateur local 1 et 2) devraient -être configurés avec leur passerelle par défaut (default gateway)pointant -sur l'adresse IP de l'interface interne du firewall, et les ordinateurs -de la DMZ devraient être configurés avec leur passerelle par défaut (default -gateway) pointant sur l'adresse IP de l'interface DMZ du firewall.

    -
    -

    Cette courte description ne fait que survoler les -concepts de routage et de sous-réseau. Si vous vous voulez en apprendre -plus sur l'adressage IP et le routage, je vous recommande chaudement "IP -Fundamentals: What Everyone Needs to Know about Addressing & -Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN -0-13-975483-0.

    -

    Pour rappel, ce guide supposera que vous avez configuré -votre réseau comme montrer ci-dessous :

    + height="13"> + Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés +avec leur passerelle par défaut (default gateway)pointant sur l'adresse +IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient +être configurés avec leur passerelle par défaut (default gateway) +pointant sur l'adresse IP de l'interface DMZ du firewall.

    +
    + +

    Cette courte description ne fait que survoler les concepts +de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur l'adressage +IP et le routage, je vous recommande chaudement "IP Fundamentals: What +Everyone Needs to Know about Addressing & Routing", Thomas A. +Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    Pour rappel, ce guide supposera que vous avez configuré votre +réseau comme montrer ci-dessous :

    +

    -

    La passerelle par défaut (default gateway) pour les -ordinateurs de la DMZ sera 10.10.11.254 et le passerelle par -défaut pour les ordinateurs en local sera 10.10.10.254.

    + height="635"> +

    + +

    La passerelle par défaut (default gateway) pour les ordinateurs +de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les ordinateurs +en local sera 10.10.10.254.

    +

    IP Masquerading (SNAT)

    -

    Les adresses réservées par la RFC 1918 sont parfois -désignées comme non-routables car les routeurs Internet (backbone) ne -font pas circuler les paquets qui ont une adresse de destination -appartenant à la RFC-1918. Lorsqu'un de vos systèmes en local (supposons -l'ordinateur1) demande une connexion à un serveur par Internet, le -firewall doit appliquer un NAT (Network Address Translation). Le -firewall ré écrit l'adresse source dans le paquet, et l'a remplace par -l'adresse de l'interface externe du firewall; en d'autres mots, le -firewall fait croire que c'est lui même qui initie la connexion. Ceci -est nécessaire afin que l'hôte de destination soit capable de renvoyer -les paquets au firewall (souvenez vous que les paquets qui ont pour -adresse de destination, une adresse réservée par la RFC 1918 ne pourront -pas être routés à travers Internet, donc l'hôte Internet ne pourra -adresser sa réponse à l'ordinateur 1). Lorsque le firewall reçoit le -paquet de réponse, il remet l'adresse de destination à 10.10.10.1 et -fait passer le paquet vers l'ordinateur 1.

    -

    Sur les systèmes Linux, ce procédé est souvent appelé -de l'IP Masquerading mais vous verrez aussi le terme de Source Network -Address Translation (SNAT) utilisé. Shorewall suit la convention -utilisée avec Netfilter :

    + +

    Les adresses réservées par la RFC 1918 sont parfois désignées +comme non-routables car les routeurs Internet (backbone) ne font pas circuler +les paquets qui ont une adresse de destination appartenant à la RFC-1918. +Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une +connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network +Address Translation). Le firewall ré écrit l'adresse source dans le paquet, +et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres +mots, le firewall fait croire que c'est lui même qui initie la connexion. +Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer +les paquets au firewall (souvenez vous que les paquets qui ont pour adresse +de destination, une adresse réservée par la RFC 1918 ne pourront pas être +routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse +à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet +l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur +1.

    + +

    Sur les systèmes Linux, ce procédé est souvent appelé de +l'IP Masquerading mais vous verrez aussi le terme de Source Network Address +Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter +:

    +
      -
    • -

      Masquerade désigne le cas ou vous laissez votre -firewall détecter automatiquement l'adresse de l'interface externe.

      -
      • -
    • -

      SNAT désigne le cas où vous spécifiez explicitement -l'adresse source des paquets sortant de votre réseau local.

      -
      • +
    • +

      Masquerade désigne le cas ou vous laissez votre firewall +détecter automatiquement l'adresse de l'interface externe.

      +
      • +
    • +

      SNAT désigne le cas où vous spécifiez explicitement l'adresse +source des paquets sortant de votre réseau local.

      +
      • +
    -

    Sous Shorewall, autant le Masquerading que le SNAT sont -configuré avec des entrés dans le fichier /etc/shorewall/masq.

    + +

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré +avec des entrés dans le fichier /etc/shorewall/masq.

    +

    Si votre interface externe est eth0, votre -interface locale eth1 et votre interface pour la DMZ eth2 -vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. -Dans le cas contraire, éditez /etc/shorewall/masq et changez le en -conséquence.

    + height="13"> + Si votre interface externe est eth0, votre interface locale eth1 +et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier +le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq + et changez le en conséquence.

    +

    Si votre IP externe est statique, vous pouvez la mettre -dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, -de toutes façons votre firewall fonctionnera bien si vous laissez cette -colonne vide. Le fait de mettre votre IP statique dans la troisième -colonne permet un traitement des paquets sortant un peu plus efficace.
    -

    + height="13"> + Si votre IP externe est statique, vous pouvez la mettre dans la troisième +colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre +firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de +mettre votre IP statique dans la troisième colonne permet un traitement des +paquets sortant un peu plus efficace.
    +

    +

    Si vous utilisez les paquets Debian, vérifiez que -votre fichier de configuration shorewall.conf contient bien les valeurs -suivantes, si elles n'y sont pas faite les changements nécessaires :
    -

    + height="13" alt=""> + Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration +shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas +faite les changements nécessaires :
    +

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • +
    +

    Port Forwarding (DNAT)

    -

    Un de nos buts est de, peut être, faire tourner un ou -plusieurs serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs -on une adresse RFC-1918, il n'est pas possible pour les clients sur -Internet de se connecter directement à eux. Il est nécessaire à ces -clients d'adresser leurs demandes de connexion au firewall qui ré écrit -l'adresse de destination de votre serveur, et fait passer le paquet à -celui-ci. Lorsque votre serveur répond, le firewall applique -automatiquement un SNAT pour ré écrire l'adresse source dans la réponse.

    -

    Ce procédé est appelé Port Forwarding ou Destination -Network Address Translation(DNAT). Vous configurez le port forwarding en -utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

    -

    La forme générale d'une simple règle de port forwarding dans -/etc/shorewall/rules est :

    -
    + +

    Un de nos buts est de, peut être, faire tourner un ou plusieurs +serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse +RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter +directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes +de connexion au firewall qui ré écrit l'adresse de destination de votre serveur, +et fait passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall +applique automatiquement un SNAT pour ré écrire l'adresse source dans la +réponse.

    + +

    Ce procédé est appelé Port Forwarding ou Destination Network +Address Translation(DNAT). Vous configurez le port forwarding en utilisant +les règles DNAT dans le fichier /etc/shorewall/rules.

    + +

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules +est :

    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server +port>]<protocol><port>
    +
    +
    -
    -

    Si vous ne spécifiez pas le <server port>, il est -supposé être le même que <port>.

    -

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et -vous voulez faire passer les paquets entrant en TCP sur le port 80 à ce -système :

    -
    +
    + +

    Si vous ne spécifiez pas le <server port>, il est supposé +être le même que <port>.

    + +

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous +voulez faire passer les paquets entrant en TCP sur le port 80 à ce système +:

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    -
    +
    +

    Deux points importants à garder en mémoire :

    +
      -
    • Lorsque vous vous connectez à votre serveur à partir de votre -réseau local, vous devez utiliser l'adresse IP interne du serveur -(10.10.11.2).
      • -
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les -requêtes de connexion entrantes sur le port 80. Si vous avez des -problèmes pour vous connecter à votre serveur web, essayez la règle -suivante et connectez vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre -IP externe).
      • +
    • Lorsque vous vous connectez à votre serveur à partir de votre réseau +local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
      • +
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes +de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous +connecter à votre serveur web, essayez la règle suivante et connectez vous +sur le port 5000 (c.a.d., connectez vous à +http://w.x.y.z:5000 où w.x.y.z est votre IP externe).
      • +
    -
    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    +
    +
    -
    -

    Si vous voulez avoir la possibilité de vous connecter à votre -serveur depuis le réseau local en utilisant votre adresse externe, et si -vous avez une adresse IP externe statique (fixe), vous pouvez remplacer -la règle loc->dmz précédente par :

    -
    +
    + +

    Si vous voulez avoir la possibilité de vous connecter à votre serveur +depuis le réseau local en utilisant votre adresse externe, et si vous avez +une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz +précédente par :

    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    -

    Si vous avez une IP dynamique, alors vous devez vous assurer que -votre interface externe est en route avant de lancer Shorewall et vous -devez suivre les étapes suivantes (en supposant que votre interface -externe est eth0) :

    +
    + +

    Si vous avez une IP dynamique, alors vous devez vous assurer que votre +interface externe est en route avant de lancer Shorewall et vous devez suivre +les étapes suivantes (en supposant que votre interface externe est eth0) +:

    +
      -
    1. Insérez ce qui suit dans /etc/shorewall/params :
      -
      -ETH0_IP=`find_interface_address eth0`
      -
      2. -
    2. Faites votre règle loc->dmz :
      3. +
    3. Insérez ce qui suit dans /etc/shorewall/params :
      +
      + ETH0_IP=`find_interface_address eth0`
      +
      4. +
    4. Faites votre règle loc->dmz :
      5. +
    -
    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    +     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    -

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant -votre adresse IP externe, regardez FAQ 2a.

    -

    A -ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    +
    + +

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre +adresse IP externe, regardez FAQ 2a.

    + +

    + A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    +

    Domain Name Server (DNS)

    -

    Normalement, quand vous vous connectez à votre -fournisseur (ISP), une partie consiste à obtenir votre adresse IP, votre -DNS pour le firewall (Domain Name Service) est configuré automatiquement -(c.a.d., le fichier /etc/resolv.conf a été écrit). Il arrive que votre -provider vous donne une paire d'adresse IP pour les DNS (name servers) -afin que vous configuriez manuellement votre serveur de nom primaire et -secondaire. La manière dont le DNS est configuré sur votre firewall est -de votre responsabilité. Vous pouvez procéder d'une de ses deux façons :

    + +

    Normalement, quand vous vous connectez à votre fournisseur +(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le +firewall (Domain Name Service) est configuré automatiquement (c.a.d., le +fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous +donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez +manuellement votre serveur de nom primaire et secondaire. La manière dont +le DNS est configuré sur votre firewall est de votre responsabilité. Vous +pouvez procéder d'une de ses deux façons :

    +
      -
    • -

      Vous pouvez configurer votre système interne pour -utiliser les noms de serveurs de votre provider. Si votre fournisseur -vous donne les adresses de leurs serveurs ou si ces adresses sont -disponibles sur leur site web, vous pouvez configurer votre système -interne afin de les utiliser. Si cette information n'est pas disponible, -regardez dans /etc/resolv.conf sur votre firewall -- les noms des -serveurs sont donnés dans l'enregistrement "nameserver" dans ce fichier.

      -
      • -
    • +
    • +

      Vous pouvez configurer votre système interne pour utiliser +les noms de serveurs de votre provider. Si votre fournisseur vous donne les +adresses de leurs serveurs ou si ces adresses sont disponibles sur leur site +web, vous pouvez configurer votre système interne afin de les utiliser. Si +cette information n'est pas disponible, regardez dans /etc/resolv.conf sur +votre firewall -- les noms des serveurs sont donnés dans l'enregistrement +"nameserver" dans ce fichier.

      +
      • +

    • Vous pouvez installer/configurer un cache dns -(Caching Name Server) sur votre firewall ou dans la DMZ. Red Hat -a un RPM pour mettre en cache un serveur de nom (le RPM requis aussi le -RPM 'bind') et pour les utilisateurs de Bering, il y a dnscache.lrp. Si -vous adoptez cette approche, vous configurez votre système interne pour -utiliser le firewall lui même comme étant le seul serveur de nom -primaire. Vous pouvez utiliser l'adresse IP interne du firewall -(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous -décidez de faire tourner le serveur de nom sur votre firewall. Pour -permettre à vos systèmes locaux de discuter avec votre serveur cache de -nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le -réseau local; vous ferez ceci en ajoutant les règles suivantes dans -/etc/shorewall/rules.

      -
      • + width="13" height="13"> + Vous pouvez installer/configurer un cache dns (Caching Name Server) sur +votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre en cache +un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs +de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez +votre système interne pour utiliser le firewall lui même comme étant le seul +serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne du firewall +(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous décidez +de faire tourner le serveur de nom sur votre firewall. Pour permettre à vos +systèmes locaux de discuter avec votre serveur cache de nom, vous devez ouvrir +le port 53 (UDP ET  TCP) sur le firewall vers le réseau local; vous ferez +ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.

      + +
    -
    -

    Si vous faites tourner le serveur de nom sur le -firewall : + +

    +

    Si vous faites tourner le serveur de nom sur le firewall +: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    -
    -
    ACCEPTlocfwudp53
    -
    -
    ACCEPTdmzfwtcp53
    -
    -
    ACCEPTdmzfwudp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    +
    +
    ACCEPTlocfwudp53
    +
    +
    ACCEPTdmzfwtcp53
    +
    +
    ACCEPTdmzfwudp53
    +
    +
    -

    -
    -
    -
    +

    +
    + +
    +

    Le serveur de nom tourne sur l'ordinateur 1 de la DMZ

    + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53
    -
    -
    ACCEPTlocdmz:10.10.11.1udp53
    -
    -
    ACCEPTfwdmz:10.10.10.1tcp53
    -
    -
    ACCEPTfwdmz:10.10.10.1udp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53
    +
    +
    ACCEPTlocdmz:10.10.11.1udp53
    +
    +
    ACCEPTfwdmz:10.10.10.1tcp53
    +
    +
    ACCEPTfwdmz:10.10.10.1udp53
    +
    +
    -
    -
    -
    +
    +
    + +

    Autres Connexions

    -
    -
    -

    L'exemple pour trois interfaces contient les règles -suivantes :

    -
    -
    -
    +
    + +
    +

    L'exemple pour trois interfaces contient les règles suivantes +:

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    -
    -
    ACCEPTfwnettcp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    +
    +
    ACCEPTfwnettcp53
    +
    +
    -
    -
    -
    -

    Ces règles permettent l'accès DNS depuis votre firewall -et peuvent être enlevées si vous avez décommenté la ligne dans -/etc/shorewall/policy autorisant toutes les connexions depuis votre -firewall et vers Internet.

    -
    -
    + +
    + +
    +

    Ces règles permettent l'accès DNS depuis votre firewall et +peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy +autorisant toutes les connexions depuis votre firewall et vers Internet.

    +
    + +

    L'exemple contient aussi :

    -
    -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    -
    -
    ACCEPTlocdmztcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    +
    +
    ACCEPTlocdmztcp22
    +
    +
    -
    -
    -
    -

    Cette règle permet de faire fonctionner une serveur SSH -sur le firewall et sur tous les systèmes de la DMZ et d'y autoriser la -connexion à partir de votre réseau local.

    -
    -
    -

    Si vous désirez permettre d'autres connexions entre vos -systèmes, la forme générale est :

    -
    -
    -
    +
    +
    + +
    +

    Cette règle permet de faire fonctionner une serveur SSH sur +le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion +à partir de votre réseau local.

    +
    + +
    +

    Si vous désirez permettre d'autres connexions entre vos systèmes, +la forme générale est :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    +
    +
    -
    -
    -
    -

    Exemple - Vous voulez faire tourner un serveur DNS -disponible pour le publique sur votre firewall :

    -
    -
    -
    +
    +
    + +
    +

    Exemple - Vous voulez faire tourner un serveur DNS disponible +pour le publique sur votre firewall :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    -
    -
    -
    -

    Ces deux règles seront, bien sur, ajoutées aux règles -décrites dans "Vous pouvez installer/configurer un cache dns (Caching -Name Server) sur votre firewall ou dans la DMZ".

    -
    -
    -

    Si vous ne savez pas quel port ou protocole une -application particulière utilise, regardez ici.

    -
    -
    -

    Important: Je ne vous recommande pas d'autoriser le -telnet depuis ou vers l'Internet car il utilise du texte en clair (même -pour le login et le mot de passe !). Si vous voulez avoir un accès au -shell de votre firewall depuis Internet, utilisez SSH :

    -
    -
    -
    +
    +
    + +
    +

    Ces deux règles seront, bien sur, ajoutées aux règles décrites +dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) +sur votre firewall ou dans la DMZ".

    +
    + +
    +

    Si vous ne savez pas quel port ou protocole une application +particulière utilise, regardez ici.

    +
    + +
    +

    Important: Je ne vous recommande pas d'autoriser le telnet +depuis ou vers l'Internet car il utilise du texte en clair (même pour le +login et le mot de passe !). Si vous voulez avoir un accès au shell de votre +firewall depuis Internet, utilisez SSH :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    -
    + +
    + +

    Et maintenant, éditez /etc/shorewall/rules pour rajouter -les autres connexions désirées.

    -
    -
    + height="13"> + Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres connexions +désirées.

    +
    + +

    Lancer et Arrêter son Firewall

    -
    -
    +
    + +

    Arrow La procédure -d'installation configure votre système pour lancer Shorewall au boot -du système, mais au début avec la version 1.3.9 de Shorewall le -lancement est désactivé, n'essayer pas de lancer Shorewall avec que la -configuration soit finie. Une fois que vous en avez fini avec la -configuration du firewall, vous pouvez permettre le lancement de -Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    -

    IMPORTANT: Les utilisateurs des paquets .deb doivent -éditer /etc/default/shorewall et mettre 'startup=1'.
    -

    -
    -
    -

    Le firewall est activé en utilisant la commande -"shorewall start" et arrêté avec "shorewall stop". Lorsque le firewall -est stoppé, le routage est autorisé sur les hôtes qui possèdent une -entrée dans /etc/shorewall/routestopped. -Un firewall qui tourne peut être relancé en utilisant la commande -"shorewall restart". Si vous voulez enlever toutes traces de Shorewall -sur votre configuration de Netfilter, utilisez "shorewall clear".

    -
    -
    + height="13" alt="Arrow"> + La procédure d'installation configure votre système +pour lancer Shorewall au boot du système, mais au début avec la version 1.3.9 +de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall +avec que la configuration soit finie. Une fois que vous en avez fini avec +la configuration du firewall, vous pouvez permettre le lancement de Shorewall +en supprimant le fichier /etc/shorewall/startup_disabled.
    +

    + +

    IMPORTANT: Les utilisateurs des paquets .deb doivent éditer +/etc/default/shorewall et mettre 'startup=1'.
    +

    +
    + +
    +

    Le firewall est activé en utilisant la commande "shorewall +start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le +routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un +firewall qui tourne peut être relancé en utilisant la commande "shorewall +restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration +de Netfilter, utilisez "shorewall clear".

    +
    + +

    L'exemple pour trois interfaces suppose que vous voulez -permettre le routage depuis/vers eth1 (votre réseau local) et -eth2(DMZ) lorsque Shorewall est arrêté. Si ces deux -interfaces ne sont pas connectées à votre réseau local et votre DMZ, ou -si vous voulez permettre un ensemble d'hôtes différents, modifiez -/etc/shorewall/routestopped en conséquence.

    -
    -
    -

    ATTENTION: Si vous êtes connecté à votre firewall -depuis Internet, n'essayez pas une commande "shorewall stop" tant que -vous n'avez pas ajouté une entrée pour votre adresse IP (celle à partir -de laquelle vous êtes connectée) dans /etc/shorewall/routestopped. -De la même manière, je ne vous recommande pas d'utiliser "shorewall -restart"; il est plus intéressant de créer une + L'exemple pour trois interfaces suppose que vous voulez permettre le routage +depuis/vers eth1 (votre réseau local) et eth2(DMZ) lorsque +Shorewall est arrêté. Si ces deux interfaces ne sont pas connectées +à votre réseau local et votre DMZ, ou si vous voulez permettre un ensemble +d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.

    +
    + + +
    +

    Last updated 12/20/2002 - Tom Eastep

    -

    Copyright 2002 -Thomas M. Eastep

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

    Copyright 2002 Thomas +M. Eastep

    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    diff --git a/Shorewall-docs/traffic_shaping.htm b/Shorewall-docs/traffic_shaping.htm index 8b6828abd..ac612fc81 100644 --- a/Shorewall-docs/traffic_shaping.htm +++ b/Shorewall-docs/traffic_shaping.htm @@ -1,333 +1,333 @@ - + - + - + - + Traffic Shaping - + - - - + + - - - + + + +
    - +
    +

    Traffic Shaping/Control

    -
    - -

    Beginning with version 1.2.0, Shorewall has limited support - for traffic shaping/control. In order to use traffic shaping under -Shorewall, it is essential that you get a copy of the Linux Advanced Routing and Shaping HOWTO, - version 0.3.0 or later. You must also install the iproute (iproute2) - package to provide the "ip" and "tc" utilities.

    - + +

    Shorewall has limited support for traffic shaping/control. +In order to use traffic shaping under Shorewall, it is essential that +you get a copy of the Linux Advanced Routing +and Shaping HOWTO, version 0.3.0 or later.

    +

    Shorewall traffic shaping support consists of the following:

    - +
      -
    • A new TC_ENABLED parameter in /etc/shorewall.conf. +
    • A new TC_ENABLED parameter in /etc/shorewall.conf. Traffic Shaping also requires that you enable packet mangling.
      • -
    • A new CLEAR_TC parameter in /etc/shorewall.conf (Added in -Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the -setting of this variable determines whether Shorewall clears the traffic -shaping configuration during Shorewall [re]start and Shorewall stop.
      -
      • -
    • /etc/shorewall/tcrules - A file where you can specify - firewall marking of packets. The firewall mark value may be used - to classify packets for traffic shaping/control.
      -
      • -
    • /etc/shorewall/tcstart - A user-supplied file that - is sourced by Shorewall during "shorewall start" and which you -can use to define your traffic shaping disciplines and classes. +
    • A new CLEAR_TC parameter in /etc/shorewall.conf (Added in + Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the + setting of this variable determines whether Shorewall clears the traffic + shaping configuration during Shorewall [re]start and Shorewall stop.
      +
      • +
    • /etc/shorewall/tcrules - A file where you can +specify firewall marking of packets. The firewall mark value may +be used to classify packets for traffic shaping/control.
      +
      • +
    • /etc/shorewall/tcstart - A user-supplied file +that is sourced by Shorewall during "shorewall start" and which +you can use to define your traffic shaping disciplines and classes. I have provided a sample that does - table-driven CBQ shaping but if you read the traffic shaping sections -of the HOWTO mentioned above, you can probably code your own faster + href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample that does + table-driven CBQ shaping but if you read the traffic shaping sections +of the HOWTO mentioned above, you can probably code your own faster than you can learn how to use my sample. I personally use HTB (see below). - HTB support may eventually become an integral part of Shorewall - since HTB is a lot simpler and better-documented than CBQ. As of -2.4.20, HTB is a standard part of the kernel but iproute2 must be patched - in order to use it.
      -
      - In tcstart, when you want to run the 'tc' utility, use the - run_tc function supplied by shorewall if you want tc errors to stop - the firewall.
      -
      - You can generally use off-the-shelf traffic shaping scripts by simply + href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB (see below). +HTB support may eventually become an integral part of Shorewall +since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20, + HTB is a standard part of the kernel but iproute2 must be patched in + order to use it.
      +
      + In tcstart, when you want to run the 'tc' utility, use +the run_tc function supplied by shorewall if you want tc errors +to stop the firewall.
      +
      + You can generally use off-the-shelf traffic shaping scripts by simply copying them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB version) - that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and - modified it according to the Wonder Shaper README). WARNING: If you - use use Masquerading or SNAT (i.e., you only have one external IP address) - then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb] - script won't work. Traffic shaping occurs after SNAT has already been applied - so when traffic shaping happens, all outbound traffic will have as a source + href="http://lartc.org/wondershaper/">The Wonder Shaper (HTB version) + that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and + modified it according to the Wonder Shaper README). WARNING: If +you use use Masquerading or SNAT (i.e., you only have one external IP address) + then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb] + script won't work. Traffic shaping occurs after SNAT has already been applied + so when traffic shaping happens, all outbound traffic will have as a source address the IP addresss of your firewall's external interface.
      -
      • -
    • /etc/shorewall/tcclear - A user-supplied file that - is sourced by Shorewall when it is clearing traffic shaping. This - file is normally not required as Shorewall's method of clearing +
      • +
    • /etc/shorewall/tcclear - A user-supplied file +that is sourced by Shorewall when it is clearing traffic shaping. +This file is normally not required as Shorewall's method of clearing qdisc and filter definitions is pretty general.
      • - +
    - Shorewall allows you to start traffic shaping when Shorewall itself starts - or it allows you to bring up traffic shaping when you bring up your interfaces.
    -
    - To start traffic shaping when Shorewall starts:
    - + Shorewall allows you to start traffic shaping when Shorewall itself starts + or it allows you to bring up traffic shaping when you bring up your interfaces.
    +
    + To start traffic shaping when Shorewall starts:
    +
      -
    1. Set TC_ENABLED=Yes and CLEAR_TC=Yes
      2. -
    2. Supply an /etc/shorewall/tcstart script to configure your traffic +
    3. Set TC_ENABLED=Yes and CLEAR_TC=Yes
      4. +
    4. Supply an /etc/shorewall/tcstart script to configure your traffic shaping rules.
      5. -
    5. Optionally supply an /etc/shorewall/tcclear script to stop traffic - shaping. That is usually unnecessary.
      6. -
    6. If your tcstart script uses the 'fwmark' classifier, you can mark +
    7. Optionally supply an /etc/shorewall/tcclear script to stop traffic + shaping. That is usually unnecessary.
      8. +
    8. If your tcstart script uses the 'fwmark' classifier, you can mark packets using entries in /etc/shorewall/tcrules.
      9. - +
    - To start traffic shaping when you bring up your network interfaces, you - will have to arrange for your traffic shaping configuration script to be -run at that time. How you do that is distribution dependent and will not -be covered here. You then should:
    - + To start traffic shaping when you bring up your network interfaces, you + will have to arrange for your traffic shaping configuration script to be +run at that time. How you do that is distribution dependent and will not be +covered here. You then should:
    +
      -
    1. Set TC_ENABLED=Yes and CLEAR_TC=No
      2. -
    2. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.
      3. -
    3. If your tcstart script uses the 'fwmark' classifier, you - can mark packets using entries in /etc/shorewall/tcrules.
      4. - +
    4. Set TC_ENABLED=Yes and CLEAR_TC=No
      5. +
    5. Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear +scripts.
      6. +
    6. If your tcstart script uses the 'fwmark' classifier, +you can mark packets using entries in /etc/shorewall/tcrules.
      7. +
    - +

    Kernel Configuration

    - +

    This screen shot show how I've configured QoS in my Kernel:

    - +

    -

    - +

    +

    /etc/shorewall/tcrules

    - -

    The fwmark classifier provides a convenient way to classify - packets for traffic shaping. The /etc/shorewall/tcrules file provides - a means for specifying these marks in a tabular fashion.
    -

    - -

    Normally, packet marking occurs in the PREROUTING chain before - any address rewriting takes place. This makes it impossible to mark inbound - packets based on their destination address when SNAT or Masquerading are - being used. Beginning with Shorewall 1.3.12, you can cause packet marking - to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in - shorewall.conf.
    -

    - + +

    The fwmark classifier provides a convenient way to classify + packets for traffic shaping. The /etc/shorewall/tcrules file provides + a means for specifying these marks in a tabular fashion.
    +

    + +

    Normally, packet marking occurs in the PREROUTING chain before + any address rewriting takes place. This makes it impossible to mark inbound + packets based on their destination address when SNAT or Masquerading are + being used. Beginning with Shorewall 1.3.12, you can cause packet marking + to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option +in shorewall.conf.
    +

    +

    Columns in the file are as follows:

    - +
      -
    • MARK - Specifies the mark value is to be assigned in case - of a match. This is an integer in the range 1-255. Beginning with -Shorewall version 1.3.14, this value may be optionally followed by ":" and -either 'F' or 'P' to designate that the marking will occur in the FORWARD -or PREROUTING chains respectively. If this additional specification is omitted, -the chain used to mark packets will be determined by the setting of the -MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      -
      - Example - 5
      -
      • -
    • SOURCE - The source of the packet. If the packet originates - on the firewall, place "fw" in this column. Otherwise, this is a - comma-separated list of interface names, IP addresses, MAC addresses +
    • MARK - Specifies the mark value is to be assigned in +case of a match. This is an integer in the range 1-255. Beginning +with Shorewall version 1.3.14, this value may be optionally followed by +":" and either 'F' or 'P' to designate that the marking will occur in the +FORWARD or PREROUTING chains respectively. If this additional specification +is omitted, the chain used to mark packets will be determined by the setting +of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
      +
      + Example - 5
      +
      • +
    • SOURCE - The source of the packet. If the packet originates + on the firewall, place "fw" in this column. Otherwise, this is a + comma-separated list of interface names, IP addresses, MAC addresses in Shorewall Format and/or Subnets.
      -
      - Examples
      -     eth0
      -     192.168.2.4,192.168.1.0/24
      -
      • -
    • DEST -- Destination of the packet. Comma-separated list +
      + Examples
      +     eth0
      +     192.168.2.4,192.168.1.0/24
      +
      • +
    • DEST -- Destination of the packet. Comma-separated list of IP addresses and/or subnets.
      -
      • -
    • PROTO - Protocol - Must be the name of a protocol from - /etc/protocol, a number or "all"
      -
      • -
    • PORT(S) - Destination Ports. A comma-separated list of -Port names (from /etc/services), port numbers or port ranges (e.g., -21:22); if the protocol is "icmp", this column is interpreted as -the destination icmp type(s).
      -
      • -
    • CLIENT PORT(S) - (Optional) Port(s) used by the client. - If omitted, any source port is acceptable. Specified as a comma-separate - list of port names, port numbers or port ranges.
      • - + +
    • PROTO - Protocol - Must be the name of a protocol from + /etc/protocol, a number or "all"
      +
      • +
    • PORT(S) - Destination Ports. A comma-separated list of + Port names (from /etc/services), port numbers or port ranges (e.g., + 21:22); if the protocol is "icmp", this column is interpreted as + the destination icmp type(s).
      +
      • +
    • CLIENT PORT(S) - (Optional) Port(s) used by the client. + If omitted, any source port is acceptable. Specified as a comma-separate + list of port names, port numbers or port ranges.
      • +
    - -

    Example 1 - All packets arriving on eth1 should be marked - with 1. All packets arriving on eth2 and eth3 should be marked with -2. All packets originating on the firewall itself should be marked with + +

    Example 1 - All packets arriving on eth1 should be marked + with 1. All packets arriving on eth2 and eth3 should be marked with +2. All packets originating on the firewall itself should be marked with 3.

    - + - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    1eth10.0.0.0/0all  
    2eth20.0.0.0/0all  
    2
    -     		eth3
    -     		0.0.0.0/0
    -     		all
    -
    -
    -
    3fw0.0.0.0/0all  
    1eth10.0.0.0/0all  
    2eth20.0.0.0/0all  
    2
    +     		eth3
    +     		0.0.0.0/0
    +     		all
    +
    +
    +
    3fw0.0.0.0/0all  
    - -

    Example 2 - All GRE (protocol 47) packets not originating - on the firewall and destined for 155.186.235.151 should be marked with + +

    Example 2 - All GRE (protocol 47) packets not originating + on the firewall and destined for 155.186.235.151 should be marked with 12.

    - + - + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    120.0.0.0/0155.186.235.15147  
    120.0.0.0/0155.186.235.15147  
    - -

    Example 3 - All SSH packets originating in 192.168.1.0/24 + +

    Example 3 - All SSH packets originating in 192.168.1.0/24 and destined for 155.186.235.151 should be marked with 22.

    - + - + + + + + + + + + - - - - - - - - - - - - - - - - - + + + + + + + + +
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    MARKSOURCEDESTPROTOPORT(S)CLIENT PORT(S)
    22192.168.1.0/24155.186.235.151tcp22 
    22192.168.1.0/24155.186.235.151tcp22 
    - +

    My Setup
    -

    - + +

    While I am currently using the HTB version of The Wonder Shaper (I just copied - wshaper.htb to /etc/shorewall/tcstart and modified it as shown in - the Wondershaper README), I have also run with the following set of hand-crafted - rules in my /etc/shorewall/tcstart file:
    -

    - -
    - 
    run_tc qdisc add dev eth0 root handle 1: htb default 30

    run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

    echo "   Added Top Level Class -- rate 384kbit"
    - - 
    run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
    run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
    run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
    - - 
    echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
    - - 
    run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
    run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
    run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
    - - 
    echo "   Enabled PFIFO on Second Level Classes"
    - - 
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
    - - 
    echo "   Defined fwmark filters"
    -
    - -

    My tcrules file that went with this tcstart file is shown in Example 1 - above.
    + href="http://lartc.org/wondershaper/">The Wonder Shaper (I just copied + wshaper.htb to /etc/shorewall/tcstart and modified it as shown +in the Wondershaper README), I have also run with the following set of +hand-crafted rules in my /etc/shorewall/tcstart file:

    +
    + 
    run_tc qdisc add dev eth0 root handle 1: htb default 30

    run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k

    echo "   Added Top Level Class -- rate 384kbit"
    + + 
    run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
    run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
    run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1
    + + 
    echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
    + + 
    run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
    run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
    run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
    + + 
    echo "   Enabled PFIFO on Second Level Classes"
    + + 
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
    run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
    + + 
    echo "   Defined fwmark filters"
    +
    + +

    My tcrules file that went with this tcstart file is shown in Example 1 + above.
    +

    +
      -
    1. I wanted to allow up to 140kbits/second for traffic outbound - from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic - can use all available bandwidth if there is no traffic from the local systems - or from my laptop or firewall).
      2. -
    2. My laptop and local systems could use up to 224kbits/second.
      3. -
    3. My firewall could use up to 20kbits/second.
      -
      4. - +
    4. I wanted to allow up to 140kbits/second for traffic outbound + from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic + can use all available bandwidth if there is no traffic from the local +systems or from my laptop or firewall).
      5. +
    5. My laptop and local systems could use up to 224kbits/second.
      6. +
    6. My firewall could use up to 20kbits/second.
      +
      7. +
    - +

    Last Updated 2/18/2003 - Tom Eastep

    - -

    Copyright + +

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

    +

    +

    diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm index a102f4090..b438ec1f7 100644 --- a/Shorewall-docs/troubleshoot.htm +++ b/Shorewall-docs/troubleshoot.htm @@ -1,232 +1,233 @@ - + Shorewall Troubleshooting - + - + - + - - - + + - - - + + + + +
    - +
    +

    Shorewall TroubleshootingBeating head on table -

    -
    - +

    Check the Errata

    - -

    Check the Shorewall Errata to be - sure that there isn't an update that you are missing for your version + +

    Check the Shorewall Errata to be + sure that there isn't an update that you are missing for your version of the firewall.

    - +

    Check the FAQs

    - -

    Check the FAQs for solutions to common + +

    Check the FAQs for solutions to common problems.

    - +

    If the firewall fails to start

    - If you receive an error message when starting or restarting -the firewall and you can't determine the cause, then do the following: - + If you receive an error message when starting or restarting + the firewall and you can't determine the cause, then do the following: +
      -
    • Make a note of the error message that you see.
      -
      • -
    • shorewall debug start 2> /tmp/trace
      • -
    • Look at the /tmp/trace file and see if that helps you - determine what the problem is. Be sure you find the place in the log -where the error message you saw is generated -- in 99.9% of the cases, it -will not be near the end of the log because after startup errors, Shorewall -goes through a "shorewall stop" phase which will also be traced.
      • -
    • If you still can't determine what's wrong then see the - support page.
      • - +
    • Make a note of the error message that you see.
      +
      • +
    • shorewall debug start 2> /tmp/trace
      • +
    • Look at the /tmp/trace file and see if that helps you + determine what the problem is. Be sure you find the place in the log + where the error message you saw is generated -- in 99.9% of the cases, it + will not be near the end of the log because after startup errors, Shorewall + goes through a "shorewall stop" phase which will also be traced.
      • +
    • If you still can't determine what's wrong then see the + support page.
      • +
    - Here's an example. During startup, a user sees the following:
    - -
    - 
    Adding Common Rules
    iptables: No chain/target/match by that name
    Terminated
    -
    - A search through the trace for "No chain/target/match by that name" turned - up the following:  -
    - 
    + echo 'Adding Common Rules'
    + add_common_rules
    + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
    ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
    ++ sed 's/!/! /g'
    + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
    iptables: No chain/target/match by that name
    -
    - The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with - tcp-reset". In this case, the user had compiled his own kernel and had forgotten - to include REJECT target support (see kernel.htm) - -

    Your network environment

    - -

    Many times when people have problems with Shorewall, the problem is - actually an ill-conceived network setup. Here are several popular snafus: -

    - -
      -
    • Port Forwarding where client and server are in -the same subnet. See FAQ 2.
      • -
    • Changing the IP address of a local system to be in the external - subnet, thinking that Shorewall will suddenly believe that the system - is in the 'net' zone.
      • -
    • Multiple interfaces connected to the same HUB or Switch. -Given the way that the Linux kernel respond to ARP "who-has" requests, -this type of setup does NOT work the way that you expect it to.
      • - -
    - -

    If you are having connection problems:

    - -

    If the appropriate policy for the connection that you are - trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING - TO MAKE IT WORK. Such additional rules will NEVER make it work, they add - clutter to your rule set and they represent a big security hole in the -event that you forget to remove them later.

    - -

    I also recommend against setting all of your policies to - ACCEPT in an effort to make something work. That robs you of one of - your best diagnostic tools - the "Shorewall" messages that Netfilter - will generate when you try to connect in a way that isn't permitted - by your rule set.

    - -

    Check your log ("/sbin/shorewall show log"). If you don't - see Shorewall messages, then your problem is probably NOT a Shorewall -problem. If you DO see packet messages, it may be an indication that you -are missing one or more rules -- see FAQ 17.

    - -

    While you are troubleshooting, it is a good idea to clear - two variables in /etc/shorewall/shorewall.conf:

    - -

    LOGRATE=""
    - LOGBURST=""

    - -

    This way, you will see all of the log messages being - generated (be sure to restart shorewall after clearing these variables).

    - -

    Example:

    - + Here's an example. During startup, a user sees the following:
    -

    Jun 27 15:37:56 gateway kernel: - Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 - LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 - LEN=47

    -     -

    Let's look at the important parts of this message:

    - -
      -
    • all2all:REJECT - This packet was REJECTed out of the all2all - chain -- the packet was rejected under the "all"->"all" REJECT policy - (see FAQ 17).
      • -
    • IN=eth2 - the packet entered the firewall via eth2
      • -
    • OUT=eth1 - if accepted, the packet would be sent on eth1
      • -
    • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
      • -
    • DST=192.168.1.3 - the packet is destined for 192.168.1.3
      • -
    • PROTO=UDP - UDP Protocol
      • -
    • DPT=53 - DNS
      • +
      + 
      Adding Common Rules
      iptables: No chain/target/match by that name
      Terminated
      +
      + A search through the trace for "No chain/target/match by that name" turned + up the following:  +
      + 
      + echo 'Adding Common Rules'
      + add_common_rules
      + run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
      ++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
      ++ sed 's/!/! /g'
      + iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
      iptables: No chain/target/match by that name
      +
      + The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with + tcp-reset". In this case, the user had compiled his own kernel and had forgotten + to include REJECT target support (see kernel.htm) -
    - -

    In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 - is in the "loc" zone. I was missing the rule:

    - -

    ACCEPT    dmz    loc    udp    53
    -

    - -

    See FAQ 17 for additional information - about how to interpret the chain name appearing in a Shorewall log message.
    -

    - -

    'Ping' Problems?

    - Either can't ping when you think you should be able to or are able to ping -when you think that you shouldn't be allowed? Shorewall's 'Ping' Management is described here.
    - -

    Other Gotchas

    - +

    Your network environment

    + +

    Many times when people have problems with Shorewall, the problem is +actually an ill-conceived network setup. Here are several popular snafus: +

    +
      -
    • Seeing rejected/dropped packets logged out of the INPUT -or FORWARD chains? This means that: - +
    • Port Forwarding where client and server are in + the same subnet. See FAQ 2.
      • +
    • Changing the IP address of a local system to be in the +external subnet, thinking that Shorewall will suddenly believe that +the system is in the 'net' zone.
      • +
    • Multiple interfaces connected to the same HUB or Switch. + Given the way that the Linux kernel respond to ARP "who-has" requests, + this type of setup does NOT work the way that you expect it to.
      • + +
    + +

    If you are having connection problems:

    + +

    If the appropriate policy for the connection that you are + trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING + TO MAKE IT WORK. Such additional rules will NEVER make it work, they +add clutter to your rule set and they represent a big security hole in +the event that you forget to remove them later.

    + +

    I also recommend against setting all of your policies to + ACCEPT in an effort to make something work. That robs you of one of + your best diagnostic tools - the "Shorewall" messages that Netfilter + will generate when you try to connect in a way that isn't permitted + by your rule set.

    + +

    Check your log ("/sbin/shorewall show log"). If you don't + see Shorewall messages, then your problem is probably NOT a Shorewall + problem. If you DO see packet messages, it may be an indication that you + are missing one or more rules -- see FAQ 17.

    + +

    While you are troubleshooting, it is a good idea to clear + two variables in /etc/shorewall/shorewall.conf:

    + +

    LOGRATE=""
    + LOGBURST=""

    + +

    This way, you will see all of the log messages being + generated (be sure to restart shorewall after clearing these variables).

    + +

    Example:

    + + +

    Jun 27 15:37:56 gateway kernel: + Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 + LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 + LEN=47

    +     +

    Let's look at the important parts of this message:

    + +
      +
    • all2all:REJECT - This packet was REJECTed out of the all2all + chain -- the packet was rejected under the "all"->"all" REJECT +policy (see FAQ 17).
      • +
    • IN=eth2 - the packet entered the firewall via eth2
      • +
    • OUT=eth1 - if accepted, the packet would be sent on eth1
      • +
    • SRC=192.168.2.2 - the packet was sent by 192.168.2.2
      • +
    • DST=192.168.1.3 - the packet is destined for 192.168.1.3
      • +
    • PROTO=UDP - UDP Protocol
      • +
    • DPT=53 - DNS
      • + +
    + +

    In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3 + is in the "loc" zone. I was missing the rule:

    + +

    ACCEPT    dmz    loc    udp    53
    +

    + +

    See FAQ 17 for additional information + about how to interpret the chain name appearing in a Shorewall log message.
    +

    + +

    'Ping' Problems?

    + Either can't ping when you think you should be able to or are able to ping + when you think that you shouldn't be allowed? Shorewall's 'Ping' Management is described here.
    + +

    Other Gotchas

    + +
      +
    • Seeing rejected/dropped packets logged out of the INPUT +or FORWARD chains? This means that: +
        -
      1. your zone definitions are screwed up and the host that -is sending the packets or the destination host isn't in any zone -(using an /etc/shorewall/hosts -file are you?); or
        2. -
      2. the source and destination hosts are both connected to -the same interface and you don't have a policy or rule for the +
      3. your zone definitions are screwed up and the host that + is sending the packets or the destination host isn't in any zone + (using an /etc/shorewall/hosts + file are you?); or
        4. +
      4. the source and destination hosts are both connected to + the same interface and you don't have a policy or rule for the source zone to or from the destination zone.
        5. - +
      -
      • -
    • Remember that Shorewall doesn't automatically allow ICMP - type 8 ("ping") requests to be sent between zones. If you want pings - to be allowed between zones, you need a rule of the form:
      -
      -     ACCEPT    <source zone>    <destination zone>    - icmp    echo-request
      -
      - The ramifications of this can be subtle. For example, if you +
      • +
    • Remember that Shorewall doesn't automatically allow ICMP + type 8 ("ping") requests to be sent between zones. If you want +pings to be allowed between zones, you need a rule of the form:
      +
      +     ACCEPT    <source zone>    <destination zone>    + icmp    echo-request
      +
      + The ramifications of this can be subtle. For example, if you have the following in /etc/shorewall/nat:
      -
      -     10.1.1.2    eth0    130.252.100.18
      -
      - and you ping 130.252.100.18, unless you have allowed icmp type - 8 between the zone containing the system you are pinging from and -the zone containing 10.1.1.2, the ping requests will be dropped. 
      • -
    • If you specify "routefilter" for an interface, that +
      +     10.1.1.2    eth0    130.252.100.18
      +
      + and you ping 130.252.100.18, unless you have allowed icmp +type 8 between the zone containing the system you are pinging from +and the zone containing 10.1.1.2, the ping requests will be dropped. 
      • +
    • If you specify "routefilter" for an interface, that interface must be up prior to starting the firewall.
      • -
    • Is your routing correct? For example, internal systems usually - need to be configured with their default gateway set to the IP address - of their nearest firewall interface. One often overlooked aspect of - routing is that in order for two hosts to communicate, the routing -between them must be set up in both directions. So when setting -up routing between A and B, be sure to verify that the -route from B back to A is defined.
      • -
    • Some versions of LRP (EigerStein2Beta for example) have +
    • Is your routing correct? For example, internal systems +usually need to be configured with their default gateway set to +the IP address of their nearest firewall interface. One often overlooked +aspect of routing is that in order for two hosts to communicate, the +routing between them must be set up in both directions. So +when setting up routing between A and B, be sure to +verify that the route from B back to A is defined.
      • +
    • Some versions of LRP (EigerStein2Beta for example) have a shell with broken variable expansion. You can get a corrected + href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected shell from the Shorewall Errata download site.
      • -
    • Do you have your kernel properly configured? Do you have your kernel properly configured? Click here to see my kernel configuration.
      • -
    • Some features require the "ip" program. That program -is generally included in the "iproute" package which should be included - with your distribution (though many distributions don't install iproute +
    • Shorewall requires the "ip" program. That program is + generally included in the "iproute" package which should be included + with your distribution (though many distributions don't install iproute by default). You may also download the latest source tarball from ftp://ftp.inr.ac.ru/ip-routing - .
      • -
    • Problems with NAT? Be sure that you let Shorewall + href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing + .
      • +
    • Problems with NAT? Be sure that you let Shorewall add all external addresses to be use with NAT unless you have set ADD_IP_ALIASES =No in /etc/shorewall/shorewall.conf.
      • - +
    - +

    Still Having Problems?

    - +

    See the support page.
    -

    - - +

    + +
    -     -

    Last updated 2/18/2003 - Tom Eastep

    - -

    Copyright + +

    Last updated 2/21/2003 - Tom Eastep

    + +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +

    diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm index d6ebaeaff..35b70685d 100644 --- a/Shorewall-docs/two-interface.htm +++ b/Shorewall-docs/two-interface.htm @@ -1,1044 +1,1048 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
    +
    - +

    Basic Two-Interface Firewall

    -
    - -

    Setting up a Linux system as a firewall for a small network - is a fairly straight-forward task if you understand the basics and - follow the documentation.

    - -

    This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall - in its most common configuration:

    - + +

    Setting up a Linux system as a firewall for a small network + is a fairly straight-forward task if you understand the basics and + follow the documentation.

    + +

    This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall + in its most common configuration:

    +
      -
    • Linux system used as a firewall/router for a small +
    • Linux system used as a firewall/router for a small local network.
      • -
    • Single public IP address.
      • -
    • Internet connection through cable modem, DSL, ISDN, -Frame Relay, dial-up ...
      • - +
    • Single public IP address.
      • +
    • Internet connection through cable modem, DSL, ISDN, + Frame Relay, dial-up ...
      • +
    - +

    Here is a schematic of a typical installation.

    - +

    -

    - -

    If you are running Shorewall under Mandrake 9.0 or later, you can easily - configure the above setup using the Mandrake "Internet Connection Sharing" - applet. From the Mandrake Control Center, select "Network & Internet" - then "Connection Sharing".
    -

    -

    Note however, that the Shorewall configuration produced by Mandrake -Internet Connection Sharing is strange and is apt to confuse you if you use -the rest of this documentation (it has two local zones; "loc" and "masq" -where "loc" is empty; this conflicts with this documentation which assumes -a single local zone "loc"). We therefore recommend that once you have set -up this sharing that you uninstall the Mandrake Shorewall RPM and install -the one from the download page then follow the -instructions in this Guide.
    -

    - -

    This guide assumes that you have the iproute/iproute2 package installed - (on RedHat, the package is called iproute). You can -tell if this package is installed by the presence of an ip program - on your firewall system. As root, you can use the 'which' command to - check for this program:

    - -
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    - -

    I recommend that you first read through the guide to familiarize yourself - with what's involved then go back through it again making your configuration - changes. Points at which configuration changes are recommended are - flagged with - . Configuration notes that are unique to LEAF/Bering are marked - with (LEAF Logo) +

    + +

    If you are running Shorewall under Mandrake 9.0 or later, you can easily + configure the above setup using the Mandrake "Internet Connection Sharing" + applet. From the Mandrake Control Center, select "Network & Internet" + then "Connection Sharing".
    +

    + +

    Note however, that the Shorewall configuration produced by Mandrake +Internet Connection Sharing is strange and is apt to confuse you if you use +the rest of this documentation (it has two local zones; "loc" and "masq" where +"loc" is empty; this conflicts with this documentation which assumes a single +local zone "loc"). We therefore recommend that once you have set up this +sharing that you uninstall the Mandrake Shorewall RPM and install the one +from the download page then follow the instructions +in this Guide.

    + +

    Shorewall requires that you have the iproute/iproute2 package installed + (on RedHat, the package is called iproute). You can + tell if this package is installed by the presence of an ip +program on your firewall system. As root, you can use the 'which' +command to check for this program:

    + +
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    +

    I recommend that you first read through the guide to familiarize yourself + with what's involved then go back through it again making your configuration + changes. Points at which configuration changes are recommended are + flagged with + . Configuration notes that are unique to LEAF/Bering are +marked with (LEAF Logo) +

    +

    -     If you edit your configuration files on a Windows system, - you must save them as Unix files if your editor supports that option - or you must run them through dos2unix before trying to use them. Similarly, - if you copy a configuration file from your Windows hard drive to a floppy - disk, you must run dos2unix against the copy before using it with Shorewall.

    - +     If you edit your configuration files on a Windows system, + you must save them as Unix files if your editor supports that option + or you must run them through dos2unix before trying to use them. Similarly, + if you copy a configuration file from your Windows hard drive to a +floppy disk, you must run dos2unix against the copy before using it with +Shorewall.

    + - +

    Shorewall Concepts

    - +

    -     The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you will only need to deal with +     The configuration files for Shorewall are contained in the directory + /etc/shorewall -- for simple setups, you will only need to deal with a few of these as described in this guide. After you have installed Shorewall, download the two-interface sample, - un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to -/etc/shorewall (these files will replace files with the same name).

    - -

    As each file is introduced, I suggest that you look through the actual - file on your system -- each file contains detailed configuration instructions - and default entries.

    - -

    Shorewall views the network where it is running as being composed of a - set of zones. In the two-interface sample configuration, the - following zone names are used:

    - + href="/pub/shorewall/LATEST.samples/two-interfaces.tgz">two-interface sample, + un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to + /etc/shorewall (these files will replace files with the same name).

    + +

    As each file is introduced, I suggest that you look through the actual + file on your system -- each file contains detailed configuration +instructions and default entries.

    + +

    Shorewall views the network where it is running as being composed of a + set of zones. In the two-interface sample configuration, +the following zone names are used:

    + - + + + + + - - - - - - - - - - - - - + + + + + + + + +
    NameDescription
    NameDescription
    netThe Internet
    locYour Local Network
    netThe Internet
    locYour Local Network
    - -

    Zones are defined in the /etc/shorewall/zones - file.

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

    - -

    Rules about what traffic to allow and what traffic to deny are expressed - in terms of zones.

    - + +

    Zones are defined in the /etc/shorewall/zones + file.

    + +

    Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

    + +

    Rules about what traffic to allow and what traffic to deny are expressed + in terms of zones.

    +
      -
    • You express your default policy for connections from +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies in +
    • You define exceptions to those default policies in the /etc/shorewall/rules file.
      • - +
    - -

    For each connection request entering the firewall, the request is first - checked against the /etc/shorewall/rules file. If no rule in that -file matches the connection request then the first policy in /etc/shorewall/policy - that matches the request is applied. If that policy is REJECT or -DROP  the request is first checked against the rules in /etc/shorewall/common - (the samples provide that file for you).

    - -

    The /etc/shorewall/policy file included with the two-interface sample has -the following policies:

    - -
    + +

    For each connection request entering the firewall, the request is first + checked against the /etc/shorewall/rules file. If no rule in that + file matches the connection request then the first policy in /etc/shorewall/policy + that matches the request is applied. If that policy is REJECT or + DROP  the request is first checked against the rules in /etc/shorewall/common + (the samples provide that file for you).

    + +

    The /etc/shorewall/policy file included with the two-interface sample +has the following policies:

    + +
    - + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + - - + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    locnetACCEPT  
    netallDROPinfo 
    allallREJECTinfo 
    -
    - -
    -

    In the two-interface sample, the line below is included but commented - out. If you want your firewall system to have full access to servers - on the internet, uncomment that line.

    - +
    + +
    +

    In the two-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers + on the internet, uncomment that line.

    + - + + + + + + + + - - - - - - - - - - - - - + + + + + + - - + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT  
    fwnetACCEPT  
    -
    - +
    +

    The above policy will:

    - +
      -
    1. allow all connection requests from your local network - to the internet
      2. -
    2. drop (ignore) all connection requests from the internet - to your firewall or local network
      3. -
    3. optionally accept all connection requests from the +
    4. allow all connection requests from your local network + to the internet
      5. +
    5. drop (ignore) all connection requests from the internet + to your firewall or local network
      6. +
    6. optionally accept all connection requests from the firewall to the internet (if you uncomment the additional policy)
      7. -
    7. reject all other connection requests.
      8. - +
    8. reject all other connection requests.
      9. +
    - +

    -     At this point, edit your /etc/shorewall/policy and make +     At this point, edit your /etc/shorewall/policy and make any changes that you wish.

    - +

    Network Interfaces

    - +

    -

    - -

    The firewall has two network interfaces. Where Internet -connectivity is through a cable or DSL "Modem", the External Interface - will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)  - unless you connect via Point-to-Point Protocol - over Ethernet (PPPoE) or Point-to-Point - Tunneling Protocol (PPTP) in which case the External - Interface will be a ppp interface (e.g., ppp0). If you connect - via a regular modem, your External Interface will also be ppp0. - If you connect via ISDN, your external interface will be ippp0.

    - +

    + +

    The firewall has two network interfaces. Where Internet connectivity +is through a cable or DSL "Modem", the External Interface will be +the ethernet adapter that is connected to that "Modem" (e.g., eth0)  + unless you connect via Point-to-Point Protocol + over Ethernet (PPPoE) or Point-to-Point + Tunneling Protocol (PPTP) in which case the External + Interface will be a ppp interface (e.g., ppp0). If you connect + via a regular modem, your External Interface will also be ppp0. + If you connect via ISDN, your external interface will be ippp0.

    +

    -     If your external interface is ppp0 or ippp0  +     If your external interface is ppp0 or ippp0  then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.

    - -

    Your Internal Interface will be an ethernet adapter - (eth1 or eth0) and will be connected to a hub or switch. Your other - computers will be connected to the same hub/switch (note: If you have - only a single internal system, you can connect the firewall directly - to the computer using a cross-over cable).

    - + +

    Your Internal Interface will be an ethernet adapter + (eth1 or eth0) and will be connected to a hub or switch. Your other + computers will be connected to the same hub/switch (note: If you +have only a single internal system, you can connect the firewall +directly to the computer using a cross-over cable).

    +

    - Do not connect the internal and external interface - to the same hub or switch (even for testing). It won't work the way - that you think that it will and you will end up confused and believing + Do not connect the internal and external interface + to the same hub or switch (even for testing). It won't work the way + that you think that it will and you will end up confused and believing that Shorewall doesn't work at all.

    - +

    -     The Shorewall two-interface sample configuration assumes - that the external interface is eth0 and the internal interface - is eth1. If your configuration is different, you will have to - modify the sample /etc/shorewall/interfaces - file accordingly. While you are there, you may wish to review the -list of options that are specified for the interfaces. Some hints:

    - +     The Shorewall two-interface sample configuration assumes + that the external interface is eth0 and the internal interface + is eth1. If your configuration is different, you will have +to modify the sample /etc/shorewall/interfaces + file accordingly. While you are there, you may wish to review the list + of options that are specified for the interfaces. Some hints:

    +
      +
    • + +

      If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-". +

      +
    • - -

      If your external interface is ppp0 or ippp0, - you can replace the "detect" in the second column with "-".

      -
      • -
    • - -

      If your external interface is ppp0 or ippp0 - or if you have a static IP address, you can remove "dhcp" from the - option list.

      -
      • - + +

      If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from +the option list.

      + +
    - +

    IP Addresses

    - -

    Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you - a single Public IP address. This address may be assigned via -the Dynamic Host Configuration Protocol (DHCP) or as part of establishing - your connection when you dial in (standard modem) or establish your PPP - connection. In rare cases, your ISP may assign you a static IP -address; that means that you configure your firewall's external interface - to use that address permanently. However your external address -is assigned, it will be shared by all of your systems when you access the - Internet. You will have to assign your own addresses in your internal network -(the Internal Interface on your firewall plus your other computers). RFC -1918 reserves several Private IP address ranges for this purpose:

    - -
    + +

    Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you + a single Public IP address. This address may be assigned via + the Dynamic Host Configuration Protocol (DHCP) or as part of +establishing your connection when you dial in (standard modem) or establish +your PPP connection. In rare cases, your ISP may assign you a static +IP address; that means that you configure your firewall's external interface + to use that address permanently. However your external address + is assigned, it will be shared by all of your systems when you access +the Internet. You will have to assign your own addresses in your internal +network (the Internal Interface on your firewall plus your other computers). +RFC 1918 reserves several Private IP address ranges for this purpose:

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    - -
    +
    + +

    -     Before starting Shorewall, you should look at the IP - address of your external interface and if it is one of the above - ranges, you should remove the 'norfc1918' option from the external +     Before starting Shorewall, you should look at the +IP address of your external interface and if it is one of the above + ranges, you should remove the 'norfc1918' option from the external interface's entry in /etc/shorewall/interfaces.

    -
    - -
    -

    You will want to assign your addresses from the same - sub-network (subnet).  For our purposes, we can consider a subnet - to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a -subnet will have a Subnet Mask of 255.255.255.0. The address -x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is -reserved as the Subnet Broadcast Address. In Shorewall, -a subnet is described using Classless InterDomain Routing - (CIDR) notation with consists of the subnet address followed - by "/24". The "24" refers to the number of consecutive leading "1" bits -from the left of the subnet mask.

    -
    - -
    +
    + +
    +

    You will want to assign your addresses from the same + sub-network (subnet).  For our purposes, we can consider a subnet + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such +a subnet will have a Subnet Mask of 255.255.255.0. The address + x.y.z.0 is reserved as the Subnet Address and x.y.z.255 is + reserved as the Subnet Broadcast Address. In Shorewall, + a subnet is described using Classless InterDomain Routing + (CIDR) notation with consists of the subnet address followed + by "/24". The "24" refers to the number of consecutive leading "1" +bits from the left of the subnet mask.

    +
    + +

    Example sub-network:

    -
    - -
    -
    +
    + +
    +
    - - - - - + - - - - - - - - - - - + + + + + + + + + + + + + + + - - + +
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Range:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    + +
    + +
    +

    It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above + example) or the last usable address (10.10.10.254).

    - -
    -

    It is conventional to assign the internal interface either - the first usable address in the subnet (10.10.10.1 in the above -example) or the last usable address (10.10.10.254).

    -
    - -
    -

    One of the purposes of subnetting is to allow all computers - in the subnet to understand which other computers can be communicated - with directly. To communicate with systems outside of the subnetwork, - systems send packets through a  gateway  (router).

    -
    - -
    + +
    +

    One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated + with directly. To communicate with systems outside of the subnetwork, + systems send packets through a  gateway  (router).

    +
    + +

    -     Your local computers (computer 1 and computer 2 in -the above diagram) should be configured with their default gateway - to be the IP address of the firewall's internal interface.      +     Your local computers (computer 1 and computer 2 in +the above diagram) should be configured with their default gateway + to be the IP address of the firewall's internal interface.     

    -
    - -

    The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning - more about IP addressing and routing, I highly recommend "IP Fundamentals: - What Everyone Needs to Know about Addressing & Routing", Thomas - A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    - -

    The remainder of this quide will assume that you have configured - your network as shown here:

    - +
    + +

    The foregoing short discussion barely scratches the surface + regarding subnetting and routing. If you are interested in learning + more about IP addressing and routing, I highly recommend "IP Fundamentals: + What Everyone Needs to Know about Addressing & Routing", +Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    The remainder of this quide will assume that you have configured + your network as shown here:

    +

    -

    - +

    +

    The default gateway for computer's 1 & 2 would be 10.10.10.254.
    -

    - +

    +

    -     WARNING: Your ISP might assign - your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24 - subnet then you will need to select a DIFFERENT RFC 1918 subnet for your -local network.
    -

    - +     WARNING: Your ISP might assign + your external interface an RFC 1918 address. If that address is in the +10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918 +subnet for your local network.
    +

    +

    IP Masquerading (SNAT)

    - -

    The addresses reserved by RFC 1918 are sometimes referred - to as non-routable because the Internet backbone routers don't - forward packets which have an RFC-1918 destination address. When one - of your local systems (let's assume computer 1) sends a connection request - to an internet host, the firewall must perform Network Address -Translation (NAT). The firewall rewrites the source address in -the packet to be the address of the firewall's external interface; in -other words, the firewall makes it look as if the firewall itself is -initiating the connection.  This is necessary so that the destination -host will be able to route return packets back to the firewall (remember -that packets whose destination address is reserved by RFC 1918 can't -be routed across the internet so the remote host can't address its response -to computer 1). When the firewall receives a return packet, it rewrites -the destination address back to 10.10.10.1 and forwards the packet on to -computer 1.

    - -

    On Linux systems, the above process is often referred to as - IP Masquerading but you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:

    - + +

    The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't + forward packets which have an RFC-1918 destination address. When +one of your local systems (let's assume computer 1) sends a connection +request to an internet host, the firewall must perform Network +Address Translation (NAT). The firewall rewrites the source address +in the packet to be the address of the firewall's external interface; +in other words, the firewall makes it look as if the firewall itself +is initiating the connection.  This is necessary so that the destination + host will be able to route return packets back to the firewall (remember + that packets whose destination address is reserved by RFC 1918 can't + be routed across the internet so the remote host can't address its response + to computer 1). When the firewall receives a return packet, it rewrites + the destination address back to 10.10.10.1 and forwards the packet on +to computer 1.

    + +

    On Linux systems, the above process is often referred to +as IP Masquerading but you will also see the term Source Network +Address Translation (SNAT) used. Shorewall follows the convention used +with Netfilter:

    +
      +
    • + +

      Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

      +
    • - -

      Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

      -
      • -
    • - -

      SNAT refers to the case when you explicitly specify - the source address that you want outbound packets from your local - network to use.

      -
      • - + +

      SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local + network to use.

      + +
    - -

    In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use Masquerading - if your external IP is dynamic and SNAT if the IP is static.

    - + +

    In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file. You will normally use Masquerading + if your external IP is dynamic and SNAT if the IP is static.

    +

    -     If your external firewall interface is eth0, you - do not need to modify the file provided with the sample. Otherwise, - edit /etc/shorewall/masq and change the first column to the name -of your external interface and the second column to the name of your -internal interface.

    - +     If your external firewall interface is eth0, you + do not need to modify the file provided with the sample. Otherwise, + edit /etc/shorewall/masq and change the first column to the name of + your external interface and the second column to the name of your internal + interface.

    +

    -     If your external IP is static, you can enter it in the - third column in the /etc/shorewall/masq entry if you like although - your firewall will work fine if you leave that column empty. Entering - your static IP in column 3 makes processing outgoing packets a little +     If your external IP is static, you can enter it in the + third column in the /etc/shorewall/masq entry if you like although + your firewall will work fine if you leave that column empty. Entering + your static IP in column 3 makes processing outgoing packets a little more efficient.
    -
    - + -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, change - them appropriately:
    -

    - +     If you are using the Debian package, please check your shorewall.conf + file to ensure that the following are set correctly; if they are not, +change them appropriately:
    +

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • - +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • +
    - +

    Port Forwarding (DNAT)

    - -

    One of your goals may be to run one or more servers on your - local computers. Because these computers have RFC-1918 addresses, -it is not possible for clients on the internet to connect directly to -them. It is rather necessary for those clients to address their connection - requests to the firewall who rewrites the destination address to the - address of your server and forwards the packet to that server. When -your server responds, the firewall automatically performs SNAT to rewrite - the source address in the response.

    - -

    The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You configure + +

    One of your goals may be to run one or more servers on your + local computers. Because these computers have RFC-1918 addresses, + it is not possible for clients on the internet to connect directly +to them. It is rather necessary for those clients to address their +connection requests to the firewall who rewrites the destination address +to the address of your server and forwards the packet to that server. +When your server responds, the firewall automatically performs SNAT +to rewrite the source address in the response.

    + +

    The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port forwarding using DNAT rules in the /etc/shorewall/rules file.

    - -

    The general form of a simple port forwarding rule in /etc/shorewall/rules - is:

    - -
    + +

    The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

    + +
    - + + + + + + + + + + - - - - - - - - - - - - + + - - - - - + + + + + - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:<server local ip address> [:<server + DNATnetloc:<server local ip address> [:<server port>]<protocol><port>  
    <protocol><port>  
    -
    - -

    Example - you run a Web Server on computer 2 and you want to forward incoming - TCP port 80 to that system:

    - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2tcp80  
    -
    - -

    A couple of important points to keep in mind:

    - -
      -
    • You must test the above rule from a client outside -of your local network (i.e., don't test from a browser running on -computers 1 or 2 or on the firewall). If you want to be able to -access your web server using the IP address of your external interface, -see Shorewall FAQ #2.
      • -
    • Many ISPs block incoming connection requests to port - 80. If you have problems connecting to your web server, try the -following rule and try connecting to port 5000.
      • - -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2:80tcp5000  
    -
    - -

    -     At this point, modify /etc/shorewall/rules to add any -DNAT rules that you require.

    - -

    Domain Name Server (DNS)

    - -

    Normally, when you connect to your ISP, as part of getting - an IP address your firewall's Domain Name Service (DNS) resolver - will be automatically configured (e.g., the /etc/resolv.conf file will - be written). Alternatively, your ISP may have given you the IP address - of a pair of DNS name servers for you to manually configure as - your primary and secondary name servers. Regardless of how DNS gets -configured on your firewall, it is your responsibility to configure -the resolver in your internal systems. You can take one of two approaches:

    - -
      -
    • - -

      You can configure your internal systems to use your ISP's - name servers. If you ISP gave you the addresses of their servers - or if those addresses are available on their web site, you can configure - your internal systems to use those addresses. If that information - isn't available, look in /etc/resolv.conf on your firewall system --- the name servers are given in "nameserver" records in that file. -

      -
      • -
    • + + +
    + +

    Example - you run a Web Server on computer 2 and you want to forward incoming + TCP port 80 to that system:

    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2tcp80  
    +
    + +

    A couple of important points to keep in mind:

    + +
      +
    • You must test the above rule from a client outside +of your local network (i.e., don't test from a browser running on +computers 1 or 2 or on the firewall). If you want to be able to access +your web server using the IP address of your external interface, see + Shorewall FAQ #2.
      • +
    • Many ISPs block incoming connection requests to port + 80. If you have problems connecting to your web server, try the +following rule and try connecting to port 5000.
      • + +
    + +
    + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetloc:10.10.10.2:80tcp5000  
    +
    + +

    +     At this point, modify /etc/shorewall/rules to add any + DNAT rules that you require.

    + +

    Domain Name Server (DNS)

    + +

    Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver + will be automatically configured (e.g., the /etc/resolv.conf file +will be written). Alternatively, your ISP may have given you the IP +address of a pair of DNS name servers for you to manually configure +as your primary and secondary name servers. Regardless of how DNS gets + configured on your firewall, it is your responsibility to configure + the resolver in your internal systems. You can take one of two approaches:

    + +
      +
    • + +

      You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers + or if those addresses are available on their web site, you can configure + your internal systems to use those addresses. If that information + isn't available, look in /etc/resolv.conf on your firewall system + -- the name servers are given in "nameserver" records in that file. +

      +
      • +
    • +

      -     You can configure a Caching Name Server on your - firewall. Red Hat has an RPM for a caching name server - (the RPM also requires the 'bind' RPM) and for Bering users, there - is dnscache.lrp. If you take this approach, you configure your internal - systems to use the firewall itself as their primary (and only) name -server. You use the internal IP address of the firewall (10.10.10.254 -in the example above) for the name server address. To allow your -local systems to talk to your caching name server, you must open port -53 (both UDP and TCP) from the local network to the firewall; you -do that by adding the following rules in /etc/shorewall/rules.

      -
      • - +     You can configure a Caching Name Server on your + firewall. Red Hat has an RPM for a caching name server + (the RPM also requires the 'bind' RPM) and for Bering users, there + is dnscache.lrp. If you take this approach, you configure your internal + systems to use the firewall itself as their primary (and only) name server. + You use the internal IP address of the firewall (10.10.10.254 in the + example above) for the name server address. To allow your local systems + to talk to your caching name server, you must open port 53 (both UDP + and TCP) from the local network to the firewall; you do that by adding + the following rules in /etc/shorewall/rules.

      + +
    - -
    + +
    - + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    ACCEPTlocfwtcp53  
    ACCEPTlocfwudp53  
    -
    - -
    +
    + +

    Other Connections

    -
    - -
    +
    + +

    The two-interface sample includes the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnettcp53  
    ACCEPTfwnetudp53  
    -
    + +
    + +
    +

    Those rules allow DNS access from your firewall and may be + removed if you uncommented the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

    - -
    -

    Those rules allow DNS access from your firewall and may be - removed if you uncommented the line in /etc/shorewall/policy allowing - all connections from the firewall to the internet.

    -
    - -
    + +

    The sample also includes:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22  
    -
    + +
    + +
    +

    That rule allows you to run an SSH server on your firewall + and connect to that server from your local systems.

    - -
    -

    That rule allows you to run an SSH server on your firewall - and connect to that server from your local systems.

    -
    - -
    -

    If you wish to enable other connections between your firewall - and other systems, the general format is:

    -
    - -
    -
    + +
    +

    If you wish to enable other connections between your firewall + and other systems, the general format is:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>  
    -
    +
    +
    + +
    +

    Example - You want to run a Web Server on your firewall + system:

    - -
    -

    Example - You want to run a Web Server on your firewall - system:

    -
    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80#Allow web accessfrom the internet
    ACCEPTlocfwtcp80#Allow web accessfrom the local network
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp80#Allow web accessfrom the internet
    ACCEPTlocfwtcp80#Allow web accessfrom the local network
    -
    +
    +
    + +
    +

    Those two rules would of course be in addition to the rules + listed above under "You can configure a Caching Name Server on +your firewall"

    - -
    -

    Those two rules would of course be in addition to the rules - listed above under "You can configure a Caching Name Server on your - firewall"

    -
    - -
    -

    If you don't know what port and protocol a particular application -uses, look here.

    -
    - -
    -

    Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you - want shell access to your firewall from the internet, use SSH:

    -
    - -
    -
    + +
    +

    If you don't know what port and protocol a particular +application uses, look here.

    +
    + +
    +

    Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If +you want shell access to your firewall from the internet, use SSH:

    +
    + +
    +
    - - - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22  
    -
    -
    - -
    +
    +
    + +

    (LEAF Logo) -     Bering users will want to add the following two rules to be compatible +     Bering users will want to add the following two rules to be compatible with Jacques's Shorewall configuration.

    - -
    -
    + +
    +
    - - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    -     		fwudp
    -     		53
    -     		#Allow DNS Cache towork
    -
    ACCEPTlocfwtcp80#Allow weblet to work
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTloc
    +     		fwudp
    +     		53
    +     		#Allow DNS Cache towork
    +
    ACCEPTlocfwtcp80#Allow weblet to work
    +
    -
    -
    - +
    +
    +


    - -     Now edit your /etc/shorewall/rules file to add or delete - other connections as required.

    -
    - -
    -

    Starting and Stopping Your Firewall

    + +     Now edit your /etc/shorewall/rules file to add or +delete other connections as required.

    - -
    + +
    +

    Starting and Stopping Your Firewall

    +
    + +

    Arrow -     The installation procedure - configures your system to start Shorewall at system boot  but beginning -with Shorewall version 1.3.9 startup is disabled so that your system -won't try to start Shorewall before configuration is complete. Once you -have completed configuration of your firewall, you can enable Shorewall -startup by removing the file /etc/shorewall/startup_disabled.
    -

    - +     The installation procedure + configures your system to start Shorewall at system boot  but beginning + with Shorewall version 1.3.9 startup is disabled so that your system + won't try to start Shorewall before configuration is complete. Once +you have completed configuration of your firewall, you can enable Shorewall + startup by removing the file /etc/shorewall/startup_disabled.
    +

    +

    IMPORTANT: Users of the .deb package must edit /etc/default/shorewall + color="#ff0000">Users of the .deb package must edit /etc/default/shorewall and set 'startup=1'.
    -

    +

    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" + command. If you want to totally remove any trace of Shorewall from + your Netfilter configuration, use "shorewall clear".

    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall from -your Netfilter configuration, use "shorewall clear".

    -
    - -
    + +

    -     The two-interface sample assumes that you want to enable - routing to/from eth1 (the local network) when Shorewall is -stopped. If your local network isn't connected to eth1 or if you -wish to enable access to/from other hosts, change /etc/shorewall/routestopped +     The two-interface sample assumes that you want to enable + routing to/from eth1 (the local network) when Shorewall is + stopped. If your local network isn't connected to eth1 or if +you wish to enable access to/from other hosts, change /etc/shorewall/routestopped accordingly.

    -
    - -
    -

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you - have added an entry for the IP address that you are connected from - to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the + +

    - -

    Last updated 2/13/2003 - + +

    Last updated 2/21/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Eastep
    -

    +

    +

    diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm index ecc24f0cd..1283e4a06 100755 --- a/Shorewall-docs/upgrade_issues.htm +++ b/Shorewall-docs/upgrade_issues.htm @@ -1,291 +1,301 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Upgrade Issues

    -
    - +

    For upgrade instructions see the Install/Upgrade page.

    - +

    - +

    Version >= 1.4.0

    - If you are upgrading from a version < 1.4.0, then:
    - +IMPORTANT: Shorewall >=1.4.0 REQUIRES the iproute package +('ip' utility).
    +
    +If you are upgrading from a version < 1.4.0, then:
    +
      -
    • The noping and forwardping interface options are no -longer supported nor is the FORWARDPING option in shorewall.conf. ICMP -echo-request (ping) packets are treated just like any other connection request -and are subject to rules and policies.
      • -
    • Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate a Shorewall error at startup (they always have produced warnings +
    • The noping and forwardping interface options are no + longer supported nor is the FORWARDPING option in shorewall.conf. +ICMP echo-request (ping) packets are treated just like any other connection +request and are subject to rules and policies.
      • +
    • Interface names of the form <device>:<integer> in /etc/shorewall/interfaces + now generate a Shorewall error at startup (they always have produced warnings in iptables).
      • -
    • The MERGE_HOSTS variable has been removed from shorewall.conf. Shorewall -1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are -determined by BOTH the interfaces and hosts files when there are entries -for the zone in both files.
      • -
    • The routestopped option in the interfaces and hosts file has - been eliminated; use entries in the routestopped file instead.
      • -
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer - accepted; you must convert to using the new syntax.
      • -
    • The ALLOWRELATED variable in shorewall.conf is no longer +
    • The MERGE_HOSTS variable has been removed from shorewall.conf. Shorewall + 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are +determined by BOTH the interfaces and hosts files when there are entries for +the zone in both files.
      • +
    • The routestopped option in the interfaces and hosts file +has been eliminated; use entries in the routestopped file instead.
      • +
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted; you must convert to using the new syntax.
      • +
    • The ALLOWRELATED variable in shorewall.conf is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
      • -
    • Late-arriving DNS replies are not dropped by default; there - is no need for your own /etc/shorewall/common file simply to avoid logging - these packets.
      • -
    • The 'firewall', 'functions' and 'version' file have been +
    • Late-arriving DNS replies are not dropped by default; +there is no need for your own /etc/shorewall/common file simply to avoid +logging these packets.
      • +
    • The 'firewall', 'functions' and 'version' file have been moved to /usr/share/shorewall.
      • -
    • The icmp.def file has been removed. If you include it from -/etc/shorewall/icmpdef, you will need to modify that file.
      • -
    • The 'multi' interface option is no longer supported.  Shorewall -will generate rules for sending packets back out the same interface that they -arrived on in two cases:
      • +
    • The icmp.def file has been removed. If you include it from + /etc/shorewall/icmpdef, you will need to modify that file.
      • +
    • The 'multi' interface option is no longer supported.  Shorewall + will generate rules for sending packets back out the same interface that +they arrived on in two cases:
      • + +
    + +
      + +
        +
      • There is an explicit policy for the source zone to or from +the destination zone. An explicit policy names both zones and does not use +the 'all' reserved word.
        • + +
      + +
        +
      • There are one or more rules for traffic for the source zone to or +from the destination zone including rules that use the 'all' reserved word. + Exception: if the source zone and destination zone are the same then the +rule must be explicit - it must name the zone in both the SOURCE and DESTINATION + columns.
        • + +
      +
      -
        -
      • There is an explicit policy for the source zone to or from -the destination zone. An explicit policy names both zones and does not use -the 'all' reserved word.
        • -
      -
        -
      • There are one or more rules for traffic for the source zone to or -from the destination zone including rules that use the 'all' reserved word. -Exception: if the source zone and destination zone are the same then the rule -must be explicit - it must name the zone in both the SOURCE and DESTINATION -columns.
        • -
      -
    -
      - -
    - -

    Version >= 1.3.14

    - -      Beginning in version 1.3.14, Shorewall treats entries in /etc/shorewall/masq differently. The change - involves entries with an interface name in the SUBNET (second) - column:
    - -
      -
    • Prior to 1.3.14, Shorewall would detect the FIRST subnet on the -interface (as shown by "ip addr show interface") and would masquerade -traffic from that subnet. Any other subnets that routed through eth1 needed -their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT -applied.
      • -
    • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's -routing table to determine ALL subnets routed through the named interface. -Traffic originating in ANY of those subnets is masqueraded or has SNAT -applied.
      • - -
    - You will need to make a change to your configuration if:
    - -
      -
    1. You have one or more entries in /etc/shorewall/masq with an interface - name in the SUBNET (second) column; and
      2. -
    2. That interface connects to more than one subnetwork.
      3. - -
    - Two examples:
    -
    -  Example 1 -- Suppose that your current config is as follows:
    -   
    - -
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    - -
    In this case, the second entry in /etc/shorewall/masq is no longer - required.
    -
    - Example 2-- What if your current configuration is like this?
    - -
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    - -
    In this case, you would want to change the entry in /etc/shorewall/masq - to:
    -
    - -
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - -     Version 1.3.14 also introduced simplified ICMP echo-request (ping) -handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf -is used to specify that the old (pre-1.3.14) ping handling is to be used -(If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes - is assumed). I don't plan on supporting the old handling indefinitely so -I urge current users to migrate to using the new handling as soon as possible. - See the 'Ping' handling documentation for details.
    -

    Version 1.3.10

    - If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to -version 1.3.10, you will need to use the '--force' option:
    -
    + + +

    Version >= 1.3.14

    + +      Beginning in version 1.3.14, Shorewall treats entries in /etc/shorewall/masq differently. The change + involves entries with an interface name in the SUBNET (second) + column:
    -
    - 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +
      +
    • Prior to 1.3.14, Shorewall would detect the FIRST subnet on the + interface (as shown by "ip addr show interface") and would masquerade + traffic from that subnet. Any other subnets that routed through eth1 needed + their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT + applied.
      • +
    • Beginning with Shorewall 1.3.14, Shorewall uses the firewall's +routing table to determine ALL subnets routed through the named interface. +Traffic originating in ANY of those subnets is masqueraded or has SNAT applied.
      • + +
    + You will need to make a change to your configuration if:
    + +
      +
    1. You have one or more entries in /etc/shorewall/masq with an interface + name in the SUBNET (second) column; and
      2. +
    2. That interface connects to more than one subnetwork.
      3. + +
    + Two examples:
    +
    +  Example 1 -- Suppose that your current config is as follows:
    +   
    + +
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    + +
    In this case, the second entry in /etc/shorewall/masq is no longer + required.
    +
    + Example 2-- What if your current configuration is like this?
    + +
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    + +
    In this case, you would want to change the entry in /etc/shorewall/masq + to:
    +
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + +     Version 1.3.14 also introduced simplified ICMP echo-request (ping) + handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf + is used to specify that the old (pre-1.3.14) ping handling is to be used + (If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes + is assumed). I don't plan on supporting the old handling indefinitely so + I urge current users to migrate to using the new handling as soon as possible. + See the 'Ping' handling documentation for details.
    + +

    Version 1.3.10

    + If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to + version 1.3.10, you will need to use the '--force' option:
    +
    + +
    + 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +
    +

    Version >= 1.3.9

    - The 'functions' file has moved to /usr/lib/shorewall/functions. If -you have an application that uses functions from that file, your application - will need to be changed to reflect this change of location.
    - -

    Version >= 1.3.8

    - -

    If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

    - -

    Version >= 1.3.7

    - -

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following rules - in their /etc/shorewall/icmpdef file (creating - this file if necessary):

    - -
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - -

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" - command from that file since the icmp.def file is now empty.

    - -

    Upgrading Bering to - Shorewall >= 1.3.3

    - -

    To properly upgrade with Shorewall version - 1.3.3 and later:

    - -
      -
    1. Be sure you have a backup -- - you will need to transcribe any Shorewall - configuration changes that you have made - to the new configuration.
      2. -
    2. Replace the shorwall.lrp package - provided on the Bering floppy with the - later one. If you did not obtain the -later version from Jacques's site, see -additional instructions below.
      3. -
    3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall - entry if present. Then do not forget to - backup root.lrp !
      4. - -
    - -

    The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions - for setting up a two-interface firewall plus you also need to add - the following two Bering-specific rules to /etc/shorewall/rules:

    - -
    - 
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    -
    - -

    Version 1.3.6 and 1.3.7

    - -

    If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions 1.3.6 - and 1.3.7

    - -
      -
    1. - -

      Create the file /etc/shorewall/newnotsyn and in it add - the following rule
      -
      - run_iptables -A newnotsyn -j RETURN - # So that the connection tracking table can be rebuilt
      -                                     # from non-SYN packets - after takeover.
      -  

      -
      2. -
    2. + The 'functions' file has moved to /usr/lib/shorewall/functions. If + you have an application that uses functions from that file, your application + will need to be changed to reflect this change of location.
      -

      Create /etc/shorewall/common (if you don't already - have that file) and include the following:
      -
      - run_iptables -A common -p tcp --tcp-flags - ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
      -                                                                     - #tracking table.
      - . /etc/shorewall/common.def

      -
      3. - +

      Version >= 1.3.8

      + +

      If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

      + +

      Version >= 1.3.7

      + +

      Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following rules + in their /etc/shorewall/icmpdef file (creating + this file if necessary):

      + +
      	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
      	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
      + +

      Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + command from that file since the icmp.def file is now empty.

      + +

      Upgrading Bering to + Shorewall >= 1.3.3

      + +

      To properly upgrade with Shorewall version + 1.3.3 and later:

      + +
        +
      1. Be sure you have a backup +-- you will need to transcribe any Shorewall + configuration changes that you have made + to the new configuration.
        2. +
      2. Replace the shorwall.lrp package + provided on the Bering floppy with the + later one. If you did not obtain the later + version from Jacques's site, see additional + instructions below.
        3. +
      3. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall + entry if present. Then do not forget +to backup root.lrp !
        4. +
      - -

      Versions >= 1.3.5

      - -

      Some forms of pre-1.3.0 rules file syntax are no - longer supported.

      - -

      Example 1:

      - -
      -
      	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
      -
      - -

      Must be replaced with:

      - -
      -
      	DNAT	net	loc:192.168.1.12:22	tcp	11111
      -
      - -
      -

      Example 2:

      -
      - -
      -
      	ACCEPT	loc	fw::3128	tcp	80	-	all
      -
      - -
      -

      Must be replaced with:

      -
      - -
      -
      	REDIRECT	loc	3128	tcp	80
      -
      - -

      Version >= 1.3.2

      - -

      The functions and versions files together with the - 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those applications - should be modified accordingly.

      - -

      Last updated 2/14/2003 - - Tom Eastep

      + +

      The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions + for setting up a two-interface firewall plus you also need to +add the following two Bering-specific rules to /etc/shorewall/rules:

      + +
      + 
      # Bering specific rules:
      # allow loc to fw udp/53 for dnscache to work
      # allow loc to fw tcp/80 for weblet to work
      #
      ACCEPT loc fw udp 53
      ACCEPT loc fw tcp 80
      +
      + +

      Version 1.3.6 and 1.3.7

      + +

      If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions 1.3.6 + and 1.3.7

      + +
        +
      1. + +

        Create the file /etc/shorewall/newnotsyn and in it add + the following rule
        +
        + run_iptables -A newnotsyn -j RETURN + # So that the connection tracking table can be rebuilt
        +                                     # from non-SYN +packets after takeover.
        +  

        +
        2. +
      2. -

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

        +

        Create /etc/shorewall/common (if you don't already + have that file) and include the following:
        +
        + run_iptables -A common -p tcp --tcp-flags + ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
        +                                                                     + #tracking table.
        + . /etc/shorewall/common.def

        +
        3. + +
      + +

      Versions >= 1.3.5

      + +

      Some forms of pre-1.3.0 rules file syntax are no + longer supported.

      + +

      Example 1:

      + +
      +
      	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
      +
      + +

      Must be replaced with:

      + +
      +
      	DNAT	net	loc:192.168.1.12:22	tcp	11111
      +
      + +
      +

      Example 2:

      +
      + +
      +
      	ACCEPT	loc	fw::3128	tcp	80	-	all
      +
      + +
      +

      Must be replaced with:

      +
      + +
      +
      	REDIRECT	loc	3128	tcp	80
      +
      + +

      Version >= 1.3.2

      + +

      The functions and versions files together with the + 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those applications + should be modified accordingly.

      + +

      Last updated 2/14/2003 - + Tom Eastep

      + +

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

      +