diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index ed8f7bf06..6c9afeffb 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,15 +1,15 @@ -Changes since 1.4.3a +Changes since 1.4.4b -1. Implement REDIRECT-. +1) The command "shorewall debug try " now correctly traces + the attempt. -2. Change LOGMARKER to a printf mask and allow embedded spaces. Renamed - it LOGFORMAT to avoid confusion. - -3. DNAT and REDIRECT logging is moved from the filter table to the nat - table. - -4. Don't include log rule number when LOGFORMAT doesn't include "%d". - -5. Add --log-level to LOG rules. +2) The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now + contain a list of addresses. If the list begins with "!' then the + rule will take effect only if the original destination address in + the connection request does not match any of the addresses listed. +3) Enhanced processing of the zones file to allow the INCLUDE + directive. + +4) Fix processing of the routestopped file's second column. diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index fd1e8500f..83ef99edd 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,3016 +1,3155 @@ - + - + - + Shorewall 1.4 Documentation - + - + - + - + - - - - - - -
- -

Shorewall 1.4 Reference

-
- -

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

- -

Components

- -

Shorewall consists of the following components:

- - - -

/etc/shorewall/params

- -

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

- -

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

- -

Example:

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

Example (/etc/shorewall/interfaces record):

- -
	net $NET_IF $NET_BCAST $NET_OPTIONS
- -

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

- -
	net eth0 130.252.100.255 blacklist,norfc1918
- -

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

- -

/etc/shorewall/zones

- -

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

- - - -

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

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

Shorewall 1.4 Reference

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

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

- -

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

- -

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

- -

/etc/shorewall/interfaces

- -

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

- + +

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

+ +

Components

+ +

Shorewall consists of the following components:

+ + +

/etc/shorewall/params

+ +

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

+ +

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

+ +

Example:

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

Example (/etc/shorewall/interfaces record):

+ +
	net $NET_IF $NET_BCAST $NET_OPTIONS
+ +

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

+ +
	net eth0 130.252.100.255 blacklist,norfc1918
+ +

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

+ +

/etc/shorewall/zones

+ +

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

+ + + +

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

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

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

+ +

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

+ +

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

+ +

/etc/shorewall/interfaces

+ +

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

+ + - +

My recommendations concerning options:
-

- +

+ - +

- -

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

- -
+ +

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

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

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

- -
+
+ +

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

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

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

- -
+
+ +

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

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

/etc/shorewall/hosts - Configuration

- -

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

- -

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

- +
+ +

/etc/shorewall/hosts + Configuration

+ +

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

+ +

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

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

Columns in this file are:

- + - -
+ +
    -
  1. An IP address - (example - eth1:192.168.1.3)
    2. -
  2. A subnet -in CIDR notation (example - -eth2:192.168.2.0/24)
    3. - +
  3. An IP +address (example - eth1:192.168.1.3)
    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.

-
- +
+ - -
-

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

-
- -

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

- -

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

- + +
+

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

+
+ +

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

+ +

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

+

Example 1:

- -

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

- + +

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

+ - +

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

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

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

- +
+ +

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

+

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

- +
- + face="Century Gothic, Arial, Helvetica"> + - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25
-
loc2eth1:192.168.1.128/25
-
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25
+
loc2eth1:192.168.1.128/25
+
-
- + +

Example 2:

- -

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

- + +

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

+ - +

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

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

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

- +
- + face="Century Gothic, Arial, Helvetica"> + - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
ZONE HOST(S) OPTIONS
loceth1:192.168.1.0/25
-
loceth1:192.168.1.128/25
-
ZONE HOST(S) OPTIONS
loceth1:192.168.1.0/25
+
loceth1:192.168.1.128/25
+
-
- -

Nested and Overlapping Zones

- -

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

- -

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

- -

/etc/shorewall/policy - Configuration.

- -

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

- -

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

- + + +

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.

- + +

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

+

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

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

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

- -

The policy file installed by default is as follows:

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

This table may be interpreted as follows:

- - - -

WARNING:

- -

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

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

IntraZone Traffic

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

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

- -
    -
  1. Multiple 'net' interfaces to different ISPs. You don't want - to route traffic from one ISP to the other through your firewall.
    2. -
  2. Multiple VPN clients. You don't necessarily want them to all - be able to communicate between themselves using your gateway/router.
    -
    3. - +
  3. SOURCE - The name of a client zone +(a zone defined in the /etc/shorewall/zones + file , the name of the firewall +zone or "all").
    4. + +
  4. DEST - The name of a destination zone +(a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone +or "all"). Shorewall automatically allows all traffic from the +firewall to itself so the name of the firewall zone +cannot appear in both the SOURCE and DEST columns.
    5. + +
  5. POLICY - The default policy for connection + requests from the SOURCE zone to the DESTINATION zone.
    6. + +
  6. LOG LEVEL - Optional. If left empty, +no log message is generated when the policy is applied. + Otherwise, this column should contain an integer or name +indicating a syslog level.
    7. + +
  7. LIMIT:BURST - Optional. If left + empty, TCP connection requests from the SOURCE zone + to the DEST zone will not be rate-limited. Otherwise, + this column specifies the maximum rate at which TCP connection + requests will be accepted followed by a colon (":") followed + by the maximum burst size that will be tolerated. Example: + 10/sec:40 specifies that the maximum rate of TCP connection + requests allowed will be 10 per second and a burst of 40 connections + will be tolerated. Connection requests in excess of these limits + will be dropped.
    8. +
- -

The CONTINUE - policy

- -

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

- + +

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

+ +

The policy file installed by default is as follows:

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

This table may be interpreted as follows:

+ + + +

WARNING:

+ +

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

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

IntraZone Traffic

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

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

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

The CONTINUE + policy

+ +

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

+

/etc/shorewall/zones:

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

/etc/shorewall/interfaces:

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

/etc/shorewall/hosts:

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

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

- + + +

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

+

/etc/shorewall/policy:

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

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

- + + +

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

+

Partial /etc/shorewall/rules:

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

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

- -

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

- -
-

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

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

The first rule allows Sam SSH access to the firewall. The second - rule says that any clients from the net zone - with the exception of those in the 'sam' -zone should have their connection -port forwarded to 192.168.1.3. If -you need to exclude more than -one zone in this way, you - can list the zones separated by commas - (e.g., net!sam,joe,fred). This technique also - may be used when the ACTION is REDIRECT.

- -

/etc/shorewall/rules

- -

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

- -

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

- -

Entries in the file have the following columns:

- - - -

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

- -
- +
+ +

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
DNATnetloc:192.168.1.3tcpssh
-
-
-
- -

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

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

+
+
+
+
+
+
+
...
+
+
+
+
+
+
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
DNATsamfwtcpssh-
+
DNATnet!samloc:192.168.1.3tcpssh-
+
...
+
+
+
+
+
+
-
- -

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

- + + +

The first rule allows Sam SSH access to the firewall. The second + rule says that any clients from the net zone + with the exception of those in the 'sam' + zone should have their connection + port forwarded to 192.168.1.3. If + you need to exclude more than + one zone in this way, you + can list the zones separated by commas + (e.g., net!sam,joe,fred). This technique also + may be used when the ACTION is +REDIRECT.

+ +

/etc/shorewall/rules

+ +

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

+ +

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

+ +

Entries in the file have the following columns:

+ + + +

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

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

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

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

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

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

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

- + + +

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

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

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

- -
+
+ +

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

+ +

passive ports 0.0.0.0/0 65500 65534

-
- -

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

- -

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

- -

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

- + + +

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

+ +

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

+ +

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

+
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-
-
-
-
+ + + ACTION + SOURCE + DEST + PROTO + DEST
+ PORT(S) + SOURCE
+ PORT(S) + ORIGINAL
+ DEST + + + ACCEPT + loc:~02-00-08-E3-FA-55 + dmz + all +
+ +
+ +
+ + - 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. Your firewall's external + interface has several IP addresses but you only want to accept SSH connections + on address 206.124.146.176.
+ +
+ + + + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		net
+ 		fw:206.124.146.176
+ 		tcp
+ 		22
+
+
+
+
+ Example 8 (For advanced users running Shorewall version 1.3.13 + or later). From the internet, you with to forward tcp port + 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 + in your DMZ. You also want to allow access from the internet directly + to tcp port 25 on 192.0.2.177.
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.178
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.179
+
ACCEPT
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+
+
+
+
+ Using "DNAT-" rather than "DNAT" avoids two + extra copies of the third rule from being generated.
+ +

Look here for information on other services. +

+

/etc/shorewall/common

- -

Shorewall allows definition of rules that apply between - all zones. By default, these rules + +

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

- -

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

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

+ +

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

+

/etc/shorewall/masq

- -

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

- + +

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

+

Columns are:

- + - -

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

- -
+ +

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

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

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

- -
+
+ +

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

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

- -
+
+ +

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

+ +
- - - - - - - - - - - - - + + + + + + + + + + + + + +
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
INTERFACE SUBNETADDRESS
eth0192.168.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 +

+ +

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

- /etc/shorewall/proxyarp

- -

If you want to use proxy ARP on an entire sub-network, - 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.

- +
+ +

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

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

+ - -

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

- + +

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:

- -
+ +

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

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

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

- -

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

- -

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

- +
+ +

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

+ +

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

+ +

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

+

In /etc/shorewall/init, include:

- +

qt service ipsec stop

- +

In /etc/shorewall/start, include:

- +

qt service ipsec start

- -

- /etc/shorewall/nat

- -

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

- + +

+ /etc/shorewall/nat

+ +

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

+

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

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

+

Columns in an entry are:

- + - -

Look here for additional information and an example. -

- -

- /etc/shorewall/tunnels

- -

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

- -

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

- -

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

- + +

Look here for additional information and an example. +

+ +

+ /etc/shorewall/tunnels

+ +

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

+ +

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

+ +

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

+

/etc/shorewall/shorewall.conf

- +

This file is used to set the following firewall parameters:

- + - +

/etc/shorewall/modules Configuration

- -

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

- -

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

- + +

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

+ +

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

+

The loadmodule function is called as follows:

- -
-

loadmodule <modulename> [ - <module parameters> ]

-
- + +
+

loadmodule <modulename> [ + <module parameters> ]

+
+

where

- -
+ +

<modulename>

- -
-

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

-
- + +
+ +

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

+
+

<module parameters>

- -
+ +
+

Optional parameters to the insmod utility.

-
-
- -

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

- -
-

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>

-
- +
+
+ +

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

+ +
+

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

+
+ +

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

+ +
+

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

+
+

/etc/shorewall/tos Configuration

- -

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

- + +

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

+

Entries in the file have the following columns:

- + - -
-
+ +
+
+

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

-
-
- -

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

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

+
+
+ +

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

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

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

- +
+ +

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

+

/etc/shorewall/blacklist

- -

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

- + +

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

+ 
      130.252.100.69
      206.124.146.0/24
- -

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

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

- +

+

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

- +

+ - -

Shorewall also has a dynamic blacklist - capability.

- -

IMPORTANT: The Shorewall blacklist file is NOT - designed to police your users' web browsing -- to do that, - I suggest that you install and configure Squid (Shorewall also has a dynamic blacklist + capability.

+ +

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

- +

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

- -

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

- + +

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

+
    -
  • SUBNET - The - subnet using VLSM notation (e.g., 192.168.0.0/16).
    • -
  • TARGET - - What to do with packets to/from the SUBNET: - +
  • SUBNET +- The subnet using VLSM notation (e.g., 192.168.0.0/16).
    • +
  • TARGET - + What to do with packets to/from the SUBNET: +
      -
    • RETURN - -Process 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.
      • - +
    • 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:

- + +

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

+ +

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

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

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

- -
+ +

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

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

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

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

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

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

Updated 5/27/2003 - Tom Eastep -

- + +

Updated 6/2/2003 - Tom Eastep +

+

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

+

+
+
diff --git a/STABLE/documentation/IPSEC.htm b/STABLE/documentation/IPSEC.htm index 842fe9168..7a0afd53a 100644 --- a/STABLE/documentation/IPSEC.htm +++ b/STABLE/documentation/IPSEC.htm @@ -1,421 +1,767 @@ - + Shorewall IPSec Tunneling - + - + - + - - - + + - - - + + + +
+

IPSEC Tunnels

-
- +

Configuring FreeS/Wan

- There is an excellent guide to configuring IPSEC tunnels at http://www.geocities.com/jixen66/ -. I highly recommend that you consult that site for information about confuring -FreeS/Wan.  + . I highly recommend that you consult that site for information about configuring + FreeS/Wan. 

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. 

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

- + (I haven't tried it):

+

In /etc/shorewall/init, include:

- +

     qt service ipsec stop

- +

In /etc/shorewall/start, include:

- +

    qt service ipsec start

- +

IPSec Gateway on the Firewall System

- +

Suppose that we have the following sutuation:

- +

-

- +

+

We want systems in the 192.168.1.0/24 sub-network to be able - to communicate with systems in the 10.0.0.0/8 network.

- + to communicate with systems in the 10.0.0.0/8 network.

+

To make this work, we need to do two things:

- +

a) Open the firewall so that the IPSEC tunnel can be established - (allow the ESP and AH protocols and UDP Port 500).

- + (allow the ESP and AH protocols and UDP Port 500).

+

b) Allow traffic through the tunnel.

- +

Opening the firewall for the IPSEC tunnel is accomplished - by adding an entry to the /etc/shorewall/tunnels file.

- + by adding an entry to the /etc/shorewall/tunnels file.

+

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

- -
+ +
- - - - - - - - - - - - - - - -
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet134.28.54.2 
-
- -

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

- -
- - + - - - - - - - - - - - - - -
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
-
- -

Note: If either of the endpoints is behind a NAT gateway - then the tunnels file entry on the other endpoint should specify - a tunnel type of ipsecnat rather than ipsec and the GATEWAY - address should specify the external address of the NAT gateway.
-

- -

You need to define a zone for the remote subnet or include - it in your local zone. In this example, we'll assume that you have -created a zone called "vpn" to represent the remote subnet.

- -
- - - - - - - - - - - - - - + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet134.28.54.2 
- -

At both systems, ipsec0 would be included in /etc/shorewall/interfaces - as a "vpn" interface:

- -
+ +

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

+ +
- + - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
vpnipsec0  
-
- -

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

- -
- - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
- + +

Note: If either of the endpoints is behind a NAT gateway + then the tunnels file entry on the other endpoint should +specify a tunnel type of ipsecnat rather than ipsec and the +GATEWAY address should specify the external address of the NAT gateway.
+

+ +

You need to define a zone for the remote subnet or include + it in your local zone. In this example, we'll assume that you have +created a zone called "vpn" to represent the remote subnet.

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

At both systems, ipsec0 would be included in /etc/shorewall/interfaces + as a "vpn" interface:

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
vpnipsec0  
+
+ +

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

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

Once you have these entries in place, restart Shorewall (type shorewall restart); you are now ready to configure the tunnel in FreeS/WAN .

- -

Mobile System (Road - Warrior)

- + +

VPN Hub

+ Shorewall can be used in a VPN Hub environment where multiple remote networks +are connected to a gateway running Shorewall. This environment is shown in +this diatram.
+ +
(Three networks linked with IPSEC) +
+
+ +

We want systems in the 192.168.1.0/24 sub-network to be able + to communicate with systems in the 10.0.0.0/16 and 10.1.0.0/16 networks +and we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to communicate.

+ +

To make this work, we need to do several things:

+ +

a) Open the firewall so that two IPSEC tunnels can be established + (allow the ESP and AH protocols and UDP Port 500).

+ +

b) Allow traffic through the tunnels two/from the local zone +(192.168.1.0/24).
+

+ +

c) Deny traffic through the tunnels between the two remote +networks.
+

+ +

Opening the firewall for the IPSEC tunnels is accomplished + by adding two entries to the /etc/shorewall/tunnels file.

+ +

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

+ +
+ + + + + + + + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsec
+ 		net134.28.54.2 
ipsec
+ 		net
+ 		130.152.100.14
+
+
+
+ +

In /etc/shorewall/tunnels on systems B and C, we would have:

+ +
+ + + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet206.161.148.9 
+
+ +

+ +

Note: If either of the endpoints is behind a NAT gateway + then the tunnels file entry on the other endpoint should +specify a tunnel type of ipsecnat rather than ipsec
+ and the GATEWAY address should specify the external address of the +NAT gateway.
+

+ +

On each system, we will create a zone to represent the remote +networks. On System A:
+

+ +
+ + + + + + + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpn1VPN1Remote Subnet on system B
vpn2
+ 		VPN2
+ 		Remote Subnet on system C
+
+
+ +

On systems B and C:
+

+ +
+ + + + + + + + + + + + + + +
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet on system A
+
+ +

At system A, ipsec0 represents two zones so we have the following +in /etc/shorewall/interfaces:

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
-
+ 		ipsec0 
+
+
+ +

The /etc/shorewall/hosts file on system A defines the two +VPN zones:
+

+ +
+ + + + + + + + + + + + + + + + + + + +
ZONE HOSTS
+ 		OPTIONS
vpn1
+ 		ipsec0:10.0.0.0/16
+
vpn2
+ 		ipsec0:10.1.0.0/16
+
+
+
+ +

At systems B and C, ipsec0 represents a single zone so we +have the following in /etc/shorewall/interfaces:

+ +
+ + + + + + + + + + + + + + + + +
ZONE INTERFACE BROADCAST OPTIONS
vpn
+ 		ipsec0 
+
+
+
+

On systems A, you will need to allow traffic between the "vpn1" +zone and the "loc" zone as well as between "vpn2" and the "loc" zone +-- if you simply want to admit all traffic in both directions, you +can use the following policy file entries on all three gateways:

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
locvpn1ACCEPT 
vpn1locACCEPT 
loc
+ 		vpn2
+ 		ACCEPT
+
+
vpn2
+ 		loc
+ 		ACCEPT
+
+
+
+

On systems B and C, you will need to allow traffic between +the "vpn" zone and the "loc" zone -- if you simply want to admit all +traffic in both directions, you can use the following policy file entries +on all three gateways:

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

Once you have the Shorewall entries added, restart Shorewall +on each gateway (type shorewall restart); you are now ready to configure +the tunnels in FreeS/WAN + .

+ Note that to allow traffic between the networks attached to systems B and +C, it is necessary to simply add two additional entries to the /etc/shorewall/policy +file on system A.
+
+ + + + + + + + + + + + + + + + + + + + + + +
SOURCEDESTPOLICYLOG LEVEL
vpn1
+ 		vpn2ACCEPT 
vpn2vpn1
+ 		ACCEPT 
+
+
+ +

Mobile System +(Road Warrior)

+

Suppose that you have a laptop system (B) that you take with you when you travel and you want to be able to establish a secure connection back to your local network.

- +

-

- +

+

You need to define a zone for the laptop or include it in - your local zone. In this example, we'll assume that you have created - a zone called "vpn" to represent the remote host.

- -
+ your local zone. In this example, we'll assume that you have created + a zone called "vpn" to represent the remote host.

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

In this instance, the mobile system (B) has IP address 134.28.54.2 + but that cannot be determined in advance. In the /etc/shorewall/tunnels +file on system A, the following entry should be made:

+ +
+ + + + + + + + + + + + + + + +
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
- -

In this instance, the mobile system (B) has IP address 134.28.54.2 - but that cannot be determined in advance. In the /etc/shorewall/tunnels -file on system A, the following entry should be made:

- -
- - - - - - - - - - - - - - - - -
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
-
- +

Note that the GATEWAY ZONE column contains the name of the zone corresponding - to peer subnetworks. This indicates that the gateway system itself comprises - the peer subnetwork; in other words, the remote gateway is a standalone + to peer subnetworks. This indicates that the gateway system itself comprises + the peer subnetwork; in other words, the remote gateway is a standalone system.

- +

You will need to configure /etc/shorewall/interfaces and establish your "through the tunnel" policy as shown under the first example above.
-

- +

+

Dynamic RoadWarrior Zones

- Beginning with Shorewall release 1.3.10, you can define multiple VPN zones - and add and delete remote endpoints dynamically using /sbin/shorewall. In - /etc/shorewall/zones:
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - -
ZONE
- 		DISPLAY
- 		COMMENTS
-
vpn1
- 		VPN-1
- 		First VPN Zone
-
vpn2
- 		VPN-2
- 		Second VPN Zone
-
vpn3
- 		VPN-3
- 		Third VPN Zone
-
+ Beginning with Shorewall release 1.3.10, you can define multiple VPN +zones and add and delete remote endpoints dynamically using /sbin/shorewall. +In /etc/shorewall/zones:

-
- In /etc/shorewall/tunnels:
- -
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + +
ZONE
+ 		DISPLAY
+ 		COMMENTS
+
vpn1
+ 		VPN-1
+ 		First VPN Zone
+
vpn2
+ 		VPN-2
+ 		Second VPN Zone
+
vpn3
+ 		VPN-3
+ 		Third VPN Zone
+
+
+
+ In /etc/shorewall/tunnels:
+ +
- - - - - - - - - - - - - - + + + + + + + + + + + + + + + +
TYPE
- 		ZONE
- 		GATEWAY
- 		GATEWAY ZONE
-
ipsec
- 		net
- 		0.0.0.0/0
- 		vpn1,vpn2,vpn3
-
TYPE
+ 		ZONE
+ 		GATEWAY
+ 		GATEWAY ZONE
+
ipsec
+ 		net
+ 		0.0.0.0/0
+ 		vpn1,vpn2,vpn3
+
+
+
+ When Shorewall is started, the zones vpn[1-3] will all be empty and +Shorewall will issue warnings to that effect. These warnings may be safely +ignored. FreeS/Wan may now be configured to have three different Road Warrior +connections with the choice of connection being based on X-509 certificates +or some other means. Each of these connectioins will utilize a different +updown script that adds the remote station to the appropriate zone when the +connection comes up and that deletes the remote station when the connection +comes down. For example, when 134.28.54.2 connects for the vpn2 zone the +'up' part of the script will issue the command":
+
+ +
/sbin/shorewall add ipsec0:134.28.54.2 vpn2
+
+ and the 'down' part will:
+ +
/sbin/shorewall delete ipsec0:134.28.54.2 vpn
+
+
+ +

Limitations of Dynamic Zones

+ If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added + hosts are not excluded from the rule.
+
+ Example with dyn=dynamic zone:
+
+ +
+ + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DESTINATION
+ 		PROTOCOL
+ 		PORT(S)
+ 		CLIENT
+ PORT(S)
+ 		ORIGINAL
+ DESTINATION
+
DNAT
+ 		z:dyn
+ 		loc:192.168.1.3
+ 		tcp
+ 		80
+
+
+
-
-
- When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall - will issue warnings to that effect. These warnings may be safely ignored. - FreeS/Wan may now be configured to have three different Road Warrior connections - with the choice of connection being based on X-509 certificates or some -other means. Each of these connectioins will utilize a different updown -script that adds the remote station to the appropriate zone when the connection -comes up and that deletes the remote station when the connection comes down. -For example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of -the script will issue the command":
-
- -
/sbin/shorewall add ipsec0:134.28.54.2 vpn2
-
- and the 'down' part will:
- -
/sbin/shorewall delete ipsec0:134.28.54.2 vpn
-
-
-

Limitations of Dynamic Zones

-If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added -hosts are not excluded from the rule.
-
-Example with dyn=dynamic zone:
-
-
- - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DESTINATION
- 		PROTOCOL
- 		PORT(S)
- 		CLIENT
-PORT(S)
- 		ORIGINAL
-DESTINATION
-
DNAT
- 		z:dyn
- 		loc:192.168.1.3
- 		tcp
- 		80
-
-
-
-
-Dynamic changes to the zone dyn will have no effect on the above rule. - -

Last updated 5/3//2003 - + Dynamic changes to the zone dyn will have no effect on the above +rule. +

Last updated 6/10//2003 - Tom Eastep

- +

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

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


diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html index 60db899b2..7c47fade6 100644 --- a/STABLE/documentation/MAC_Validation.html +++ b/STABLE/documentation/MAC_Validation.html @@ -2,110 +2,118 @@ MAC Verification - + - + - + - - - + + - - - + +
+ + + +
- +

MAC Verification
-

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

Example 1: Here are my files:

- /etc/shorewall/shorewall.conf:
- + /etc/shorewall/shorewall.conf:
+ 
     MACLIST_DISPOSITION=REJECT
     MACLIST_LOG_LEVEL=info
- /etc/shorewall/interfaces:
- -
     #ZONE           INTERFACE       BROADCAST       OPTIONS
     net             eth0            206.124.146.255 norfc1918,dhcp,blacklist
     loc             eth2            192.168.1.255   dhcp,maclist
     dmz             eth1            192.168.2.255
     net             eth3            206.124.146.255 blacklist
     -               texas           192.168.9.255
     loc             ppp+
- /etc/shorewall/maclist:
- -
     #INTERFACE              MAC                     IP ADDRESSES (Optional)
     eth2                    00:A0:CC:63:66:89       192.168.1.3      #Wookie
     eth2                    00:10:B5:EC:FD:0B       192.168.1.4      #Tarry
     eth2                    00:A0:CC:DB:31:C4       192.168.1.5      #Ursa
     eth2                    00:A0:CC:DB:31:C4       192.168.1.128/26 #PPTP Clients to server on Ursa
     eth2                    00:06:25:aa:a8:0f       192.168.1.7      #Eastept1 (Wireless)
     eth2                    00:04:5A:0E:85:B9       192.168.1.250    #Wap
- As shown above, I use MAC Verification on my local zone.
- + /etc/shorewall/interfaces:
+ +
+ 
#ZONE   INTERFACE        BROADCAST       OPTIONS
net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
loc     eth2            192.168.1.255   dhcp
dmz     eth1            192.168.2.255
wap     eth3            192.168.3.255   dhcp,maclist
-       texas           192.168.9.255
+
+ /etc/shorewall/maclist:
+ +
+ 
#INTERFACE              MAC                     IP ADDRESSES (Optional)
eth3                    00:A0:CC:A2:0C:A0       192.168.3.7     #Work Laptop
eth3                    00:04:5a:fe:85:b9       192.168.3.250   #WAP11
eth3                    00:06:25:56:33:3c                       #WET11
eth3                    00:0b:cd:C4:cc:97       192.168.3.8     #TIPPER
+
+ As shown above, I use MAC Verification on my wireless zone.
+
+Note: The WET11 is a somewhat curious device; when forwarding DHCP +traffic, it uses the MAC address of the host (TIPPER) but for other forwarded +traffic it uses it's own MAC address. Consequently, I don't assign the WET11 +a fixed IP address in /etc/shorewall/maclist.
+

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:
- -
     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/21/2002 - Tom Eastep -

- - - + Suppose now that I add a second wireless segment to my wireless +zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15 + and IP address 192.168.3.253. Hosts in the second segment have IP addresses + in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist + file:
+ +
     eth3                     00:06:43:45:C6:15       192.168.3.253,192.168.4.0/24
+ This entry accomodates traffic from the router itself (192.168.3.253) + and from the second wireless segment (192.168.4.0/24). Remember that +all traffic being sent to my firewall from the 192.168.4.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 6/10/2002 - Tom Eastep +

+

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

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

+
+


diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm index ef0fb56b0..2d1316734 100644 --- a/STABLE/documentation/News.htm +++ b/STABLE/documentation/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -14,3235 +14,3358 @@ - + - + - + - - - + + + + - + + + + - - - + + +
+ +
- + +

Shorewall News Archive

-
- -

5/29/2003 - Shorewall-1.4.4b

-

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

6/17/2003 - Shorewall-1.4.5

+

Problems Corrected:

-

5/27/2003 - Shorewall-1.4.4a

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out - that the code in 1.4.4 restricts the length of short zone names to 4 characters. - I've produced version 1.4.4a that restores the previous 5-character limit - by conditionally omitting the log rule number when the LOGFORMAT doesn't -contain '%d'.
+
    +
  1. The command "shorewall debug try <directory>" now correctly traces +the attempt.
    2. +
  2. The INCLUDE directive now works properly in the zones file; previously, +INCLUDE in that file was ignored.
    3. +
  3. /etc/shorewall/routestopped records with an empty second column are +no longer ignored.
    +
    4. +
+

New Features:
+

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

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

+ +

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

+ +

6/8/2003 - Updated Samples

+ +

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

+ +

5/29/2003 - Shorewall-1.4.4b

+

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

+ +

5/27/2003 - Shorewall-1.4.4a

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

5/23/2003 - Shorewall-1.4.4

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

5/20/2003 - Shorewall-1.4.3a
-

- This version primarily corrects the documentation included in the .tgz - and in the .rpm. In addition:
- -
    -
  1. (This change is in 1.4.3 but is not documented) If you are running - iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject replies - as follows:
    -    a) tcp - RST
    -    b) udp - ICMP port unreachable
    -    c) icmp - ICMP host unreachable
    -    d) Otherwise - ICMP host prohibited
    - If you are running earlier software, Shorewall will follow it's traditional - convention:
    -    a) tcp - RST
    -    b) Otherwise - ICMP port unreachable
    2. -
  2. UDP port 135 is now silently dropped in the common.def chain. -Remember that this chain is traversed just before a DROP or REJECT policy -is enforced.
    +
  3. A REDIRECT- rule target has been added. This target behaves +for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter +nat table REDIRECT rule is added but not the companion filter table ACCEPT +rule.
    +
    4. - +
  4. The LOGMARKER variable has been renamed LOGFORMAT and has been + changed to a 'printf' formatting template which accepts three arguments + (the chain name, logging rule number and the disposition). To use LOGFORMAT + with fireparse (http://www.fireparse.com), + set it as:
    +  
    +        LOGFORMAT="fp=%s:%d a=%s "
    +  
    + CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT + string (up to but not including the first '%') to find log messages in +the 'show log', 'status' and 'hits' commands. This part should not be omitted + (the LOGFORMAT should not begin with "%") and the leading part should be + sufficiently unique for /sbin/shorewall to identify Shorewall messages.
    +
    +
    5. +
  5. When logging is specified on a DNAT[-] or REDIRECT[-] rule, +the logging now takes place in the nat table rather than in the filter +table. This way, only those connections that actually undergo DNAT or +redirection will be logged.
    +
    6. +
- + +

5/20/2003 - Shorewall-1.4.3a
+

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

5/18/2003 - Shorewall 1.4.3
-

-     Problems Corrected:
- +

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

5/10/2003 - Shorewall Mirror in Asia
-

- +

+

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

- +

+

5/8/2003 - Shorewall Mirror in Chile

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

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

- -

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

- + +

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

+

4/9/2003 - Shorewall 1.4.2
-

- -

    Problems Corrected:

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

    New Features:

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

3/24/2003 - Shorewall 1.4.1

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

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

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

3/17/2003 - Shorewall 1.4.0

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

3/10/2003 - Shoreall 1.3.14a

- -

A roleup of the following bug fixes and other updates:

- -
    -
  • There is an updated rfc1918 file that reflects the resent - allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • - -
+

-
    -
  • The documentation for the routestopped file claimed that - a comma-separated list could appear in the second column while -the code only supported a single host or network address.
    • -
  • Log messages produced by 'logunclean' and 'dropunclean' - were not rate-limited.
    • -
  • 802.11b devices with names of the form wlan<n> - don't support the 'maclist' interface option.
    • -
  • Log messages generated by RFC 1918 filtering are not -rate limited.
    • -
  • The firewall fails to start in the case where you have - "eth0 eth1" in /etc/shorewall/masq and the default route is through -eth1
    • - -
- -

2/8/2003 - Shoreawall 1.3.14

- -

New features include

+

    Problems Corrected:

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

    New Features:

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

3/24/2003 - Shorewall 1.4.1

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

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

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

3/17/2003 - Shorewall 1.4.0

+ Shorewall + 1.4 represents the next step in the evolution of Shorewall. The + main thrust of the initial release is simply to remove the cruft that + has accumulated in Shorewall over time.
+
+ IMPORTANT: Shorewall 1.4.0 requires the iproute + package ('ip' utility).
+
+ Function from 1.3 that has been omitted from this + version include:
+ +
    +
  1. The MERGE_HOSTS variable in shorewall.conf + is no longer supported. Shorewall 1.4 behavior is the same as 1.3 + with MERGE_HOSTS=Yes.

    2. -
  2. Support for VLAN devices with names of the - form $DEV.$VID (e.g., eth0.0)
    +
  3. Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate an error.
    +
    +
    4. +
  4. Shorewall 1.4 implements behavior consistent + with OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate + an error at startup as will specification of the 'noping' or 'filterping' + interface options.
    +
    +
    5. +
  5. The 'routestopped' option in the /etc/shorewall/interfaces + and /etc/shorewall/hosts files is no longer supported and will + generate an error at startup if specified.
    +
    +
    6. +
  6. The Shorewall 1.2 syntax for DNAT and REDIRECT + rules is no longer accepted.
    +
    +
    7. +
  7. The ALLOWRELATED variable in shorewall.conf + is no longer supported. Shorewall 1.4 behavior is the same as +1.3 with ALLOWRELATED=Yes.

    8. -
  8. In /etc/shorewall/tcrules, the MARK value may - be optionally followed by ":" and either 'F' or 'P' to designate - that the marking will occur in the FORWARD or PREROUTING chains respectively. - If this additional specification is omitted, the chain used to mark - packets will be determined by the setting of the MARK_IN_FORWARD_CHAIN - option in shorewall.conf.
    +
  9. The icmp.def file has been removed.
    +
    10. + +
+ Changes for 1.4 include:
+ +
    +
  1. The /etc/shorewall/shorewall.conf file has +been completely reorganized into logical sections.

    2. -
  2. 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
    +
  3. LOG is now a valid action for a rule (/etc/shorewall/rules).
    +
    4. - +
  4. The firewall script and version file are now + installed in /usr/share/shorewall.
    +
    +
    5. +
  5. Late arriving DNS replies are now silently +dropped in the common chain by default.
    +
    +
    6. +
  6. 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.
    +
    +
    7. +
  7. CONTINUE is now a valid action for a rule (/etc/shorewall/rules).
    +
    +
    8. +
  8. 802.11b devices with names of the form wlan<n> + now support the 'maclist' option.
    +
    +
    9. +
  9. Explicit Congestion Notification (ECN - RFC 3168) + may now be turned off on a host or network basis using the new /etc/shorewall/ecn + file. To use this facility:
    +
    +    a) You must be running kernel 2.4.20
    +    b) You must have applied the patch in
    +    http://www.shorewall/net/pub/shorewall/ecn/patch.
    +    c) You must have iptables 1.2.7a installed.
    +
    +
    10. +
  10. The /etc/shorewall/params file is now processed +first so that variables may be used in the /etc/shorewall/shorewall.conf + file.
    +
    +
    11. +
  11. Shorewall now gives a more helpful diagnostic + when the 'ipchains' compatibility kernel module is loaded and a +'shorewall start' command is issued.
    +
    +
    12. +
  12. The SHARED_DIR variable has been removed from shorewall.conf. + This variable was for use by package maintainers and was not documented + for general use.
    +
    +
    13. +
  13. Shorewall now ignores 'default' routes when detecting + masq'd networks.
    14. +
- -


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

- -

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

- -

Includes the Beta 2 content plus support for OpenVPN tunnels.

- -

1/28/2003 - Shorewall 1.3.14-Beta2

- -

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

- -

1/25/2003 - Shorewall 1.3.14-Beta1
-

- -

The Beta includes the following changes:
-

- + +

3/10/2003 - Shoreall 1.3.14a

+ +

A roleup of the following bug fixes and other updates:

+ +
    +
  • There is an updated rfc1918 file that reflects the +resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
    • + +
+ +
    +
  • The documentation for the routestopped file claimed + that a comma-separated list could appear in the second column +while the code only supported a single host or network address.
    • +
  • Log messages produced by 'logunclean' and 'dropunclean' + were not rate-limited.
    • +
  • 802.11b devices with names of the form wlan<n> + don't support the 'maclist' interface option.
    • +
  • Log messages generated by RFC 1918 filtering are not + rate limited.
    • +
  • The firewall fails to start in the case where you +have "eth0 eth1" in /etc/shorewall/masq and the default route is through + eth1
    • + +
+ +

2/8/2003 - Shoreawall 1.3.14

+ +

New features include

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


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

+ +

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

+

Includes the Beta 2 content plus support for OpenVPN tunnels.

+ +

1/28/2003 - Shorewall 1.3.14-Beta2

+ +

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

+ +

1/25/2003 - Shorewall 1.3.14-Beta1
+

+ +

The Beta includes the following changes:
+

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

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

- -

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

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

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

1/17/2003 - shorewall.net has MOVED 

- + +

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

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

+ +

1/13/2003 - Shorewall 1.3.13
-

- +

+ +

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

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

1/6/2003 - BURNOUT -

- -

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

- -

-Tom Eastep
-

- -

12/30/2002 - Shorewall Documentation in PDF Format

- - -

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

- - -

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

- - -

12/27/2002 - Shorewall 1.3.12 Released

- - -

Features include:
-

+

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

12/20/2002 - Shorewall 1.3.12 Beta 3
-

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

1/6/2003 - BURNOUT +

- + +

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

+ + +

-Tom Eastep
+

+ + +

12/30/2002 - Shorewall Documentation in PDF Format

+ + +

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

+ + +

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

+ + +

12/27/2002 - Shorewall 1.3.12 Released

+ + +

Features include:
+

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

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

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

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

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

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

12/7/2002 - Shorewall Support for Mandrake 9.0

- -

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

+ +

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

- +

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

+

- +

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

- +

12/3/2002 - Shorewall 1.3.11a

- -

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

+ +

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

+ +

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

- +

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

+

- -

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

+ +

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

- +

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

+

- +

11/09/2002 - Shorewall 1.3.10

- +

In this version:

- + - +

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

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

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

10/23/2002 - Shorewall 1.3.10 Beta 1

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

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

+ + +

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

-

10/23/2002 - Shorewall 1.3.10 Beta 1

- In this version:
+

10/9/2002 - Shorewall 1.3.9b

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

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

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

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

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

9/28/2002 - Shorewall 1.3.9

+ + +

In this version:
+

- You may download -the Beta from:
- - - - - -

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 +
  • 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.
    -
    • +
  • The +'functions' and 'version' files and the 'firewall' + symbolic link have been moved from /var/lib/shorewall + to /usr/lib/shorewall to appease the LFS police at +Debian.
    +
    • - +
- -

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

- Brown Paper Bag - A couple - of recent configuration changes at www.shorewall.net + +

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

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

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

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

9/18/2002 -  Debian 1.3.8 Packages Available
-

- - -

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

- - -

9/16/2002 - Shorewall 1.3.8

- - -

In this version:
-

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

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

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

9/18/2002 -  Debian 1.3.8 Packages Available
+

+ + +

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

+ + +

9/16/2002 - Shorewall 1.3.8

+ + +

In this version:
+

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

9/11/2002 - Debian 1.3.7c Packages Available

- +

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

- +

9/2/2002 - Shorewall 1.3.7c

- -

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

+ +

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

- +

8/31/2002 - I'm not available

- -

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

+ +

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

- +

-Tom

- +

8/26/2002 - Shorewall 1.3.7b

- -

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

+ +

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

- +

8/26/2002 - French FTP Mirror is Operational

- +

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

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

- +

8/25/2002 - Shorewall Mirror in France

- -

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

- +

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

- -

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

- -

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

+

- -

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

+ +

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

- +

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

- +

Features in this release include:

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

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

+ +

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

- +

8/13/2002 - Documentation in the CVS Repository

- -

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

+ +

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

- +

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

- -

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

+ +

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

- -

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

+ +

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

- -

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

+ +

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

- +

8/7/2002 - Shorewall 1.3.6

- +

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

- + - +

7/30/2002 - Shorewall 1.3.5b Released

- +

This interim release:

- +
    -
  • Causes - the firewall script to remove the lock file if it - is killed.
    • -
  • Once - again allows lists in the second column of the - /etc/shorewall/hosts file.
    • -
  • Includes - the latest QuickStart - Guides.
    • - +
  • Causes the firewall script to remove the lock + file if it is killed.
    • + +
  • Once again allows lists in the second column + of the /etc/shorewall/hosts + file.
    • + +
  • Includes the latest QuickStart Guides.
    • + +
- +

7/29/2002 - New Shorewall Setup Guide Available

- +

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

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

- +

7/28/2002 - Shorewall 1.3.5 Debian Package Available

- -

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

- +

7/27/2002 - Shorewall 1.3.5a Released

- +

This interim release restores correct handling of REDIRECT rules.

- +

7/26/2002 - Shorewall 1.3.5 Released

- -

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

+ +

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

- +

 In this version:

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

7/16/2002 - New Mirror in Argentina

- -

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

+ +

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

- +

7/16/2002 - Shorewall 1.3.4 Released

- +

In this version:

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

7/8/2002 - Shorewall 1.3.3 Debian Package Available

- +

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

- +

7/6/2002 - Shorewall 1.3.3 Released

- +

In this version:

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

6/25/2002 - Samples Updated for 1.3.2

- -

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

+ +

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

- +

6/25/2002 - Shorewall 1.3.1 Debian Package Available

- +

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

- +

6/19/2002 - Documentation Available in PDF Format

- -

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

+ +

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

- +

6/16/2002 - Shorewall 1.3.2 Released

- +

In this version:

- + - +

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

- -

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

+ +

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

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

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

+ +

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

- -

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

+ +

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

- +

6/5/2002 - Shorewall 1.3.1 Debian Package Available

- +

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

- +

6/2/2002 - Samples Corrected

- -

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

- +

6/1/2002 - Shorewall 1.3.1 Released

- +

Hot on the heels of 1.3.0, this release:

- + - +

5/29/2002 - Shorewall 1.3.0 Released

- -

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

+ +

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

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

5/23/2002 - Shorewall 1.3 RC1 Available

- -

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

+ +

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

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

5/17/2002 - Shorewall 1.3 Beta 1 Available

- -

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

+ +

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

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

5/4/2002 - Shorewall 1.2.13 is Available

- +

In this version:

- + - +

4/30/2002 - Shorewall Debian News

- -

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

+ +

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

- +

4/20/2002 - Shorewall 1.2.12 is Available

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

4/17/2002 - Shorewall Debian News

- +

Lorenzo Marignoni reports that:

- + - +

Thanks, Lorenzo!

- +

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

- -

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

+ +

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

- +

4/13/2002 - Shorewall 1.2.11 Available

- +

In this version:

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

4/13/2002 - Hamburg Mirror now has FTP

- +

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

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

- +

4/12/2002 - New Mirror in Hamburg

- -

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

+ +

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

- +

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

- -

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

+ +

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

- +

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

- -

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

+ +

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

- +

4/8/2002 - Parameterized Samples Withdrawn

- +

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

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

- +

4/2/2002 - Updated Log Parser

- -

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

+ +

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

- +

3/30/2002 - Shorewall Website Search Improvements

- -

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

+ +

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

- +

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

- + - +

3/25/2002 - Log Parser Available

- +

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

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

- +

3/20/2002 - Shorewall 1.2.10 Released

- +

In this version:

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

3/11/2002 - Shorewall 1.2.9 Released

- +

In this version:

- + - +

3/1/2002 - 1.2.8 Debian Package is Available

- +

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

- +

2/25/2002 - New Two-interface Sample

- -

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

+ +

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

- +

2/23/2002 - Shorewall 1.2.8 Released

- -

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

+ +

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

- +

2/22/2002 - Shorewall 1.2.7 Released

- +

In this version:

- +
    -
  • UPnP - probes (UDP destination port 1900) are now silently - dropped in the common chain
    • -
  • RFC - 1918 checking in the mangle table has been streamlined - to no longer require packet marking. RFC 1918 - checking in the filter 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.
    • - +
  • 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.
    • - +
  • $-variables may now be used anywhere in the +configuration files except /etc/shorewall/zones.
    • + +
  • The interfaces and hosts files now have their + contents validated before any changes are made to +the existing Netfilter configuration. The appearance + of a zone name that isn't defined in /etc/shorewall/zones + causes "shorewall start" and "shorewall restart" + to abort without changing the Shorewall state. Unknown +options in either file cause a warning to be issued.
    • + +
  • A problem occurring when BLACKLIST_LOGLEVEL + was not set has been corrected.
    • + +
- +

2/4/2002 - Shorewall 1.2.5 Debian Package Available

- +

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

- +

2/1/2002 - Shorewall 1.2.5 Released

- -

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

+ +

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

- +

In version 1.2.5:

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

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

- +

1/20/2002 - Corrected firewall script available 

- -

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

+ +

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

- +

1/19/2002 - Shorewall 1.2.3 Released

- +

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

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

The following problems were corrected:

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

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

- -

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

+ +

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

- +

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

- +

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

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

- +

1/8/2002 - Shorewall 1.2.2 Released

- +

In version 1.2.2

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

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

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

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

See the README file for upgrade instructions.

- +

1/1/2002 - Shorewall Mailing List Moving

- -

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

- +

12/31/2001 - Shorewall 1.2.1 Released

- +

In version 1.2.1:

- + - -

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

+ +

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

- +

Version 1.2 contains the following new features:

- + - -

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

- - -

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

- - -
+ +

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

- +

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

+ href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample + Configurations has been released. In this version:

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

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

- +

In this version:

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

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

+ +

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

+ + -

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

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

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

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

- -

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

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

- +

In this version:

- + + + + +

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

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

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

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

+

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

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

+

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

- +
    -
  • Support - for nested zones has been improved. See the documentation for -details
    • -
  • Shorewall - now correctly checks the alternate configuration - directory for the 'zones' file.
    • - +
  • 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.
    • + +
- -

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

+ +

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

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

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

+ +

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

- +
    -
  • Shell - variables can now be used to parameterize Shorewall - rules.
    • -
  • The - second column in the hosts file may now contain a - comma-separated list.
    -
    - Example:
    -     - sea    eth0:130.252.100.0/24,206.191.149.0/24
    • -
  • Handling - of multi-zone interfaces has been improved. See - the documentation - for the /etc/shorewall/interfaces file.
    • - +
  • A "shorewall refresh" command has been added + to allow for refreshing the rules associated with +the broadcast address on a dynamic interface. This + command should be used in place of "shorewall restart" + when the internet interface's IP address changes.
    • + +
  • The /etc/shorewall/start file (if any) is now + processed after all temporary rules have been + deleted. This change prevents the accidental + removal of rules added during the processing of that file.
    • + +
  • The "dhcp" interface option is now applicable + to firewall interfaces used by a DHCP server running + on the firewall.
    • + +
  • The RPM can now be built from the .tgz file using + "rpm -tb" 
    • + +
- -

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

+ +

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

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

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

+ +

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

- +
    -
  • A - "shorewall refresh" command has been added to allow - for refreshing the rules associated with the broadcast - address on a dynamic interface. This command should - be used in place of "shorewall restart" when the internet - interface's IP address changes.
    • -
  • The - /etc/shorewall/start file (if any) is now processed - after all temporary rules have been deleted. -This change prevents the accidental removal of -rules added during the processing of that file.
    • -
  • The - "dhcp" interface option is now applicable to firewall - interfaces used by a DHCP server running on the firewall.
    • -
  • The - RPM can now be built from the .tgz file using "rpm - -tb" 
    • - +
  • The "tunnels" file really is in the + RPM now.
    • + +
  • SNAT can now be applied to port-forwarded connections.
    • + +
  • A bug which would cause firewall start failures + in some dhcp configurations has been fixed.
    • + +
  • The firewall script now issues a message if you + have the name of an interface in the second column + in an entry in /etc/shorewall/masq and that interface + is not up.
    • + +
  • You can now configure Shorewall so that it doesn't require the NAT and/or + mangle netfilter modules.
    • + +
  • Thanks to Alex  Polishchuk, the "hits" command + from seawall is now in shorewall.
    • + +
  • Support for IPIP tunnels + has been added.
    • + +
- -

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

+ +

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

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

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

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

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

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

    + +

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

    - + - -

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

    + +

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

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

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

    + +

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

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

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

    + +

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

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

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

    +

    - +

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

    - +
      -
    • The - common chain is traversed from INPUT, OUTPUT and FORWARD - before logging occurs
      • -
    • The - source has been 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 firewall is cleared.
      • -
    • The - Linux kernel's route filtering facility can now be - specified selectively on network interfaces.
      • - +
    • 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.
      • + +
    - +

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

    - +
      -
    • Allows - user-defined zones. Shorewall now has only one -pre-defined zone (fw) with the remaining zones being - defined in the new configuration file /etc/shorewall/zones. - The /etc/shorewall/zones file released in this version - provides behavior that is compatible with Shorewall - 1.0.3. 
      • -
    • Adds - the ability to specify logging in entries in the - /etc/shorewall/rules file.
      • -
    • Correct - handling of the icmp-def chain so that only ICMP -packets are 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).
      • - +
    • 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).
      • + +
    - -

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

    + +

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

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

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

    + +

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

    - -

    Updated 5/29/2003 - Tom Eastep -

    + +

    Updated 6/17/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.

    diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index dd30bd648..61a732279 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -2,389 +2,362 @@ Shorewall Squid Usage - + - + - + - - - - - - - - -
    -
    -     		Using Shorewall with Squid
    -     		-
    -
    -
    - This page covers Shorewall configuration to use with Squid running as a Transparent - Proxy. If you are running Shorewall 1.3, please see this documentation.
    -
    - Caution -     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 iptables installed on your -Squid server.
    -
    - -     You must have NAT and MANGLE enabled in your - /etc/shorewall/conf file
    -
    -         NAT_ENABLED=Yes
    -             MANGLE_ENABLED=Yes
    -
    - Three different configurations are covered:
    - -
      -
    1. Squid running -on the Firewall.
      2. -
    2. Squid running in -the local network
      3. -
    3. Squid running in the - DMZ
      4. - -
    - -

    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:
    -
    - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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
    -
    - -
      -
    • If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please -upgrade to Shorewall 1.4.2 or later.
      -
      -
      • -
    • If you are running Shorewall 1.4.2 or later, then in /etc/shorewall/interfaces:
      -
      - - - - - - - - - - - - - - -
      ZONE
      +       		+
      		INTERFACE
      +       		Using Shorewall with Squid
      		BROADCAST
      -       		OPTIONS
      +       		+
      loc
      -       		eth1
      -       		detect
      -       		routeback
      -
      -
      -
      • -
    • In /etc/shorewall/rules:
      -
      - - - - - - - - - - - - - - - - - - - - - + + +
      ACTIONSOURCEDEST PROTODEST
      - PORT(S)      		SOURCE
      - PORT(S)      		ORIGINAL
      - DEST
      ACCEPT
      -       		locloc
      -       		tcpwww
      -
      -
      +
      + This page covers Shorewall configuration to use with Squid running as a Transparent + Proxy. If you are running Shorewall 1.3, please see this documentation.
      +
      + Caution +     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 iptables installed on your +Squid server.
      +
      + +     You must have NAT and MANGLE enabled in +your /etc/shorewall/conf file
      +
      +         NAT_ENABLED=Yes
      +               MANGLE_ENABLED=Yes
      +
      + Three different configurations are covered:
      + +
        +
      1. Squid running + on the Firewall.
        2. +
      2. Squid running in + the local network
        3. +
      3. Squid running in +the DMZ
        4. + +
      + +

      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:
      +
      + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDEST PROTODEST
      + PORT(S)      		SOURCE
      + PORT(S)      		ORIGINAL
      + DEST
      REDIRECTloc3128tcpwww -
      +       		!206.124.146.177
      ACCEPTfwnettcpwww
      +
      +
      +
      +
      + There may be a requirement to exclude additional destination hosts +or networks from being redirected. For example, you might also want requests +destined for 130.252.100.0/24 to not be routed to Squid. In that case, you +must add a manual rule in /etc/shorewall/start:
      +
      + 
      run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN
      +
      + To exclude additional hosts or networks, just add additional similar +rules.
      +

      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
      +
      + +
        +
      • If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, +please upgrade to Shorewall 1.4.2 or later.
        +
        +
        • +
      • If you are running Shorewall 1.4.2 or later, then in /etc/shorewall/interfaces:
        +
        + + + + + + + + + + + + + + + + + +
        ZONE
        +         		INTERFACE
        +         		BROADCAST
        +         		OPTIONS
        +
        loc
        +         		eth1
        +         		detect
        +         		routeback
        +
        +
        +
        • +
      • In /etc/shorewall/rules:
        +
        + + + + + + + + + + + + + + + + + + + + + + + +
        ACTIONSOURCEDEST PROTODEST
        + PORT(S)        		SOURCE
        + PORT(S)        		ORIGINAL
        + DEST
        ACCEPT
        +         		locloc
        +         		tcpwww
        +
        +
        +
        • +
        +
      • Alternativfely, if you are running Shorewall 1.4.0 you can have the +following policy in place of the above rule:
        + + + + + + + + + + + + + + + + + +
        SOURCE
        +         		DESTINATION
        +         		POLICY
        +         		LOG LEVEL
        +         		BURST PARAMETERS
        +
        loc
        +         		loc
        +         		ACCEPT
        +
        +
        +
        -
        • -
        -
      • Alternativfely, if you are running Shorewall 1.4.0 you can have the -following policy in place of the above rule:
        - - - - - - - - - - - - - - - - - - - -
        SOURCE
        -         		DESTINATION
        -         		POLICY
        -         		LOG LEVEL
        -         		BURST PARAMETERS
        -
        loc
        -         		loc
        -         		ACCEPT
        -
        -
        -
        -
        -
        • -
      • In /etc/shorewall/start add:
        -
        • - +
        + +
      • In /etc/shorewall/start add:
        +
        • +
      - -
      + +
      iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
      -
      - +
      +
        -
      • On 192.168.1.3, arrange for the following command to be executed +
      • On 192.168.1.3, arrange for the following command to be executed after networking has come up
        - + 
        iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128
        -
        • - + +
      - -
      If you are running RedHat on the server, you can simply execute + +
      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
        -
        • - +
      •  Do one of the following:
        +
        + A) In /etc/shorewall/start add
        +
        • +
      - -
      + +
      	iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
      -
      - -
      B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf +
      + +
      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:
      -
      - -
      -
      +
      + +
      +
      @@ -402,7 +375,7 @@ interface is eth1 and your local interface is eth2.
      - @@ -415,104 +388,144 @@ interface is eth1 and your local interface is eth2.
      - - + +
      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:
        • - +
      • In /etc/shorewall/rules, you will need:
        • +
      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTION
      -       		SOURCE
      -       		DEST
      -       		PROTO
      -       		DEST
      - PORT(S)
      -       		CLIENT
      - PORT(2)
      -       		ORIGINAL
      - DEST
      -
      ACCEPT
      -       		loc
      -       		dmz
      -       		tcp
      -       		80
      -
      -
      -
      ACCEPT
      -       		dmz
      -       		net
      -       		tcp
      -       		80
      -
      -
      -
      ACTION
      +       		SOURCE
      +       		DEST
      +       		PROTO
      +       		DEST
      + PORT(S)
      +       		CLIENT
      + PORT(2)
      +       		ORIGINAL
      + DEST
      +
      ACCEPT
      +       		loc
      +       		dmz
      +       		tcp
      +       		80
      +
      +
      +
      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:
      +
      - -
      + +
        +
      • 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 4/7/2003 - Tom Eastep + +

      Updated 5/29/2003 - Tom Eastep

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

      diff --git a/STABLE/documentation/Shorewall_index_frame.htm b/STABLE/documentation/Shorewall_index_frame.htm index 560b3148e..97f753f49 100644 --- a/STABLE/documentation/Shorewall_index_frame.htm +++ b/STABLE/documentation/Shorewall_index_frame.htm @@ -1,120 +1,138 @@ - + - + - + - + Shorewall Index - + + - + - - - + + - - - - + + + + + + + + + + + +
      +
      +

      Shorewall

      -
      - - - -
      -
      - +

      Copyright © 2001-2003 Thomas M. Eastep.

      diff --git a/STABLE/documentation/Shorewall_sfindex_frame.htm b/STABLE/documentation/Shorewall_sfindex_frame.htm index 11de0abe7..4a2d44d7e 100644 --- a/STABLE/documentation/Shorewall_sfindex_frame.htm +++ b/STABLE/documentation/Shorewall_sfindex_frame.htm @@ -1,124 +1,140 @@ - + - + - + - + Shorewall Index - + + - + - - - + + - - - + + + - - - -
      +
      +

      Shorewall

      -
      +
      + - - -
      +
      • + +
    + + + + + + + + +

    Copyright © 2001-2003 Thomas M. Eastep.

    -
    -
    -
    -
    + size="2">2001-2003 Thomas M. Eastep.
    +

    diff --git a/STABLE/documentation/download.htm b/STABLE/documentation/download.htm index c988c73ff..9c3fcd3e6 100644 --- a/STABLE/documentation/download.htm +++ b/STABLE/documentation/download.htm @@ -1,197 +1,192 @@ - + - + - + - + Download - + - - - + + - - - + + + +
    +
    +

    Shorewall Download

    -
    - +

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

    - + href="shorewall_quickstart_guide.htm">Shorewall QuickStart Guide +for the configuration that most closely matches your own.
    +

    +

    The entire set of Shorewall documentation is available in PDF format at:

    - +

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

    - -

    The documentation in HTML format is included in the .rpm and in the .tgz -packages below.

    - -

    Once you've printed the appropriate QuickStart Guide, download - one of the modules:

    - +     rsync://slovakia.shorewall.net/shorewall/pdf/ +

    + +

    The documentation in HTML format is included in the .rpm and in the +.tgz packages below.

    + +

    Once you've printed the appropriate QuickStart Guide, download + one of the modules:

    +
      -
    • If you run a RedHat, SuSE, Mandrake, - Linux PPC or TurboLinux distribution - with a 2.4 kernel, you can use the RPM version (note: the - RPM should also work with other distributions that store - init scripts in /etc/init.d and that include chkconfig or +
    • If you run a RedHat, SuSE, Mandrake, + Linux PPC or TurboLinux distribution + with a 2.4 kernel, you can use the RPM version (note: the + RPM should also work with other distributions that store + init scripts in /etc/init.d and that include chkconfig or insserv). If you find that it works in other cases, let me know so that - I can mention them here. See the Installation - Instructions if you have problems installing the RPM.
      • -
    • If you are running LRP, download the .lrp file - (you might also want to download the .tgz so you will have a + href="mailto:teastep@shorewall.net"> me know so that + I can mention them here. See the Installation + Instructions if you have problems installing the RPM.
      • +
    • If you are running LRP, download the .lrp file + (you might also want to download the .tgz so you will have a copy of the documentation).
      • -
    • If you run Debian - and would like a .deb package, Shorewall is included in both - the Debian - Testing Branch and the Debian Unstable +
    • If you run Debian + and would like a .deb package, Shorewall is included in both + the Debian + Testing Branch and the Debian Unstable Branch.
      • -
    • Otherwise, download the shorewall - module (.tgz)
      • - +
    • Otherwise, download the shorewall + module (.tgz)
      • +
    - -

    The documentation in HTML format is included in the .tgz and .rpm files - and there is an documentation .deb that also contains the documentation.  The - .rpm will install the documentation in your default document directory which - can be obtained using the following command:
    -

    - -
    + +

    The documentation in HTML format is included in the .tgz and .rpm files + and there is an documentation .deb that also contains the documentation.  The + .rpm will install the documentation in your default document directory +which can be obtained using the following command:
    +

    + +

    rpm --eval '%{defaultdocdir}'

    -
    - -

    Please check the errata - to see if there are updates that apply to the version -that you have downloaded.

    - -

    WARNING - YOU CAN NOT SIMPLY INSTALL - THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION IS -REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration +

    + +

    Please check the errata + to see if there are updates that apply to the version + that you have downloaded.

    + +

    WARNING - YOU CAN NOT SIMPLY INSTALL + THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION + IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.

    - +

    - +

    Download Sites:

    - -
    + +
    - - - - - - - - - - - + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + - - - - - - - - - - + + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    SERVER LOCATIONDOMAINHTTPFTP
    SourceForge
    -     		sf.net +
    SERVER LOCATIONDOMAINHTTPFTP
    SourceForge
    +     		sf.netBrowseN/A
    Slovak RepublicShorewall.netBrowse Browse
    Texas, USAInfohiiway.comBrowseBrowse
    Hamburg, GermanyShorewall.netBrowseBrowse
    Martinez (Zona Norte - GBA), ArgentinaCorreofuego.com.arBrowse Browse
    FranceShorewall.netBrowse Browse
    N/A
    Taiwan
    -     		Greshko.com
    -     		Browse
    -     		Browse
    -
    Washington State, USAShorewall.netBrowseBrowseSlovak RepublicShorewall.netBrowse Browse
    Texas, USAInfohiiway.comBrowseBrowse
    Hamburg, GermanyShorewall.netBrowseBrowse
    FranceShorewall.netBrowse Browse
    Taiwan
    +     		Greshko.com
    +     		Browse
    +     		Browse
    +
    Washington State, USAShorewall.netBrowseBrowse
    -
    - +
    +

    CVS:

    - -
    + +

    The CVS repository - at cvs.shorewall.net contains the latest snapshots of the each - Shorewall component. There's no guarantee that what you find there - will work at all.
    -

    -
    - + href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS repository + at cvs.shorewall.net contains the latest snapshots of the each + Shorewall component. There's no guarantee that what you find there + will work at all.
    +

    +
    +

    Last Updated 3/24/2003 - Tom Eastep

    - +

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

    +

    +



    diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index f2502ca45..d83aaea9e 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -1,313 +1,352 @@ - + Shorewall 1.4 Errata - + - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Shorewall Errata/Upgrade Issues

    -
    - +

    IMPORTANT

    - +
      -
    1. -

      If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved - it to your Linux system.

      -
      2. -
    2. -

      If you are installing Shorewall for the -first time and plan to use the .tgz and install.sh script, you can -untar the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

      -
      3. -
    3. -

      When the instructions say to install a corrected - firewall script in /usr/share/shorewall/firewall, you -may rename the existing file before copying in the new file.

      -
      4. -
    4. -

      DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. - For example, do NOT install the 1.3.9a firewall script if you are -running 1.3.7c.
      -

      -
      5. - +
    5. + +

      If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved + it to your Linux system.

      +
      6. +
    6. + +

      If you are installing Shorewall for the first +time and plan to use the .tgz and install.sh script, you can untar +the archive, replace the 'firewall' script in the untarred directory + with the one you downloaded below, and then run install.sh.

      +
      7. +
    7. + +

      When the instructions say to install a corrected + firewall script in /usr/share/shorewall/firewall, you + may rename the existing file before copying in the new file.

      +
      8. +
    8. + +

      DO NOT INSTALL CORRECTED COMPONENTS + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER +BELOW. For example, do NOT install the 1.3.9a firewall script if +you are running 1.3.7c.
      +

      +
      9. +
    - + - -
    + +

    Problems in Version 1.4

    - +

    - -

    1.4.4-1.4.4a

    + +

    1.4.4b

    +
      -
    • Log messages are being displayed on the system console even though -the log level for the console is set properly according to FAQ 16. This problem may be corrected by installing - this firewall script in /usr/share/shorewall/firewall -as described above.
      +
    • Shorewall is ignoring records in /etc/shorewall/routestopped that +have an empty second column (HOSTS). This problem may be corrected by installing + this firewall script in /usr/share/shorewall/firewall as +described above.
      • +
    • The INCLUDE directive doesn't work when placed in the /etc/shorewall/zones +file. This problem may be corrected by installing this functions script in /usr/share/shorewall/functions.
      • +
    + +

    1.4.4-1.4.4a

    + +
      +
    • Log messages are being displayed on the system console even though + the log level for the console is set properly according to FAQ 16. This problem may be corrected by installing + this firewall script in /usr/share/shorewall/firewall as +described above.
      +
      • + +
    +

    1.4.4
    -

    - + +
      -
    • If you have zone names that are 5 characters long, you may experience -problems starting Shorewall because the --log-prefix in a logging rule is -too long. Upgrade to Version 1.4.4a to fix this problem..
      • - +
    • If you have zone names that are 5 characters long, you may experience + problems starting Shorewall because the --log-prefix in a logging rule +is too long. Upgrade to Version 1.4.4a to fix this problem..
      • +
    - +

    1.4.3

    - -
      -
    • The LOGMARKER variable introduced in version 1.4.3 was intended to - allow integration of Shorewall with Fireparse (http://www.firewparse.com). - Unfortunately, LOGMARKER only solved part of the integration problem. I -have implimented a new LOGFORMAT variable which will replace LOGMARKER which -has completely solved this problem and is currently in production with fireparse - here at shorewall.net. The updated files may be found at ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/. - See the 0README.txt file for details.
      -
      • - -
    - -

    1.4.2

    - -
      -
    • When an 'add' or 'delete' command is executed, a temporary directory - created in /tmp is not being removed. This problem may be corrected by -installing this firewall script in /usr/share/shorewall/firewall -as described above.
      -
      • - -
    - -

    1.4.1a, 1.4.1 and 1.4.0

      -
    • Some TCP requests are rejected in the 'common' chain with an ICMP - port-unreachable response rather than the more appropriate TCP RST response. - This problem is corrected in this updated common.def file which may be installed in - /etc/shorewall/common.def.
      +
    • The LOGMARKER variable introduced in version 1.4.3 was intended + to allow integration of Shorewall with Fireparse (http://www.firewparse.com). + Unfortunately, LOGMARKER only solved part of the integration problem. I +have implimented a new LOGFORMAT variable which will replace LOGMARKER which +has completely solved this problem and is currently in production with fireparse + here at shorewall.net. The updated files may be found at ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/. + See the 0README.txt file for details.
    -

    1.4.1

    - -
      -
    • When a "shorewall check" command is executed, each "rule" produces - the harmless additional message:
      -
      -      /usr/share/shorewall/firewall: line 2174: [: =: unary operator -expected
      -
      - You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall - as described above.
      -
      • - -
    - -

    1.4.0

    +

    1.4.2

      -
    • When running under certain shells Shorewall will attempt to -create ECN rules even when /etc/shorewall/ecn is empty. You may either -just remove /etc/shorewall/ecn or you can install this - correct script in /usr/share/shorewall/firewall as described above.
      +
    • When an 'add' or 'delete' command is executed, a temporary directory + created in /tmp is not being removed. This problem may be corrected by +installing this firewall script in /usr/share/shorewall/firewall as +described above.
    -
    -

    Upgrade Issues

    - -

    The upgrade issues have moved to a separate page.

    - -
    -

    Problem with - iptables version 1.2.3

    - -
    -

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, - RedHat released this buggy iptables in RedHat 7.2. 

    - -

    I have built a - corrected 1.2.3 rpm which you can download here  and I -have also built an -iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs - before you upgrade to RedHat 7.2.

    - -

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can - download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works - fine.

    - -

    If you would like to patch iptables 1.2.3 yourself, - the patches are available for download. This patch - which corrects a problem with parsing of the --log-level - specification while this patch - corrects a problem in handling the  TOS target.

    - -

    To install one of the above patches:

    - -
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • - -
    -
    - -

    Problems with kernels >= 2.4.18 -and RedHat iptables

    - -
    -

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 - may experience the following:

    - -
    - 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    -
    - -

    The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by - installing - this iptables RPM. If you are already running a 1.2.5 - version of iptables, you will need to specify the --oldpackage - option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    - -

    Problems installing/upgrading - RPM on SuSE

    - -

    If you find that rpm complains about a conflict with kernel <= - 2.2 yet you have a 2.4 kernel installed, simply use the -"--nodeps" option to rpm.

    - -

    Installing: rpm -ivh --nodeps <shorewall rpm>

    - -

    Upgrading: rpm -Uvh --nodeps <shorewall rpm>

    - -

    Problems with iptables version 1.2.7 and - MULTIPORT=Yes

    - -

    The iptables 1.2.7 release of iptables has made an incompatible - change to the syntax used to specify multiport match rules; -as a consequence, if you install iptables 1.2.7 you must - be running Shorewall 1.3.7a or later or:

    +

    1.4.1a, 1.4.1 and 1.4.0

      -
    • set MULTIPORT=No - in /etc/shorewall/shorewall.conf; or -
      • -
    • if you are - running Shorewall 1.3.6 you may - install - this firewall script in /var/lib/shorewall/firewall - as described above.
      • - +
    • Some TCP requests are rejected in the 'common' chain with an + ICMP port-unreachable response rather than the more appropriate TCP RST + response. This problem is corrected in this updated common.def file which may be installed in + /etc/shorewall/common.def.
      +
      • +
    - + +

    1.4.1

    + +
      +
    • When a "shorewall check" command is executed, each "rule" +produces the harmless additional message:
      +
      +      /usr/share/shorewall/firewall: line 2174: [: =: unary operator + expected
      +
      + You may correct the problem by installing this corrected script in /usr/share/shorewall/firewall + as described above.
      +
      • + +
    + +

    1.4.0

    + +
      +
    • When running under certain shells Shorewall will attempt +to create ECN rules even when /etc/shorewall/ecn is empty. You may either + just remove /etc/shorewall/ecn or you can install this + correct script in /usr/share/shorewall/firewall as described above.
      +
      • + +
    + +
    +

    Upgrade Issues

    + +

    The upgrade issues have moved to a separate page.

    + +
    +

    Problem with + iptables version 1.2.3

    + +
    +

    There are a couple of serious bugs in iptables 1.2.3 that + prevent it from working with Shorewall. Regrettably, + RedHat released this buggy iptables in RedHat 7.2. 

    + +

    I have built a + corrected 1.2.3 rpm which you can download here  and +I have also built an + iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    + +

    Update 11/9/2001: RedHat + has released an iptables-1.2.4 RPM of their own which you + can download from http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it + works fine.

    + +

    If you would like to patch iptables 1.2.3 yourself, + the patches are available for download. This patch + which corrects a problem with parsing of the --log-level + specification while this patch + corrects a problem in handling the  TOS target.

    + +

    To install one of the above patches:

    + +
      +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • + +
    +
    + +

    Problems with kernels >= 2.4.18 and +RedHat iptables

    + +
    +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 + may experience the following:

    + +
    + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    +
    + +

    The RedHat iptables RPM is compiled with debugging enabled but the + user-space debugging code was not updated to reflect recent changes in + the Netfilter 'mangle' table. You can correct the problem by + installing + this iptables RPM. If you are already running a 1.2.5 + version of iptables, you will need to specify the --oldpackage + option to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    + +

    Problems installing/upgrading + RPM on SuSE

    + +

    If you find that rpm complains about a conflict with kernel <= + 2.2 yet you have a 2.4 kernel installed, simply use the +"--nodeps" option to rpm.

    + +

    Installing: rpm -ivh --nodeps <shorewall rpm>

    + +

    Upgrading: rpm -Uvh --nodeps <shorewall rpm>

    + +

    Problems with iptables version 1.2.7 and + MULTIPORT=Yes

    + +

    The iptables 1.2.7 release of iptables has made an incompatible + change to the syntax used to specify multiport match rules; + as a consequence, if you install iptables 1.2.7 you must + be running Shorewall 1.3.7a or later or:

    + +
      +
    • set MULTIPORT=No + in /etc/shorewall/shorewall.conf; +or
      • +
    • if you + are running Shorewall 1.3.6 you may + install + this firewall script in /var/lib/shorewall/firewall + as described above.
      • + +
    +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

    - /etc/shorewall/nat entries of the following form -will result in Shorewall being unable to start:
    -
    - + + /etc/shorewall/nat entries of the following form + will result in Shorewall being unable to start:
    +
    + 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    192.0.2.22      eth0            192.168.9.22    yes                     yes
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - Error message is:
    - + Error message is:
    + 
    Setting up NAT...
    iptables: Invalid argument
    Terminated

    - The solution is to put "no" in the LOCAL column. -Kernel support for LOCAL=yes has never worked properly and 2.4.18-10 -has disabled it. The 2.4.19 kernel contains corrected support under -a new kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
    - -

    Last updated 5/29/2003 - Tom -Eastep

    - +
    + +

    Problems with RH Kernels after 2.4.20-9 and REJECT +(also applies to 2.4.21-RC1)

    + Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with tcp-reset" +is broken. The symptom most commonly seen is that REJECT rules act just like +DROP rules when dealing with TCP. A kernel patch and precompiled modules to +fix this problem are available at ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel.
    + +
    +

    Last updated 6/13/2003 - Tom Eastep +

    +

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

    -
    +

    diff --git a/STABLE/documentation/mailing_list.htm b/STABLE/documentation/mailing_list.htm index 120fb94b8..bbe056d61 100644 --- a/STABLE/documentation/mailing_list.htm +++ b/STABLE/documentation/mailing_list.htm @@ -1,144 +1,153 @@ - + - + - + - + Shorewall Mailing Lists - + - + - - - + + - + - + - - - + +
    + +

    +
    +
    + + + +
    +
    +

    Vexira Logo -

    - + - - -

     

    -     		- + + +

      (Razor Logo) +

    +     		+

    Shorewall Mailing Lists

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

    -
    -    
    -
    -
    - +

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

    - + read the Shorewall Support + Guide.
    + +

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

    - + let me know

    +

    Not able to Post Mail to shorewall.net?

    - +

    You can report such problems by sending mail to tmeastep at hotmail dot com.

    - +

    A Word about the SPAM Filters at Shorewall.net 

    - +

    Please note that the mail server at shorewall.net checks incoming mail:
    -

    - +

    +
      -
    1. against Spamassassin - (including Vipul's Razor).
      -
      2. -
    2. to ensure that the sender address is fully -qualified.
      3. -
    3. to verify that the sender's domain has an A -or MX record in DNS.
      4. -
    4. to ensure that the host name in the HELO/EHLO - command is a valid fully-qualified DNS name that resolves.
      5. -
    5. to ensure that the client system has a valid PTR record in DNS.
      -
      6. - +
    6. against Spamassassin (including Vipul's Razor).
      +
      7. +
    7. to ensure that the sender address is fully + qualified.
      8. +
    8. to verify that the sender's domain has an +A or MX record in DNS.
      9. +
    9. to ensure that the host name in the HELO/EHLO + command is a valid fully-qualified DNS name that resolves.
      10. +
    10. to ensure that the sending system has a valid PTR record in DNS.
      11. +
    - +This last point is important. If you run your +own outgoing mail server and it doesn't have a valid DNS PTR record, your +email won't reach the lists unless/until the postmaster notices that your +posts are being rejected. To avoid this problem, you should configure your +MTA to forward posts to shorewall.net through an MTA that does have +a valid PTR record (such as the one at your ISP).
    +

    Please post in plain text

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

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

    - +

    +

    Other Mail Delivery Problems

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

    Mailing Lists Archive Search

    - +
    - -

    Match: + +

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

    - - + +

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

    - +
    +

    Shorewall CA Certificate

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

    Shorewall Users Mailing List

    - +

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

    - + to get answers to questions and to report problems. Information + of general interest to the Shorewall user community is also +posted to this list.

    +

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

    - +

    To subscribe to the mailing list:
    -

    - +

    + - +

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

    - +

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

    - +

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

    - +

    Shorewall Announce Mailing List

    - +

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

    - + Shorewall community. To subscribe:
    +

    +

    - + - +


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

    - +

    Shorewall Development Mailing List

    - +

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

    - + the exchange of ideas about the future of Shorewall and for + coordinating ongoing Shorewall Development.

    +

    To subscribe to the mailing list:
    -

    - +

    + - +

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

    - +

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

    - +

    How to Unsubscribe from one of - the Mailing Lists

    - + the Mailing Lists +

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

    - + from Mailman-managed lists although Mailman 2.1 has attempted + to make this less confusing. To unsubscribe:

    +
      -
    • +
    • +

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

      -
      • -
    • + to the list.

      +
      • +
    • +

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

      -
      • -
    • + " To unsubscribe from <list name>, get + a password reminder, or change your subscription options enter + your subscription email address:". Enter your email address + in the box and click on the "Unsubscribe or edit options" + button.

      +
      • +
    • +

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

      -
      • - + +
    - -
    + +

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

    - +

    Check out these instructions

    - -

    Last updated 5/29/2003 - Last updated 6/14/2003 - Tom Eastep

    - +

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

    -
    -
    -
    +

    diff --git a/STABLE/documentation/myfiles.htm b/STABLE/documentation/myfiles.htm index 53c7516ce..ad126154b 100644 --- a/STABLE/documentation/myfiles.htm +++ b/STABLE/documentation/myfiles.htm @@ -1,229 +1,238 @@ - + My Shorewall Configuration - + - + - + - + - - - + + - - - + + + +
    +
    +

    About My Network

    -
    - +
    - +

    My Current Network

    - -
    -

    Warning 1: I - use a combination of Static NAT and Proxy ARP, neither of which are relevant - to a simple configuration with a single public IP address. - If you have just a single public IP address, most of what you see here -won't apply to your setup so beware of copying parts of this configuration -and expecting them to work for you. What you copy may or may not work in -your configuration.
    -

    - -

    Warning 2: My - configuration uses features introduced in Shorewall version 1.4.1.
    -

    - -

    I have DSL service and have 5 static IP addresses (206.124.146.176-180). - My DSL "modem" (Fujitsu Speedport) - is connected to eth0. I have a local network connected to eth2 (subnet - 192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). 

    - + +
    +

    Warning 1: I + use a combination of Static NAT and Proxy ARP, neither of which are relevant + to a simple configuration with a single public IP address. + If you have just a single public IP address, most of what you see here + won't apply to your setup so beware of copying parts of this configuration + and expecting them to work for you. What you copy may or may not work in + your configuration.
    +

    + +

    Warning 2: My + configuration uses features introduced in Shorewall version 1.4.4b.
    +

    + +

    I have DSL service and have 5 static IP addresses (206.124.146.176-180). + My DSL "modem" (Fujitsu Speedport) + is connected to eth0. I have a local network connected to eth2 (subnet + 192.168.1.0/24), a DMZ connected to eth1 (192.168.2.0/24) and a Wireless + network connected to eth3 (192.168.3.0/24).

    +

    I use:
    -

    - +

    +
      -
    • Static NAT for Ursa (my XP System) - Internal address - 192.168.1.5 and external address 206.124.146.178.
      • -
    • Static NAT for Wookie (my Linux System). Internal address - 192.168.1.3 and external address 206.124.146.179.
      • -
    • SNAT through the primary gateway address (206.124.146.176) - for  my Wife's system (Tarry) and our  laptop (Tipper) which connects -through the Wireless Access Point (wap) via a Wireless Bridge (bridge).
      -
      -Note:       While the distance between the WAP and where I usually use the -laptop isn't very far (25 feet or so), using a WAC11 (CardBus wireless card) -has proved very unsatisfactory (lots of lost connections). By replacing the -WAC11 with the WET11 wireless bridge, I have virtually eliminated these problems -(I was also able to eliminate them by hanging a piece of aluminum foil on -the family room wall but Tarry rejected that as a permanent solution :-).
      • - +
    • Static NAT for Ursa (my XP System) - Internal address + 192.168.1.5 and external address 206.124.146.178.
      • +
    • Static NAT for Wookie (my Linux System). Internal + address 192.168.1.3 and external address 206.124.146.179.
      • +
    • Static NAT for EastepLaptop (My work system). Internal address +192.168.1.7 and external address 206.124.146.180.
      +
      • +
    • SNAT through the primary gateway address (206.124.146.176) + for  my Wife's system (Tarry) and our  laptop (Tipper) which connects + through the Wireless Access Point (wap) via a Wireless Bridge (bridge). +
      +
      + Note:       While the distance between the WAP and where I usually use +the laptop isn't very far (25 feet or so), using a WAC11 (CardBus wireless +card) has proved very unsatisfactory (lots of lost connections). By replacing +the WAC11 with the WET11 wireless bridge, I have virtually eliminated these +problems (Being an old radio tinkerer (K7JPV), I was also able to eliminate +the disconnects by hanging a piece of aluminum foil on the family room wall. +Needless to say, my wife Tarry rejected that as a permanent solution :-).
      • +
    - -

    The firewall runs on a 256MB PII/233 with RH8.0.

    - -

    Wookie runs Samba and acts as the a WINS server.  Wookie is in its - own 'whitelist' zone called 'me'.

    - -

    My work laptop (easteplaptop) is connected to eth3 using a cross-over -cable. It runs its own Sygate -firewall software and is managed by Proxy ARP. It connects to the local -network through a PPTP server. running on Ursa.

    - -

    The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP - server (Pure-ftpd). The system also runs fetchmail to fetch our email - from our old and current ISPs. That server is managed through Proxy -ARP.

    - -

    The firewall system itself runs a DHCP server that serves the local - network.

    - -

    All administration and publishing is done using ssh/scp. I have X installed - on both the firewall and the server but no X server or desktop is installed. - X applications tunnel through SSH to XWin.exe running on Ursa.

    - + +

    The firewall runs on a 256MB PII/233 with RH9.0.

    + +

    Wookie and the Firewall both run Samba and the Firewall acts as the +a WINS server.
    +

    + +

    Wookie is in its own 'whitelist' zone called 'me' which is embedded +in the local zone.

    + +

    The wireless network connects to eth3 via a LinkSys WAP11.  In additional + to using the rather weak WEP 40-bit encryption (64-bit with the 24-bit prefix), + I use MAC verification. This is still a + weak combination and if I lived near a wireless "hot spot", I would probably + add IPSEC or something similar to my WiFi->local connections.
    +

    + +

    The single system in the DMZ (address 206.124.146.177) runs postfix, + Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an +FTP server (Pure-ftpd). The system also runs fetchmail to fetch our +email from our old and current ISPs. That server is managed through +Proxy ARP.

    + +

    The firewall system itself runs a DHCP server that serves the local + network. It also runs Postfix which is configured as a Virus and + Spam filter with all incoming mail then being forwarded to the MTA in the + DMZ.

    + +

    All administration and publishing is done using ssh/scp. I have X installed + on the firewall but no X server or desktop is installed. X applications +tunnel through SSH to XWin.exe running on Ursa. The server does have a desktop +environment installed and that desktop environment is available via XDMCP +from the local zone. For the most part though, X tunneled through SSH is +used for server administration and the server runs at run level 3 (multi-user +console mode on RedHat).

    +

    I run an SNMP server on my firewall to serve MRTG running - in the DMZ.

    - + href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG running + in the DMZ.

    +

    -

    - + src="images/network.png" width="764" height="846" + alt="(My network layout)"> +

    +

     

    - -

    The ethernet interface in the Server is configured with IP address -206.124.146.177, netmask 255.255.255.0. The server's default gateway is - 206.124.146.254 (Router at my ISP. This is the same default -gateway used by the firewall itself). On the firewall, - Shorewall automatically adds a host route to - 206.124.146.177 through eth1 (192.168.2.1) because of - the entry in /etc/shorewall/proxyarp (see below).

    - -

    A similar setup is used on eth3 (192.168.3.1) which interfaces -to my laptop (206.124.146.180).
    -

    - -

    Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior - access.
    -

    - + +

    The ethernet interface in the Server is configured with IP address + 206.124.146.177, netmask 255.255.255.0. The server's default gateway + is 206.124.146.254 (Router at my ISP. This is the same default + gateway used by the firewall itself). On the firewall, + Shorewall automatically adds a host route to + 206.124.146.177 through eth1 (192.168.2.1) because of + the entry in /etc/shorewall/proxyarp (see below).

    + +

    Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior + access.
    +

    +

    -
    - +
    +

    Shorewall.conf

    - -
    - 
    SHARED_DIR=/usr/share/shorewall
    LOGFILE=/var/log/firewall
    LOGRATE=
    LOGBURST=
    LOGUNCLEAN=info
    BLACKLIST_LOGLEVEL=
    LOGNEWNOTSYN=
    MACLIST_LOG_LEVEL=$LOG
    TCP_FLAGS_LOG_LEVEL=$LOG
    RFC1918_LOG_LEVEL=$LOG
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
    SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall
    MODULESDIR=
    FW=fw
    NAT_ENABLED=Yes
    MANGLE_ENABLED=Yes
    IP_FORWARDING=On
    ADD_IP_ALIASES=Yes
    ADD_SNAT_ALIASES=Yes
    TC_ENABLED=Yes
    CLEAR_TC=No
    MARK_IN_FORWARD_CHAIN=No
    CLAMPMSS=Yes
    ROUTE_FILTER=No
    NAT_BEFORE_RULES=No
    MULTIPORT=Yes
    DETECT_DNAT_IPADDRS=Yes
    MUTEX_TIMEOUT=60
    NEWNOTSYN=Yes
    BLACKLIST_DISPOSITION=DROP
    MACLIST_DISPOSITION=REJECT
    TCP_FLAGS_DISPOSITION=DROP
    + +
    + 
    LOGFILE=/var/log/messages
    LOGRATE=
    LOGBURST=
    LOGUNCLEAN=$LOG
    BLACKLIST_LOGLEVEL=
    LOGNEWNOTSYN=
    MACLIST_LOG_LEVEL=$LOG
    TCP_FLAGS_LOG_LEVEL=$LOG
    RFC1918_LOG_LEVEL=$LOG
    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
    SUBSYSLOCK=/var/lock/subsys/shorewall
    STATEDIR=/var/state/shorewall
    MODULESDIR=
    FW=fw
    NAT_ENABLED=Yes
    MANGLE_ENABLED=Yes
    IP_FORWARDING=On
    ADD_IP_ALIASES=Yes
    ADD_SNAT_ALIASES=Yes
    TC_ENABLED=Yes
    CLEAR_TC=No
    MARK_IN_FORWARD_CHAIN=No
    CLAMPMSS=Yes
    ROUTE_FILTER=No
    NAT_BEFORE_RULES=No
    MULTIPORT=Yes
    DETECT_DNAT_IPADDRS=Yes
    MUTEX_TIMEOUT=60
    NEWNOTSYN=Yes
    BLACKLIST_DISPOSITION=DROP
    MACLIST_DISPOSITION=REJECT
    TCP_FLAGS_DISPOSITION=DROP
    SHARED_DIR=/usr/share/shorewall
    - -

    - +

    Params File (Edited):

    - -
    + +
    MIRRORS=<list of shorewall mirror ip addresses>
    NTPSERVERS=<list of the NTP servers I sync with>
-TEXAS=<ip address of gateway in Dallas>
    LOG=ULOG
    -
    - +TEXAS=<ip address of gateway in Dallas>
    LOG=info
    +
    +

    Zones File

    - -
    - 
    #ZONE	DISPLAY		COMMENTS
    net     Internet        Internet
    me      Wookie          My Linux Workstation
    dmz     DMZ             Demilitarized zone
    loc     Local           Local networks
    tx      Texas           Peer Network in Dallas
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE                     
+  
    #ZONE	DISPLAY		COMMENTS
    net     Internet        Internet
    WiFi    Wireless        Wireless Network on eth3
    me      Wookie          My Linux Workstation
    dmz     DMZ             Demilitarized zone
    loc     Local           Local networks
    tx      Texas           Peer Network in Dallas
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    
-
    - +
    +

    Interfaces File:

    - -
    -

    This is set up so that I can start the firewall before bringing up my -Ethernet interfaces.

    -
    - -
    - 
    #ZONE	INERFACE	BROADCAST	OPTIONS
    net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
    loc     eth2            192.168.1.255   dhcp,maclist
    dmz     eth1            192.168.2.255
    net     eth3            206.124.146.255
    -       texas           192.168.9.255
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE                      
+  
     This is set up so that I can start the firewall before bringing up
+my Ethernet  interfaces. 
    
+
    + +
    + 
    #ZONE	INERFACE	BROADCAST	OPTIONS
    net     eth0            206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
    loc     eth2            192.168.1.255   dhcp
    dmz     eth1            192.168.2.255
    WiFi    eth3            192.168.3.255   dhcp,maclist
    -       texas           192.168.9.255
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Hosts File:

    - -
    + +
    #ZONE		HOST(S)			OPTIONS
    me              eth2:192.168.1.3
    tx              texas:192.168.8.0/22
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - +
    +

    Routestopped File:

    - -
    - 
    #INTERFACQ	HOST(S)
    eth1            206.124.146.177
    eth2            -
    eth3            206.124.146.180
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE                     
+  
    #INTERFACQ	HOST(S)
    eth1            206.124.146.177
    eth2            -
    eth3            192.168.3.8
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE	
    
-
    - +
    +

    Policy File:

    - -
    - 
    #SOURCE		DESTINATION	POLICY		LOG LEVEL	BURST:LIMIT
    me		loc		NONE
    loc		me		NONE
    me              all             ACCEPT
    tx              me              ACCEPT
    all             me              CONTINUE        -               2/sec:5
    loc             net             ACCEPT
    $FW             loc             ACCEPT
    $FW             tx              ACCEPT
    loc             tx              ACCEPT
    loc             fw              REJECT          $LOG
    net             all             DROP            $LOG            10/sec:40
    all             all             REJECT          $LOG
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    -
    - + +
    + 
    #SOURCE		DESTINATION	POLICY		LOG LEVEL	BURST:LIMIT
    me              loc             NONE
    me              all             ACCEPT
    tx              me              ACCEPT
    WiFi            loc             ACCEPT
    loc             WiFi            ACCEPT
    loc             me              NONE
    all             me              CONTINUE        -               2/sec:5
    loc             net             ACCEPT
    $FW             loc             ACCEPT
    $FW             tx              ACCEPT
    loc             tx              ACCEPT
    loc             fw              REJECT          $LOG
    WiFi            net             ACCEPT
    net             all             DROP            $LOG            10/sec:40
    all             all             REJECT          $LOG
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
    +
    +

    Masq File:

    - -
    -

    Although most of our internal systems use static NAT, my wife's system - (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors -with laptops. Also, I masquerade wookie to the peer subnet in Texas.

    -
    - -
    - 
    #INTERFACE              SUBNET          ADDRESS
    eth0:0.0.0.0/0          eth2            206.124.146.176
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    - + +
    +

    Although most of our internal systems use static NAT, my wife's system + (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors + with laptops. Also, I masquerade systems connected through the wireless + network.

    +
    + +
    + 
    #INTERFACE              SUBNET          ADDRESS
    eth0                    eth2            206.124.146.176
    eth0                    eth3            206.124.146.176
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    +
    +

    NAT File:

    - -
    - 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    206.124.146.178 eth0:0          192.168.1.5     No                      No
    206.124.146.179 eth0:1          192.168.1.3     No                      No
    192.168.1.193   eth2:0          206.124.146.177 No                      No
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    -
    - + +
    + 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    206.124.146.178 eth0:0          192.168.1.5     No                      No
    206.124.146.179 eth0:1          192.168.1.3     No                      No
    206.124.146.180 eth0:2          192.168.1.7     No                      No
    192.168.1.193   eth2:0          206.124.146.177 No                      No
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE\
    +
    +

    Proxy ARP File:

    - -
    - 
    #ADDRESS                INTERFACE       EXTERNAL        HAVEROUTE
    206.124.146.177         eth1            eth0            No
    206.124.146.180         eth3            eth0            No
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE                     
+  
    #ADDRESS                INTERFACE       EXTERNAL        HAVEROUTE
    206.124.146.177         eth1            eth0            No
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE     	
    
-
    - + +

    Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):

    - -
    - 
    #TYPE			ZONE    GATEWAY         GATEWAY ZONE    PORT
    gre                     net     $TEXAS
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - -

    Common File:

    - -
    - 
    . /etc/shorewall/common.def
    run_iptables -A common -p tcp --dport auth -j REJECT
    -
    - + +
    + 
    #TYPE			ZONE    GATEWAY         GATEWAY ZONE    PORT
    gre                     net     $TEXAS
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +
    + +

    +

    Rules File (The shell variables are set in /etc/shorewall/params):

    - -
    - 
    ################################################################################################################################################################
    #RESULT         CLIENT(S)                       SERVER(S)               PROTO   PORT(S)                                 CLIENT          ORIGINAL DEST:SNAT
    ################################################################################################################################################################
    # Local Network to Internet - Reject attempts by Trojans to call home
    #
    REJECT:$LOG     loc                             net                     tcp     6667
    #
    # Stop NETBIOS crap since our policy is ACCEPT
    #
    REJECT          loc                             net                     tcp     137,445
    REJECT          loc                             net                     udp     137:139
    LOG:$LOG        loc                             net                     tcp     137:139
    ################################################################################################################################################################
    # Local Network to Firewall
    #
    ACCEPT          loc                             fw                      tcp     ssh,time,10000
    ACCEPT          loc                             fw                      udp     snmp
    ACCEPT          loc                             fw                      udp     ntp
    ################################################################################################################################################################
    # Local Network to DMZ (10027 is our SMTP backdoor that bypasses virus/spam filtering)
    #
    ACCEPT          loc                             dmz                     udp     domain
    ACCEPT          loc                             dmz                     tcp     smtp,domain,ssh,imap,https,imaps,cvspserver,www,ftp,10027,10000,8080    -
    ################################################################################################################################################################
    # Internet to DMZ
    #
    ACCEPT          net                             dmz                     tcp     www,smtp,ftp,imaps,domain,cvspserver,https,imap -
    ACCEPT          net                             dmz                     udp     domain
    ACCEPT          net:$MIRRORS                    dmz                     tcp     rsync
    ACCEPT:$LOG     net                             dmz                     tcp     32768:61000                             20
    DROP            net                             dmz                     tcp     1433
    ################################################################################################################################################################
    #
    # Net to Local
    #
    # My laptop isn't NATTED when in its docking station. To allow access to the local lan, I need a VPN to Ursa which is enabled by the following "half"-rules.
    #
    DNAT-           net                             loc:192.168.1.5         tcp     1723                                    -               206.124.146.178
    DNAT-           net                             loc:192.168.1.5         gre     -                                       -               206.124.146.178
    #
    # When I'm "on the road", the following two rules allow me VPN access back home.
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     1723
    ACCEPT          net                             loc:192.168.1.5         gre
    #
    # ICQ to Ursa
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     4000:4100
    ################################################################################################################################################################
    # Net to me
    #
    ACCEPT          net                             me:192.168.1.3          tcp     4000:4100
    ################################################################################################################################################################
    # DMZ to Internet
    #
    ACCEPT          dmz                             net                     tcp     smtp,domain,www,https,whois,echo,2702,21,2703,ssh
    ACCEPT          dmz                             net                     udp     domain
    ACCEPT          dmz                             net:206.124.128.8       tcp     pop3
    ACCEPT          dmz                             net:66.216.26.115       tcp     pop3
    #
    # Something is wrong with the FTP connection tracking code or there is some client out there
    # that is sending a PORT command which that code doesn't understand. Either way,
    # the following works around the problem.
    #
    ACCEPT:$LOG     dmz                             net                     tcp     1024:                                   20
    ################################################################################################################################################################
    # DMZ to Firewall -- ntp & snmp
    #
    ACCEPT          dmz                             fw                      udp     ntp                                     ntp
    ACCEPT          dmz                             fw                      tcp     snmp
    ACCEPT          dmz                             fw                      udp     snmp
    ################################################################################################################################################################
    #
    # DMZ to Local Network
    #
    ACCEPT          dmz                             loc                     tcp     smtp
    ################################################################################################################################################################
    #
    # DMZ to Me -- NFS
    #
    ACCEPT          dmz                             me                      tcp     111
    ACCEPT          dmz                             me                      udp     111
    ACCEPT          dmz                             me                      udp     2049
    ACCEPT          dmz                             me                      udp     32700:
    ################################################################################################################################################################
    # Internet to Firewall
    #
    ACCEPT          net:eth3:206.124.146.180        fw                      udp     ntp                                     ntp
    REJECT          net                             fw                      tcp     www
    DROP            net                             fw                      tcp     1433
    DROP            net:eth3:!206.124.146.180       fw                      all
    ################################################################################################################################################################
    # Firewall to Internet
    #
    ACCEPT          fw                              net:$NTPSERVERS         udp     ntp                                     ntp
    ACCEPT          fw                              net                     udp     domain
    ACCEPT          fw                              net                     tcp     domain,www,https,ssh,1723,whois,1863
    ACCEPT          fw                              net                     udp     33435:33535
    ACCEPT          fw                              net                     icmp    8
    ################################################################################################################################################################
    # Firewall to DMZ
    #
    ACCEPT          fw                              dmz                     tcp     www,ftp,ssh,smtp
    ACCEPT          fw                              dmz                     udp     domain
    ACCEPT          fw                              dmz                     icmp    8
    REJECT          fw                              dmz                     udp     137:139
    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    -
    - + +
    + 
    ################################################################################################################################################################
    #RESULT         CLIENT(S)                       SERVER(S)               PROTO   PORT(S)                                 CLIENT          ORIGINAL DEST:SNAT
    ################################################################################################################################################################
    # Local Network to Internet - Reject attempts by Trojans to call home
    #
    REJECT:$LOG     loc                             net                     tcp     6667
    #
    # Stop NETBIOS crap since our policy is ACCEPT
    #
    REJECT          loc                             net                     tcp     137,445
    REJECT          loc                             net                     udp     137:139
    ################################################################################################################################################################
    # Local Network to Firewall
    #
    DROP            loc:!192.168.1.0/24             fw
    ACCEPT          loc                             fw                      tcp     ssh,time,10000,smtp,swat,137,139,445
    ACCEPT          loc                             fw                      udp     snmp,ntp,445
    ACCEPT          loc                             fw                      udp     137:139
    ACCEPT          loc                             fw                      udp     1024:                                   137
    ################################################################################################################################################################
    # Local Network to DMZ
    #
    ACCEPT          loc                             dmz                     udp     domain,xdmcp
    ACCEPT          loc                             dmz                     tcp     www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,pop3     -
    ################################################################################################################################################################
    # Internet to DMZ
    #
    ACCEPT          net                             dmz                     tcp     www,ftp,imaps,domain,cvspserver,https   -
    ACCEPT          net                             dmz                     udp     domain
    ACCEPT          net:$MIRRORS                    dmz                     tcp     rsync
    ACCEPT:$LOG     net                             dmz                     tcp     32768:61000                             20
    DROP            net                             dmz                     tcp     1433
    ################################################################################################################################################################
    #
    # Net to Local
    #
    # When I'm "on the road", the following two rules allow me VPN access back home.
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     1723
    ACCEPT          net                             loc:192.168.1.5         gre
    #
    # ICQ
    #
    ACCEPT          net                             loc:192.168.1.5         tcp     4000:4100
    #
    # Real Audio
    #
    ACCEPT          net                             loc:192.168.1.5         udp     6790
    ################################################################################################################################################################
    # Net to me
    #
    ACCEPT          net                             loc:192.168.1.3         tcp     4000:4100
    ################################################################################################################################################################
    # DMZ to Internet
    #
    ACCEPT          dmz                             net                     tcp     smtp,domain,www,https,whois,echo,2702,21,2703,ssh
    ACCEPT          dmz                             net                     udp     domain
    #ACCEPT         dmz                             net:$POPSERVERS         tcp     pop3
    #ACCEPT         dmz                             net:206.191.151.2       tcp     pop3
    #ACCEPT         dmz                             net:66.216.26.115       tcp     pop3
    #
    # Something is wrong with the FTP connection tracking code or there is some client out there
    # that is sending a PORT command which that code doesn't understand. Either way,
    # the following works around the problem.
    #
    ACCEPT:$LOG     dmz                             net                     tcp     1024:                                   20
    ################################################################################################################################################################
    # DMZ to Firewall -- ntp & snmp, Silently reject Auth
    #
    ACCEPT          dmz                             fw                      udp     ntp                                     ntp
    ACCEPT          dmz                             fw                      tcp     snmp,ssh
    ACCEPT          dmz                             fw                      udp     snmp
    REJECT          dmz                             fw                      tcp     auth
    ################################################################################################################################################################
    #
    # DMZ to Local Network
    #
    ACCEPT          dmz                             loc                     tcp     smtp,6001:6010
    ################################################################################################################################################################
    #
    # DMZ to Me -- NFS
    #
    ACCEPT          dmz                             me                      tcp     111
    ACCEPT          dmz                             me                      udp     111
    ACCEPT          dmz                             me                      udp     2049
    ACCEPT          dmz                             me                      udp     32700:
    ################################################################################################################################################################
    # Internet to Firewall
    #
    REDIRECT-       net                             25                      tcp     smtp                                    -               206.124.146.177
    ACCEPT          net                             fw                      tcp     smtp
    REJECT          net                             fw                      tcp     www
    DROP            net                             fw                      tcp     1433
    ################################################################################################################################################################
    # WiFi to Firewall (SMB and NTP)
    #
    ACCEPT          WiFi                            fw                      tcp     ssh,137,139,445
    ACCEPT          WiFi                            fw                      udp     137:139,445
    ACCEPT          WiFi                            fw                      udp     1024:                                   137
    ACCEPT          WiFi                            fw                      udp     ntp                                     ntp
    ################################################################################################################################################################
    # Firewall to WiFi (SMB)
    #
    ACCEPT          fw                              WiFi                    tcp     137,139,445
    ACCEPT          fw                              WiFi                    udp     137:139,445
    ACCEPT          fw                              WiFi                    udp     1024:                                   137
    ###############################################################################################################################################################
    # WiFi to DMZ
    #
    DNAT-           WiFi                            dmz:206.124.146.177     all     -                                       -               192.168.1.193
    ACCEPT          WiFi                            dmz                     tcp     smtp,www,ftp,imaps,domain,https,ssh     -
    ACCEPT          WiFi                            dmz                     udp     domain
    ################################################################################################################################################################
    # Firewall to Internet
    #
    ACCEPT          fw                              net:$NTPSERVERS         udp     ntp                                     ntp
    ACCEPT          fw                              net:$POPSERVERS         tcp     pop3
    ACCEPT          fw                              net                     udp     domain
    ACCEPT          fw                              net                     tcp     domain,www,https,ssh,1723,whois,1863,smtp,ftp,2702,2703,7
    ACCEPT          fw                              net                     udp     33435:33535
    ACCEPT          fw                              net                     icmp    8
    ################################################################################################################################################################
    # Firewall to DMZ
    #
    ACCEPT          fw                              dmz                     tcp     www,ftp,ssh,smtp
    ACCEPT          fw                              dmz                     udp     domain
    ACCEPT          fw                              dmz                     icmp    8
    REJECT          fw                              dmz                     udp     137:139

    #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
    +
    +

    Tom Eastep

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

    diff --git a/STABLE/documentation/seattlefirewall_index.htm b/STABLE/documentation/seattlefirewall_index.htm index 4ebd9e654..9dcad3225 100644 --- a/STABLE/documentation/seattlefirewall_index.htm +++ b/STABLE/documentation/seattlefirewall_index.htm @@ -2,119 +2,102 @@ - + Shoreline Firewall (Shorewall) 1.4 - + + - + - + - + - + + + - - -
    - - - -

    Shorewall 1.4 "iptables made easy"
    -
    - - -

    -
    - - - - -

    - - - - - + +
    + + - -

    Shorwall Logo - - Shorewall 1.4 "iptables made easy"

    +     		+

    (Shorewall Logo) -

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

    What is it?

    - -

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

    + +

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

    - -

    This program is free software; you can redistribute it and/or modify - it - 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

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    @@ -123,303 +106,360 @@ GNU General Public License as published by the Free Software - +

    Running Shorewall on Mandrake with a two-interface setup?

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

    Getting Started with Shorewall

    - New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
    + If so, almost NOTHING on this site will apply directly + to your setup. If you want to use the documentation that you find here, + it is best if you uninstall what you have and install a setup that +matches the documentation on this site. See the Two-interface QuickStart Guide for details.
    - + +

    Getting Started with Shorewall

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

    News

    - -

    5/29/2003 - Shorewall-1.4.4b (New) -

    + +

    6/17/2003 - Shorewall-1.4.5 (New) +

    -

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

    Problems Corrected:

    -

    5/27/2003 - Shorewall-1.4.4a (New) -

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

    5/23/2003 - Shorewall-1.4.4 (New) -

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

    5/20/2003 - Shorewall-1.4.3a
    -

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

    5/18/2003 - Shorewall 1.4.3
    -

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

      New Features:
      +

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

      5/10/2003 - Shorewall Mirror in Asia
      -

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

      5/8/2003 - Shorewall Mirror in Chile  

      - - -

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

      - - -

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

      +

      6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 + (New) +

      + +

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

      + +

      6/8/2003 - Updated Samples

      + +

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

      + +

      5/29/2003 - Shorewall-1.4.4b

      + +

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

      + +

      5/27/2003 - Shorewall-1.4.4a

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

      5/23/2003 - Shorewall-1.4.4 +

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

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

        +
      + +

      5/20/2003 - Shorewall-1.4.3a
      +

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

      5/18/2003 - Shorewall 1.4.3
      +

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

      5/10/2003 - Shorewall Mirror in Asia
      +

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

      5/8/2003 - Shorewall Mirror in Chile

      -

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

      +

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

      + + +

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

      - -

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

      - - - -

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

      + +

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

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

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

      - -

      - -
      - + +

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

      + + + +

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

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

      More News

      - +

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

      +

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

      Donations

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

    Quick Search
    - -

    - +

    +
    - + +

    Extended Search

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

    + hspace="10" alt="(Starlight Logo)"> -

    +

    - -

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

    + +


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

    -
    - -

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

    Updated 6/17/2003 - Tom Eastep +

    diff --git a/STABLE/documentation/shoreline.htm b/STABLE/documentation/shoreline.htm index 08ec79f06..a23d64d03 100644 --- a/STABLE/documentation/shoreline.htm +++ b/STABLE/documentation/shoreline.htm @@ -1,144 +1,135 @@ - + About the Shorewall Author - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Tom Eastep

    -
    - -

    Tom on the PCT - 1991 -

    - -

    Tarry & Tom -- August 2002
    -
    -

    - + +

    Tom - June 2003 +

    + +

    Tom -- June 2003
    +
    +

    + - -

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

    - -

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

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

    + +

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

    - +

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

    - + href="http://www.cityofshoreline.com">Shoreline, Washington where +I live with my wife Tarry. 

    +

    Our current home network consists of:

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

    For more about our network see my Shorewall Configuration.

    - +

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

    - +

    - - + - - + Powered by Mandrake - Protected by Shorewall - (Opera Logo) -     -

    - -

    Last updated 5/8/2003 -

    + +

    Last updated 6/15/2003 - Tom Eastep

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

    diff --git a/STABLE/documentation/shorewall_mirrors.htm b/STABLE/documentation/shorewall_mirrors.htm index 4ec6a248f..396d6d401 100644 --- a/STABLE/documentation/shorewall_mirrors.htm +++ b/STABLE/documentation/shorewall_mirrors.htm @@ -1,90 +1,96 @@ - + - + - + - + Shorewall Mirrors - + - - - + + - - - + + + +
    +

    Shorewall Mirrors

    -
    - -

    Remember that updates to the mirrors are often delayed - for 6-12 hours after an update to the primary rsync site. For HTML content, -the main web site (http://shorewall.sf.net) -is updated at the same time as the rsync site.

    - + +

    Remember that updates to the mirrors are often delayed + for 6-12 hours after an update to the primary rsync site. For HTML content, + the main web site (http://shorewall.sf.net) + is updated at the same time as the rsync site.

    +

    The main Shorewall Web Site is http://shorewall.sf.net - and is located in California, USA. It is mirrored at:

    - + href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net + and is located in California, USA. It is mirrored at:

    + - +

    The rsync site is mirrored via FTP at:

    - + - Search results and the mailing list archives are always fetched from the -site in Washington State.
    - -

    Last Updated 5/8/2003 - + +

    Last Updated 6/5/2003 - Tom Eastep

    - +

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

    +
    +

    +



    diff --git a/STABLE/documentation/shorewall_setup_guide.htm b/STABLE/documentation/shorewall_setup_guide.htm index a4e291505..08fb15740 100644 --- a/STABLE/documentation/shorewall_setup_guide.htm +++ b/STABLE/documentation/shorewall_setup_guide.htm @@ -1,431 +1,211 @@ - + - + - + - + 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 (ARP)
    - 4.5 RFC 1918

    -
    - -

    5.0 Setting up your Network

    - -
    -

    5.1 Routed
    - 5.2 Non-routed

    - -
    -

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

    + 4.2 Subnets
    + 4.3 Routing
    + 4.4 Address Resolution Protocol (ARP)
    + 4.5 RFC 1918

    - + +

    5.0 Setting up your Network

    + +
    +

    5.1 Routed
    + 5.2 Non-routed

    + +
    +

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

    +
    +

    5.3 Rules
    - 5.4 Odds and Ends

    -
    - + 5.4 Odds and Ends

    +
    +

    6.0 DNS
    - 7.0 Starting and Stopping the Firewall

    - + 7.0 Starting and Stopping the +Firewall

    +

    1.0 Introduction

    - +

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

    - + the range of possible applications is so broad, the Guide will give + you general guidelines and will point you to other resources as necessary.

    +

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

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

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

    - + .

    +

    -     If you edit your configuration files on a Windows system, -you must save them as Unix files if your editor supports that option +     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.

    - + Similarly, if you copy a configuration file from your Windows hard drive + to a floppy disk, you must run dos2unix against the copy before using + it with Shorewall.

    + - +

    2.0 Shorewall Concepts

    - +

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

    - +

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

    - + file on your system -- each file contains detailed configuration instructions + and some contain default entries.

    +

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

    - + set of zones. In the default installation, the following zone + names are used:

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

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

    - + file.

    +

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

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

    - + to zone names. Zones are entirely what YOU make of them. That means + that you should not expect Shorewall to do something special "because + this is the internet zone" or "because that is the DMZ".

    +

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

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

    +

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

    - + in terms of zones.

    + - +

    Shorewall is built on top of the Netfilter - kernel facility. Netfilter implements a connection - tracking function that allows what is often referred to as stateful - inspection of packets. This stateful property allows firewall rules - to be defined in terms of connections rather than in terms of - packets. With Shorewall, you:

    - + tracking function that allows what is often referred to as stateful + inspection of packets. This stateful property allows firewall rules + to be defined in terms of connections rather than in terms +of packets. With Shorewall, you:

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

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

    - + from zone A to zone B    . It rather means that you can + have a proxy running on the firewall that accepts a connection from + zone A and then establishes its own separate connection from the firewall + to zone B.

    +

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

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

    +

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

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

    The above policy will:

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

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

    - -

    3.0 Network Interfaces

    - -

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

    - -

    In this diagram:

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

    -

    - -

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

    - -

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

    - -

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

    - -

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

    - -

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

    - -

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

    - -

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

    - -
      -
    • -

      The external interface is eth0.

      -
      • -
    • -

      The Local interface is eth1.

      -
      • -
    • -

      The DMZ interface is eth2.

      -
      • - -
    - -

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

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

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

    - -

    Example:

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

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

    -
    - -
    -
    +
    - + @@ -434,2110 +214,2400 @@ many times as necessary.

    - + - - + + + + + + + + + + + + + + + +
    Source Zone Destination Zone Policy
    loclocnet ACCEPT    
    netallDROPinfo 
    allallREJECTinfo 
    -
    - + +

    The above policy will:

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

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

    + +

    3.0 Network Interfaces

    + +

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

    + +

    In this diagram:

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

    +

    + +

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

    + +

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

    + +

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

    + +

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

    + +

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

    + +

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

    + +

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

    + +
      +
    • +

      The external interface is eth0.

      +
      • +
    • +

      The Local interface is eth1.

      +
      • +
    • +

      The DMZ interface is eth2.

      +
      • + +
    + +

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

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

    -     You may define more complicated zones using the + +

    Example:

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

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

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

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

    - + cases, that isn't necessary.

    +

    4.0 Addressing, Subnets and Routing

    - +

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

    - +

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

    - + you may go to the next section.

    +

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

    - +

    4.1 IP Addresses

    - +

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

    - -
    + The notation w.x.y.z refers to an address where the high-order byte has + value "w", the next byte has value "x", etc. If we take the address 192.0.2.14 + and express it in hexadecimal, we get:

    + +

    C0.00.02.0E

    -
    - +
    +

    or looking at it as a 32-bit integer

    - -
    + +

    C000020E

    -
    - +
    +

    4.2 Subnets

    - +

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

    - -
    + network" and "Class C network". In the early days of IP, networks only + came in three sizes (there were also Class D networks but they were +used differently):

    + +

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

    - +

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

    - +

    Class C - netmask 255.255.255.0, size = 256

    -
    - +
    +

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

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

    +

    As the internet grew, it became clear that such a gross partitioning -of the 32-bit address space was going to be very limiting (early on, large -corporations and universities were assigned their own class A 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.

    - + 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 contiguous set of IP addresses such that:

    - + a contiguous set of IP addresses such that:

    +
      -
    1. +

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

      -
      3. -
    3. +
      4. +

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

      -
      5. -
    5. + size.

      +
      6. +

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

      -
      7. -
    7. + to as the subnet address.

      +
      8. +

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

      -
      9. - + broadcast address.

      + +
    - +

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

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

    +

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

    - -
    + the Natural Logarithm (log2) of n. For the more + common subnet sizes, the size and its natural logarithm are given in the + following table:

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

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

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

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

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

    - + will often hear a subnet of size 64 referred to as a "slash 26" subnet + and one of size 8 referred to as a "slash 29".

    +

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

    - -
    + simply a 32-bit number with the first "VLSM" bits set to one and the + remaining bits set to zero. For example, for a subnet of size 64, +the subnet mask has 26 leading one bits:

    + +

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

    -
    - + = 255.255.255.192

    +
    +

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

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

    +

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

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

    +

    Example:

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

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

    - -
    + the subnet with one member and the subnet with 2 ** 32 members.

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

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

    - -

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

    - -

    Example: 192.0.2.65/29

    - -

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

    - -

    4.3 Routing

    - -

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

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

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

    + +

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

    + +

    Example: 192.0.2.65/29

    + +

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

    + +

    4.3 Routing

    + +

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

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

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

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

    +

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

    - +
      -
    • +

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

      -
      • -
    • +
      • +

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

      -
      • -
    • + the table entry.

      +
      • +

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

      - + then:

      +
        -
      • +

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

        -
        • -
      • + sent to the gateway over the interface named in the 'Iface' column.

        +
        • +

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

        + the interface named in the 'iface' column.

        +
        • + +
      +
      • +
    • +

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

      • -
    - -
  • -

    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:

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

    - +

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

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

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

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

    -
    - -
    +
    + +

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

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

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

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

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

    + +

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

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

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

    - -

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

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

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

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

    +

    4.5 RFC 1918

    - +

    IP addresses are allocated by the Internet Assigned Number Authority (IANA) - who delegates allocations on a geographic basis to Regional Internet - Registries (RIRs). For example, allocation for the Americas and for - sub-Sahara Africa is delegated to the 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.

    - + (ARIN). These RIRs may in turn delegate to national registries. Most + of us don't deal with these registrars but rather get our IP addresses + from our ISP.

    +

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

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

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

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

    +
    + +

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

    -
    - -
    + of things to keep in mind:

    +
    + +
      -
    • +

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

      -
      • -
    • + in their infrastructure.

      +
      • +

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

      -
      • - + your ISP or by another organization with whom you want to establish + a VPN relationship.

      + +
    -
    - -
    +
    + +

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

    -
    - -
    + are using (or are planning to use) private addresses before you decide + the addresses that you are going to use.

    +
    + +

    5.0 Setting up your Network

    -
    - -
    +
    + +

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

    -
    - -
    +
    + +
      -
    1. +

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

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

      +
      4. +

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

      -
      5. - + of your addresses directly.

      + +
    -
    - -
    +
    + +

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

    - + separately.
    +

    +

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

    - +

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

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

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

    5.1 Routed

    -
    - -
    +
    + +

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

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

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

    +
    + +

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

    -
    - -
    -
    + external interface is actually part of the DMZ subnet (192.0.2.64/29). + What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The + routing table on DMZ 1 will look like this:

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

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

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

    +
    + +

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

    -
    - -
    + interfaces that connect to the hub/switch can respond! It is then + a race as to which "here-is" response reaches the sender first.

    +
    + +

    5.2 Non-routed

    -
    - -
    +
    + +

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

    -
    - -
    +
    + +

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

    -
    - -
    +
    + +

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

    -
    - -
    + has assigned you IP addresses 192.0.2.176-180 and has told you to + use netmask 255.255.255.0 and default gateway 192.0.2.254.

    +
    + +

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

    -
    - -
    + and there aren't enough addresses for all of the network interfaces. + There are four different techniques that can be used to work around + this problem.

    +
    + +
      -
    • +

    • Source Network Address Translation (SNAT). -

      -
      • -
    • +

      +
      • +

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

      -
      • -
    • + also known as Port Forwarding.

      +
      • +

    • Proxy ARP.

      -
      • -
    • +
      • +

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

      -
      • - + to as Static NAT.

      + +
    -
    - -
    +
    + +

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

    -
    - -
    +
    + +

     5.2.1 SNAT

    -
    - -
    +
    + +

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

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

    +
    + +

    Let's suppose that you decide to use SNAT on your local zone - and use public address 192.0.2.176 as both your firewall's external - IP address and the source IP address of internet requests sent from -that 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 - (netmask 255.255.255.248).
    - + (netmask 255.255.255.248). +
     
    - +
    -     The systems in the local zone would be configured with a -default gateway of 192.168.201.1 (the IP address of the firewall's -local interface).
    - +     The systems in the local zone would be configured with +a default gateway of 192.168.201.1 (the IP address of the firewall's + local interface). +
     
    - +
    -     SNAT is configured in Shorewall using the /etc/shorewall/masq file.
    - -
    -
    + +
    +
    - - - - - - - - - - - - - + + + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    +
    +
    + +

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

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

    +
    + +

    5.2.2 DNAT

    -
    - -
    +
    + +

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

    -
    - -
    + to initiate a connection to one of the internal systems since those + systems do not have a public IP address. DNAT provides a way to allow + selected connections from the internet.

    +
    + +

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

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

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

    -
    - -
    + IP address) and the firewall will rewrite the destination IP address + to 192.168.201.4 (your daughter's system) and forward the request. + When your daughter's server responds, the firewall will rewrite the + source address back to 192.0.2.176 and send the response back to A.

    +
    + +

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

    -
    - -
    +
    + +

    5.2.3 Proxy ARP

    -
    - -
    +
    + +

    The idea behind proxy ARP is that:

    -
    - -
    +
    + +
      -
    • +

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

      -
      • -
    • +of your public IP addresses (A) and is assigned the same netmask + (M) as the firewall's external interface.

      +
      • +

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

      -
      • -
    • +

      +
      • +

    • When H issues an ARP "who has" request for an address in the subnetwork defined by A and M, the firewall will respond (with the MAC if the firewall interface to H).

      -
      • - + +
    -
    - -
    +
    + +

    Let suppose that we decide to use Proxy ARP on the DMZ in - our example network.

    -
    - -
    + our example network.

    +
    + +

    -

    -
    - +

    + +
    Here, we've assigned the IP addresses 192.0.2.177 to - system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned - an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface - on the firewall. That address and netmask isn't relevant - just be -sure it doesn't overlap another subnet that you've defined.
    - + system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned + an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface + on the firewall. That address and netmask isn't relevant - just be + sure it doesn't overlap another subnet that you've defined. +
     
    - +
    -     The Shorewall configuration of Proxy ARP is done using the - /etc/shorewall/proxyarp file.
    - -
    -
    +     The Shorewall configuration of Proxy ARP is done using +the /etc/shorewall/proxyarp file.
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    + +
    + +

    Because the HAVE ROUTE column contains No, Shorewall will - add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
    -

    - -

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured - to have the IP addresses shown but should have the same default gateway -as the firewall itself -- namely 192.0.2.254. In other words, they should -be configured just like they would be if they were parallel to the firewall -rather than behind it.
    -

    - -

    NOTE: Do not add the Proxy ARP'ed address(es) -(192.0.2.177 and 192.0.2.178 in the above example)  to the external interface -(eth0 in this example) of the firewall.
    -

    - -
    -
    - -
    -

    -
    - -
    -
    -

    A word of warning is in order here. ISPs typically configure - their routers with a long ARP cache timeout. If you move a system from - parallel to your firewall to behind your firewall with Proxy ARP, it - will probably be HOURS before that system can communicate with the internet. - There are a couple of things that you can try:
    + add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

    - + +

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured + to have the IP addresses shown but should have the same default gateway + as the firewall itself -- namely 192.0.2.254. In other words, they should + be configured just like they would be if they were parallel to the firewall + rather than behind it.
    +

    + +

    NOTE: Do not add the Proxy ARP'ed address(es) + (192.0.2.177 and 192.0.2.178 in the above example)  to the external interface + (eth0 in this example) of the firewall.
    +

    + +
    +
    + +
    +

    +
    + +
    +
    +

    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,...
      -
      - "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.
      -
      -
      2. -
    2. 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.
      3. - +
    3. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP + Illustrated, Vol 1 reveals that a
      +
      + "gratuitous" ARP packet should cause the ISP's router to refresh +their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting +the MAC address for its own IP; in addition to ensuring that the IP address + isn't a duplicate,...
      +
      + "if the host sending the gratuitous ARP has just changed its hardware + address..., this packet causes any other host...that has an entry in its + cache for the old hardware address to update its ARP cache entry accordingly."
      +
      + Which is, of course, exactly what you want to do when you switch + a host from being exposed to the Internet to behind Shorewall using proxy + ARP (or static NAT for that matter). Happily enough, recent versions of + Redhat's iputils package include "arping", whose "-U" flag does just that:
      +
      +     arping -U -I <net if> <newly + proxied IP>
      +     arping -U -I eth0 66.58.99.83 # for + example
      +
      + Stevens goes on to mention that not all systems respond correctly + to gratuitous ARPs, but googling for "arping -U" seems to support the +idea that it works most of the time.
      +
      +
      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 192.0.2.177. 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):

    -
    - -
    -
    	ping 130.252.100.254
    -
    -
    - -
    +
    + +
    +

    Now from 192.0.2.177, ping the ISP's gateway (which we + will assume is 192.0.2.254):

    +
    + +
    +
    	ping 192.0.2.254
    +
    +
    + +

    We can now observe the tcpdump output:

    -
    - -
    +
    + +
    	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
    	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
    -
    - -
    +
    + +

    Notice that the source MAC address in the echo request is - different from the destination MAC address in the echo reply!! In -this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while -0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the -gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ -1 rather than with the firewall's eth0.

    -
    - -
    + different from the destination MAC address in the echo reply!! In + this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC +while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, +the gateway's ARP cache still associates 192.0.2.177 with the NIC +in DMZ 1 rather than with the firewall's eth0.

    +
    + +

    5.2.4 Static NAT

    -
    - -
    +
    + +

    With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public - IP addresses. For outgoing connections SNAT (Source Network Address - Translation) occurs and on incoming connections DNAT (Destination Network - Address Translation) occurs. Let's go back to our earlier example involving - your daughter's web server running on system Local 3.

    -
    - -
    + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT (Source Network Address + Translation) occurs and on incoming connections DNAT (Destination +Network Address Translation) occurs. Let's go back to our earlier example +involving your daughter's web server running on system Local 3.

    +
    + +

    -

    -
    - -
    +

    +
    + +

    Recall that in this setup, the local network is using SNAT - and is sharing the firewall external IP (192.0.2.176) for outbound -connections. This is done with the following entry in /etc/shorewall/masq:

    -
    - -
    -
    + and is sharing the firewall external IP (192.0.2.176) for outbound + connections. This is done with the following entry in /etc/shorewall/masq:

    +
    + +
    +
    - - - - - - - - - - - - - + + + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    -     Suppose now that you have decided to give your daughter -her own IP address (192.0.2.179) for both inbound and outbound connections. - You would do that by adding an entry in /etc/shorewall/nat.

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    + +
    + +

    With this entry in place, you daughter has her own IP address - and the other two local systems share the firewall's IP address.

    -
    - -
    + and the other two local systems share the firewall's IP address.

    +
    + +

    -     Once the relationship between 192.0.2.179 and 192.168.201.4 - is established by the nat file entry above, it is no longer appropriate - to use a DNAT rule for you daughter's web server -- you would rather - just use an ACCEPT rule:

    -
    - -
    -
    +     Once the relationship between 192.0.2.179 and 192.168.201.4 + is established by the nat file entry above, it is no longer appropriate + to use a DNAT rule for you daughter's web server -- you would rather + just use an ACCEPT rule:

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
    ACCEPTnetloc:192.168.201.4tcpwww  
    -
    -
    - -
    + +
    + +
    +
    +
    +

    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 static NAT, +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,...
      +
      + "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.
      +
      +
      2. +
    2. 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.
      3. +
    + 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 209.0.2.179. On the firewall, run tcpdump + as follows:
    + +
    +
    	tcpdump -nei eth0 icmp
    +
    + +
    +

    Now from the 192.168.201.4, ping the ISP's gateway (which +we will assume is 192.0.2.254):

    +
    + +
    +
    	ping 192.0.2.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.179 > 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.179 : 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.179 with the NIC +in the local zone rather than with the firewall's eth0.

    +
    +

    5.3 Rules

    -
    - -
    +
    + +

    -     With the default policies, your local systems (Local 1-3) -can access any servers on the internet and the DMZ can't access any -other host (including the firewall). With the exception of DNAT rules which cause address translation and allow - the translated connection request to pass through the firewall, the -way to allow connection requests through your firewall is to use ACCEPT - rules.

    -
    - -
    + the translated connection request to pass through the firewall, the + way to allow connection requests through your firewall is to use ACCEPT + rules.

    +
    + +

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't - used in this section, they won't be shown

    -
    - -
    + used in this section, they won't be shown

    +
    + +

    You probably want to allow ping between your zones:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    -
    -
    - -
    + +
    + +

    Let's suppose that you run mail and pop3 servers on DMZ 2 - and a Web Server on DMZ 1. The rules that you would need are:

    -
    - -
    -
    + and a Web Server on DMZ 1. The rules that you would need are:

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    -
    -
    - -
    + +
    + +

    If you run a public DNS server on 192.0.2.177, you would need to add the following rules:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    -
    -
    - -
    + +
    + +

    You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which through - its scp utility can also do publishing and software update distribution.

    -
    - -
    -
    + and DMZ systems from the local network -- I recommend SSH which through + its scp utility can also do publishing and software update distribution.

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    5.4 Odds and Ends

    -
    - -
    +
    + +

    The above discussion reflects my personal preference for using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I prefer to use NAT only in cases where a system that is part of an RFC 1918 subnet needs to have it's own public IP. 

    -
    - -
    +
    + +

    -     If you haven't already, it would be a good idea to browse -through /etc/shorewall/shorewall.conf -just to see if there is anything there that might be of interest. -You might also want to look at the other configuration files that +     If you haven't already, it would be a good idea to browse + through /etc/shorewall/shorewall.conf + just to see if there is anything there that might be of interest. + You might also want to look at the other configuration files that you haven't touched yet just to get a feel for the other things that Shorewall can do.

    -
    - -
    +
    + +

    In case you haven't been keeping score, here's the final set of configuration files for our sample network. Only those that were modified from the original installation are shown.

    -
    - -
    +
    + +

    /etc/shorewall/interfaces (The "options" will be very site-specific).

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    -
    -
    - -
    + +
    + +

    The setup described here requires that your network interfaces - be brought up before Shorewall can start. This opens a short window - during which you have no firewall protection. If you replace 'detect' - with the actual broadcast addresses in the entries above, you can bring - up Shorewall before you bring up your network interfaces.

    -
    - -
    -
    + be brought up before Shorewall can start. This opens a short window + during which you have no firewall protection. If you replace 'detect' + with the actual broadcast addresses in the entries above, you can bring + up Shorewall before you bring up your network interfaces.

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    ZoneInterfaceBroadcastOptions
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    -
    -
    - -
    + +
    + +

    /etc/shorewall/masq - Local subnet

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - + + + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    /etc/shorewall/proxyarp - DMZ

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    + +
    + +

    /etc/shorewall/nat- Daughter's System

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    + +
    + +

    /etc/shorewall/rules

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    6.0 DNS

    -
    - -
    +
    + +

    Given the collection of RFC 1918 and public addresses in this setup, it only makes sense to have separate internal and external DNS servers. You can combine the two into a single BIND 9 server using Views. If you are not interested in Bind 9 views, you can go to the next section.

    -
    - -
    +
    + +

    Suppose that your domain is foobar.net and you want the two - DMZ systems named www.foobar.net and mail.foobar.net and you want -the three local systems named "winken.foobar.net, blinken.foobar.net -and nod.foobar.net. You want your firewall to be known as firewall.foobar.net - externally and it's interface to the local network to be know as gateway.foobar.net - and its interface to the dmz as dmz.foobar.net. Let's have the DNS -server on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    -
    - -
    + DMZ systems named www.foobar.net and mail.foobar.net and you want + the three local systems named "winken.foobar.net, blinken.foobar.net + and nod.foobar.net. You want your firewall to be known as firewall.foobar.net + externally and it's interface to the local network to be know as gateway.foobar.net + and its interface to the dmz as dmz.foobar.net. Let's have the DNS + server on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    +
    + +

    The /etc/named.conf file would look like this:

    -
    - -
    -
    -
    +
    + +
    +
    + 
    options {
    	directory "/var/named";
    	listen-on { 127.0.0.1 ; 192.0.2.177; };
    };

    logging {
    	channel xfer-log {
    		file "/var/log/named/bind-xfer.log";
    		print-category yes;
    		print-severity yes;
    		print-time yes;
    		severity info;
    	};
    	category xfer-in { xfer-log; };
    	category xfer-out { xfer-log; };
    	category notify { xfer-log; };
    };
    -
    - -
    - 
    #
    # This is the view presented to our internal systems
    #

    view "internal" {
    	#
    	# These are the clients that see this view
    	#
    	match-clients { 192.168.201.0/29;
    			192.168.202.0/29;
    			127.0.0/24;
    			192.0.2.176/32; 
    			192.0.2.178/32;
    			192.0.2.179/32;
    			192.0.2.180/32; };
    	#
    	# If this server can't complete the request, it should use outside
    	# servers to do so
    	#
    	recursion yes;

    	zone "." in {
    		type hint;
    		file "int/root.cache";
    	};

    	zone "foobar.net" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.foobar";
    	};

    	zone "0.0.127.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.127.0.0";	
    	};

    	zone "201.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.201";
    	};

    	zone "202.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.202";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.176";
    	};
     (or status NAT for that matter)
    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.206.124.146.179";
    	};

    };
    #
    # This is the view that we present to the outside world
    #
    view "external" {
    	match-clients { any; };
    	#
    	# If we can't answer the query, we tell the client so
    	#
    	recursion no;

    	zone "foobar.net" in {
    		type master;
    		notify yes;
    		allow-update {none; };
    		allow-transfer { <secondary NS IP>; };
    		file "ext/db.foobar";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
     		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.176";
    	};

    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.179";
    	};
    };
    -
    -
    -
    - -
    +
    + +
    + 
    #
    # 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.0/8;
    			192.0.2.176/32; 
    			192.0.2.178/32;
    			192.0.2.179/32;
    			192.0.2.180/32; };
    	#
    	# If this server can't complete the request, it should use outside
    	# servers to do so
    	#
    	recursion yes;

    	zone "." in {
    		type hint;
    		file "int/root.cache";
    	};

    	zone "foobar.net" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.foobar";
    	};

    	zone "0.0.127.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.127.0.0";	
    	};

    	zone "201.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.201";
    	};

    	zone "202.168.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "int/db.192.168.202";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.176";
    	};
     (or status NAT for that matter)
    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify no;
    		allow-update { none; };
    		file "db.206.124.146.179";
    	};

    };
    #
    # This is the view that we present to the outside world
    #
    view "external" {
    	match-clients { any; };
    	#
    	# If we can't answer the query, we tell the client so
    	#
    	recursion no;

    	zone "foobar.net" in {
    		type master;
    		notify yes;
    		allow-update {none; };
    		allow-transfer { <secondary NS IP>; };
    		file "ext/db.foobar";
    	};

    	zone "176.2.0.192.in-addr.arpa" in {
     		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.176";
    	};

    	zone "177.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.177";
    	};

    	zone "178.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.178";
    	};

    	zone "179.2.0.192.in-addr.arpa" in {
    		type master;
    		notify yes;
    		allow-update { none; };
    		allow-transfer { <secondary NS IP>; };
    		file "db.192.0.2.179";
    	};
    };
    +
    +
    +
    + +

    Here are the files in /var/named (those not shown are usually - included in your bind disbribution).

    - + included in your bind disbribution).

    +

    db.192.0.2.176 - This is the reverse zone for the firewall's - external interface

    - -
    + external interface

    + +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
    ; Filename: db.192.0.2.176
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
    -
    -
    - -
    + +
    + +
    db.192.0.2.177 - This is the reverse zone for the www/DNS - server -
    + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
    ; Filename: db.192.0.2.177
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
    -
    -
    -
    - -
    + +
    + + +
    db.192.0.2.178 - This is the reverse zone for the mail - server -
    + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
    ; Filename: db.192.0.2.178
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
    -
    -
    -
    - -
    + +
    + + +
    db.192.0.2.179 - This is the reverse zone for daughter's - web server's public IP -
    + web server's public IP +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
    ; Filename: db.192.0.2.179
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
    -
    -
    -
    - -
    + +
    + + +

    int/db.127.0.0 - The reverse zone for localhost

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
    ; Filename: db.127.0.0
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    				2001092901 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR	localhost.foobar.net.
    -
    -
    - -
    + +
    + +

    int/db.192.168.201 - Reverse zone for the local net. This - is only shown to internal clients

    -
    - -
    -
    + is only shown to internal clients

    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
    ; Filename: db.192.168.201
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR 	gateway.foobar.net.
    2	86400		IN PTR	winken.foobar.net.
    3	86400		IN PTR	blinken.foobar.net.
    4	86400		IN PTR	nod.foobar.net.
    -
    -
    - -
    + +
    + +

    int/db.192.168.202 - Reverse zone for the firewall's DMZ interface

    -
    - -
    -
    -
    +
    + +
    +
    + 
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
    ; Filename: db.192.168.202
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @		604800	IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1 		86400 IN PTR	dmz.foobar.net.
    -
    -
    -
    - -
    +
    +
    +
    + +

    int/db.foobar - Forward zone for use by internal clients.

    -
    - -
    -
    +
    + +
    +
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002071501 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; foobar.net Nameserver Records (NS)
    ;############################################################
    @ 		604800	IN NS	ns1.foobar.net.

    ;############################################################
    ; Foobar.net Office Records (ADDRESS)
    ;############################################################
    localhost	86400 	IN A 	127.0.0.1

    firewall	86400	IN A	192.0.2.176
    www		86400	IN A	192.0.2.177
    ns1 		86400	IN A 	192.0.2.177
    www		86400	IN A	192.0.2.177

    gateway		86400	IN A 	192.168.201.1
    winken		86400	IN A 	192.168.201.2
    blinken		86400	IN A	192.168.201.3
    nod		86400	IN A	192.168.201.4
    -
    -
    - -
    + +
    + +

    ext/db.foobar - Forward zone for external clients

    -
    - -
    -
    -
    +
    + +
    +
    + 
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002052901 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; Foobar.net Nameserver Records (NS)
    ;############################################################
    @		86400	IN NS	ns1.foobar.net.
    @		86400	IN NS	<secondary NS>.
    ;############################################################
    ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
    ;############################################################
    localhost	86400	IN A	127.0.0.1
    ;
    ; The firewall itself
    ;
    firewall	86400	IN A	192.0.2.176
    ;
    ; The DMZ
    ;
    ns1		86400	IN A	192.0.2.177
    www		86400	IN A	192.0.2.177
    mail		86400	IN A	192.0.2.178
    ;
    ; The Local Network
    ;
    nod		86400	IN A	192.0.2.179

    ;############################################################
    ; Current Aliases for foobar.net (CNAME)
    ;############################################################

    ;############################################################
    ; foobar.net MX Records (MAIL EXCHANGER)
    ;############################################################
    foobar.net.	86400	IN A	192.0.2.177
    		86400 	IN MX 0 mail.foobar.net.
    		86400	IN MX 1 <backup MX>.
    -
    -
    -
    - -
    +
    +
    +
    + +

    7.0 Starting and Stopping - Your Firewall

    -
    - -
    + Your Firewall +
    + +

    The installation procedure configures - your system to start Shorewall at system boot.

    -
    - -
    + your system to start Shorewall at system boot.

    +
    + +

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, -routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" command. - If you want to totally remove any trace of Shorewall from your Netfilter - configuration, use "shorewall clear".

    -
    - -
    + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

    +
    + +

    -     Edit the /etc/shorewall/routestopped file and configure -those systems that you want to be able to access the firewall when -it is stopped.

    -
    - -
    +     Edit the /etc/shorewall/routestopped file and configure + those systems that you want to be able to access the firewall when + it is stopped.

    +
    + +

    WARNING: If you are connected to your firewall from - the internet, do not issue a "shorewall stop" command unless you have - added an entry for the IP address that you are connected from to -/etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create - an alternate configuration - and test it using the "shorewall - try" command.

    -
    - -

    Last updated 5/3/2003 - /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 6/7/2003 - Tom Eastep

    - +

    Copyright 2002, 2003 - Thomas M. Eastep

    -
    -
    -
    -
    -
    -
    -
    -
    -
    -
    + Thomas M. Easte
    +


    diff --git a/STABLE/documentation/sourceforge_index.htm b/STABLE/documentation/sourceforge_index.htm index 441f66055..22495a654 100644 --- a/STABLE/documentation/sourceforge_index.htm +++ b/STABLE/documentation/sourceforge_index.htm @@ -2,430 +2,488 @@ - + Shoreline Firewall (Shorewall) 1.3 - + - + - + - + - + + + - Shorewall 1.4 - - "iptables made easy"
    -
    -     - - - - - - - + +
    + + - -

    Shorwall Logo + +

    Shorewall 1.4 "iptables made easy"

    +

    		+


    +

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

    What is it?

    - +

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

    + a Netfilter + (iptables) based firewall that can be used + on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

    - +

    This program is free software; you can redistribute it and/or modify - it - 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

    - +

    Copyright 2001, 2002, 2003 Thomas M. Eastep

    - + +

    Running Shorewall on Mandrake with a two-interface setup?

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

    Getting Started with Shorewall

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

    News

    - - - - -

    5/29/2003 - Shorewall-1.4.4b (New) -

    - -

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

    - -

    5/27/2003 - Shorewall-1.4.4a (New) -

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

    5/23/2003 - Shorewall-1.4.4 (New) -

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

    5/20/2003 - Shorewall-1.4.3a -
    -

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

    5/18/2003 - Shorewall 1.4.3
    -

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

    5/10/2003 - Shorewall Mirror in Asia
    -

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

    5/8/2003 - Shorewall Mirror in Chile  

    - - -

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

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

    Getting Started with Shorewall

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

    News

    + + + + +

    6/17/2003 - Shorewall-1.4.5 (New) +

    + +

    Problems Corrected:
    +

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

    New Features:
    +

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

    6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 + (New) +

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

    6/8/2003 - Updated Samples (New) +

    + +

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

    + +

    5/29/2003 - Shorewall-1.4.4b

    + +

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

    + +

    5/27/2003 - Shorewall-1.4.4a

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

    5/23/2003 - Shorewall-1.4.4 +

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

    5/20/2003 - Shorewall-1.4.3a +
    +

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

    5/18/2003 - Shorewall 1.4.3
    +

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

    5/10/2003 - Shorewall Mirror in Asia
    +

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

    5/8/2003 - Shorewall Mirror in Chile  

    + + +

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

    + +

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

    - + +

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

    +

    - + +

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

    +

    +

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

    - - -

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

    + to Shorewall version 1.4.2.

    +

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

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

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

    + + + + +

    More News

    + -

    - - - - -

    More News

    - - - -

    - + - +

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

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

    SourceForge Logo -

    - + + - +

    - + - +

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

    - + - +

    Donations

    -     		- + +
    - +


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

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

    - + +

    Quick Search
    -

    -
    - +

    Extended Search

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

    -

    +

    - -

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

    + +


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

    -
    - -

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

    Updated 6/17/2003 - Tom Eastep +

    diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index 775227cf0..486c59c19 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,81 +1,81 @@ - + - + Shorewall Support Guide - + - - - + - - - + + + + +
    +
    - +

    Shorewall Support Guide -

    -
    - +

    Before Reporting a Problem or Asking a Question
    -

    - There -are a number of sources of Shorewall information. Please try these -before you post. + + There + are a number of sources of Shorewall information. Please try these + before you post. - +

    Site and Mailing List Archive Search

    - -
    + +
    Match: - + - Format: - + Format: + - Sort by: - + Sort by: + - Include Mailing List Archives: - + -
    - Search:
    + Search:
    -
    -
    - + +
    +

    Problem Reporting Guidelines
    -

    - + +
      -
    • Please remember we only know what - is posted in your message. Do not leave out any information - that appears to be correct, or was mentioned in a previous -post. There have been countless posts by people who were sure +
    • Please remember we only know +what is posted in your message. Do not leave out any information + that appears to be correct, or was mentioned in a previous + post. There have been countless posts by people who were sure that some part of their configuration was correct when it actually - contained a small error. We tend to be skeptics where detail - is lacking.
      -
      -
      • -
    • Please keep in mind that you're - asking for free technical support. -Any help we offer is an act of generosity, not an obligation. - Try to make it easy for us to help you. Follow good, courteous -practices in writing and formatting your e-mail. Provide details that + contained a small error. We tend to be skeptics where detail + is lacking.
      +
      +
      • +
    • Please keep in mind that you're + asking for free technical support. + Any help we offer is an act of generosity, not an obligation. + Try to make it easy for us to help you. Follow good, courteous + practices in writing and formatting your e-mail. Provide details that we need if you expect good answers. Exact quoting of error messages, log entries, command output, and other output is better than a paraphrase or summary.
      -
      -
      • -
    • - Please don't describe your environment and then ask -us to send you custom configuration files. We're -here to answer your questions but we can't do +
      +
      • +
    • + Please don't describe your environment and then ask + us to send you custom configuration files. We're + here to answer your questions but we can't do your job for you.
      -
      -
      • -
    • When reporting a problem, ALWAYS - include this information:
      • - +
      + +
    • When reporting a problem, ALWAYS + include this information:
      • +
    - +
      - +
        -
      • the exact version of Shorewall - you are running.
        -
        - shorewall - version
        -
        -
        • - +
      • the exact version of Shorewall + you are running.
        +
        + shorewall + version
        +
        +
        • +
      - +
        -
      • the exact kernel version you -are running
        -
        - uname --a
        -
        -
        • - +
      • the exact kernel version you + are running
        +
        + uname + -a
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip addr - show
        -
        -
        • - +
      • the complete, exact output +of
        +
        + ip +addr show
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip route - show
        -
        -
        • - +
      • the complete, exact output +of
        +
        + ip +route show
        +
        +
        • +
      - +
        -
      • If your kernel is modularized, - the exact output from
        -
        - lsmod
        -
        • +
      • If your kernel is modularized, + the exact output from
        +
        + lsmod
        +
        • - +
      - +
    - +
      - +
        -
      • If you are having -connection problems of any kind then:
        -
        - 1. /sbin/shorewall reset
        -
        - 2. Try the connection that is failing.
        -
        - 3. /sbin/shorewall status - > /tmp/status.txt
        -
        - 4. Post the /tmp/status.txt file as an attachment.
        -
        -
        • -
      • the exact wording of any If you are having + connection problems of any kind then:
        +
        + 1. /sbin/shorewall reset
        +
        + 2. Try the connection that is failing.
        +
        + 3. /sbin/shorewall status + > /tmp/status.txt
        +
        + 4. Post the /tmp/status.txt file as an attachment.
        +
        +
        • +
      • the exact wording of any ping failure responses
        -
        -
        • -
      • If you installed Shorewall using one of the QuickStart - Guides, please indicate which one.
        -
        -
        • -
      • If you are running Shorewall under Mandrake using - the Mandrake installation of Shorewall, please say so.
        -
        -
        • - +
        + +
      • If you installed Shorewall using one of the QuickStart + Guides, please indicate which one.
        +
        +
        • +
      • If you are running Shorewall under Mandrake using + the Mandrake installation of Shorewall, please say so.
        +
        +
        • +
      -
    • As - a general matter, please do not edit the diagnostic - information in an attempt to conceal your IP address, - netmask, nameserver addresses, domain name, etc. These aren't - secrets, and concealing them often misleads us (and 80% of the time, - a hacker could derive them anyway from information contained in - the SMTP headers of your post).
      -
      -
      • -
    • Do you see any "Shorewall" messages ("As a general matter, please do not edit the diagnostic + information in an attempt to conceal your IP address, + netmask, nameserver addresses, domain name, etc. These aren't + secrets, and concealing them often misleads us (and 80% of the time, + a hacker could derive them anyway from information contained +in the SMTP headers of your post).
      +
      +
      • +
    • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when - you exercise the function that is giving you problems? If so, - include the message(s) in your post along with a copy of your /etc/shorewall/interfaces + you exercise the function that is giving you problems? If +so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces file.
      -
      -
      • -
    • Please include any of the Shorewall configuration - files (especially the /etc/shorewall/hosts file -if you have modified that file) that you think are - relevant. If you include /etc/shorewall/rules, please include -/etc/shorewall/policy as well (rules are meaningless unless one -also knows the policies).
      -
      -
      • -
    • If an error occurs when you try to " +
      • +
    • Please include any of the Shorewall configuration + files (especially the /etc/shorewall/hosts file + if you have modified that file) that you think are + relevant. If you include /etc/shorewall/rules, please include + /etc/shorewall/policy as well (rules are meaningless unless +one also knows the policies).
      +
      +
      • +
    • If an error occurs when you try to "shorewall start", include a trace - (See the Troubleshooting - section for instructions).
      -
      -
      • -
    • The list server limits posts to 120kb so don't - post GIFs of your network layout, etc. -to the Mailing List -- your post will be rejected.
      • - + (See the Troubleshooting + section for instructions).
      +
      + +
    • The list server limits posts to 120kb so don't + post GIFs of your network layout, etc. + to the Mailing List -- your post will be rejected.
      • +
    - +
    The author gratefully acknowleges that the above list was - heavily plagiarized from the excellent LEAF document by Ray - Olszewski found at Ray + Olszewski found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
    -
    - + +

    When using the mailing list, please post in plain text

    - +
    A growing number of MTAs serving list subscribers are rejecting all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net "for continuous abuse" because it has been my policy to allow HTML in list posts!!
    -
    - I think that blocking all HTML -is a Draconian way to control spam and that the ultimate -losers here are not the spammers but the list subscribers - whose MTAs are bouncing all shorewall.net mail. As one list subscriber - wrote to me privately "These e-mail admin's need to get a (expletive - deleted) life instead of trying to rid the planet of HTML based - e-mail". Nevertheless, to allow subscribers to receive list posts - as must as possible, I have now configured the list server at -shorewall.net to strip all HTML from outgoing posts.
    -
    - +
    + I think that blocking all HTML + is a Draconian way to control spam and that the ultimate + losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list +subscriber wrote to me privately "These e-mail admin's need + to get a (expletive deleted) life instead of trying to +rid the planet of HTML based e-mail". Nevertheless, to allow +subscribers to receive list posts as must as possible, I have now + configured the list server at shorewall.net to strip all HTML from + outgoing posts.
    +
    + If you run your own outgoing mail server +and it doesn't have a valid DNS PTR record, your email won't reach the lists +unless/until the postmaster notices that your posts are being rejected. To +avoid this problem, you should configure your MTA to forward posts to shorewall.net +through an MTA that does have a valid PTR record (such as the one +at your ISP).
    +

    Where to Send your Problem Report or to Ask for Help

    - -
    + +

    If you run Shorewall under Bering -- please post your question or problem - to the LEAF Users mailing - list.

    - If you run Shorewall under MandrakeSoft - Multi Network Firewall (MNF) and you have not purchased -an MNF license from MandrakeSoft then you can post non MNF-specific - Shorewall questions to the . + If you run Shorewall under +MandrakeSoft Multi Network Firewall (MNF) and you have +not purchased an MNF license from MandrakeSoft then you can + post non MNF-specific Shorewall questions to the Shorewall users mailing - list. Do not expect to get free MNF support on the list.
    - -

    Otherwise, please post your question or problem to the . Do not expect to get free MNF support on the list.
    + +

    If you have a question, you may post it on the Shorewall Forum: + DO NOT USE THE FORUM FOR REPORTING PROBLEMS OR +ASKING FOR HELP WITH PROBLEMS.
    +
    + Otherwise, please post your question or problem to the Shorewall users mailing - list .

    - + list .

    +

    To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users - .
    -

    -
    - + .
    +

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 5/28/2003 - Tom Eastep

    - +

    + +

    Last Updated 6/14/2003 - Tom Eastep

    +

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

    -
    +

    diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index cb1efc4c7..14ffb549a 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.4.4b +VERSION=1.4.5 usage() # $1 = exit status { diff --git a/STABLE/firewall b/STABLE/firewall index 5a4d0c256..513d7b43c 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -354,11 +354,11 @@ setpolicy() # $1 = name of chain, $2 = policy } # -# Set a standard chain to enable established connections +# Set a standard chain to enable established and related connections # setcontinue() # $1 = name of chain { - run_iptables -A $1 -m state --state ESTABLISHED -j ACCEPT + run_iptables -A $1 -m state --state ESTABLISHED,RELATED -j ACCEPT } # @@ -1000,7 +1000,7 @@ stop_firewall() { while read interface host; do expandv interface host - [ "x$host" = "x-" -o -z "$hosts" ] && host=0.0.0.0/0 + [ "x$host" = "x-" -o -z "$host" ] && host=0.0.0.0/0 for h in `separate_list $host`; do hosts="$hosts $interface:$h" done @@ -1793,19 +1793,13 @@ refresh_tc() { # add_nat_rule() { local chain + local excludedests= - # Be sure we should and can NAT + # Be sure we can NAT - case $logtarget in - DNAT|REDIRECT) - if [ -z "$NAT_ENABLED" ]; then - fatal_error "Rule \"$rule\" requires NAT which is disabled" - fi - ;; - *) - fatal_error "Only DNAT and REDIRECT rules may specify port mapping; rule \"$rule\"" - ;; - esac + if [ -z "$NAT_ENABLED" ]; then + fatal_error "Rule \"$rule\" requires NAT which is disabled" + fi # Parse SNAT address if any @@ -1823,14 +1817,20 @@ add_nat_rule() { addr= ;; detect) - addr= - if [ -n "$DETECT_DNAT_IPADDRS" -a "$source" != "$FW" ]; then - eval interfaces=\$${source}_interfaces - for interface in $interfaces; do - addr="`find_interface_address $interface` $addr" - done - fi - ;; + addr= + if [ -n "$DETECT_DNAT_IPADDRS" -a "$source" != "$FW" ]; then + eval interfaces=\$${source}_interfaces + for interface in $interfaces; do + addr=${addr:+$addr,}`find_interface_address $interface` + done + fi + ;; + !*) + if [ `list_count $addr` -gt 1 ]; then + excludedests="`separate_list ${addr#\!}`" + addr= + fi + ;; esac addr=${addr:-0.0.0.0/0} @@ -1844,42 +1844,75 @@ add_nat_rule() { target1="REDIRECT --to-port $servport" fi + if [ $source = $FW ]; then + [ -n "$excludezones" ] && fatal_error "Invalid Source in rule \"$rule\"" + fi + # Generate nat table rules if [ $command != check ]; then if [ "$source" = "$FW" ]; then - run_iptables2 -t nat -A OUTPUT $proto $sports -d $addr \ - $multiport $dports -j $target1 - else - chain=`dnat_chain $source` - - if [ -n "$excludezones" ]; then + if [ -n "$excludedests" ]; then chain=nonat${nonat_seq} nonat_seq=$(($nonat_seq + 1)) createnatchain $chain - addnatrule `dnat_chain $source` -j $chain + run_iptables -t nat -A OUTPUT $cli $proto $multiport $sports $dports -j $chain + + for adr in $excludedests; do + addnatrule $chain -d $adr -j RETURN + done + + if [ -n "$loglevel" ]; then + log_rule $loglevel $chain $logtarget -t nat + fi + + addnatrule $chain -j $target1 + else + for adr in `separate_list $addr`; do + run_iptables2 -t nat -A OUTPUT $proto $sports -d $adr \ + $multiport $dports -j $target1 + done + fi + else + chain=`dnat_chain $source` + + if [ -n "${excludezones}${excludedests}" ]; then + chain=nonat${nonat_seq} + nonat_seq=$(($nonat_seq + 1)) + createnatchain $chain + addnatrule `dnat_chain $source` $cli $proto $multiport $sports $dports -j $chain for z in $excludezones; do eval hosts=\$${z}_hosts for host in $hosts; do - for adr in $addr; do - addnatrule $chain $proto -s ${host#*:} \ - $multiport $sports -d $adr $dports -j RETURN + for adr in `separate_list $addr`; do + addnatrule $chain -s ${host#*:} -d $adr -j RETURN done done done + + for adr in $excludedests; do + addnatrule $chain -d $adr -j RETURN + done + + for adr in `separate_list $addr`; do + if [ -n "$loglevel" ]; then + log_rule $loglevel $chain $logtarget -t nat -d `fix_bang $adr` + fi + + addnatrule $chain -d $adr -j $target1 + done + else + for adr in `separate_list $addr`; do + if [ -n "$loglevel" ]; then + ensurenatchain $chain + log_rule $loglevel $chain $logtarget -t nat \ + `fix_bang $proto $cli $sports -d $adr $multiport $dports` + fi + + addnatrule $chain $proto $cli $sports \ + -d $adr $multiport $dports -j $target1 + done fi - - for adr in $addr; do - if [ -n "$loglevel" ]; then - ensurenatchain $chain - log_rule $loglevel $chain $logtarget -t nat \ - `fix_bang $proto $cli $sports -d $adr $multiport $dports` - loglevel= - fi - - addnatrule $chain $proto $cli $sports \ - -d $adr $multiport $dports -j $target1 - done fi fi @@ -1930,11 +1963,13 @@ add_nat_rule() { # add_a_rule() { - # Set source variables + local natrule= + + # Set source variables. The 'cli' variable will hold the client match predicate(s). cli= - [ -n "$client" ] && case "$client" in + case "$client" in -) ;; *:*) @@ -1947,16 +1982,16 @@ add_a_rule() cli=`mac_match $client` ;; *) - cli="-i $client" + [ -n "$client" ] && cli="-i $client" ;; esac - # Set destination variables + # Set destination variables - 'serv' and 'dest_interface' hold the server match predicate(s). dest_interface= serv= - [ -n "$server" ] && case "$server" in + case "$server" in -) ;; *.*.*) @@ -1966,7 +2001,7 @@ add_a_rule() fatal_error "Rule \"$rule\" - Destination may not be specified by MAC Address" ;; *) - dest_interface="-o $server" + [ -n "$server" ] && dest_interface="-o $server" ;; esac @@ -2032,10 +2067,12 @@ add_a_rule() [ -n "$serv" ] && startup_error "REDIRECT rules cannot"\ " specify a server IP; rule: \"$rule\"" servport=${servport:=$port} + natrule=Yes ;; DNAT) [ -n "$serv" ] || fatal_error "DNAT rules require a" \ " server address; rule: \"$rule\"" + natrule=Yes ;; LOG) [ -z "$loglevel" ] && fatal_error "LOG requires log level" @@ -2044,7 +2081,7 @@ add_a_rule() # Complain if the rule is really a policy - if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" ]; then + if [ -z "$proto" -a -z "$cli" -a -z "$serv" -a -z "$servport" -a "$logtarget" != LOG ]; then error_message "Warning -- Rule \"$rule\" is a POLICY" error_message " -- and should be moved to the policy file" fi @@ -2054,15 +2091,16 @@ add_a_rule() # A specific server or server port given - if [ -n "$addr" -a "$addr" != "$serv" ]; then - add_nat_rule - elif [ -n "$servport" -a "$servport" != "$port" ]; then + if [ -n "$natrule" ]; then add_nat_rule + elif [ -n "$addr" -a "$addr" != "$serv" ] || [ -n "$servport" -a "$servport" != "$port" ]; then + fatal_error "Only DNAT and REDIRECT rules may specify destination mapping; rule \"$rule\"" fi if [ -z "$dnat_only" -a $chain != ${FW}2${FW} ]; then serv="${serv:+-d $serv}" - if [ -n "$loglevel" ]; then + + if [ -n "$loglevel" -a -z "$natrule" ]; then log_rule $loglevel $chain $logtarget \ `fix_bang $proto $sports $multiport $state $cli $serv $dports` fi @@ -2126,7 +2164,12 @@ process_rule() # $1 = target logtarget="$target" dnat_only= - # Convert 1.3 Rule formats to 1.2 format + # Tranform the rule: + # + # - set 'target' to the filter table target. + # - make $FW the destination for REDIRECT + # - remove '-' suffix from logtargets while setting 'dnat_only' + # - clear 'address' if it has been set to '-' [ "x$address" = "x-" ] && address= @@ -2185,9 +2228,7 @@ process_rule() # $1 = target fatal_error "Exclude list only allowed with DNAT or REDIRECT" fi - if ! validate_zone $clientzone; then - fatal_error "Undefined Client Zone in rule \"$rule\"" - fi + validate_zone $clientzone || fatal_error "Undefined Client Zone in rule \"$rule\"" # Parse and validate destination @@ -2220,7 +2261,7 @@ process_rule() # $1 = target dest=$serverzone - # Create canonical chain if necessary + # Ensure that this rule doesn't apply to a NONE policy pair of zones chain=${source}2${dest} @@ -2229,11 +2270,14 @@ process_rule() # $1 = target [ $policy = NONE ] && \ fatal_error "Rules may not override a NONE policy: rule \"$rule\"" - [ $command = check ] || ensurechain $chain + # Be sure that this isn't a fw->fw rule. if [ "x$chain" = x${FW}2${FW} ]; then case $logtarget in - REDIRECT) + REDIRECT|DNAT) + # + # Redirect rules that have the firewall as the source are fw->fw rules + # ;; *) error_message "WARNING: fw -> fw rules are not supported; rule \"$rule\" ignored" @@ -2241,6 +2285,9 @@ process_rule() # $1 = target ;; esac else + + # Create the canonical chain if it doesn't already exist + [ $command = check ] || ensurechain $chain fi @@ -2252,15 +2299,25 @@ process_rule() # $1 = target `list_count $ports` -le 15 -a \ `list_count $cports` -le 15 ] then + # + # MULTIPORT is enabled, there are no port ranges in the rule and less than + # 16 ports are listed - use multiport match. + # multioption="-m multiport" for client in `separate_list ${clients:=-}`; do for server in `separate_list ${servers:=-}`; do + # + # add_a_rule() modifies these so we must set their values each time + # port=${ports:=-} cport=${cports:=-} add_a_rule done done else + # + # MULTIPORT is disabled or the rule isn't compatible with multiport match + # multioption= for client in `separate_list ${clients:=-}`; do for server in `separate_list ${servers:=-}`; do @@ -2272,7 +2329,9 @@ process_rule() # $1 = target done done fi - + # + # Report Result + # if [ $command = check ]; then echo " Rule \"$rule\" checked." else @@ -3774,9 +3833,11 @@ activate_rules() complete_standard_chain INPUT all $FW complete_standard_chain OUTPUT $FW all complete_standard_chain FORWARD all all - + # + # Remove rules added to keep the firewall alive during [re]start" + # for chain in INPUT OUTPUT FORWARD; do - run_iptables -D $chain -m state --state ESTABLISHED -j ACCEPT + run_iptables -D $chain -m state --state ESTABLISHED,RELATED -j ACCEPT run_iptables -D $chain -p udp --dport 53 -j ACCEPT done } diff --git a/STABLE/functions b/STABLE/functions index 746a86657..621a7cf38 100644 --- a/STABLE/functions +++ b/STABLE/functions @@ -83,29 +83,23 @@ find_display() # $1 = zone, $2 = name of the zone file [ "x$1" = "x$z" ] && echo $display done } - +# +# This function assumes that the TMP_DIR variable is set and that +# its value named an existing directory. +# determine_zones() { local zonefile=`find_file zones` multi_display=Multi-zone - - if [ -f $zonefile ]; then - zones=`find_zones $zonefile` - zones=`echo $zones` # Remove extra trash - - for zone in $zones; do - dsply=`find_display $zone $zonefile` - eval ${zone}_display=\$dsply - done - else - zones="net local dmz gw" - net_display=Net - local_display=Local - dmz_display=DMZ - gw_display=Gateway - fi - + strip_file zones $zonefile + zones=`find_zones $TMP_DIR/zones` + zones=`echo $zones` # Remove extra trash + + for zone in $zones; do + dsply=`find_display $zone $TMP_DIR/zones` + eval ${zone}_display=\$dsply + done } # diff --git a/STABLE/install.sh b/STABLE/install.sh index 09c34d68f..a51dd999c 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.4.4b +VERSION=1.4.5 usage() # $1 = exit status { diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index efa8ced70..670d034f7 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -2,32 +2,19 @@ This is a minor release of Shorewall. Problems Corrected: +1) The command "shorewall debug try " now correctly traces + the attempt. + +2) The INCLUDE directive now works properly in the zones file; + previously, INCLUDE in that file was ignored. + +3) /etc/shorewall/routestopped records with an empty second column are no + longer ignored. + New Features: -1) A REDIRECT- rule target has been added. This target behaves for - REDIRECT in the same was as DNAT- does for DNAT in that the - Netfilter nat table REDIRECT rule is added but not the companion - filter table ACCEPT rule. - -2) The LOGMARKER variable has been renamed LOGFORMAT and has been - changed to a 'printf' formatting template which accepts three - arguments (the chain name, logging rule number (optional) and the - disposition). The logging rule number is included if the LOGFORMAT - value contains '%d'. For example, to use LOGFORMAT with fireparse, - set it as: - - LOGFORMAT="fp=%s:%d a=%s " - - - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages - in the 'show log', 'status' and 'hits' commands. This part should - not be omitted (the LOGFORMAT should not begin with "%") and the - leading part should be sufficiently unique for /sbin/shorewall to - identify Shorewall messages. - -3) When logging is specified on a DNAT[-] or REDIRECT[-] rule, the - logging now takes place in the nat table rather than in the filter - table. This way, only those connections that actually undergo DNAT - or redirection will be logged. +1) The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule may now + contain a list of addresses. If the list begins with "!' then the + rule will take effect only if the original destination address in + the connection request does not match any of the addresses listed. diff --git a/STABLE/rules b/STABLE/rules index e658a9e9f..5cc3c328e 100644 --- a/STABLE/rules +++ b/STABLE/rules @@ -31,6 +31,11 @@ # the companion ACCEPT rule. # REDIRECT -- Redirect the request to a local # port on the firewall. +# REDIRECT- +# -- Advanced users only. +# Like REDIRET but only generates the +# REDIRECT iptables rule and not +# the companion ACCEPT rule. # CONTINUE -- (For experts only). Do not process # any of the following rules for this # (source zone,destination zone). If @@ -157,14 +162,24 @@ # Otherwise, a separate rule will be generated for each # port. # -# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT or -# REDIRECT) If included and different from the IP +# ORIGINAL DEST (0ptional -- only allowed if ACTION is DNAT[-] or +# REDIRECT[-]) If included and different from the IP # address given in the SERVER column, this is an address # on some interface on the firewall and connections to # that address will be forwarded to the IP and port # specified in the DEST column. # -# The address may optionally be followed by +# A comma-separated list of addresses may also be used. +# This is usually most useful with the REDIRECT target +# where you want to redirect traffic destined for +# particular set of hosts. +# +# Finally, if the list of addresses begins with "!" then +# the rule will be followed only if the original +# destination address in the connection request does not +# match any of the addresses listed. +# +# The address (list) may optionally be followed by # a colon (":") and a second IP address. This causes # Shorewall to use the second IP address as the source # address in forwarded packets. See the Shorewall diff --git a/STABLE/shorewall b/STABLE/shorewall index 44c9cc5db..fa5555fa3 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -348,7 +348,16 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that timeout=$1 fi - qt which awk && { haveawk=Yes; determine_zones; } || haveawk= + + if qt which awk; then + TMP_DIR=/tmp/shorewall-$$ + mkdir $TMP_DIR + haveawk=Yes + determine_zones + rm -rf $TMP_DIR + else + haveawk= + fi while true; do display_chains @@ -756,7 +765,7 @@ case "$1" in echo " HITS PORT SERVICE(S)" echo " ---- ----- ----------" - grep '${LOGFORMAT}.*DPT' $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ + grep "$LOGFORMAT.*DPT" $LOGFILE | sed 's/\(.*DPT=\)\([0-9]\{1,5\}\)\(.*\)/\2/' | sort | uniq -c | sort -rn | \ while read count port ; do # List all services defined for the given port srv=`grep "^[^#].*\\b$port/" /etc/services | cut -f 1 | sort -u` @@ -776,7 +785,7 @@ case "$1" in try) [ -n "$SHOREWALL_DIR" ] && startup_error "Error: -c option may not be used with \"try\"" [ $# -lt 2 -o $# -gt 3 ] && usage 1 - if ! $0 -c $2 restart; then + if ! $0 $debugging -c $2 restart; then if ! iptables -L shorewall > /dev/null 2> /dev/null; then $0 start fi diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 9f0f91acf..526f74ab4 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.4.4b +%define version 1.4.5 %define release 1 %define prefix /usr @@ -105,6 +105,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Tue Jun 17 2003 Tom Eastep +- Changed version to 1.4.5-1 * Thu May 29 2003 Tom Eastep - Changed version to 1.4.4b-1 * Tue May 27 2003 Tom Eastep diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index d8cff3b55..e6738e95f 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.4.4b +VERSION=1.4.5 usage() # $1 = exit status {