diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index b8dbf4ef3..c0f8ce32a 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -2,1726 +2,1853 @@ + + + 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.

- + +

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

- + +

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

+ - -

- -

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:

- -
- - + +

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

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

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

- -
- - + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - -
netNetInternet
locLocalLocal + networks
dmzDMZDemilitarized + zone
ZONE INTERFACE BROADCAST OPTIONS
netppp0
-
-
-
- -

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

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

/etc/shorewall/hosts - Configuration

- -

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

- -

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

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

Columns in this file are:

- + + + + +

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:

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

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

-
- - - -
-

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

-
- -

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

- -

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

- -

Example 1:

- -

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

- - - -

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

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

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

- -

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

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

Example 2:

- -

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

- - - -

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

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

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

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

Nested and Overlapping -Zones

- -

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

- -

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

- -

/etc/shorewall/policy - Configuration.

- -

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

- -

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

- -

Four policies are defined:

- - - -

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

- -

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

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

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

- -

The policy file installed by default is as follows:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDEST POLICY LOG -LEVELLIMIT:BURST
locnetACCEPT
-
-
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
-
- -

/etc/shorewall/interfaces:

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

/etc/shorewall/hosts:

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

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

- -

/etc/shorewall/policy:

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

- -

Partial /etc/shorewall/rules:

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

-
-
-
-
-
-
-
...
-
-
-
-
-
-
DNATsamfwtcpssh-
-
DNATnet!samloc:192.168.1.3tcpssh-
-
...
-
-
-
-
-
-
-
- -

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

- -

/etc/shorewall/rules

- -

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

- -

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

- -

Entries in the file have the following columns:

- - + +

My recommendations concerning options:
+

+ + + +

+ +

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

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

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

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

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

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

/etc/shorewall/hosts + Configuration

+ +

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

+ +

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

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

Columns in this file are:

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

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

+

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

+
+ + + +
+ +

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 /etc/shorewall/interfaces file might look like:

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

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

+ +

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

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

Example 2:

+ +

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

+ + + +

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

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

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

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

Nested and Overlapping Zones

+ +

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

+ +

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

+ +

/etc/shorewall/policy + Configuration.

+ +

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

+ +

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

+ +

Four policies are defined:

+ + + +

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

The CONTINUE + policy

+ +

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

+ +

/etc/shorewall/zones:

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

/etc/shorewall/interfaces:

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

/etc/shorewall/hosts:

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

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

+ +

/etc/shorewall/policy:

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

+ +

Partial /etc/shorewall/rules:

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

+
+
+
+
+
+
+
...
+
+
+
+
+
+
DNATsamfwtcpssh-
+
DNATnet!samloc:192.168.1.3tcpssh-
+
...
+
+
+
+
+
+
+
+ +

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

+ +

/etc/shorewall/rules

+ +

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

+ +

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

+ +

Entries in the file have the following columns:

+ + - +

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

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

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

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

- +
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
ACTIONSOURCEDEST +PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
REDIRECTloc3128tcpwww -
+ 		!206.124.146.177
ACCEPTfwnettcpwww
+
+
-
- -

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

- + + +

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

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

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

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 @@ -1734,1617 +1861,1605 @@ rule though because clearly not what you want - .

- + .

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

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

- -
+
+ +

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

+ +
+

passive ports 0.0.0.0/0 65500 65534

-
- -

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

- -

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

- -

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

- + + +

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

+ +

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

+ +

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

+
- + face="Century Gothic, Arial, Helvetica"> + - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-
-
-
ACTIONSOURCEDEST +PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
+
+
+
-
+ - Example 6. You wish to allow access to -the SMTP server in your DMZ from all zones.
- -
+ Example 6. You wish to allow access +to the SMTP server in your DMZ from all zones.
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		all
- 		dmz
- 		tcp
- 		25
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		all
+ 		dmz
+ 		tcp
+ 		25
+
+
+
-
- Note: When 'all' is used as a -source or destination, intra-zone traffic is not affected. -In this example, if there were two DMZ interfaces then the - above rule would NOT enable SMTP traffic between hosts on these - interfaces.
-
- Example 7. Your firewall's external - interface has several IP addresses but you only want to accept SSH connections - on address 206.124.146.176.
- -
+
+ Note: When 'all' is used as +a source or destination, intra-zone traffic is not affected. + In this example, if there were two DMZ interfaces then the + above rule would NOT enable SMTP traffic between hosts on these + interfaces.
+
+ Example 7. Your firewall's + external interface has several IP addresses but you only want to accept + SSH connections on address 206.124.146.176.
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		net
- 		fw:206.124.146.176
- 		tcp
- 		22
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		net
+ 		fw:206.124.146.176
+ 		tcp
+ 		22
+
+
+
-
- Example 8 (For advanced users running Shorewall version - 1.3.13 or later). From the internet, you with to forward - tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to host - 192.0.2.177 in your DMZ. You also want to allow access from the - internet directly to tcp port 25 on 192.0.2.177.
- -
+
+ Example 8 (For advanced users running Shorewall version + 1.3.13 or later). From the internet, you with to forward + tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to host + 192.0.2.177 in your DMZ. You also want to allow access from the + internet directly to tcp port 25 on 192.0.2.177.
+ +
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
DNAT-
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
- 		0
- 		192.0.2.178
-
DNAT-
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
- 		0
- 		192.0.2.179
-
ACCEPT
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.178
+
DNAT-
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+ 		0
+ 		192.0.2.179
+
ACCEPT
+ 		net
+ 		dmz:192.0.2.177
+ 		tcp
+ 		25
+
+
+
-
- Using "DNAT-" rather than "DNAT" avoids - two extra copies of the third rule from being generated.
-
- Example 9a (Shorewall version 1.4.6 or later). You have 9 http servers - behind a Shorewall firewall and you want connection requests to be distributed - among your servers. The servers are 192.168.1.101-192.168.1.109.
-
- -
+
+ Using "DNAT-" rather than "DNAT" +avoids two extra copies of the third rule from being generated.
+
+ Example 9 (Shorewall version 1.4.6 or later). You have 9 http +servers behind a Shorewall firewall and you want connection requests to +be distributed among your servers. The servers are 192.168.1.101-192.168.1.109.
+
+ +
+ - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + - - + + +
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
DNAT
- 		net
- 		loc:192.168.1.101-192.168.1.109
- 		tcp
- 		80
-
-
-
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		SOURCE
+ PORT(S)
+ 		ORIGINAL
+ DEST
+
DNAT
+ 		net
+ 		loc:192.168.1.101-192.168.1.109
+ 		tcp
+ 		80
+
+
+
-
- Note that Shorewall limits the use of IP - ranges in DNAT rules to 256 addresses. For even a moderate number of addresses - (> 16), it is better to split the single DNAT rule into a DNAT- rule -that specifies the range of addresses (no limit on the number of addresses -in the range) and one or more ACCEPT rules that use CIDR in the destination -to cover the range. For example, if the range of addresses was 192.168.1.32 -- 192.168.1.63:
-
- Example 9b:
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
DNAT-
- 		net
- 		loc:192.168.1.32-192.168.1.63
- 		tcp
- 		80
-
-
-
ACCEPT
- 		net
- 		loc:192.168.1.32/27
- 		tcp
- 		80
-
-
-
-
-
- The above generates a much more efficient ruleset than the one in Example - 9a.
- -

Look here for information on other services. -

- +
+ +

Look here for information on other services. +

+

/etc/shorewall/common

- -

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

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

- -

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

- + +

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

+

/etc/shorewall/masq

- -

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

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 +

+ +

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

+ +

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 +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 - the SNAT rule.

- -
+
+ +

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 +

+ +

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

+ +

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

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

- + href="#ProxyArp"> 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 +

+
+ +

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>

-
- -

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:

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

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

-
-
- -

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

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

+
+
+ +

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

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

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

- +
+ +

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

+

/etc/shorewall/blacklist

- -

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

- + +

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

+ 
      130.252.100.69
      206.124.146.0/24
- -

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

- + +

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

+

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

- +

+
    -
  • ADDRESS/SUBNET -- As described above.
    • -
  • PROTOCOL - -Optional. If specified, only packets specifying this -protocol will be blocked.
    • -
  • PORTS - Optional; - may only be given if PROTOCOL is tcp, udp or icmp. Expressed - as a comma-separated list of port numbers or service names - (from /etc/services). If present, only packets destined for the - specified protocol and one of the listed ports are blocked. When - the PROTOCOL is icmp, the PORTS column contains a comma-separated - list of ICMP type numbers or names (see "iptables -h icmp").
    -
    • - +
  • ADDRESS/SUBNET + - As described above.
    • +
  • PROTOCOL +- Optional. If specified, only packets specifying this + protocol will be blocked.
    • +
  • PORTS - Optional; + may only be given if PROTOCOL is tcp, udp or icmp. +Expressed as a comma-separated list of port numbers or service + names (from /etc/services). If present, only packets destined + for the specified protocol and one of the listed ports are +blocked. When the PROTOCOL is icmp, the PORTS column contains + a comma-separated list of ICMP type numbers or names (see "iptables + -h icmp").
    +
    • +
- -

Shorewall also has a dynamic blacklist - capability.

- -

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

Shorewall also has a dynamic blacklist + capability.

+ +

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

- +

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

- -

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

- + +

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

+
    -
  • SUBNET - - The subnet using VLSM notation (e.g., 192.168.0.0/16).
    • -
  • TARGET - - What to do with packets to/from the SUBNET: - - +
  • SUBNET + - The subnet using VLSM notation (e.g., 192.168.0.0/16).
    • +
  • TARGET + - What to do with packets to/from the + SUBNET: +
      -
    • RETURN - - Process the packet normally thru the rules and 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.
- + This file is described in + the MAC Validation Documentation.
+

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

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

Updated 6/28/2003 - Tom Eastep -

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

Updated 6/28/2003 - Tom Eastep +

+

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

+

+
+
+
diff --git a/Shorewall-docs/FAQ.htm b/Shorewall-docs/FAQ.htm index 9c90fbc71..26a4781bd 100644 --- a/Shorewall-docs/FAQ.htm +++ b/Shorewall-docs/FAQ.htm @@ -1,1316 +1,1317 @@ - + - + - + - + Shorewall FAQ - + - + - - - + + - - - + + + +
- +
+

Shorewall FAQs

-
- +

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

- + +

PORT FORWARDING
-

- -

1. I want to forward UDP - port 7777 to my my personal PC with IP -address 192.168.1.5. I've looked everywhere and -can't find how to do it.

- -

1a. Ok -- I followed those instructions - but it doesn't work.
-

- -

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

- -

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

- -

DNS and PORT FORWARDING/NAT
-

- -

2. I port forward www requests - to www.mydomain.com (IP 130.151.100.69) to system - 192.168.1.5 in my local network. External clients - can browse http://www.mydomain.com but internal - clients can't.

- -

2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign - non-RFC1918 addresses to hosts in Z. Hosts in Z -cannot communicate with each other using their external - (non-RFC1918 addresses) so they can't access each other -using their DNS names.

- -

NETMEETING/MSN
-

- -

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

- -

OPEN PORTS
-

- -

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

- -

4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports -as open!!!!
-

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

CONNECTION PROBLEMS

- -

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

- -

LOGGING
-

- -

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

- -

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

- -

6b. DROP messages on port 10619 are flooding the logs with their connect - requests. Can i exclude these error messages for this port -temporarily from logging in Shorewall?
-

- -

6c. All day long I get a steady flow - of these DROP messages from port 53 to some high -numbered port. They get dropped, but what the heck are -they?
-

- -

6d. Why is the MAC address - in Shorewall log messages so long? I thought MAC addresses - were only 6 bytes in length.
-

- -

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

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

STARTING AND STOPPING
-

- -

7. When I stop Shorewall using -'shorewall stop', I can't connect to anything. Why doesn't that command - work?

- -

8. When I try to start Shorewall - on RedHat I get messages about insmod failing - -- what's wrong?
-

- -

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

- -

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

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

ABOUT SHOREWALL
-

- -

10. What distributions does - it work with?

- -

11. What features does it -support?

- -

12. Is there a GUI?

- -

13. Why do you call it "Shorewall"?

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

RFC 1918
-

- -

14. I'm connected via a cable modem - and it has an internel web server that allows - me to configure/monitor it but as expected if I -enable rfc1918 blocking for my eth0 interface, - it also blocks the cable modems web server.

- -

14a. Even though it assigns public - IP addresses, my ISP's DHCP server has an RFC - 1918 address. If I enable RFC 1918 filtering on my - external interface, my DHCP client cannot renew its lease.

- -

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
-

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

MISCELLANEOUS

- 19. I have added entries to - /etc/shorewall/tcrules but they don't seem to do - anything. Why?
-
- 20. I have just set up a server. Do I have + +

1. I want to forward UDP + port 7777 to my my personal PC with IP address + 192.168.1.5. I've looked everywhere and can't +find how to do it.

+ +

1a. Ok -- I followed those instructions + but it doesn't work.
+

+ +

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

+ +

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

+ +

DNS and PORT FORWARDING/NAT
+

+ +

2. I port forward www requests + to www.mydomain.com (IP 130.151.100.69) to system + 192.168.1.5 in my local network. External clients + can browse http://www.mydomain.com but internal + clients can't.

+ +

2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign + non-RFC1918 addresses to hosts in Z. Hosts in Z +cannot communicate with each other using their external + (non-RFC1918 addresses) so they can't access each other +using their DNS names.

+ +

NETMEETING/MSN
+

+ +

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

+ +

OPEN PORTS
+

+ +

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

+ +

4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as + open!!!!
+

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

CONNECTION PROBLEMS

+ +

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

+ +

LOGGING
+

+ +

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

+ +

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

+ +

6b. DROP messages on port 10619 are flooding the logs with their connect + requests. Can i exclude these error messages for this port temporarily + from logging in Shorewall?
+

+ +

6c. All day long I get a steady flow + of these DROP messages from port 53 to some high numbered + port. They get dropped, but what the heck are they?
+

+ +

6d. Why is the MAC address + in Shorewall log messages so long? I thought MAC addresses + were only 6 bytes in length.
+

+ +

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

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

STARTING AND STOPPING
+

+ +

7. When I stop Shorewall using 'shorewall +stop', I can't connect to anything. Why doesn't that command + work?

+ +

8. When I try to start Shorewall + on RedHat I get messages about insmod failing + -- what's wrong?
+

+ +

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

+ +

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

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

ABOUT SHOREWALL
+

+ +

10. What distributions does + it work with?

+ +

11. What features does it support?

+ +

12. Is there a GUI?

+ +

13. Why do you call it "Shorewall"?

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

RFC 1918
+

+ +

14. I'm connected via a cable modem + and it has an internel web server that allows + me to configure/monitor it but as expected if I enable + rfc1918 blocking for my eth0 interface, it also + blocks the cable modems web server.

+ +

14a. Even though it assigns public + IP addresses, my ISP's DHCP server has an RFC + 1918 address. If I enable RFC 1918 filtering on my + external interface, my DHCP client cannot renew its lease.

+ +

ALIAS IP ADDRESSES/VIRTUAL INTERFACES
+

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

MISCELLANEOUS
+

+ 19. I have added entries to + /etc/shorewall/tcrules but they don't seem to do + anything. Why?
+
+ 20. I have just set up a server. Do I have to change Shorewall to allow access to my server from the internet?
-
- 24. How can I allow - conections to let's say the ssh port only from specific - IP Addresses on the internet?
-
- 26. When I try to use any of the -SYN options in nmap on or behind the firewall, I get "operation +
+ 24. How can I allow + conections to let's say the ssh port only from specific + IP Addresses on the internet?
+
+ 26. When I try to use any of the +SYN options in nmap on or behind the firewall, I get "operation not permitted". How can I use nmap with Shorewall?"
- -
-

1. I want to forward UDP port 7777 to - my my personal PC with IP address 192.168.1.5. - I've looked everywhere and can't find how to do -it.

- + +
+

1. I want to forward UDP port 7777 to + my my personal PC with IP address 192.168.1.5. + I've looked everywhere and can't find how to do it.

+

Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. The format + href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a port-forwarding rule to a local system is as follows:

- -
+ +
- - - - - - - - + + + + + + + - - - - - - + + + + - - + - - - - - + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATnetloc:<local +
DNATnetloc:<local IP address>[:<local port>]<protocol><port + <protocol><port #>
-
-

+
+
-
- -

So to forward UDP port 7777 to internal system 192.168.1.5, +

+ +

So to forward UDP port 7777 to internal system 192.168.1.5, the rule is:

- -
+ +
- - - - - - - - + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATnetloc:192.168.1.5udp7777
-
-
DNATnetloc:192.168.1.5udp7777
+
+
-
- -
If - you want to forward requests directed to a particular -address ( <external IP> ) on your firewall -to an internal system:
- -
+
+ +
If + you want to forward requests directed to a particular address + ( <external IP> ) on your firewall to an internal + system:
+ +
- - - - - - - - + + + + + + + - - - - - - + + + + - - + - - + - - - + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATnetloc:<local +
DNATnetloc:<local IP address>[:<local port>]<protocol><port + <protocol><port #>-<external + -<external IP>
-
- Finally, if you need to forward a range of ports, -in the PORT column specify the range as low-port:high-port.
- -

1a. Ok -- I followed those instructions - but it doesn't work

- -

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

- -
    -
  • You are -trying to test from inside your firewall (no, that won't - work -- see FAQ #2).
    • -
  • You have - a more basic problem with your local system such as - an incorrect default gateway configured (it should be -set to the IP address of your firewall's internal interface).
    • -
  • Your ISP is blocking that particular port inbound.
    -
    • - -
- -

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

- Answer: To further - diagnose this problem:
- -
    -
  • As root, type "iptables - -t nat -Z". This clears the NetFilter counters in the - nat table.
    • -
  • Try to connect to -the redirected port from an external host.
    • -
  • As root type "shorewall - show nat"
    • -
  • Locate the appropriate - DNAT rule. It will be in a chain called <source - zone>_dnat ('net_dnat' in the above examples).
    • -
  • Is the packet count - in the first column non-zero? If so, the connection - request is reaching the firewall and is being redirected -to the server. In this case, the problem is usually a missing - or incorrect default gateway setting on the server (the server's - default gateway should be the IP address of the firewall's - interface to the server).
    • -
  • If the packet count - is zero:
    • - -
      -
    • the connection -request is not reaching your server (possibly it is -being blocked by your ISP); or
      • -
    • you are trying -to connect to a secondary IP address on your firewall - and your rule is only redirecting the primary IP address -(You need to specify the secondary IP address in the "ORIG. - DEST." column in your DNAT rule); or
      • -
    • your DNAT rule -doesn't match the connection request in some other - way. In that case, you may have to use a packet sniffer such - as tcpdump or ethereal to further diagnose the problem.
      -
      • - -
    - -
- -

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

- -
-
- - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE - PORTORIG. - DEST.
DNATnet
- 		loc:192.168.1.3:22tcp1022
-
-
-
-
-
- -

2. I port forward www requests to www.mydomain.com - (IP 130.151.100.69) to system 192.168.1.5 in -my local network. External clients can browse http://www.mydomain.com - but internal clients can't.

- -

Answer: I have two objections to this setup.

- -
    -
  • Having -an internet-accessible server in your local network - is like raising foxes in the corner of your hen house. - If the server is compromised, there's nothing between - that server and your other internal systems. For the -cost of another NIC and a cross-over cable, you can put -your server in a DMZ such that it is isolated from your local systems - - assuming that the Server can be located near the Firewall, - of course :-)
    • -
  • The accessibility - problem is best solved using Bind Version 9 "views" - (or using a separate DNS server for local clients) such that www.mydomain.com - resolves to 130.141.100.69 externally and 192.168.1.5 - internally. That's what I do here at shorewall.net for -my local systems that use static NAT.
    • - -
+
+ Finally, if you need to forward a range of ports, + in the PORT column specify the range as low-port:high-port.
-

If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that - your external interface is eth0 and your internal - interface is eth1 and that eth1 has IP address 192.168.1.254 - with subnet 192.168.1.0/24.
-

- -

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

- -

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

- -

Otherwise:
-

- +

1a. Ok -- I followed those instructions + but it doesn't work

+ +

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

+
    - +
  • You are + trying to test from inside your firewall (no, that + won't work -- see FAQ #2).
    • +
  • You have + a more basic problem with your local system such as + an incorrect default gateway configured (it should be +set to the IP address of your firewall's internal interface).
    • +
  • Your ISP is blocking that particular port inbound.
    +
    • +
- + +

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

+ Answer: To further + diagnose this problem:
+
    - +
  • As root, type "iptables + -t nat -Z". This clears the NetFilter counters in +the nat table.
    • +
  • Try to connect to + the redirected port from an external host.
    • +
  • As root type "shorewall + show nat"
    • +
  • Locate the appropriate + DNAT rule. It will be in a chain called <source + zone>_dnat ('net_dnat' in the above examples).
    • +
  • Is the packet count + in the first column non-zero? If so, the connection + request is reaching the firewall and is being redirected + to the server. In this case, the problem is usually a missing + or incorrect default gateway setting on the server (the +server's default gateway should be the IP address of the firewall's + interface to the server).
    • +
  • If the packet count + is zero:
    • + +
      +
    • the connection +request is not reaching your server (possibly it is +being blocked by your ISP); or
      • +
    • you are trying +to connect to a secondary IP address on your firewall + and your rule is only redirecting the primary IP address (You + need to specify the secondary IP address in the "ORIG. DEST." +column in your DNAT rule); or
      • +
    • your DNAT rule +doesn't match the connection request in some other +way. In that case, you may have to use a packet sniffer such + as tcpdump or ethereal to further diagnose the problem.
      +
      • + +
    +
- -
    -
  • 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
DNAT
- 		locweb:192.168.1.5
- 		tcpwww -
- 		130.151.100.69:192.168.1.254
-
-
- -
-

That rule only works of course if you have a static external - IP address. If you have a dynamic IP address - and are running Shorewall 1.3.4 or later then include - this in /etc/shorewall/init:

-
- -
-
     ETH0_IP=`find_interface_address eth0`
-
- -
-

and make your DNAT rule:

-
- -
-
+ +

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

+ +
+
- - - - - - - - + + + + + + + - - - - - - - - - - - - - + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIG. + ORIG. DEST.
DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
DNATnet
+ 		loc:192.168.1.3:22tcp1022
+
+
+
-
+
+
+ +

2. I port forward www requests to www.mydomain.com + (IP 130.151.100.69) to system 192.168.1.5 in +my local network. External clients can browse http://www.mydomain.com + but internal clients can't.

+ +

Answer: I have two objections to this setup.

+ +
    +
  • Having +an internet-accessible server in your local network + is like raising foxes in the corner of your hen house. +If the server is compromised, there's nothing between + that server and your other internal systems. For the cost +of another NIC and a cross-over cable, you can put your + server in a DMZ such that it is isolated from your local systems + - assuming that the Server can be located near the Firewall, + of course :-)
    • +
  • The accessibility + problem is best solved using Bind Version 9 "views" + (or using a separate DNS server for local clients) such that www.mydomain.com + resolves to 130.141.100.69 externally and 192.168.1.5 + internally. That's what I do here at shorewall.net for my + local systems that use static NAT.
    • + +
+ +

If you insist on an IP solution to the accessibility problem + rather than a DNS solution, then assuming that + your external interface is eth0 and your internal + interface is eth1 and that eth1 has IP address 192.168.1.254 + with subnet 192.168.1.0/24.
+

+ +

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

+ +

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

+ +

Otherwise:
+

+ +
    + +
+ +
    + +
+ +
    +
  • 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
DNAT
+ 		locweb:192.168.1.5
+ 		tcpwww -
+ 		130.151.100.69:192.168.1.254
+
+
+ +
+

That rule only works of course if you have a static external + IP address. If you have a dynamic IP address + and are running Shorewall 1.3.4 or later then include + this in /etc/shorewall/init:

- -
-

Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each - time that you get a new IP address.

-
- -

2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 - addresses to hosts in Z. Hosts in Z cannot communicate - with each other using their external (non-RFC1918 -addresses) so they can't access each other using their DNS - names.

- -

Answer: This is another problem that is best solved - using Bind Version 9 "views". It allows both -external and internal clients to access a NATed -host using the host's DNS name.

- -

Another good way to approach this problem is to switch from - static NAT to Proxy ARP. That way, the hosts - in Z have non-RFC1918 addresses and can be accessed + +

+
     ETH0_IP=`find_interface_address eth0`
+
+ +
+

and make your DNAT rule:

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE + PORTORIG. + DEST.
DNATlocweb:192.168.1.5tcpwww-$ETH0_IP:192.168.1.254
+
+
+ +
+

Using this technique, you will want to configure your DHCP/PPPoE + client to automatically restart Shorewall each + time that you get a new IP address.

+
+ +

2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 + addresses to hosts in Z. Hosts in Z cannot communicate + with each other using their external (non-RFC1918 addresses) + so they can't access each other using their DNS names.

+ +

Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both +external and internal clients to access a NATed host +using the host's DNS name.

+ +

Another good way to approach this problem is to switch from + static NAT to Proxy ARP. That way, the hosts + in Z have non-RFC1918 addresses and can be accessed externally and internally using the same address.

- -

If you don't like those solutions and prefer routing all Z->Z -traffic through your firewall then:

- + +

If you don't like those solutions and prefer routing all +Z->Z traffic through your firewall then:

+

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

- + b) Masquerade + Z to itself.
+
+ Example:

+

Zone: dmz
- Interface: eth2
- Subnet: 192.168.2.0/24

- + Interface: eth2
+ Subnet: 192.168.2.0/24

+

In /etc/shorewall/interfaces:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
ZONEINTERFACEBROADCASTOPTIONS
ZONEINTERFACEBROADCASTOPTIONS
dmzeth2192.168.2.255
-
dmzeth2192.168.2.255
+
-
- +
+

In /etc/shorewall/policy:

- -
+ +
- - - + + - - - - - - - - - - - - + + + + + + + + + + + +
SOURCE +
SOURCE DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
-
DESTINATIONPOLICYLIMIT:BURST
dmzdmzACCEPT
+
-
- +
+

In /etc/shorewall/masq:

- -
+ +
- - - + - - + + + + + + + + +
+
INTERFACE SUBNETADDRESS
eth2192.168.2.0/24
+
+
+ +

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

+ +

Answer: There is an H.323 connection + tracking/NAT module that may help with Netmeeting. + Look here for +a solution for MSN IM but be aware that there are significant security + risks involved with this solution. Also check the Netfilter +mailing list archives at http://www.netfilter.org. +

+ +

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

+ +

Answer: The common.def included with version 1.3.x + always rejects connection requests on TCP +port 113 rather than dropping them. This is necessary + to prevent outgoing connection problems to services + that use the 'Auth' mechanism for identifying requesting + users. Shorewall also rejects TCP ports 135, 137 and +139 as well as UDP ports 137-139. These are ports that are + used by Windows (Windows can be configured to use the +DCE cell locator on port 135). Rejecting these connection requests + rather than dropping them cuts down slightly on the amount of +Windows chatter on LAN segments connected to the Firewall. +

+ +

If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web + server in violation of your Service Agreement.

+ +

4a. I just ran an nmap UDP scan of my + firewall and it showed 100s of ports as open!!!!

+ +

Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing + back from your firewall then it reports the port + as open. If you want to see which UDP ports are really + open, temporarily change your net->all policy to +REJECT, restart Shorewall and do the nmap UDP scan again.
+

+ +

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

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

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

+ +

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

+ +

a) Create /etc/shorewall/common if it doesn't already exist. +
+ b) Be sure that + the first command in the file is ". /etc/shorewall/common.def"
+ c) Add the following + to /etc/shorewall/common

+ +
+

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

+
+ For a complete description of Shorewall + 'ping' management, see this page. + +

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

+ +

Answer: NetFilter uses the kernel's equivalent of +syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern) +facility (see "man openlog") and you get to choose the log level (again, +see "man syslog") in your policies + and rules. The destination for messaged + logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). + When you have changed /etc/syslog.conf, be sure + to restart syslogd (on a RedHat system, "service syslog + restart").

+ +

By default, older versions of Shorewall ratelimited log messages + through settings + in /etc/shorewall/shorewall.conf -- If you want + to log all messages, set:

+ +
+
     LOGLIMIT=""
     LOGBURST=""
+ Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages + to a separate file.
+
+ +

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

+ +

Answer: Here are several links that may be helpful: +

+ +
+

http://www.shorewall.net/pub/shorewall/parsefw/
+ http://www.fireparse.com
+ http://cert.uni-stuttgart.de/projects/fwlogwatch
+ http://www.logwatch.org
+ http://gege.org/iptables
+

+
+ I personnaly use Logwatch. It emails + me a report each day from my various systems with each +report summarizing the logged activity on the corresponding + system. +

6b. DROP messages on port 10619 + are flooding the logs with their connect requests. Can + i exclude these error messages for this port temporarily from logging + in Shorewall?

+ Temporarily add the following rule:
+ +
	DROP    net    fw    udp    10619
+ +

6c. All day long I get a steady flow + of these DROP messages from port 53 to some high numbered port. + They get dropped, but what the heck are they?

+ +
Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
                                                        SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
                                                        TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
+ Answer: There are two possibilities:
+ +
    +
  1. They are late-arriving replies to DNS +queries.
    2. +
  2. They are corrupted reply packets.
    3. + +
+ You can distinguish the difference by setting + the logunclean option (/etc/shorewall/interfaces) + on your external interface (eth0 in the above example). If they get + logged twice, they are corrupted. I solve this problem by using + an /etc/shorewall/common file like this:
+ +
+ 
#
# Include the standard common.def file
#
. /etc/shorewall/common.def
#
# The following rule is non-standard and compensates for tardy
# DNS replies
#
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
+
+ The above file is also include in all of my +sample configurations available in the Quick Start Guides and in + the common.def file in Shorewall 1.4.0 and later.
+ +

6d. Why is the MAC address in + Shorewall log messages so long? I thought MAC addresses were only + 6 bytes in length.

+ What is labeled as the MAC address in a Shorewall log message + is actually the Ethernet frame header. IT contains:
+ +
    +
  • the destination MAC address (6 bytes)
    • +
  • the source MAC address (6 bytes)
    • +
  • the ethernet frame type (2 bytes)
    • + +
+ Example:
+
+ MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
+ +
    +
  • Destination MAC address = 00:04:4c:dc:e2:28
    • +
  • Source MAC address = 00:b0:8e:cf:3c:4c
    • +
  • Ethernet Frame Type = 08:00 (IP Version 4)
    • + +
+ +

7. When I stop Shorewall using 'shorewall + stop', I can't connect to anything. Why doesn't + that command work?

+ +

The 'stop' command is intended to place your firewall into + a safe state whereby only those hosts listed +in /etc/shorewall/routestopped' are activated. If +you want to totally open up your firewall, you must use the +'shorewall clear' command.

+ +

8. When I try to start Shorewall on RedHat, + I get messages about insmod failing -- what's wrong?

+ +

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

+ +
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
     Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
     iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
     Perhaps iptables or your kernel needs to be upgraded.
+ +

This is usually cured by the following sequence of commands: +

+ +
+
     service ipchains stop
     chkconfig --delete ipchains
     rmmod ipchains
+
+ +
+

Also, be sure to check the errata + for problems concerning the version of iptables + (v1.2.3) shipped with RH7.2.
+

+ +

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

+ Answer: This is usually cured by the sequence of commands + shown above in FAQ #8 +
+ +

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

+ +

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

+ +
+
     Processing /etc/shorewall/params ...
     Processing /etc/shorewall/shorewall.conf ...
     Starting Shorewall...
     Loading Modules...
     Initializing...
     Determining Zones...
     Zones: net loc
     Validating interfaces file...
     Validating hosts file...
     Determining Hosts in Zones...
     Net Zone: eth0:0.0.0.0/0
     Local Zone: eth1:0.0.0.0/0
     Deleting user chains...
     Creating input Chains...
     ...
+
+ +
+

Why can't Shorewall detect my interfaces properly?

+
+ +
+

Answer: The above output is perfectly normal. The +Net zone is defined as all hosts that are connected through eth0 and the +local zone is defined as all hosts connected through eth1

+
+ +

10. What Distributions does it work + with?

+ +

Shorewall works with any GNU/Linux distribution that includes + the proper prerequisites.

+ +

11. What Features does it have?

+ +

Answer: See the Shorewall + Feature List.

+ +

12. Is there a GUI?

+ +

Answer: Yes. Shorewall support is included in Webmin + 1.060 and later versions. See http://www.webmin.com +

+ +

13. Why do you call it "Shorewall"?

+ +

Answer: Shorewall is a concatenation of "Shoreline" + (the + city where I live) and "Firewall". The full + name of the product is actually "Shoreline Firewall" but "Shorewall" + is must more commonly used.

+ +

14. I'm connected via a cable modem + and it has an internal web server that allows + me to configure/monitor it but as expected if I +enable rfc1918 blocking for my eth0 interface (the internet + one), it also blocks the cable modems web server.

+ +

Is there any way it can add a rule before the rfc1918 blocking + that will let all traffic to and from the 192.168.100.1 + address of the modem in/out but still block all other + rfc1918 addresses?

+ +

Answer: If you are running a version of Shorewall +earlier than 1.3.1, create /etc/shorewall/start and in it, place the +following:

+ +
+
     run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
+
+ +
+

If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:

+
+ +
+
+ + + + + + + + + + + + +
SUBNET + TARGET
192.168.100.1RETURN
+
+
+ +
+

Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
+

+ +

Note: If you add a second IP address to your external firewall + interface to correspond to the modem address, +you must also make an entry in /etc/shorewall/rfc1918 +for that address. For example, if you configure the address + 192.168.100.2 on your firewall, then you would add two entries + to /etc/shorewall/rfc1918:
+

+ +
+ + + + + - - - - - -
SUBNET
+ 		TARGET
+
eth2192.168.2.0/24
-
-
- -

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

- -

Answer: There is an H.323 connection - tracking/NAT module that may help with Netmeeting. - Look here for -a solution for MSN IM but be aware that there are significant security - risks involved with this solution. Also check the Netfilter - mailing list archives at http://www.netfilter.org. -

- -

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

- -

Answer: The common.def included with version 1.3.x - always rejects connection requests on TCP -port 113 rather than dropping them. This is necessary - to prevent outgoing connection problems to services -that use the 'Auth' mechanism for identifying requesting - users. Shorewall also rejects TCP ports 135, 137 and 139 - as well as UDP ports 137-139. These are ports that are used - by Windows (Windows can be configured to use the DCE cell -locator on port 135). Rejecting these connection requests rather -than dropping them cuts down slightly on the amount of Windows chatter - on LAN segments connected to the Firewall.

- -

If you are seeing port 80 being 'closed', that's probably - your ISP preventing you from running a web - server in violation of your Service Agreement.

- -

4a. I just ran an nmap UDP scan of my - firewall and it showed 100s of ports as open!!!!

- -

Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing - back from your firewall then it reports the port - as open. If you want to see which UDP ports are really -open, temporarily change your net->all policy to REJECT, - restart Shorewall and do the nmap UDP scan again.
-

- -

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

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

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

- -

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

- -

a) Create /etc/shorewall/common if it doesn't already exist. -
- b) Be sure that - the first command in the file is ". /etc/shorewall/common.def"
- c) Add the following - to /etc/shorewall/common

- -
-

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

-
- For a complete description of Shorewall - 'ping' management, see this page. - -

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

- -

Answer: NetFilter uses the kernel's equivalent of syslog -(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility -(see "man openlog") and you get to choose the log level (again, see "man -syslog") in your policies and rules. The destination for messaged -logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). - When you have changed /etc/syslog.conf, be sure - to restart syslogd (on a RedHat system, "service syslog - restart").

- -

By default, older versions of Shorewall ratelimited log messages - through settings - in /etc/shorewall/shorewall.conf -- If you want - to log all messages, set:

- -
-
     LOGLIMIT=""
     LOGBURST=""
- Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages - to a separate file.
-
- -

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

- -

Answer: Here are several links that may be helpful: -

- -
-

http://www.shorewall.net/pub/shorewall/parsefw/
- http://www.fireparse.com
- http://cert.uni-stuttgart.de/projects/fwlogwatch
- http://www.logwatch.org
- http://gege.org/iptables
-

-
- I personnaly use Logwatch. It emails - me a report each day from my various systems with each report - summarizing the logged activity on the corresponding system. - -

6b. DROP messages on port 10619 - are flooding the logs with their connect requests. Can - i exclude these error messages for this port temporarily from -logging in Shorewall?

- Temporarily add the following rule:
- -
	DROP    net    fw    udp    10619
- -

6c. All day long I get a steady flow - of these DROP messages from port 53 to some high numbered port. - They get dropped, but what the heck are they?

- -
Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00
                                                        SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
                                                        TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
- Answer: There are two possibilities:
- -
    -
  1. They are late-arriving replies to DNS queries.
    2. -
  2. They are corrupted reply packets.
    3. - -
- You can distinguish the difference by setting -the logunclean option (/etc/shorewall/interfaces) - on your external interface (eth0 in the above example). If they get - logged twice, they are corrupted. I solve this problem by using -an /etc/shorewall/common file like this:
- -
- 
#
# Include the standard common.def file
#
. /etc/shorewall/common.def
#
# The following rule is non-standard and compensates for tardy
# DNS replies
#
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
-
- The above file is also include in all of my sample - configurations available in the Quick Start Guides and in - the common.def file in Shorewall 1.4.0 and later.
- -

6d. Why is the MAC address in - Shorewall log messages so long? I thought MAC addresses were only - 6 bytes in length.

- What is labeled as the MAC address in a Shorewall log message - is actually the Ethernet frame header. IT contains:
- -
    -
  • the destination MAC address (6 bytes)
    • -
  • the source MAC address (6 bytes)
    • -
  • the ethernet frame type (2 bytes)
    • - -
- Example:
-
- MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00
- -
    -
  • Destination MAC address = 00:04:4c:dc:e2:28
    • -
  • Source MAC address = 00:b0:8e:cf:3c:4c
    • -
  • Ethernet Frame Type = 08:00 (IP Version 4)
    • - -
- -

7. When I stop Shorewall using 'shorewall - stop', I can't connect to anything. Why doesn't - that command work?

- -

The 'stop' command is intended to place your firewall into - a safe state whereby only those hosts listed -in /etc/shorewall/routestopped' are activated. -If you want to totally open up your firewall, you must use -the 'shorewall clear' command.

- -

8. When I try to start Shorewall on RedHat, - I get messages about insmod failing -- what's wrong?

- -

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

- -
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
     Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
     /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
     iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
     Perhaps iptables or your kernel needs to be upgraded.
- -

This is usually cured by the following sequence of commands: -

- -
-
     service ipchains stop
     chkconfig --delete ipchains
     rmmod ipchains
-
- -
-

Also, be sure to check the errata - for problems concerning the version of iptables - (v1.2.3) shipped with RH7.2.
-

- -

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

- Answer: This is usually cured by the sequence of commands - shown above in FAQ #8 -
- -

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

- -

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

- -
-
     Processing /etc/shorewall/params ...
     Processing /etc/shorewall/shorewall.conf ...
     Starting Shorewall...
     Loading Modules...
     Initializing...
     Determining Zones...
     Zones: net loc
     Validating interfaces file...
     Validating hosts file...
     Determining Hosts in Zones...
     Net Zone: eth0:0.0.0.0/0
     Local Zone: eth1:0.0.0.0/0
     Deleting user chains...
     Creating input Chains...
     ...
-
- -
-

Why can't Shorewall detect my interfaces properly?

-
- -
-

Answer: The above output is perfectly normal. The Net - zone is defined as all hosts that are connected through eth0 and the local - zone is defined as all hosts connected through eth1

-
- -

10. What Distributions does it work - with?

- -

Shorewall works with any GNU/Linux distribution that includes - the proper prerequisites.

- -

11. What Features does it have?

- -

Answer: See the Shorewall - Feature List.

- -

12. Is there a GUI?

- -

Answer: Yes. Shorewall support is included in Webmin - 1.060 and later versions. See http://www.webmin.com -

- -

13. Why do you call it "Shorewall"?

- -

Answer: Shorewall is a concatenation of "Shoreline" - (the - city where I live) and "Firewall". The full - name of the product is actually "Shoreline Firewall" but "Shorewall" - is must more commonly used.

- -

14. I'm connected via a cable modem - and it has an internal web server that allows - me to configure/monitor it but as expected if I - enable rfc1918 blocking for my eth0 interface (the -internet one), it also blocks the cable modems web server.

- -

Is there any way it can add a rule before the rfc1918 blocking - that will let all traffic to and from the 192.168.100.1 - address of the modem in/out but still block all -other rfc1918 addresses?

- -

Answer: If you are running a version of Shorewall earlier -than 1.3.1, create /etc/shorewall/start and in it, place the following:

- -
-
     run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT
-
- -
-

If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:

-
- -
-
- - - - - - - - - - - - -
SUBNET - TARGET
192.168.100.1RETURN
-
-
- -
-

Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
-

- -

Note: If you add a second IP address to your external firewall - interface to correspond to the modem address, -you must also make an entry in /etc/shorewall/rfc1918 -for that address. For example, if you configure the address - 192.168.100.2 on your firewall, then you would add two entries - to /etc/shorewall/rfc1918:
-

- -
- - - - - - - - - - - - + + - - - - + + + +
SUBNET
- 		TARGET
-
192.168.100.1
- 		+ RETURN
-
+
192.168.100.2
- 		+ RETURN
-
-
-
- -
-

14a. Even though it assigns public IP - addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC -1918 filtering on my external interface, my DHCP client cannot renew its -lease.

+
- -
-

The solution is the same as FAQ 14 above. Simply substitute + +

+

14a. Even though it assigns public +IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable +RFC 1918 filtering on my external interface, my DHCP client cannot renew +its lease.

+
+ +
+

The solution is the same as FAQ 14 above. Simply substitute the IP address of your ISPs DHCP server.

-
- -

15. My local systems can't see out to +

+ +

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

- -

Answer: Every time I read "systems can't see out to - the net", I wonder where the poster bought -computers with eyes and what those computers will -"see" when things are working properly. That aside, - the most common causes of this problem are:

- + +

Answer: Every time I read "systems can't see out to + the net", I wonder where the poster bought computers + with eyes and what those computers will "see" when + things are working properly. That aside, the most +common causes of this problem are:

+
    -
  1. - -

    The default gateway on each local system isn't set to +

  2. + +

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

    -
    3. -
  3. - -

    The entry for the local network in the /etc/shorewall/masq +

    4. +
  4. + +

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

    -
    5. -
  5. - -

    The DNS settings on the local systems are wrong or the - user is running a DNS server on the firewall - and hasn't enabled UDP and TCP port 53 from the - firewall to the internet.

    -
    6. - + +
  6. + +

    The DNS settings on the local systems are wrong or the + user is running a DNS server on the firewall + and hasn't enabled UDP and TCP port 53 from the + firewall to the internet.

    +
    7. +
- -

16. Shorewall is writing log messages + +

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

- -

Answer: If you are running Shorewall version 1.4.4 -or 1.4.4a then check the errata. Otherwise, see the -'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg' command - to your startup scripts or place it in /etc/shorewall/start. - Under RedHat, the max log level that is sent - to the console is specified in /etc/sysconfig/init -in the LOGLEVEL variable.
-

- -

17. How do I find out why this traffic is getting + +

Answer: If you are running Shorewall version 1.4.4 + or 1.4.4a then check the errata. Otherwise, see +the 'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg' command + to your startup scripts or place it in /etc/shorewall/start. + Under RedHat, the max log level that is sent + to the console is specified in /etc/sysconfig/init in + the LOGLEVEL variable.
+

+ +

17. How do I find out why this traffic is getting logged?

- Answer: Logging - occurs out of a number of chains (as indicated in -the log message) in Shorewall:
- + Answer: Logging + occurs out of a number of chains (as indicated in + the log message) in Shorewall:
+
    -
  1. man1918 - - The destination address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see man1918 + or logdrop - The destination address is + listed in /etc/shorewall/rfc1918 with a logdrop target + -- see /etc/shorewall/rfc1918.
    2. +
  2. rfc1918 + or logdrop - The source address is listed in /etc/shorewall/rfc1918 + with a logdrop target -- see /etc/shorewall/rfc1918.
    3. -
  3. rfc1918 - - The source address is listed in /etc/shorewall/rfc1918 - with a logdrop target -- see /etc/shorewall/rfc1918.
    4. -
  4. all2<zone>, - <zone>2all or all2all - - You have a policy -that specifies a log level and this packet is being -logged under that policy. If you intend to ACCEPT this -traffic then you need a rule to -that effect.
    -
    5. -
  5. <zone1>2<zone2> +
  6. all2<zone>, + <zone>2all or all2all + - You have a policy that + specifies a log level and this packet is being logged +under that policy. If you intend to ACCEPT this traffic +then you need a rule to that effect.
    +
    7. +
  7. <zone1>2<zone2> - Either you have a policy for <zone1> - to <zone2> that specifies a log level and - this packet is being logged under that policy or this packet - matches a rule that + href="Documentation.htm#Policy"> policy for <zone1> + to <zone2> that specifies a log level and + this packet is being logged under that policy or this packet + matches a rule that includes a log level.
    8. -
  8. <interface>_mac - - The packet is being logged under the maclist +
  9. <interface>_mac + - The packet is being logged under the maclist interface option.
    -
    10. -
  10. logpkt - - The packet is being logged under the logunclean +
    11. +
  11. logpkt + - The packet is being logged under the logunclean interface option.
    12. -
  12. badpkt - - The packet is being logged under the dropunclean - interface option +
  13. badpkt - + The packet is being logged under the dropunclean + interface option as specified in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
    14. -
  14. blacklst - - The packet is being logged because the source IP - is blacklisted in the /etc/shorewall/blacklist +
  15. blacklst + - The packet is being logged because the source IP + is blacklisted in the /etc/shorewall/blacklist file.
    16. -
  16. newnotsyn - - The packet is being logged because it is a -TCP packet that is not part of any current connection yet -it is not a syn packet. Options affecting the logging of such - packets include NEWNOTSYN and LOGNEWNOTSYN - in /etc/shorewall/shorewall.conf.
    17. -
  17. INPUT -or FORWARD - The packet has a source IP address - that isn't in any of your defined zones ("shorewall check" - and look at the printed zone definitions) or the chain is FORWARD - and the destination IP isn't in any of your defined zones.
    18. -
  18. logflags - The -packet is being logged because it failed the checks implemented - by the tcpflags newnotsyn + - The packet is being logged because it is a + TCP packet that is not part of any current connection yet + it is not a syn packet. Options affecting the logging of such + packets include NEWNOTSYN and LOGNEWNOTSYN + in /etc/shorewall/shorewall.conf.
    19. +
  19. INPUT +or FORWARD - The packet has a source IP address + that isn't in any of your defined zones ("shorewall check" + and look at the printed zone definitions) or the chain is +FORWARD and the destination IP isn't in any of your defined + zones.
    20. +
  20. logflags - The +packet is being logged because it failed the checks implemented + by the tcpflags interface option.
    -
    21. - + +
- -

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

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

- Answer: Yes. See - Shorewall and Aliased Interfaces. - -

19. I have added entries to /etc/shorewall/tcrules + Answer: Yes. See + Shorewall and Aliased Interfaces. + +

19. I have added entries to /etc/shorewall/tcrules but they don't seem to do anything. Why?

- You probably haven't set TC_ENABLED=Yes - in /etc/shorewall/shorewall.conf so the contents of - the tcrules file are simply being ignored.
- -

20. I have just set up a server. Do I have - to change Shorewall to allow access to my server from + You probably haven't set +TC_ENABLED=Yes in /etc/shorewall/shorewall.conf so +the contents of the tcrules file are simply being ignored.
+ +

20. I have just set up a server. Do I have + to change Shorewall to allow access to my server from the internet?
-

- Yes. Consult the QuickStart guide that -you used during your initial setup for information about how to set - up rules for your server.
- -

21. I see these strange log entries occasionally; +

+ Yes. Consult the QuickStart guide that you +used during your initial setup for information about how to set up +rules for your server.
+ +

21. I see these strange log entries occasionally; what are they?
-

- -
+

+ +
Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00
     SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 
     [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
-
- 192.0.2.3 is external on my firewall... - 172.16.0.0/24 is my internal LAN
-
- Answer: While most people - associate the Internet Control Message Protocol (ICMP) - with 'ping', ICMP is a key piece of the internet. ICMP -is used to report problems back to the sender of a packet; this - is what is happening here. Unfortunately, where NAT is involved -(including SNAT, DNAT and Masquerade), there are a lot of broken + + 192.0.2.3 is external on my +firewall... 172.16.0.0/24 is my internal LAN
+
+ Answer: While most people + associate the Internet Control Message Protocol (ICMP) + with 'ping', ICMP is a key piece of the internet. ICMP is + used to report problems back to the sender of a packet; this + is what is happening here. Unfortunately, where NAT is involved +(including SNAT, DNAT and Masquerade), there are a lot of broken implementations. That is what you are seeing with these messages.
+
+ Here is my interpretation of +what is happening -- to confirm this analysis, one would +have to have packet sniffers placed a both ends of the connection.

- Here is my interpretation of what - is happening -- to confirm this analysis, one would have - to have packet sniffers placed a both ends of the connection.
-
- Host 172.16.1.10 behind NAT gateway - 206.124.146.179 sent a UDP DNS query to 192.0.2.3 and - your DNS server tried to send a response (the response information - is in the brackets -- note source port 53 which marks this as - a DNS reply). When the response was returned to to 206.124.146.179, - it rewrote the destination IP TO 172.16.1.10 and forwarded the -packet to 172.16.1.10 who no longer had a connection on UDP port -2857. This causes a port unreachable (type 3, code 3) to be generated -back to 192.0.2.3. As this packet is sent back through 206.124.146.179, - that box correctly changes the source address in the packet to 206.124.146.179 - but doesn't reset the DST IP in the original DNS response similarly. - When the ICMP reaches your firewall (192.0.2.3), your firewall has - no record of having sent a DNS reply to 172.16.1.10 so this ICMP -doesn't appear to be related to anything that was sent. The final - result is that the packet gets logged and dropped in the all2all -chain. I have also seen cases where the source IP in the ICMP itself -isn't set back to the external IP of the remote NAT gateway; that causes -your firewall to log and drop the packet out of the rfc1918 chain because + Host 172.16.1.10 behind NAT gateway + 206.124.146.179 sent a UDP DNS query to 192.0.2.3 and + your DNS server tried to send a response (the response information + is in the brackets -- note source port 53 which marks this as +a DNS reply). When the response was returned to to 206.124.146.179, + it rewrote the destination IP TO 172.16.1.10 and forwarded the +packet to 172.16.1.10 who no longer had a connection on UDP port +2857. This causes a port unreachable (type 3, code 3) to be generated +back to 192.0.2.3. As this packet is sent back through 206.124.146.179, + that box correctly changes the source address in the packet to 206.124.146.179 + but doesn't reset the DST IP in the original DNS response similarly. + When the ICMP reaches your firewall (192.0.2.3), your firewall has + no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't + appear to be related to anything that was sent. The final result + is that the packet gets logged and dropped in the all2all chain. I + have also seen cases where the source IP in the ICMP itself isn't set +back to the external IP of the remote NAT gateway; that causes your +firewall to log and drop the packet out of the rfc1918 chain because the source IP is reserved by RFC 1918.
- -

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

- You can place these commands -in one of the Shorewall Extension - Scripts. Be sure that you look at the contents of the chain(s) that - you will be modifying with your commands to be sure that the - commands will do what they are intended. Many iptables commands - published in HOWTOs and other instructional material use the -A -command which adds the rules to the end of the chain. Most chains -that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT - rule and any rules that you add after that will be ignored. Check -"man iptables" and look at the -I (--insert) command.
- -

23. Why do you use such ugly fonts on your + +

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

+ You can place these commands +in one of the Shorewall Extension + Scripts. Be sure that you look at the contents of the chain(s) +that you will be modifying with your commands to be sure +that the commands will do what they are intended. Many iptables +commands published in HOWTOs and other instructional material +use the -A command which adds the rules to the end of the chain. Most +chains that Shorewall constructs end with an unconditional DROP, ACCEPT +or REJECT rule and any rules that you add after that will be ignored. + Check "man iptables" and look at the -I (--insert) command.
+ +

23. Why do you use such ugly fonts on your web site?

- The Shorewall web site is almost font neutral - (it doesn't explicitly specify fonts except on a few pages) -so the fonts you see are largely the default fonts configured in -your browser. If you don't like them then reconfigure your browser.
- -

24. How can I allow conections to let's say - the ssh port only from specific IP Addresses on the + The Shorewall web site is almost font +neutral (it doesn't explicitly specify fonts except on a few +pages) so the fonts you see are largely the default fonts configured + in your browser. If you don't like them then reconfigure your +browser.
+ +

24. How can I allow conections to let's say + the ssh port only from specific IP Addresses on the internet?

- In the SOURCE column of the rule, follow "net" - by a colon and a list of the host/subnet addresses as a comma-separated - list.
- + In the SOURCE column of the rule, follow +"net" by a colon and a list of the host/subnet addresses as +a comma-separated list.
+ 
    net:<ip1>,<ip2>,...
- Example:
- + Example:
+ 
    ACCEPT	net:192.0.2.16/28,192.0.2.44	fw	tcp	22
- +
- -

25. How to I tell which version of Shorewall + +

25. How to I tell which version of Shorewall I am running?
-

- At the shell prompt, type:
-
- /sbin/shorewall version
- -

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

+ At the shell prompt, type:
+
+ /sbin/shorewall version
+ +

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

-Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" + Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes" then restart Shorewall.
-
- Last updated 6/29/2003 - Tom Eastep +
+ Last updated 7/5/2003 - Tom Eastep

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

+

+

diff --git a/Shorewall-docs/NAT.htm b/Shorewall-docs/NAT.htm index eb4530c3a..aa65d51b0 100644 --- a/Shorewall-docs/NAT.htm +++ b/Shorewall-docs/NAT.htm @@ -1,117 +1,117 @@ - + Shorewall NAT - + - + - -
+ +
- - - + + - - - + + + +
+

Static NAT

-
- -

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.

- -

Static NAT is a way to make systems behind a firewall and configured -with private IP addresses (those reserved for private use in RFC1918) -appear to have public IP addresses. Before you try to use this technique, -I strongly recommend that you read the 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.

+ +

Static NAT is a way to make systems behind a firewall and configured + with private IP addresses (those reserved for private use in RFC1918) + appear to have public IP addresses. Before you try to use this technique, + I strongly recommend that you read the Shorewall Setup Guide.

- +

The following figure represents a static NAT environment.

- +

-

- +

+
- -

Static NAT can be used to make the systems with the 10.1.1.* -addresses appear to be on the upper (130.252.100.*) subnet. If we assume -that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT -file would make the lower left-hand system appear to have IP address -130.252.100.18 and the right-hand one to have IP address 130.252.100.19.

- + +

Static NAT can be used to make the systems with the 10.1.1.* +addresses appear to be on the upper (130.252.100.*) subnet. If we assume +that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT +file would make the lower left-hand system appear to have IP address 130.252.100.18 +and the right-hand one to have IP address 130.252.100.19.

+ - - - - - - - - + - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + +
EXTERNALINTERFACEINTERNALALL INTERFACESLOCAL
130.252.100.18eth010.1.1.2yesyes
130.252.100.19eth010.1.1.3yesyes
EXTERNALINTERFACEINTERNALALL INTERFACESLOCAL
130.252.100.18eth010.1.1.2yesyes
130.252.100.19eth010.1.1.3yesyes
- -

Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above - example) is (are) not included in any specification in /etc/shorewall/masq - or /etc/shorewall/proxyarp.

- -

Note 1: The "ALL INTERFACES" column is used -to specify whether access to the external IP from all firewall interfaces -should undergo NAT (Yes or yes) or if only access from the interface in -the INTERFACE column should undergo NAT. If you leave this column empty, + +

Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above + example) is (are) not included in any specification in /etc/shorewall/masq + or /etc/shorewall/proxyarp.

+ +

Note 1: The "ALL INTERFACES" column is used +to specify whether access to the external IP from all firewall interfaces +should undergo NAT (Yes or yes) or if only access from the interface in +the INTERFACE column should undergo NAT. If you leave this column empty, "Yes" is assumed. The ALL INTERFACES column was added in version 1.1.6.

+ +

Note 2: Shorewall will automatically add the external address to the + specified interface unless you specify ADD_IP_ALIASES="no" (or "No") in + /etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if + you set it to "Yes" or "yes" then you must NOT configure your own alias(es). + RESTRICTION: Shorewall versions earlier than 1.4.6 can only add +external addresses to an interface that is configured with a single subnetwork +-- if your external interface has addresses in more than one subnetwork, +Shorewall 1.4.5 and earlier can only add addresses to the first one.

+ +

Note 3: The contents of the "LOCAL" column + determine whether packets originating on the firewall itself and destined + for the EXTERNAL address are redirected to the internal ADDRESS. If +this column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also +contains "Yes" or "yes") then such packets are redirected; otherwise, +such packets are not redirected. The LOCAL column was added in version +1.1.8.

+
-

Note 2: Shorewall will automatically add the external address to the - specified interface unless you specify ADD_IP_ALIASES="no" (or "No") in -/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if -you set it to "Yes" or "yes" then you must NOT configure your own alias(es). - RESTRICTION: Shorewall can only add external addresses to an interface -that is configured with a single subnetwork -- if your external interface -has addresses in more than one subnetwork, Shorewall can only add addresses -to the first one.

- -

Note 3: The contents of the "LOCAL" column -determine whether packets originating on the firewall itself and destined -for the EXTERNAL address are redirected to the internal ADDRESS. If this -column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also contains -"Yes" or "yes") then such packets are redirected; otherwise, such packets -are not redirected. The LOCAL column was added in version 1.1.8.

-
-
- -

Last updated 4/11/2003 - Last updated 7/6/2003 - Tom Eastep

- Copyright © Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index f4c928717..0cb348f92 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -4,7 +4,7 @@ - + Shorewall News @@ -14,404 +14,594 @@ - + - + - + + - + - + - + + + - - - +
+ - +

Shorewall News Archive

-
-

7/4/2003 - Shorewall-1.4.6 Beta 1

+ +

7/7/2003 - Shorewall-1.4.6 Beta 2

+

Problems Corrected:
-

+

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

Migration Issues:
+

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

New Features:
-

+

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

6/17/2003 - Shorewall-1.4.5

- -

Problems Corrected:
-

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

New Features:
-

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

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

+

7/4/2003 - Shorewall-1.4.6 Beta 1

-

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

Problems Corrected:

-

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

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

New Features:
+

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

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

      + +
    + +
      +
    • To handle 'norfc1918' filtering, Shorewall will not create chains + in the mangle table but will rather do all 'norfc1918' filtering in the +filter table (rfc1918 chain).
      • +
    • Recall that Shorewall DNAT rules generate two netfilter rules; +one in the nat table and one in the filter table. If the Connection Tracking +Match Extension is available, the rule in the filter table is extended to +check that the original destination address was the same as specified (or +defaulted to) in the DNAT rule.
      +
      +
      • + +
    +
  7. The shell used to interpret the firewall script (/usr/share/shorewall/firewall) + may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.
    +
    8. + +
+ +

6/17/2003 - Shorewall-1.4.5

+ +

Problems Corrected:
+

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

New Features:
+

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

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

+ +

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

+

6/8/2003 - Updated Samples

+ +

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

+ +

5/29/2003 - Shorewall-1.4.4b

+ +

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

+

5/27/2003 - Shorewall-1.4.4a

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed - out that the code in 1.4.4 restricts the length of short zone names to -4 characters. I've produced version 1.4.4a that restores the previous 5-character - limit by conditionally omitting the log rule number when the LOGFORMAT -doesn't contain '%d'.
- + 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:
- + I apologize for the rapid-fire releases but since there is a potential + configuration change required to go from 1.4.3a to 1.4.4, I decided +to make it a full release rather than just a bug-fix release.
+
+     Problems corrected:
+
None.
-
-     New Features:
- + +     New Features:
+
    -
  1. A REDIRECT- rule target has been added. This target behaves -for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter -nat table REDIRECT rule is added but not the companion filter table ACCEPT -rule.
    -
    -
    2. -
  2. The LOGMARKER variable has been renamed LOGFORMAT and has been - changed to a 'printf' formatting template which accepts three arguments - (the chain name, logging rule number and the disposition). To use LOGFORMAT - with fireparse (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 +
  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:
- -
    -
  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.
    + 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/10/2003 - Shorewall Mirror in Asia
-

- -

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

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. + Thanks to Darcy Ganga, there is now an HTTP mirror +in Santiago Chile.

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

- +

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

- +

4/9/2003 - Shorewall 1.4.2
-

- +

+

    Problems Corrected:

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

    New Features:

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

3/24/2003 - Shorewall 1.4.1

- + @@ -431,1706 +621,1764 @@ the 'ZONE' column may not contain '-'; in other words, 'routeback' can't + +

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

+ +
    +
  1. An OLD_PING_HANDLING option has been + added to shorewall.conf. When set to Yes, Shorewall ping +handling is as it has always been (see http://www.shorewall.net/ping.html).
    +
    + When OLD_PING_HANDLING=No, icmp echo +(ping) is handled via rules and policies just like any other +connection request. The FORWARDPING=Yes option in shorewall.conf + and the 'noping' and 'filterping' options in /etc/shorewall/interfaces + will all generate an error.
    +
    +
    2. +
  2. It is now possible to direct Shorewall + to create a "label" such as  "eth0:0" for IP addresses that + it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. + This is done by specifying the label instead of just the interface + name:
    +  
    +    a) In the INTERFACE column of /etc/shorewall/masq
    +    b) In the INTERFACE column of /etc/shorewall/nat
    +  
    3. +
  3. Support for OpenVPN Tunnels.
    +
    +
    4. +
  4. Support for VLAN devices with names +of the form $DEV.$VID (e.g., eth0.0)
    +
    +
    5. +
  5. In /etc/shorewall/tcrules, the MARK value + may be optionally followed by ":" and either 'F' or 'P' to designate + that the marking will occur in the FORWARD or PREROUTING chains + respectively. If this additional specification is omitted, the chain + used to mark packets will be determined by the setting of the MARK_IN_FORWARD_CHAIN + option in shorewall.conf.
    +
    +
    6. +
  6. When an interface name is entered in + the SUBNET column of the /etc/shorewall/masq file, Shorewall + previously masqueraded traffic from only the first subnet +defined on that interface. It did not masquerade traffic from:
    +  
    +    a) The subnets associated with other + addresses on the interface.
    +    b) Subnets accessed through local +routers.
    +  
    + Beginning with Shorewall 1.3.14, if +you enter an interface name in the SUBNET column, shorewall +will use the firewall's routing table to construct the masquerading/SNAT + rules.
    +  
    + Example 1 -- This is how it works in +1.3.14.
    +   
    + + + -

    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

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


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

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

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

    - + $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 +
    2. 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.
      -
      -
      3. -
    3. It is now possible to direct Shorewall - to create a "label" such as  "eth0:0" for IP addresses that - it creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes. - This is done by specifying the label instead of just the interface - name:
      -  
      -    a) In the INTERFACE column of /etc/shorewall/masq
      -    b) In the INTERFACE column of /etc/shorewall/nat
      -  
      4. -
    4. 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.
      -   
      +
      + 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. 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 +  
      + 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:
      -   
      +  
      + Example 2 -- Suppose that your current + config is as follows:
      +   
      - + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         eth0                    192.168.10.0/24         206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, the second entry in /etc/shorewall/masq - is no longer required.
      -  
      - Example 3 -- What if your current configuration - is like this?
      -  
      +  
      +    In this case, the second entry in +/etc/shorewall/masq is no longer required.
      +  
      + Example 3 -- What if your current configuration + is like this?
      +  
      - + + 
         [root@gateway test]# cat /etc/shorewall/masq
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    eth2                    206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      - + + 
         [root@gateway test]# ip route show dev eth2
         192.168.1.0/24  scope link
         192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
         [root@gateway test]#
      -  
      -    In this case, you would want to change - the entry in  /etc/shorewall/masq to:
      +  
      +    In this case, you would want to change + the entry in  /etc/shorewall/masq to:
      - + + 
         #INTERFACE              SUBNET                  ADDRESS
         eth0                    192.168.1.0/24          206.124.146.176
         #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
      -
      7. - + +
    - +

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

    - +

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

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

    1/17/2003 - shorewall.net has MOVED 

    - +

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

    - - -

    1/13/2003 - Shorewall 1.3.13
    -

    - - -

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

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

    1/6/2003 - BURNOUT -

    - - -

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

    - - -

    -Tom Eastep

    +

    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

    + 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 +
    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 If you are running a kernel + that has a FORWARD chain in the mangle table ("shorewall + show mangle" will show you the chains in the mangle table), + you can set MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for marking input packets based on their destination even when you are using Masquerading or SNAT.
      11. -
    11. I have cluttered up the /etc/shorewall - directory with empty 'init', 'start', 'stop' and 'stopped' - files. If you already have a file with one of these names, - don't worry -- the upgrade process won't overwrite your file.
      12. -
    12. I have added a new RFC1918_LOG_LEVEL - variable to 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.
      -
      13. +
    13. I have cluttered up the +/etc/shorewall directory with empty 'init', 'start', +'stop' and 'stopped' files. If you already have a file with + one of these names, don't worry -- the upgrade process won't + overwrite your file.
      14. +
    14. I have added a new RFC1918_LOG_LEVEL + variable to shorewall.conf. + This variable specifies the syslog level at which packets + are logged as a result of entries in the /etc/shorewall/rfc1918 + file. Previously, these packets were always logged at the +'info' level.
      +
      15. - +
    - +

    12/20/2002 - Shorewall 1.3.12 Beta 3
    -

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

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

    12/20/2002 - Shorewall 1.3.12 Beta 2

    - +

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

    - Features include:
    + 1 was made available only to a limited audience).
    +

    + Features include:
    - +
      -
    1. "shorewall refresh" -now reloads the traffic shaping rules (tcrules and -tcstart).
      2. -
    2. "shorewall debug [re]start" - now turns off debugging after an error occurs. This - places the point of the failure near the end of the trace +
    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

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

    12/7/2002 - Shorewall Support for Mandrake 9.0

    - +

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

    + I have installed 9.0 on one of my systems and I +am now in a position to support Shorewall users who run +Mandrake 9.0.

    - +

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

    +

    - +

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

    - +

    12/3/2002 - Shorewall 1.3.11a

    - +

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

    + excluded subnets (e.g., "DNAT foo!bar ..."). Current + 1.3.11 users who don't need rules of this type need + not upgrade to 1.3.11.

    - +

    11/24/2002 - Shorewall 1.3.11

    - +

    In this version:

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

    11/14/2002 - Shorewall Documentation in PDF Format

    - +

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

    + the PDF may be downloaded from

    - +

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

    +

    - +

    11/09/2002 - Shorewall is Back at SourceForge

    +

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

    +

    - + +

    11/09/2002 - Shorewall 1.3.10

    - +

    In this version:

    - + - +

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

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

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

    10/23/2002 - Shorewall 1.3.10 Beta 1

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

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

    +

    - +

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

    - +

    10/9/2002 - Shorewall 1.3.9b

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

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

    - Roles up the - fix for broken tunnels.
    + 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.
    + -- copy that file to /usr/lib/shorewall/firewall.
    - +

    9/28/2002 - Shorewall 1.3.9

    - +

    In this version:
    -

    +

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

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

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

    + connection SOURCE may now be qualified by both interface + and IP address in a Shorewall rule.
    7. +
  7. 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.
    8. +
  8. 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. + + + +

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

    - +

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

    9/11/2002 - Debian 1.3.7c Packages Available

    - +

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

    - +

    9/2/2002 - Shorewall 1.3.7c

    - +

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

    + (fw).

    - +

    8/31/2002 - I'm not available

    - +

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

    - +

    -Tom

    - +

    8/26/2002 - Shorewall 1.3.7b

    - +

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

    + reverses the order of "dhcp" and "norfc1918" + checking.

    - +

    8/26/2002 - French FTP Mirror is Operational

    - +

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

    + is now available.

    - +

    8/25/2002 - Shorewall Mirror in France

    - +

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

    - +

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

    - +

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

    - +

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

    + +

    - +

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

    + Shorewall 1.3.7.

    - +

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

    - +

    Features in this release include:

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

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

    + SYN and ICMP treatment in Shorewall. + That input has led to marked improvement in + Shorewall in the last two releases.

    - +

    8/13/2002 - Documentation in the CVS Repository

    - +

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

    - +

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

    - +

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

    + so you can always update from this branch + to get the latest stable tree.

    - +

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

    - +

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

    + to recent versions of Shorewall.

    - +

    8/7/2002 - Shorewall 1.3.6

    - +

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

    - + +

    7/30/2002 - Shorewall 1.3.5b Released

    - +

    This interim release:

    - + +

    7/29/2002 - New Shorewall Setup Guide Available

    - +

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

    + The guide is intended for use by people + who are setting up Shorewall to manage multiple + public IP addresses and by people who want to learn + more about Shorewall than is described in the single-address + guides. Feedback on the new guide is welcome.

    - +

    7/28/2002 - Shorewall 1.3.5 Debian Package Available

    - +

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

    - +

    7/27/2002 - Shorewall 1.3.5a Released

    - +

    This interim release restores correct handling of REDIRECT rules.

    - +

    7/26/2002 - Shorewall 1.3.5 Released

    - +

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

    - +

     In this version:

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

    7/16/2002 - New Mirror in Argentina

    - +

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

    + Argentina. Thanks Buanzo!!!

    - +

    7/16/2002 - Shorewall 1.3.4 Released

    - +

    In this version:

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

    7/8/2002 - Shorewall 1.3.3 Debian Package Available

    - +

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

    - +

    7/6/2002 - Shorewall 1.3.3 Released

    - +

    In this version:

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

    6/25/2002 - Samples Updated for 1.3.2

    - +

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

    + new features introduced in Shorewall + 1.3.2.

    - +

    6/25/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/19/2002 - Documentation Available in PDF Format

    - +

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

    - +

    6/16/2002 - Shorewall 1.3.2 Released

    - +

    In this version:

    - + +

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

    - +

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

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

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

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

    - +

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

    + more RAM if that is what is required), + CVS Web access will remain Password Protected. +

    - +

    6/5/2002 - Shorewall 1.3.1 Debian Package Available

    - +

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

    - +

    6/2/2002 - Samples Corrected

    - +

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

    - +

    6/1/2002 - Shorewall 1.3.1 Released

    - +

    Hot on the heels of 1.3.0, this release:

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

    5/29/2002 - Shorewall 1.3.0 Released

    - +

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

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

    5/23/2002 - Shorewall 1.3 RC1 Available

    - +

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

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

    5/19/2002 - Shorewall 1.3 Beta 2 Available

    - +

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

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

    5/17/2002 - Shorewall 1.3 Beta 1 Available

    - +

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

    + features:

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

    5/4/2002 - Shorewall 1.2.13 is Available

    - +

    In this version:

    - + +

    4/30/2002 - Shorewall Debian News

    - +

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

    - +

    4/20/2002 - Shorewall 1.2.12 is Available

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

    4/17/2002 - Shorewall Debian News

    - +

    Lorenzo Marignoni reports that:

    - +     +

    Thanks, Lorenzo!

    - +

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

    - +

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

    + SuSE RPM available.

    - +

    4/13/2002 - Shorewall 1.2.11 Available

    - +

    In this version:

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

    4/13/2002 - Hamburg Mirror now has FTP

    - +

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

    + Thanks Stefan!

    - +

    4/12/2002 - New Mirror in Hamburg

    - +

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

    + is now a mirror of the Shorewall website + at http://germany.shorewall.net. +

    - +

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

    - +

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

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

    - +

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

    - +

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

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

    - +

    4/8/2002 - Parameterized Samples Withdrawn

    - +

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

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

    - +

    4/2/2002 - Updated Log Parser

    - +

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

    - +

    3/30/2002 - Shorewall Website Search Improvements

    - +

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

    + page.

    - +

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

    - + +

    3/25/2002 - Log Parser Available

    - +

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

    + John.

    - +

    3/20/2002 - Shorewall 1.2.10 Released

    - +

    In this version:

    - + +

    3/11/2002 - Shorewall 1.2.9 Released

    - +

    In this version:

    - + - +

    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

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

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

    + 1.2.5. Sorry for the rapid-fire development.

    - +

    In version 1.2.5:

    - +
      -
    • The installation problems have been corrected.
      • +
    • The installation problems have been corrected.
      • -
    • SNAT is now supported.
      • +
    • SNAT is now supported.
      • -
    • A "shorewall version" command has been added
      • +
    • 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 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.
      • +
    • 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
      • +
    • 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".
      • +
    • 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 "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.

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

    + for details.

    - +

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

    - +

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

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

    + 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.
      • +
    • 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.
      • +
    • 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 is moving to Shorewall.net. + If you are a current subscriber to the list +at Sourceforge, please see these instructions. - If you would like to subscribe to the new - list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users.

    - +

    12/31/2001 - Shorewall 1.2.1 Released

    - +

    In version 1.2.1:

    - + +

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

    - +

    Version 1.2 contains the following new features:

    - + - + +

    For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current + 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 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 + Cowles, there is now a Shorewall mirror in Texas. This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 

    - +

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

    - +
      -
    • Ping is now allowed between the zones.
      • +
    • 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. 
      • +
    • 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 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 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 /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 , 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:

    + There are three sample configurations:

    - +
      -
    • One Interface -- for a standalone system.
      • +
    • One Interface -- for a standalone system.
      • -
    • Two Interfaces -- A masquerading firewall.
      • +
    • Two Interfaces -- A masquerading firewall.
      • -
    • Three Interfaces -- A masquerading firewall -with DMZ.
      • +
    • 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.

    + . See the README file for instructions.

    - +

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

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

    -

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

    - -
      -
    • Support for nested zones has been improved. - See the documentation - for details
      • +
    • A new "shorewall show connections" command + has been added.
      • -
    • Shorewall now correctly checks the alternate - configuration directory for the 'zones' file.
      • +
    • 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/4/2001 - The current version of Shorewall is 1.1.14. In this - version

    - + +

    10/15/2001 - The current version of Shorewall is 1.1.15. 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:
      +
    • Support for nested zones has been improved. + See the documentation + for details
      • - 1. Create a New Directory
      +
    • Shorewall now correctly checks the alternate + configuration directory for the 'zones' file.
      • - 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. -
  9. 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.
    10. + +

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

    -
  10. Rules that specify multiple client ip addresses - or subnets no longer cause startup failures.
    11. -
  11. Zone names in the policy file are now validated - against the zones file.
    12. + + - + +

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

    + version

    - + +
      -
    • Shell variables can now be used to parameterize - Shorewall rules.
      • +
    • Shell variables can now be used to parameterize + Shorewall rules.
      • -
    • The second column in the hosts file may now -contain a comma-separated list.
      +
    • The second column in the hosts file may now + contain a comma-separated list.
      -
      +
      - Example:
      + Example:
      -     sea    eth0:130.252.100.0/24,206.191.149.0/24
      • +     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.
      • +
    • Handling of multi-zone interfaces has been +improved. See the documentation for the /etc/shorewall/interfaces + file.
      • - + +
    - + +

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

    + version

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

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

    + 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.
      • +
    • 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 /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 "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 RPM can now be built from the .tgz file + using "rpm -tb" 
      • - + +
    - + +

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

    - + +
      -
    • 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.
      • +
    • 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.
      • +
    • The "shorewall hits" command no longer lists + extraneous service names in its last report.
      • -
    • Erroneous instructions in the comments at the - head of the firewall script have been corrected.
      • +
    • Erroneous instructions in the comments at the + head of the firewall script have been corrected.
      • - + +
    - + +

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

    - + +
      -
    • The "tunnels" file really is in the - RPM now.
      • +
    • The "tunnels" file really is in the + RPM now.
      • -
    • SNAT can now be applied to port-forwarded connections.
      • +
    • SNAT can now be applied to port-forwarded connections.
      • -
    • A bug which would cause firewall start failures - in some dhcp configurations has been fixed.
      • +
    • 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.
      • +
    • 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 itYou can now configure Shorewall so that it doesn't require the NAT and/or - mangle netfilter modules.
      • + mangle netfilter modules. -
    • Thanks to Alex  Polishchuk, the "hits" command - from seawall is now in shorewall.
      • +
    • Thanks to Alex  Polishchuk, the "hits" command + from seawall is now in shorewall.
      • -
    • Support for IPIP tunnels - has been added.
      • +
    • 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 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 regardless of which + version of iptables is installed.
      • -
    • The .rpm will now install without iproute2 being - installed.
      • +
    • The .rpm will now install without iproute2 + being installed.
      • -
    • The documentation has been cleaned up.
      • +
    • The documentation has been cleaned up.
      • -
    • The sample configuration files included in Shorewall - have been formatted to 80 columns for ease of -editing on a VGA console.
      • +
    • The sample configuration files included in + Shorewall have been formatted to 80 columns for +ease of editing on a VGA console.
      • - + +
    - + +

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

    - + + - + +

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

    - + +
      -
    • Accepting RELATED - connections is now optional.
      • +
    • 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 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.
      • +
    • Corrected rules generated for port redirection.
      • -
    • The order in which iptables kernel modules are - loaded has been corrected (Thanks to Mark Pavlidis). 
      • +
    • The order in which iptables kernel modules + are loaded has been corrected (Thanks to Mark + Pavlidis). 
      • - + +
    - + +

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

    - + +
      -
    • Correct message issued when Proxy ARP address - added (Thanks to Jason Kirtland).
      • +
    • 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.
      • +
    • /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.
      • +
    • /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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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 "#".
      • +
    • 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

    - + +
      -
    • Port redirection now works again.
      • +
    • Port redirection now works again.
      • -
    • The icmpdef and common chains 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 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.
      • +
    • The LRP Version is renamed "shorwall" for +8,3 MSDOS file system compatibility.
      • -
    • A couple of LRP-specific problems were corrected.
      • +
    • 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 common chain is traversed from INPUT, OUTPUT + and FORWARD before logging occurs
      • -
    • The source has been cleaned up dramatically
      • +
    • 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. 
      • +
    • 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.
      • +
    • Log messages now indicate the packet disposition.
      • -
    • Error messages have been improved.
      • +
    • Error messages have been improved.
      • -
    • The ability to define zones consisting of an - enumerated set of hosts and/or subnetworks has been - added.
      • +
    • 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.
      • +
    • 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.
      • +
    • 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 +
    • Exits are now provided for executing an user-defined + script when a chain is defined, when the firewall + is initialized, when the firewall is started, + when the firewall is stopped and when the firewall is cleared.
      • -
    • The Linux kernel's route filtering facility - can now be specified selectively on network -interfaces.
      • +
    • The Linux kernel's route filtering facility + can now be specified selectively on network + interfaces.
      • - + +
    +

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

    - + +
      -
    • Allows user-defined zones. Shorewall now has - only one pre-defined zone (fw) with the remaining +
    • 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. 
      • + 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.
      • +
    • 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.
      • +
    • 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).
      • +
    • 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.

    + release with no new features.

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

    3/8/2001 - The current version of Shorewall is 1.0.2. It supports an - additional "gw" (gateway) zone for + 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 7/4/2003 - Tom Eastep -

    + +

    Updated 7/7/2003 - Tom Eastep +

    - +

    Copyright © 2001, 2002 Thomas M. Eastep.
    -

    +

    +
    +

    diff --git a/Shorewall-docs/images/Netfilter.png b/Shorewall-docs/images/Netfilter.png index 070cf469c..170752fb3 100755 Binary files a/Shorewall-docs/images/Netfilter.png and b/Shorewall-docs/images/Netfilter.png differ diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm index 2b5ed0fbd..a7f339ac6 100644 --- a/Shorewall-docs/seattlefirewall_index.htm +++ b/Shorewall-docs/seattlefirewall_index.htm @@ -3,110 +3,111 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - + - + - - + - + - + +
    + + - - + + +
    - + - +

    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

    @@ -116,304 +117,384 @@ General Public License as published by the Free Software - + +

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

    Looking for Information?

    + The Documentation +Index is a good place to start as is the Quick Search to your right. +

    Running Shorewall on Mandrake with a two-interface setup?

    - If so, the documentation on this site will not apply - directly to your setup. If you want to use the documentation that you - find here, you will want to consider uninstalling what you have and installing - 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, the documentation on this site will not + apply directly to your setup. If you want to use the documentation + that you find here, you will want to consider uninstalling what you have + and installing a setup that matches the documentation on this site. + See the Two-interface QuickStart Guide + for details.
    +

    News

    - -

    7/4/2003 - Shorewall-1.4.6 Beta 1 (New) -
    -

    - -
    http://shorewall.net/pub/shorewall/testing
    - ftp://shorewall.net/pub/shorewall/testing
    -
    - -

    Problems Corrected:
    -

    - + +

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

    New Features:
    -

    - + +

    7/7/2003 - Shorewall-1.4.6 Beta 2 (New) +
    +

    +

    Problems Corrected:
    +

    +
      -
    1. A 'newnotsyn' interface option has been added. This option -may be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.
      -
      -
      2. -
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq +
    3. A problem seen on RH7.3 systems where Shorewall encountered start +errors when started using the "service" mechanism has been worked around.
      +
      +
      4. +
    4. Where a list of IP addresses appears in the DEST column of a +DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat +table (one for each element in the list). Shorewall now correctly creates +a single DNAT rule with multiple "--to-destination" clauses.
      +
      +
      5. +
    5. Corrected a problem in Beta 1 where DNS names containing a "-" +were mis-handled when they appeared in the DEST column of a rule.
      +
      6. +
    + +

    Migration Issues:
    +

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

    New Features:
    +

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

    6/17/2003 - Shorewall-1.4.5

    - +

    Problems Corrected:
    -

    - +

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

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

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

    - + +

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

    +

    - +
      - +
    - +

    More News

    - +

    (Leaf Logo) - Jacques Nilo and Eric Wolzak - have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution - called Bering that features - Shorewall-1.4.2 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.4.2 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.
    - - - + - + + +

    Quick Search
    - -

    - +

    + - + +

    Extended Search

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

    (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 7/4/2003 - Tom Eastep -
    -

    -
    -
    -
    + +

    Updated 7/7/2003 - Tom Eastep +
    +

    diff --git a/Shorewall-docs/shorewall_firewall_structure.htm b/Shorewall-docs/shorewall_firewall_structure.htm index b27c3ee0b..3597f28a5 100644 --- a/Shorewall-docs/shorewall_firewall_structure.htm +++ b/Shorewall-docs/shorewall_firewall_structure.htm @@ -1,333 +1,326 @@ - + - + - + - + Shorewall Firewall Structure - + - - - + + - - + + + + +
    +

    Firewall Structure

    -
    + +

    Shorewall views the network in which it is running as a set of + zones. Shorewall itself defines exactly one zone called "fw" which + refers to the firewall system itself . The /etc/shorewall/zones file is + used to define additional zones and the example file provided with Shorewall + defines the zones:

    + +
      +
    1. net -- the (untrusted) internet.
      2. +
    2. dmz - systems that must be accessible from the internet + and from the local network.  These systems cannot be trusted completely since + their servers may have been compromised through a security exploit.
      3. +
    3. loc - systems in your local network(s). These systems + must be protected from the internet and from the DMZ and in some cases, + from each other.
      4. + +
    + +

    Note: You can specify the name of the firewall zone. + For ease of description in this documentation, it is assumed that the firewall +zone is named "fw".

    + +

    It can't be stressed enough that with the exception of the firewall zone, + Shorewall itself attaches no meaning to zone names. Zone names are simply + labels used to refer to a collection of network hosts.

    + +

    While zones are normally disjoint (no two zones have a host in common), + there are cases where nested or overlapping zone definitions are appropriate.

    + +

    Netfilter has the concept of tables and chains. For the +purpose of this document, we will consider Netfilter to have three tables:

    + +
      +
    1. Filter table -- this is the main table for packet filtering and can + be displayed with the command "shorewall show".
      2. +
    2. Nat table -- used for all forms of Network Address Translation (NAT); + SNAT, DNAT and MASQUERADE.
      3. +
    3. Mangle table -- used to modify fields in the packet header.
      +
      4. + +
    + +

    Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT, + FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables + as shown in this table.
    +

    + +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    CHAIN
    +     		Filter
    +     		Nat
    +     		Mangle
    +
    PREROUTING
    +
    +     		X
    +     		X
    +
    INPUT
    +     		X
    +
    +     		X
    +
    OUTPUT
    +     		X
    +     		X
    +     		X
    +
    FORWARD
    +     		X
    +
    +     		X
    +
    POSTROUTING
    +
    +     		X
    +     		X
    +
    - -

    Shorewall views the network in which it is running as a set of - zones. Shorewall itself defines exactly one zone called "fw" which - refers to the firewall system itself . The /etc/shorewall/zones file is - used to define additional zones and the example file provided with Shorewall - defines the zones:

    - -
      -
    1. net -- the (untrusted) internet.
      2. -
    2. dmz - systems that must be accessible from the internet - and from the local network.  These systems cannot be trusted completely -since their servers may have been compromised through a security exploit.
      3. -
    3. loc - systems in your local network(s). These systems - must be protected from the internet and from the DMZ and in some cases, - from each other.
      4. - -
    - -

    Note: You can specify the name of the firewall -zone. For ease of description in this documentation, it is assumed -that the firewall zone is named "fw".

    - -

    It can't be stressed enough that with the exception of the firewall zone, - Shorewall itself attaches no meaning to zone names. Zone names are simply - labels used to refer to a collection of network hosts.

    - -

    While zones are normally disjoint (no two zones have a host in common), - there are cases where nested or overlapping zone definitions are appropriate.

    - -

    Netfilter has the concept of tables and chains. For the purpose -of this document, we will consider Netfilter to have three tables:

    - -
      -
    1. Filter table -- this is the main table for packet filtering and can -be displayed with the command "shorewall show".
      2. -
    2. Nat table -- used for all forms of Network Address Translation (NAT); -SNAT, DNAT and MASQUERADE.
      3. -
    3. Mangle table -- used to modify fields in the packet header.
      -
      4. - -
    - -

    Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT, -FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables -as shown in this table.
    -

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

    Shorewall doesn't create rules in all of the builtin chains. In the large + diagram below are boxes such as  shown below.  This box represents in INPUT + chain and shows that packets first flow through the INPUT chain in the Mangle + table followed by the INPUT chain in the Filter table. The parentheses around + "Mangle" indicate that while the packets will flow through the INPUT chain + in the Mangle table, Shorewall does not create any rules in that chain.
    +

    - -
    CHAIN
    -     		Filter
    -     		Nat
    -     		Mangle
    -
    PREROUTING
    -
    -     		X
    -     		X
    -
    INPUT
    -     		X
    -
    -     		X
    -
    OUTPUT
    -     		X
    -     		X
    -     		X
    -
    FORWARD
    -     		X
    -
    -     		X
    -
    POSTROUTING
    -
    -     		X
    -     		X
    -
    -
    - -

    Shorewall doesn't create rules in all of the builtin chains. In the large -diagram below are boxes such as  shown below.  This box represents in INPUT -chain and shows that packets first flow through the INPUT chain in the Mangle -table followed by the INPUT chain in the Filter table. The parentheses around -"Mangle" indicate that while the packets will flow through the INPUT chain -in the Mangle table, Shorewall does not create any rules in that chain.
    -

    -
    (Box Legend) -
    -
    - -

    - -

    Here is a picture of how packets traverse the various chains and tables - in Netfilter. In that diagram, "Local Process" refers to a process running - on the Firewall itself (in the 'fw' zone).

    +
    +
    +

    + +

    Here is a picture of how packets traverse the various chains and tables + in Netfilter. In that diagram, "Local Process" refers to a process running + on the Firewall itself (in the 'fw' zone).

    +
    Netfilter Flow Diagram -
    - -


    -
    - In the text that follows, the paragraph numbers correspond to the box number -in the diagram above.
    -

    - -
      -
    1. Packets entering the firewall first pass through the mangle table's - PREROUTING chain (you can see the mangle table by typing "shorewall show - mangle"). If the packet entered through an interface that has the norfc1918 - option, then the packet is sent down the man1918 chain which will - drop the packet if its destination IP address is reserved (as specified -in the /etc/shorewall/rfc1918 file). Next the packet passes through the -pretos chain to set its TOS field as specified in the /etc/shorewall/tos -file. Finally, if traffic control/shaping is being used, the packet is sent -through the tcpre chain to be marked for later use in policy routing -or traffic control.
      -
      - Next, if the packet isn't part of an established connection, it passes - through the nat table's PREROUTING chain (you can see the nat table - by typing "shorewall show nat"). If you are doing both static nat and -port forwarding, the order in which chains are traversed is dependent on -the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is -on then packets will ender a chain called interface_in where - interface is the name of the interface on which the packet entered. -Here it's destination IP is compared to each of the EXTERNAL IP -addresses from /etc/shorewall/nat that correspond to this interface; if -there is a match, DNAT is applied and the packet header is modified to -the IP in the INTERNAL column of the nat file record. If the destination -address doesn't match any of the rules in the interface_in -chain then the packet enters a chain called sourcezone_dnat - where sourcezone is the source zone of the packet. There it is compared - for a match against each of the DNAT records in the rules file that specify - sourcezone as the source zone. If a match is found, the destination -IP address (and possibly the destination port) is modified based on the -rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of -the interface_in and sourcezone_dnat is reversed.
      -
      -
      2. -
    2. Depending on whether the packet is destined for the firewall itself -or for another system, it follows either the left or the right path. Traffic -going to the firewall goes through chains called INPUT in the mangle table. -Shorewall doesn't add any rules to that chain. Traffic next passes the the -INPUT chain in the filter table where it is broken out based on the interface -on which the packet arrived; packets from interface interface are routed -to chain interface_in. For example, packets arriving through -eth0 are passed to the chain eth0_in.
      3. - -
        -
      1. The first rule in interface_in jumps to the chain -named dynamic which matches the source IP in the packet against all -of the addresses that have been blacklisted using dynamic blacklisting.
        2. -
      2. If the the interface has the norfc1918 option then the packet -is sent down the rfc1918 which checks the source address against those -listed in /etc/shorewall/rfc1918 and treats the packet according to the first -match in that file (if any).
        3. -
      3. If the interface has the  dhcp option, UDP packets to ports -67 and 68 are accepted.
        4. -

      4. -
        5. - -
      -
    3. Traffic is next sent to an input chain in the mail Netfilter - table (called 'filter'). If the traffic is destined for the firewall itself, - the name of the input chain is formed by appending "_in" to the interface - name. So traffic on eth0 destined for the firewall will enter a chain called - eth0_in. The input chain for traffic that will be routed to -another system is formed by appending "_fwd" to the interface name. So traffic - from eth1 that is going to be forwarded enters a chain called eth1_fwd. - Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces, - share input chains. if ppp+ appears in /etc/shorewall/interfaces -then all PPP interfaces (ppp0, ppp1, ...) will share the input chains ppp_in - and ppp_fwd. In other words, "+" is deleted from the name before -forming the input chain names.
      4. - -
    - -

    While the use of input chains may seem wasteful in simple environments, - in complex setups it substantially reduces the number of rules that each - packet must traverse. 

    - -

    Traffic directed from a zone to the firewall itself is sent through -a chain named <zone name>2fw. For example, traffic inbound from - the internet and addressed to the firewall is sent through a chain named - net2fw. Similarly, traffic originating in the firewall and being sent to - a host in a given zone is sent through a chain named fw2<zone name>. - For example, traffic originating in the firewall and destined - for a host in the local network is sent through a chain named fw2loc. -  

    - -

    Traffic being forwarded between two zones (or from one interface to -a zone to another interface to that zone) is sent through a chain named - <source zone>2 <destination zone>. So for example, - traffic originating in a local system and destined for a remote web server - is sent through chain loc2net. This chain is referred to as -the canonical chain from <source zone> to <destination - zone>. Any destination NAT will have occurred before the packet - traverses one of these chains so rules in /etc/shorewall/rules should be - expressed in terms of the destination system's real IP address as opposed - to its apparent external address. Similarly, source NAT will occur after - the packet has traversed the appropriate forwarding chain so the rules - again will be expressed using the source system's real IP address.

    - -

    For each record in the /etc/shorewall/policy file, a chain is created. - Policies in that file are expressed in terms of a source zone and destination - zone where these zones may be a zone defined in /etc/shorewall/zones, -"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined - zones and "fw". These chains are referred to as Policy Chains. Notice - that for an ordered pair of zones (za,zb), the canonical chain (za2zb) -may also be the policy chain for the pair or the policy chain may be a -different chain (za2all, for example). Packets from one zone to another -will traverse chains as follows:

    - -
      -
    1. If the canonical chain exists, packets first traverse that - chain.
      2. -
    2. If the canonical chain and policy chain are different and - the packet does not match a rule in the canonical chain, it then is sent - to the policy chain.
      3. -
    3. If the canonical chain does not exist, packets are sent -immediately to the policy chain.
      4. - -
    - -

    The canonical chain from zone za to zone zb will be created only if -there are exception rules defined in /etc/shorewall/rules for packets going -from za to zb.

    - -

    Shorewall is built on top of the Netfilter kernel facility. Netfilter - implements connection tracking function that allow what is often referred - to as "statefull inspection" of packets. This statefull property allows - firewall rules to be defined in terms of "connections" rather than in - terms of "packets". With Shorewall, you:

    - -
      -
    1. Identify the client's zone.
      2. -
    2. Identify the server's 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. - -
    - -

    Just because connections of a particular type are allowed between zone - A and the firewall and are also allowed between the firewall and zone -B DOES NOT mean that these connections -are allowed between zone A and 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.

    - -

    If you adopt the default policy of ACCEPT from the local zone to the - internet zone and you are having problems connecting from a local client - to an internet server, adding a rule won't - help (see point 3 above).

    + -

    Last modified 5/22/2003 - Tom Eastep

    - -

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

    +



    + In the text that follows, the paragraph numbers correspond to the box number + in the diagram above.
    +

    + +
      +
    1. Packets entering the firewall first pass through the mangle table's + PREROUTING chain (you can see the mangle table by typing "shorewall show + mangle"). If the packet entered through an interface that has the norfc1918 + option and if iptables/netfilter doesn't support the connection tracking +match extension, then the packet is sent down the man1918 chain which +will drop the packet if its destination IP address is reserved (as specified +in the /etc/shorewall/rfc1918 file). Next the packet passes through the +pretos chain to set its TOS field as specified in the /etc/shorewall/tos +file. Finally, if traffic control/shaping is being used, the packet is sent +through the tcpre chain to be marked for later use in policy routing +or traffic control.
      +
      + Next, if the packet isn't part of an established connection, it passes + through the nat table's PREROUTING chain (you can see the nat table + by typing "shorewall show nat"). If you are doing both static nat and port + forwarding, the order in which chains are traversed is dependent on the + setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on +then packets will ender a chain called interface_in where + interface is the name of the interface on which the packet entered. +Here it's destination IP is compared to each of the EXTERNAL IP addresses +from /etc/shorewall/nat that correspond to this interface; if there is +a match, DNAT is applied and the packet header is modified to the IP in +the INTERNAL column of the nat file record. If the destination address +doesn't match any of the rules in the interface_in chain then +the packet enters a chain called sourcezone_dnat where sourcezone +is the source zone of the packet. There it is compared for a match against +each of the DNAT records in the rules file that specify sourcezone + as the source zone. If a match is found, the destination IP address +(and possibly the destination port) is modified based on the rule matched. +If NAT_BEFORE_RULES is off, then the order of traversal of the interface_in +and sourcezone_dnat is reversed.
      +
      +
      2. +
    2. Depending on whether the packet is destined for the firewall itself + or for another system, it follows either the left or the right path. Traffic + going to the firewall goes through chain called INPUT in the mangle table. + Shorewall doesn't add any rules to that chain.
      +
      +
      3. +
    3. Traffic that is to be forwarded to another host goes through the chains +called FORWARD in the mangle table. If MARK_IN_FORWARD=Yes in shorewall.conf, +all rules in /etc/shorewall/tcrules that do not specify Prerouting (:P) are +processed in a chain called
      +
      +
      4. +
        + +
      +
    4. Traffic is next sent to an interface chain in the main Netfilter + table (called 'filter'). If the traffic is destined for the firewall itself, + the name of the interface chain is formed by appending "_in" to the interface + name. So traffic on eth0 destined for the firewall will enter a chain called + eth0_in. The interface chain for traffic that will be routed +to another system is formed by appending "_fwd" to the interface name. +So traffic from eth1 that is going to be forwarded enters a chain called +eth1_fwd. Interfaces described with the wild-card character ("+") +in /etc/shorewall/interfaces, share input chains. if ppp+ appears +in /etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will +share the interface chains ppp_in and ppp_fwd. In other words, +"+" is deleted from the name before forming the input chain names.
      +
      +While the use of interfacechains may seem wasteful in simple environments, + in complex setups it substantially reduces the number of rules that each + packet must traverse. 
      5. + +
    + +

    Traffic directed from a zone to the firewall itself is sent through a +chain named <zone name>2fw. For example, traffic inbound from + the internet and addressed to the firewall is sent through a chain named + net2fw. Similarly, traffic originating in the firewall and being sent +to a host in a given zone is sent through a chain named fw2<zone +name>. For example, traffic originating in the firewall and +destined for a host in the local network is sent through a chain named +fw2loc.  

    + +

    Traffic being forwarded between two zones (or from one interface to a +zone to another interface to that zone) is sent through a chain named + <source zone>2 <destination zone>. So for example, + traffic originating in a local system and destined for a remote web server + is sent through chain loc2net. This chain is referred to +as the canonical chain from <source zone> to <destination + zone>. Any destination NAT will have occurred before the packet + traverses one of these chains so rules in /etc/shorewall/rules should +be expressed in terms of the destination system's real IP address as opposed + to its apparent external address. Similarly, source NAT will occur after + the packet has traversed the appropriate forwarding chain so the rules + again will be expressed using the source system's real IP address.

    + +

    For each record in the /etc/shorewall/policy file, a chain is created. + Policies in that file are expressed in terms of a source zone and destination + zone where these zones may be a zone defined in /etc/shorewall/zones, "fw" + or "all". Policies specifying the pseudo-zone "all" matches all defined + zones and "fw". These chains are referred to as Policy Chains. Notice + that for an ordered pair of zones (za,zb), the canonical chain (za2zb) +may also be the policy chain for the pair or the policy chain may be a +different chain (za2all, for example). Packets from one zone to another +will traverse chains as follows:

    + +
      +
    1. If the canonical chain exists, packets first traverse that + chain.
      2. +
    2. If the canonical chain and policy chain are different and + the packet does not match a rule in the canonical chain, it then is sent + to the policy chain.
      3. +
    3. If the canonical chain does not exist, packets are sent +immediately to the policy chain.
      4. + +
    + +

    The canonical chain from zone za to zone zb will be created only if there +are exception rules defined in /etc/shorewall/rules for packets going from +za to zb.

    + +

    Shorewall is built on top of the Netfilter kernel facility. Netfilter + implements connection tracking function that allow what is often referred + to as "statefull inspection" of packets. This statefull property allows + firewall rules to be defined in terms of "connections" rather than +in terms of "packets". With Shorewall, you:

    + +
      +
    1. Identify the client's zone.
      2. +
    2. Identify the server's 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. + +
    + +

    Just because connections of a particular type are allowed between zone + A and the firewall and are also allowed between the firewall and zone B + DOES NOT mean that these connections are + allowed between zone A and 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.

    + +

    If you adopt the default policy of ACCEPT from the local zone to the + internet zone and you are having problems connecting from a local client + to an internet server, adding a rule won't + help (see point 3 above).

    + +

    Last modified 5/22/2003 - Tom Eastep

    + +

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

    +
    +


    diff --git a/Shorewall-docs/shorewall_quickstart_guide.htm b/Shorewall-docs/shorewall_quickstart_guide.htm index 80dde2b5b..fb2dffc2c 100644 --- a/Shorewall-docs/shorewall_quickstart_guide.htm +++ b/Shorewall-docs/shorewall_quickstart_guide.htm @@ -1,308 +1,321 @@ - + - + - + - + Shorewall QuickStart Guide - + - + - - - - - - + + + + + +
    - -

    Shorewall QuickStart Guides - (HOWTO's)
    - Version 4.0

    -
    + +

    Shorewall QuickStart Guides + (HOWTO's)
    +

    +
    - -

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

    - + +

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

    +

    The Guides

    - -

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

    - + +

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

    +

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

    - + - -

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

    - -

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

    - + +

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

    + +

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

    +
      - +
    - +

    Documentation Index

    - -

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

    - + +

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

    + - +

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

    - -

    Last modified 5/18/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 Thomas M. - Eastep
    -

    -
    -
    -
    -
    -
    + +

    Last modified 7/6/2003 - Tom Eastep

    + +

    Copyright 2002, 2003 Thomas M. + Eastep
    +

    diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm index caac7ea7f..d9db44e55 100644 --- a/Shorewall-docs/shorewall_setup_guide.htm +++ b/Shorewall-docs/shorewall_setup_guide.htm @@ -1,2617 +1,2632 @@ - + - + - + - + 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

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

    + +

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

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

    +
    +

    5.3 Rules
    - 5.4 Odds and Ends

    -
    - + 5.4 Odds and Ends

    +
    +

    6.0 DNS
    - 7.0 Starting and Stopping the + 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.

    - + +

    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.

    +

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

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

    + +

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

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

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

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

    - + .

    +

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

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

    + - +

    2.0 Shorewall Concepts

    - -

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

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

    - -

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

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

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

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

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

    - -

    Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw but that may be changed -in the /etc/shorewall/shorewall.conf + +

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

    - -

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

    - + +

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

    +

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

    - -

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

    + +

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

    - +
      -
    • You express your default policy for connections from +
    • You express your default policy for connections from one zone to another zone in the /etc/shorewall/policy file.
      • -
    • You define exceptions to those default policies in the +
    • You define exceptions to those default policies in the /etc/shorewall/rules file.
      • - +
    - -

    Shorewall is built on top of the Netfilter + +

    Shorewall is built on top of the Netfilter kernel facility. Netfilter implements a connection - tracking function that allows what is often referred to as stateful - inspection of packets. This stateful property allows firewall -rules to be defined in terms of connections rather than in -terms of packets. With Shorewall, you:

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

    +
      -
    1. Identify the source zone.
      2. -
    2. Identify the destination zone.
      3. -
    3. If the POLICY from the client's zone to the server's - zone is what you want for this client/server pair, you need do - nothing 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 +
    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.

    - -

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

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

    + +

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

    - +

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

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

    The above policy will:

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

    -     At this point, edit your /etc/shorewall/policy and make +     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 + +

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

    + +

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

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

    - + +

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

    - +

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

    - +
      -
    • +

    • The external interface is eth0.

      -
      • -
    • +
      • +

    • The Local interface is eth1.

      -
      • -
    • +
      • +

    • The DMZ interface is eth2.

      -
      • - + +
    - -

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

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

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

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

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

    +

    Example:

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

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

    + +
    +

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

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

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

    - +

    4.0 Addressing, Subnets and Routing

    - -

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

    - -

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

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

    + +

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

    - -

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

    - + +

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

    +

    4.1 IP Addresses

    - -

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

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

    - -
    + +

    C0.00.02.0E

    -
    - +
    +

    or looking at it as a 32-bit integer

    - -
    + +

    C000020E

    -
    - +
    +

    4.2 Subnets

    - -

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

    - -
    + +

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

    + +

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

    - +

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

    - +

    Class C - netmask 255.255.255.0, size = 256

    -
    - -

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

    - -

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

    + +

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

    + +

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

    - -

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

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

    - +
      -
    1. +

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

      -
      3. -
    3. -

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

      4. +
    4. +

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

      -
      5. -
    5. -

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

      6. +
    6. +

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

      -
      7. -
    7. -

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

      8. +
    8. +

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

      -
      9. - + +
    - -

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

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

    - -

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

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

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

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

    - -
    +
    + +

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

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

    Notice that the VLSM is written with a slash ("/") -- you - will often hear a subnet of size 64 referred to as a "slash 26" -subnet 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:

    - -
    -

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

    + +

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

    + +

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

    + +
    +

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

    -
    - -

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

    + +

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

    - -

    For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork + +

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

    - +

    Example:

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

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

    + +

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

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

    So any address a.b.c.d may also be written a.b.c.d/32 +

    + +

    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.

    - + +

    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.

    - + +

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

    +

    Beginning with Shorewall 1.4.6, /sbin/shorewall supports +an ipcalc command that automatically calculates information about +a [sub]network.
    +

    +

    Example 1:
    +

    +
    + 
    ipcalc 10.10.10.0/25
       CIDR=10.10.10.0/25
       NETMASK=255.255.255.128
       NETWORK=10.10.10.0
       BROADCAST=10.10.10.127
    +
    +Example 2 +
    + 
    ipcalc 10.10.10.0 255.255.255.128
       CIDR=10.10.10.0/25
       NETMASK=255.255.255.128
       NETWORK=10.10.10.0
       BROADCAST=10.10.10.127
    +
    +

    4.3 Routing

    - -

    One of the purposes of subnetting is that it forms the basis + +

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

    - + +

    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 +

    • +

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

      +
      • +
    • +

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

      -
      • -
    • -

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

      • +
    • +

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

      - +
        -
      • -

        If the 'Gateway' column is non-zero, the packet is +

      • +

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

        -
        • -
      • -

        Otherwise, the packet is sent directly to A over +

        • +
      • +

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

        -
        • - + +
      -
      • -
    • -

      Otherwise, the above steps are repeated on the next entry +

      • +
    • +

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

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

    + +

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

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

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

    -
    - -

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

    - +
    + +

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

    +
    + +

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

    +

    4.4 Address Resolution Protocol (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 + +

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

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

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

    -
    - -
    -

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

    +
    + +
    +

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

    +
    + +
    +

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

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

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

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

    + + + +

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

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

    +

    4.5 RFC 1918

    - +

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

    - -

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

    - -
    + +

    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.

    - -
    -

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

    -
    - -
    -

    When selecting addresses from these ranges, there's a couple + +

    +

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

    -
    - -
    +
    + +
      -
    • -

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

    • +

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

      -
      • -
    • -

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

      • +
    • +

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

      -
      • - + +
    +
    + +
    +

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

    - -
    -

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

    -
    - -
    + +

    5.0 Setting up your Network

    +
    + +
    +

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

    - -
    -

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

    -
    - -
    + +
      -
    1. -

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

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

      Non-routed - Your ISP will send traffic to each +

      4. +
    4. +

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

      -
      5. - + +
    -
    - -
    -

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

    + +
    +

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

    - +

    +

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

    - +

    -     If you are using the Debian package, please check your shorewall.conf - file to ensure that the following are set correctly; if they are not, +     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 (Shorewall versions earlier than 1.4.6)
      • -
    • IP_FORWARDING=On
      -
      • - +
    • NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
      • +
    • 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.

    -
    - -
    + +
    +

    5.1 Routed

    +
    + +
    +

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

    +
    + +

    -

    -
    - -
    -

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

    -
    - -
    -

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

    +
    + +
    +

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

    +
    + +
    +

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

    -
    - -
    -

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

    + +
    +

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

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

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

    + +
    +

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

    -
    - -
    -

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

    -
    - -
    +
    + +
    +

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

    +
    + +

    5.2 Non-routed

    +
    + +
    +

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

    - -
    -

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

    -
    - -
    -

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

    -
    - -
    -

    For the remainder of this section, assume that your ISP - has assigned you IP addresses 192.0.2.176-180 and has told you to - use 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 + +

    +

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

    +
    + +
    +

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

    +
    + +
    +

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

    -
    - -
    +
    + +
      -
    • -

      Source Network Address Translation (SNAT). -

      -
      • -
    • -

      Destination Network Address Translation (DNAT) +

    • +

      Source Network Address Translation (SNAT). +

      +
      • +
    • +

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

      -
      • -
    • +
      • +

    • Proxy ARP.

      -
      • -
    • -

      Network Address Translation (NAT) also referred +

      • +
    • +

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

      -
      • - + +
    +
    + +
    +

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

    - -
    -

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

    -
    - -
    + +

     5.2.1 SNAT

    +
    + +
    +

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

    - -
    -

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

    -
    - -
    -

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

    +

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

    -
    - -
    +
    + +

    -

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

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

    - -
    -

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

    -
    - -
    + +

    5.2.2 DNAT

    -
    - -
    -

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

    + +
    +

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

    -
    - -
    +
    + +

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

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

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

    + +
    +

    If one of your daughter's friends at address A wants to access your daughter's server, she can connect to http://192.0.2.176 (the firewall's external - IP address) and the firewall will rewrite the destination IP address - to 192.168.201.4 (your daughter's system) and forward the request. - When your daughter's server responds, the firewall will rewrite the - source 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.

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

    +
    + +
    +

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

    +
    + +

    5.2.3 Proxy ARP

    -
    - -
    +
    + +

    The idea behind proxy ARP is that:

    -
    - -
    -
      -
    • -

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

      -
      • -
    • -

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

      -
      • -
    • -

      When H issues an ARP "who has" request for an address - in the subnetwork defined by A and M, the firewall will -respond (with the MAC if the firewall interface to H).

      -
      • - -
    - -
    -

    Let suppose that we decide to use Proxy ARP on the DMZ in + +

    +
      +
    • +

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

      +
      • +
    • +

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

      +
      • +
    • +

      When H issues an ARP "who has" request for an +address in the subnetwork defined by A and M, the firewall +will respond (with the MAC if the firewall interface to H).

      +
      • + +
    +
    + +
    +

    Let suppose that we decide to use Proxy ARP on the DMZ in 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.
    - +

    +
    + +
    Here, we've assigned the IP addresses 192.0.2.177 to + system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned + an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface + on the firewall. That address and netmask isn't relevant - just be + sure it doesn't overlap another subnet that you've defined.
    +
     
    - +
    -     The Shorewall configuration of Proxy ARP is done using - the /etc/shorewall/proxyarp +     The Shorewall configuration of Proxy ARP is done using + the /etc/shorewall/proxyarp file.
    - -
    -
    + +
    +
    - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    -

    Because the HAVE ROUTE column contains No, Shorewall will +

    +
    + +
    +

    Because the HAVE ROUTE column contains No, Shorewall will add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
    -

    - -

    The ethernet interfaces on DMZ 1 and DMZ 2 should be configured - to have the IP addresses shown but should have the same default gateway - as the firewall itself -- namely 192.0.2.254. In other words, they should - be configured just like they would be if they were parallel to the firewall +

    + +

    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 +

    + +

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

    - +
    + +
    +
    +

    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 +
    2. (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 +
      + "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 +
      + "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 +     arping -U -I eth0 66.58.99.83 # +for example
      +
      + Stevens goes on to mention that not all systems respond correctly + to gratuitous ARPs, but googling for "arping -U" seems to support the idea that it works most of the time.
      -
      -
      3. -
    3. You can call your ISP and ask them to purge the stale +
      +
      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 192.0.2.177. 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 192.0.2.177, ping the ISP's gateway (which we + will assume is 192.0.2.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.

    - -
    -

    Notice that the source MAC address in the echo request is - different from the destination MAC address in the echo reply!! In - this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while - 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the - gateway's ARP cache still associates 192.0.2.177 with the NIC in -DMZ 1 rather than with the firewall's eth0.

    -
    - -
    + +

    5.2.4 Static NAT

    -
    - -
    -

    With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and -public IP addresses. For outgoing connections SNAT (Source Network -Address Translation) occurs and on incoming connections DNAT (Destination - Network Address Translation) occurs. Let's go back to our earlier example +

    + +
    +

    With static NAT, you assign local systems RFC 1918 addresses + then establish a one-to-one mapping between those addresses and public + IP addresses. For outgoing connections SNAT (Source Network Address + Translation) occurs and on incoming connections DNAT (Destination + Network Address Translation) occurs. Let's go back to our earlier example involving your daughter's web server running on system Local 3.

    -
    - -
    +
    + +

    -

    -
    - -
    -

    Recall that in this setup, the local network is using SNAT - and is sharing the firewall external IP (192.0.2.176) for outbound +

    +
    + +
    +

    Recall that in this setup, the local network is using SNAT + and is sharing the firewall external IP (192.0.2.176) for outbound connections. This is done with the following entry in /etc/shorewall/masq:

    -
    - -
    -
    +
    + +
    +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    -     Suppose now that you have decided to give your daughter - her own IP address (192.0.2.179) for both inbound and outbound connections. +     Suppose now that you have decided to give your daughter + her own IP address (192.0.2.179) for both inbound and outbound connections. You would do that by adding an entry in /etc/shorewall/nat.

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    -

    With this entry in place, you daughter has her own IP address + +

    + +
    +

    With this entry in place, you daughter has her own IP address and the other two local systems share the firewall's IP address.

    -
    - -
    +
    + +

    -     Once the relationship between 192.0.2.179 and 192.168.201.4 - is established by the nat file entry above, it is no longer appropriate - to use a DNAT rule for you daughter's web server -- you would rather +     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 + +

    + +
    +
    +
    +

    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 +
    2. (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 +
      + "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 +     arping -U -I eth0 66.58.99.83 # +for example
      +
      + Stevens goes on to mention that not all systems respond correctly + to gratuitous ARPs, but googling for "arping -U" seems to support the idea that it works most of the time.
      -
      -
      3. -
    3. You can call your ISP and ask them to purge the stale ARP cache - entry but many either can't or won't purge individual entries.
      4. - +
      + +
    4. You can call your ISP and ask them to purge the stale ARP cache + entry but many either can't or won't purge individual entries.
      5. +
    - You can determine if your ISP's gateway ARP cache is stale -using ping and tcpdump. Suppose that we suspect that the gateway -router has a stale ARP cache entry for 209.0.2.179. 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 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):

    - -
    -

    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.

    - -
    -

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

    -
    - -
    -

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't + href="#DNAT">DNAT rules which cause address translation and allow + the translated connection request to pass through the firewall, the + way to allow connection requests through your firewall is to use ACCEPT + rules.

    +
    + +
    +

    NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't used in this section, they won't be shown

    -
    - -
    +
    + +

    You probably want to allow ping between your zones:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    ACTIONSOURCEDESTINATIONPROTOCOLPORT
    ACCEPTnetdmzicmpecho-request
    ACCEPTnetlocicmpecho-request
    ACCEPTdmzlocicmpecho-request
    ACCEPTlocdmzicmpecho-request
    -
    -
    - -
    -

    Let's suppose that you run mail and pop3 servers on DMZ 2 + +

    + +
    +

    Let's suppose that you run mail and pop3 servers on DMZ 2 and a Web Server on DMZ 1. The rules that you would need are:

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
    -
    + +
    + +
    +

    If you run a public DNS server on 192.0.2.177, you would +need to add the following rules:

    - -
    -

    If you run a public DNS server on 192.0.2.177, you would need - to add the following rules:

    -
    - -
    -
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    -
    +
    +
    + +
    +

    You probably want some way to communicate with your firewall + and DMZ systems from the local network -- I recommend SSH which through + its scp utility can also do publishing and software update distribution.

    - -
    -

    You probably want some way to communicate with your firewall - and DMZ systems from the local network -- I recommend SSH which -through its scp utility can also do publishing and software update -distribution.

    -
    - -
    -
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    +
    +
    + +

    5.4 Odds and Ends

    +
    + +
    +

    The above discussion reflects my personal preference for +using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. +I prefer to use NAT only in cases where a system that is part of an RFC +1918 subnet needs to have it's own public IP. 

    - -
    -

    The above discussion reflects my personal preference for using - Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I -prefer to use NAT only in cases where a system that is part of an RFC 1918 -subnet needs to have it's own public IP. 

    -
    - -
    + +

    -     If you haven't already, it would be a good idea to browse - through /etc/shorewall/shorewall.conf - just to see if there is anything there that might be of interest. - You might also want to look at the other configuration files that -you haven't touched yet just to get a feel for the other things that -Shorewall can 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).

    -
    - -
    -
    +     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
    ZoneInterfaceBroadcastOptions
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    neteth0detectnorfc1918,routefilter
    loceth1detect 
    dmzeth2detect 
    -
    -
    - -
    -

    The setup described here requires that your network interfaces - be brought up before Shorewall can start. This opens a short window - during which you have no firewall protection. If you replace 'detect' - with the actual broadcast addresses in the entries above, you can + +

    + +
    +

    The setup described here requires that your network interfaces + be brought up before Shorewall can start. This opens a short window + during which you have no firewall protection. If you replace 'detect' + with the actual broadcast addresses in the entries above, you can bring up Shorewall before you bring up your network interfaces.

    -
    - -
    -
    +
    + +
    +
    - + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ZoneInterfaceBroadcastOptions
    ZoneInterfaceBroadcastOptions
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    neteth0192.0.2.255norfc1918,routefilter
    loceth1192.168.201.7 
    dmzeth2192.168.202.7 
    -
    -
    - -
    + +
    + +

    /etc/shorewall/masq - Local subnet

    -
    - -
    -
    +
    + +
    +
    - - - - - - + - - - - - - + + + + + + + + + + +
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    INTERFACESUBNETADDRESS
    eth0192.168.201.0/29192.0.2.176
    -
    -
    - -
    + +
    + +

    /etc/shorewall/proxyarp - DMZ

    -
    - -
    -
    +
    + +
    +
    - - - - - - - + - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    ADDRESSINTERFACEEXTERNALHAVE ROUTE
    192.0.2.177eth2eth0No
    192.0.2.178eth2eth0No
    -
    -
    - -
    + +
    + +

    /etc/shorewall/nat- Daughter's System

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - + - - - - - - - - + + + + + + + + + + + + + + +
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
    192.0.2.179eth0192.168.201.4NoNo
    -
    -
    - -
    + +
    + +

    /etc/shorewall/rules

    -
    - -
    -
    +
    + +
    +
    - - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
    ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
    ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
    ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
    ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
    ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
    ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
    ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
    ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
    ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
    ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
    ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
    ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
    ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
    ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
    ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
    ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
    ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
    ACCEPTnetdmzicmpecho-request# Ping
    ACCEPTnetlocicmpecho-request#  "
    ACCEPTdmzlocicmpecho-request# "
    ACCEPTlocdmzicmpecho-request# "
    ACCEPTlocdmztcpssh# SSH to the DMZ
    ACCEPTlocfwtcpssh# SSH to the Firewall
    -
    -
    - -
    + +
    + +

    6.0 DNS

    -
    - -
    -

    Given the collection of RFC 1918 and public addresses in this - setup, it only makes sense to have separate internal and external DNS -servers. You can combine the two into a single BIND 9 server using Views. - If you are not interested in Bind 9 views, you can + +

    - -
    -

    Suppose that your domain is foobar.net and you want the two - DMZ systems named www.foobar.net and mail.foobar.net and you want - the three local systems named "winken.foobar.net, blinken.foobar.net - and nod.foobar.net. You want your firewall to be known as firewall.foobar.net - externally and it's interface to the local network to be know as gateway.foobar.net - and its interface to the dmz as dmz.foobar.net. Let's have the DNS - server on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    -
    - -
    +
    + +
    +

    Suppose that your domain is foobar.net and you want the two + DMZ systems named www.foobar.net and mail.foobar.net and you want + the three local systems named "winken.foobar.net, blinken.foobar.net + and nod.foobar.net. You want your firewall to be known as firewall.foobar.net + externally and it's interface to the local network to be know as gateway.foobar.net + and its interface to the dmz as dmz.foobar.net. Let's have the DNS + server on 192.0.2.177 which will also be known by the name ns1.foobar.net.

    +
    + +

    The /etc/named.conf file would look like this:

    -
    - -
    -
    -
    +
    + +
    +
    + 
    options {
    	directory "/var/named";
    	listen-on { 127.0.0.1 ; 192.0.2.177; };
    };

    logging {
    	channel xfer-log {
    		file "/var/log/named/bind-xfer.log";
    		print-category yes;
    		print-severity yes;
    		print-time yes;
    		severity info;
    	};
    	category xfer-in { xfer-log; };
    	category xfer-out { xfer-log; };
    	category notify { xfer-log; };
    };
    -
    - -
    +
    + + 
    #
    # This is the view presented to our internal systems
    #

    view "internal" {
    	#
    	# These are the clients that see this view
    	#
    	match-clients { 192.168.201.0/29;
    			192.168.202.0/29;
    			127.0.0.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 +

    +
    +
    + +
    +

    Here are the files in /var/named (those not shown are usually included in your bind disbribution).

    - -

    db.192.0.2.176 - This is the reverse zone for the firewall's + +

    db.192.0.2.176 - This is the reverse zone for the firewall's external interface

    - -
    + +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
    ; Filename: db.192.0.2.176
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
    -
    -
    - -
    -
    db.192.0.2.177 - This is the reverse zone for the www/DNS - server -
    +
    +
    + +
    +
    db.192.0.2.177 - This is the reverse zone for the www/DNS + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
    ; Filename: db.192.0.2.177
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
    -
    -
    -
    - -
    -
    db.192.0.2.178 - This is the reverse zone for the mail - server -
    +
    +
    +
    + +
    +
    db.192.0.2.178 - This is the reverse zone for the mail + server +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
    ; Filename: db.192.0.2.178
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
    -
    -
    -
    - -
    -
    db.192.0.2.179 - This is the reverse zone for daughter's - web server's public IP -
    +
    +
    +
    + +
    +
    db.192.0.2.179 - This is the reverse zone for daughter's + web server's public IP +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
    ; Filename: db.192.0.2.179
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2001102303 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ) ; minimum (1 day)
    ;
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800	IN NS	ns1.foobar.net.
    @	604800	IN NS	<name of secondary ns>.
    ;
    ; ############################################################
    ; Iverse Address Arpa Records (PTR's) 
    ; ############################################################
    179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
    -
    -
    -
    - -
    + +
    +
    + +

    int/db.127.0.0 - The reverse zone for localhost

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
    ; Filename: db.127.0.0
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    				2001092901 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)
    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR	localhost.foobar.net.
    -
    -
    - -
    -

    int/db.192.168.201 - Reverse zone for the local net. This + +

    + +
    +

    int/db.192.168.201 - Reverse zone for the local net. This is only shown to internal clients

    -
    - -
    -
    +
    + +
    +
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
    ; Filename: db.192.168.201
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @	604800		IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1	86400		IN PTR 	gateway.foobar.net.
    2	86400		IN PTR	winken.foobar.net.
    3	86400		IN PTR	blinken.foobar.net.
    4	86400		IN PTR	nod.foobar.net.
    -
    + +
    + +
    +

    int/db.192.168.202 - Reverse zone for the firewall's DMZ + interface

    - -
    -

    int/db.192.168.202 - Reverse zone for the firewall's DMZ - interface

    -
    - -
    -
    -
    + +
    +
    + 
    ; ############################################################
    ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
    ; Filename: db.192.168.202
    ; ############################################################
    @ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
    				2002032501 ; serial
    				10800 ; refresh (3 hour)
    				3600 ; retry (1 hour)
    				604800 ; expire (7 days)
    				86400 ) ; minimum (1 day)

    ; ############################################################
    ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
    ; ############################################################
    @		604800	IN NS	ns1.foobar.net.

    ; ############################################################
    ; Iverse Address Arpa Records (PTR's)
    ; ############################################################
    1 		86400 IN PTR	dmz.foobar.net.
    -
    -
    -
    - -
    +
    +
    +
    + +

    int/db.foobar - Forward zone for use by internal clients.

    -
    - -
    -
    +
    + +
    +
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002071501 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; foobar.net Nameserver Records (NS)
    ;############################################################
    @ 		604800	IN NS	ns1.foobar.net.

    ;############################################################
    ; Foobar.net Office Records (ADDRESS)
    ;############################################################
    localhost	86400 	IN A 	127.0.0.1

    firewall	86400	IN A	192.0.2.176
    www		86400	IN A	192.0.2.177
    ns1 		86400	IN A 	192.0.2.177
    www		86400	IN A	192.0.2.177

    gateway		86400	IN A 	192.168.201.1
    winken		86400	IN A 	192.168.201.2
    blinken		86400	IN A	192.168.201.3
    nod		86400	IN A	192.168.201.4
    -
    -
    - -
    + +
    + +

    ext/db.foobar - Forward zone for external clients

    -
    - -
    -
    -
    +
    + +
    +
    + 
    ;##############################################################
    ; Start of Authority for foobar.net.
    ; Filename: db.foobar
    ;##############################################################
    @ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
    			2002052901 ; serial
    			10800 ; refresh (3 hour)
    			3600 ; retry (1 hour)
    			604800 ; expire (7 days)
    			86400 ); minimum (1 day)
    ;############################################################
    ; Foobar.net Nameserver Records (NS)
    ;############################################################
    @		86400	IN NS	ns1.foobar.net.
    @		86400	IN NS	<secondary NS>.
    ;############################################################
    ; Foobar.net 	Foobar Wa Office Records (ADDRESS)
    ;############################################################
    localhost	86400	IN A	127.0.0.1
    ;
    ; The firewall itself
    ;
    firewall	86400	IN A	192.0.2.176
    ;
    ; The DMZ
    ;
    ns1		86400	IN A	192.0.2.177
    www		86400	IN A	192.0.2.177
    mail		86400	IN A	192.0.2.178
    ;
    ; The Local Network
    ;
    nod		86400	IN A	192.0.2.179

    ;############################################################
    ; Current Aliases for foobar.net (CNAME)
    ;############################################################

    ;############################################################
    ; foobar.net MX Records (MAIL EXCHANGER)
    ;############################################################
    foobar.net.	86400	IN A	192.0.2.177
    		86400 	IN MX 0 mail.foobar.net.
    		86400	IN MX 1 <backup MX>.
    -
    -
    -
    - -
    -

    7.0 Starting and Stopping +

    +
    +
    + +
    +

    7.0 Starting and Stopping Your Firewall

    -
    - -
    -

    The installation procedure configures +

    + +
    +

    The installation procedure configures your system to start Shorewall at system boot.

    -
    - -
    -

    The firewall is started using the "shorewall start" command - and stopped using "shorewall stop". When the firewall is stopped, - routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A - running firewall may be restarted using the "shorewall restart" -command. If you want to totally remove any trace of Shorewall from -your Netfilter configuration, use "shorewall clear".

    -
    - -
    +
    + +
    +

    The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, + routing is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

    +
    + +

    -     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 +     Edit the /etc/shorewall/routestopped file and configure + those systems that you want to be able to access the firewall when + it is stopped.

    +
    + + - -

    Last updated 6/27/2003 - + +

    Last updated 7/6/2003 - Tom Eastep

    - -

    Copyright 2002, 2003 + +

    Copyright 2002, 2003 Thomas M. Easte
    -

    +

    +
    diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 51ca27dbc..7d0b069d3 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -3,473 +3,556 @@ - + Shoreline Firewall (Shorewall) 1.4 - + - + - + - + - - + - + - + +
    + + - - + + +
    - + - +

    Shorewall 1.4 "iptables made easy"

    -     		- + +


    -

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

    What is it?

    - -

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

    + +

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

    - -

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

    This program is free software; you can redistribute it and/or modify + it under the terms of Version 2 of the -GNU General Public License as published by the Free Software - Foundation.
    + href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU +General Public License as published by the Free Software + Foundation.
    -
    +
    - This program is distributed in the - hope that it will be useful, but WITHOUT - ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS - FOR A PARTICULAR PURPOSE. See the GNU General - Public License for more details.
    + This program is distributed in + the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even +the implied warranty of MERCHANTABILITY + or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details.
    -
    +
    - You should have received a copy -of the GNU General Public License - along with this program; if not, write - to the Free Software Foundation, + 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, the documentation on this site will not apply - directly to your setup. If you want to use the documentation that -you find here, you will want to consider uninstalling what you have and -installing 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

    - - - - - -

    7/4/2003 - Shorewall-1.4.6 Beta 1 (New) -
    -

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

    Looking for Information?

    + The Documentation +Index is a good place to start as is the Quick Search to your right. -
    http://shorewall.net/pub/shorewall/testing
    - ftp://shorewall.net/pub/shorewall/testing
    -
    - +

    Running Shorewall on Mandrake with a two-interface setup?

    + If so, the documentation on this site will not + apply directly to your setup. If you want to use the documentation + that you find here, you will want to consider uninstalling what you have + and installing a setup that matches the documentation on this site. + See the Two-interface QuickStart Guide + for details. +

    + + + +

    News

    +

    7/7/2003 - Shorewall-1.4.6 Beta 2 (New) +
    +

    +

    Problems Corrected:
    -

    - +

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

    New Features:
    -

    - + +

    Migration Issues:
    +

    +
      -
    1. A 'newnotsyn' interface option has been added. This option -may be specified in /etc/shorewall/interfaces and overrides the setting -NEWNOTSYN=No for packets arriving on the associated interface.
      -
      -
      2. -
    2. The means for specifying a range of IP addresses in /etc/shorewall/masq +
    3. In earlier versions, an undocumented feature allowed entries +in the host file as follows:
      +
      +     z    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      + This capability was never documented and has been removed in 1.4.6 to allow +entries of the following format:
      +
      +     z   eth1:192.168.1.0/24,192.168.2.0/24
      +
      +
      4. +
    4. The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been +removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically +detected by Shorewall (see below).
      +
      5. +
    + +

    New Features:
    +

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

    6/17/2003 - Shorewall-1.4.5

    - +

    Problems Corrected:
    -

    - +

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

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

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

    - + + +

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

    +

    - +
      - +
    - +

    - +

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

    - + - +

    More News

    - + - +

    - + - +

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

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

    SourceForge Logo -

    - + + - +

    - + - +

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

    - + - +

    Donations

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


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

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

    - +

    Quick Search
    - -

    - +

    + -
    + value="[http://lists.shorewall.net/pipermail/*]"> + - +

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

    -
    -
    -
    + +

    Updated 7/7/2003 - Tom Eastep +
    +

    diff --git a/Shorewall-docs/starting_and_stopping_shorewall.htm b/Shorewall-docs/starting_and_stopping_shorewall.htm index 50f99a757..af85106e4 100644 --- a/Shorewall-docs/starting_and_stopping_shorewall.htm +++ b/Shorewall-docs/starting_and_stopping_shorewall.htm @@ -1,341 +1,294 @@ - + - + - + - + Starting and Stopping Shorewall - - - + - - - - - + + - - - - - + + + +
    - - -

    Starting/Stopping and Monitoring +

    +

    Starting/Stopping and Monitoring the Firewall

    - -
    - - - - -

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

    - - - - - - - - + +

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

    +

    Important Notes:
    -

    - +

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

    -

    - - - - -

    You can manually start and stop Shoreline Firewall using the "shorewall" + +

    + +

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

    - - + - If you include the keyword debug as the first argument, then + If you include the keyword debug as the first argument, then a shell trace of the command is produced as in:
    - + 
    	shorewall debug start 2> /tmp/trace
    - - - - -

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

    - -

    The Shorewall State Diagram is shown at the + +

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

    + +

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

    - +

    +

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

    - - +
      -
    • shorewall status - produce a verbose report about the +
    • shorewall status - produce a verbose report about the firewall (iptables -L -n -v)
      • -
    • shorewall show chain - produce a verbose report +
    • shorewall show chain - produce a verbose report about chain (iptables -L chain -n -v)
      • -
    • shorewall show nat - produce a verbose report about the - nat table (iptables -t nat -L -n -v)
      • -
    • shorewall show tos - produce a verbose report about the - mangle table (iptables -t mangle -L -n -v)
      • -
    • shorewall show log - display the last 20 packet log entries.
      • -
    • shorewall show connections - displays the IP connections +
    • shorewall show nat - produce a verbose report about +the nat table (iptables -t nat -L -n -v)
      • +
    • shorewall show tos - produce a verbose report about +the mangle table (iptables -t mangle -L -n -v)
      • +
    • shorewall show log - display the last 20 packet log +entries.
      • +
    • shorewall show connections - displays the IP connections currently being tracked by the firewall.
      • -
    • shorewall - show - tc - displays +
    • shorewall show + tc - displays information about the traffic control/shaping configuration.
      • -
    • shorewall monitor [ delay ] - Continuously display the - firewall status, last 20 log entries and nat. When the log +
    • shorewall monitor [ delay ] - Continuously display the + firewall status, last 20 log entries and nat. When the log entry display changes, an audible alarm is sounded.
      • -
    • shorewall hits - Produces several reports about the Shorewall - packet log messages in the current /var/log/messages file.
      • -
    • shorewall version - Displays the installed version +
    • shorewall hits - Produces several reports about the +Shorewall packet log messages in the current /var/log/messages +file.
      • +
    • shorewall version - Displays the installed version number.
      • -
    • shorewall check - Performs a cursory validation of the +
    • shorewall check - Performs a cursory validation of the zones, interfaces, hosts, rules and policy files.
      -
      - The "check" command is totally unsuppored -and does not parse and validate the generated iptables commands. Even -though the "check" command completes successfully, the configuration -may fail to start. Problem reports that complain about errors that the 'check' +
      + The "check" command is totally unsuppored +and does not parse and validate the generated iptables commands. +Even though the "check" command completes successfully, the configuration +may fail to start. Problem reports that complain about errors that the 'check' command does not detect will not be accepted.
      +
      + See the recommended way to make configuration changes described below.

      - See the recommended way to make configuration changes described below.
      -
      -
      • -
    • shorewall try configuration-directory [ timeout - ] - Restart shorewall using the specified configuration and if an - error occurs or if the timeout option is given and the new -configuration has been up for that many seconds then shorewall is -restarted using the standard configuration.
      • -
    • shorewall deny, shorewall reject, shorewall accept and - shorewall save implement dynamic +
      • +
    • shorewall try configuration-directory [ timeout + ] - Restart shorewall using the specified configuration and if +an error occurs or if the timeout option is given and the +new configuration has been up for that many seconds then shorewall +is restarted using the standard configuration.
      • +
    • shorewall deny, shorewall reject, shorewall accept and + shorewall save implement dynamic blacklisting.
      • -
    • shorewall logwatch (added in version 1.3.2) - Monitors - the LOGFILE and produces an audible alarm when +
    • shorewall logwatch (added in version 1.3.2) - Monitors + the LOGFILE and produces an audible alarm when new Shorewall messages are logged.
      • - +
    - Finally, the "shorewall" program may be used to dynamically alter - the contents of a zone.
    - +Beginning with Shorewall 1.4.6, /sbin/shorewall supports a couple of commands +for dealing with IP addresses and IP address ranges:
      -
    • shorewall add interface[:host] zone - - Adds the specified interface (and host if included) to the specified -zone.
      • -
    • shorewall delete interface[:host] zone - - Deletes the specified interface (and host if included) from the specified - zone.
      • - +
    • shorewall ipcalc [ address mask | address/vlsm ] - displays +the network address, broadcast address, network in CIDR notation and netmask +corresponding to the input[s].
      • +
    • shorewall iprange address1-address2 - Decomposes the specified +range of IP addresses into the equivalent list of network/host addresses. +
      +
    - +Finally, the "shorewall" program may be used to dynamically alter the +contents of a zone.
    + +
      +
    • shorewall add interface[:host] zone - + Adds the specified interface (and host if included) to the specified zone.
      • +
    • shorewall delete interface[:host] zone + - Deletes the specified interface (and host if included) from +the specified zone.
      • + +
    +
    Examples:
    - -
    shorewall add ipsec0:192.0.2.24 vpn1 + +
    shorewall add ipsec0:192.0.2.24 vpn1 -- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1
    - shorewall delete ipsec0:192.0.2.24 -vpn1 -- deletes the address 192.0.2.24 from interface ipsec0 + shorewall delete ipsec0:192.0.2.24 +vpn1 -- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1
    -
    -
    - - -

    The shorewall start, shorewall restart, shorewall check, and +

    + + +

    The shorewall start, shorewall restart, shorewall check, and shorewall try commands allow you to specify which Shorewall configuration + href="configuration_file_basics.htm#Configs"> Shorewall configuration to use:

    - - -
    - - + +

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

    -
    - - -

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

    +
    + +

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

    - - - - -

    When changing the configuration of a production firewall, I recommend + +

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

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

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

    - - - - + +

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

    +

    When the new configuration works then just

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

    The Shorewall State Diargram is depicted below.
    -

    - +

    +
    (State Diagram) -
    -
    - +
    +
    +

     
    -

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

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

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

    Updated 7/6/2003 - Tom Eastep

    - - - -

    Copyright + +

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

    +

    +

    diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index 3d8772b91..6367fef2a 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -1,82 +1,84 @@ - + - + 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: - - + action="http://lists.shorewall.net/cgi-bin/htsearch"> Match: + + - Format: - + Format: + - Sort by: - + Sort by: + - Include Mailing List Archives: - + size="-1"> 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 - 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 - 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 -your job for you.
      -
      -
      • -
    • When reporting a problem, ALWAYS - include this information:
      • - +
    • 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 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 + your job for you.
      +
      +
      • +
    • When reporting a problem, + ALWAYS include this information:
      • +
    - +
      - +
        -
      • the exact version of Shorewall +
      • the exact version of Shorewall you are running.
        -
        - shorewall +
        + shorewall version
        -
        -
        • - +
        + +
      - +
        -
      • the exact kernel version -you are running
        -
        - uname - -a
        -
        -
        • - -
      - -
        -
      • the complete, exact output - of
        -
        - ip -addr show
        -
        -
        • - -
      - -
        -
      • the complete, exact output - of
        -
        - ip -route show
        -
        -
        • - -
      - -
        -
      • If your kernel is modularized, - the exact output from
        -
        - lsmod
        -
        • - +
      - + +
        +
      • the complete, exact output + of
        +
        + ip + addr show
        +
        +
        • + +
      + +
        +
      • the complete, exact output + of
        +
        + ip + route show
        +
        • + +
      + +
        + + +
      +
    - +
      - +
        -
      • If you are having - connection problems of any kind then:
        -
        - 1. /sbin/shorewall -reset
        -
        - 2. Try the connection that is failing.
        -
        - 3. /sbin/shorewall +
      • THIS IS IMPORTANT!
        +
        +         If your problem is that some type of connection +to/from or through your firewall isn't working then please:
        +
        +1. /sbin/shorewall reset
        +
        + 2. Try making 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 + 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 -("/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 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 -"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, +
    • 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 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 +"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.
      • - +
    - -
    The author gratefully acknowleges that the above list was - heavily plagiarized from the excellent LEAF document by Ray - Olszewski found at The author gratefully acknowleges that the above list was + heavily plagiarized from the excellent LEAF document by 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.
    -
    - 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).
    -
    - + +
    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.
    +
    + 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 + style="font-weight: 400;">please post your question or problem to the LEAF Users mailing + href="mailto:leaf-user@lists.sourceforge.net">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 + 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 - + href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing + list. Do not expect to get free MNF support on the list +

    Otherwise, please post your question or problem to the Shorewall users mailing + href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing list .

    - +

    To Subscribe to the mailing list go to http://lists.shorewall.net/mailman/listinfo/shorewall-users + href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users .
    -

    -
    - +

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 6/24/2003 - Tom Eastep

    - +

    + +

    Last Updated 7/6/2003 - Tom Eastep

    +

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

    +

    +

    diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm index af536b3de..c026ca9a5 100755 --- a/Shorewall-docs/upgrade_issues.htm +++ b/Shorewall-docs/upgrade_issues.htm @@ -1,447 +1,464 @@ - + Upgrade Issues - + - + - + - + - - - + + - - - + + + +
    - +
    +

    Upgrade Issues

    -
    - +

    For upgrade instructions see the Install/Upgrade page.
    -

    - -

    It is important that you read all of the sections on this page where the - version number mentioned in the section title is later than what you -are currently running.
    -

    - -

    In the descriptions 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.
    -

    - +

    + +

    It is important that you read all of the sections on this page where the + version number mentioned in the section title is later than what you + are currently running.
    +

    + +

    In the descriptions 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 +    
    +     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.
    -

    - +

    +

    - +

    Version >= 1.4.6

    -The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed from -shorewall.conf. These capabilities are now automatically detected by Shorewall.
    -

    Version >= 1.4.4

    - If you are upgrading from 1.4.3 and have set the LOGMARKER variable in -/etc/shorewall/shorewall.conf, then you - must set the new LOGFORMAT variable appropriately and remove your setting - of LOGMARKER
    -
    +
      +
    • The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed +from shorewall.conf. These capabilities are now automatically detected by +Shorewall.
      • +
    • An undocumented feature previously allowed entries in the host +file as follows:
      +
      + zone    eth1:192.168.1.0/24,eth2:192.168.2.0/24
      +
      +This capability was never documented and has been removed in 1.4.6 to allow +entries of the following format:
      +
      + zone   eth1:192.168.1.0/24,192.168.2.0/24
      +
      • +
    +

    Version >= 1.4.4

    + If you are upgrading from 1.4.3 and have set the LOGMARKER variable in + /etc/shorewall/shorewall.conf, then +you must set the new LOGFORMAT variable appropriately and remove your setting + of LOGMARKER
    +
    +

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

    Version >= 1.4.2

    - There are some cases where you may want to handle traffic from a particular - group to itself. While I personally think that such a setups are ridiculous, - there are two cases covered in this documentation where it can occur:
    - + There are some cases where you may want to handle traffic from a particular + group to itself. While I personally think that such a setups are ridiculous, + there are two cases covered in this documentation where it can occur:
    +
      -
    1. In FAQ #2.
      2. -
    2. When running Squid as a transparent - proxy in your local zone.
      3. - +
    3. In FAQ #2.
      4. +
    4. When running Squid as a +transparent proxy in your local zone.
      5. +
    - If you have either of these cases, you will want to review the current - documentation and change your configuration accordingly.
    - + If you have either of these cases, you will want to review the current + documentation and change your configuration accordingly.
    +

    Version >= 1.4.1

    - +
      -
    • Beginning with Version 1.4.1, traffic between groups in the - same zone is accepted by default. Previously, traffic from a zone to -itself was treated just like any other traffic; any matching rules were -applied followed by enforcement of the appropriate policy. With 1.4.1 -and later versions, unless you have explicit rules for traffic from Z -to Z or you have an explicit Z to Z policy (where "Z" is some zone) then -traffic between the groups in zone Z will be accepted. If you do have one -or more explicit rules for Z to Z or if you have an explicit Z to Z policy -then the behavior is as it was in prior versions.
      • - +
    • Beginning with Version 1.4.1, traffic between groups in the + same zone is accepted by default. Previously, traffic from a zone to itself + was treated just like any other traffic; any matching rules were applied + followed by enforcement of the appropriate policy. With 1.4.1 and later + versions, unless you have explicit rules for traffic from Z to Z or you + have an explicit Z to Z policy (where "Z" is some zone) then traffic between + the groups in zone Z will be accepted. If you do have one or more explicit + rules for Z to Z or if you have an explicit Z to Z policy then the behavior + is as it was in prior versions.
      • +
    - -
    + +
      -
    1. If you have a Z Z ACCEPT policy for a zone to allow traffic - between two interfaces to the same zone, that policy can be removed and +
    2. If you have a Z Z ACCEPT policy for a zone to allow traffic + between two interfaces to the same zone, that policy can be removed and traffic between the interfaces will traverse fewer rules than previously.
      3. -
    3. If you have a Z Z DROP or Z Z REJECT policy or you have +
    4. If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z rules then your configuration should not require any change.
      5. -
    5. If you are currently relying on a implicit policy (one that - has "all" in either the SOURCE or DESTINATION column) to prevent traffic - between two interfaces to a zone Z and you have no rules for Z->Z then - you should add an explicit DROP or REJECT policy for Z to Z.
      -
      6. - +
    6. If you are currently relying on a implicit policy (one that + has "all" in either the SOURCE or DESTINATION column) to prevent traffic + between two interfaces to a zone Z and you have no rules for Z->Z +then you should add an explicit DROP or REJECT policy for Z to Z.
      +
      7. +
    -
    - +
    +
      -
    • Sometimes, you want two separate zones on one interface but -you don't want Shorewall to set up any infrastructure to handle traffic -between them.
      • - +
    • Sometimes, you want two separate zones on one interface but + you don't want Shorewall to set up any infrastructure to handle traffic + between them.
      • +
    - +
    Example:
    - -
    + + 
    /etc/shorewall/zones

    z1	Zone1	The first Zone
    z2	Zone2	The secont Zone

    /etc/shorewall/interfaces

    z2	eth1	192.168.1.255

    /etc/shorewall/hosts

    z1	eth1:192.168.1.3
    -
    - Here, zone z1 is nested in zone z2 and the firewall is not going -to be involved in any traffic between these two zones. Beginning with Shorewall - 1.4.1, you can prevent Shorewall from setting up any infrastructure to +
    + Here, zone z1 is nested in zone z2 and the firewall is not going +to be involved in any traffic between these two zones. Beginning with Shorewall + 1.4.1, you can prevent Shorewall from setting up any infrastructure to handle traffic between z1 and z2 by using the new NONE policy:
    - -
    + + 
    /etc/shorewall/policy
    z1	z2	NONE
    z2	z1	NONE
    -
    - Note that NONE policies are generally used in pairs unless there -is asymetric routing where only the traffic on one direction flows through - the firewall and you are using a NONE polciy in the other direction. 
    - -

    Version 1.4.1
    -

    - -
      -
    • In Version 1.4.1, Shorewall will never create rules to deal - with traffic from a given group back to itself. The multi interface - option is no longer available so if you want to route traffic between -two subnetworks on the same interface then I recommend that you upgrade -to Version 1.4.2 and use the 'routeback' interface or host option. 
      • - -
    - -

    Version >= 1.4.0

    - IMPORTANT: Shorewall >=1.4.0 requires the - iproute package ('ip' utility).
    -
    - Note: Unfortunately, some distributions call this package - iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
    -
    -      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 -
    -
    - This may be worked around by using the --nodeps option of rpm -(rpm -Uvh --nodeps <shorewall rpm>).
    -
    - If you are upgrading from a version < 1.4.0, then:
    - -
      -
    • The noping and forwardping interface -options are no longer supported nor is the FORWARDPING option -in shorewall.conf. ICMP echo-request (ping) packets are treated just -like any other connection request and are subject to rules and policies.
      • -
    • Interface names of the form <device>:<integer> - in /etc/shorewall/interfaces now generate a Shorewall error at startup - (they always have produced warnings in iptables).
      • -
    • The MERGE_HOSTS variable has been removed from shorewall.conf. - Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone - contents are determined by BOTH the interfaces and hosts files when -there are entries for the zone in both files.
      • -
    • The routestopped option in the interfaces and - hosts file has been eliminated; use entries in the routestopped file - instead.
      • -
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules - is no longer accepted; you must convert to using the new syntax.
      • -
    • The ALLOWRELATED variable in shorewall.conf - is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with - ALLOWRELATED=Yes.
      • -
    • Late-arriving DNS replies are now dropped -by default; there is no need for your own /etc/shorewall/common file -simply to avoid logging these packets.
      • -
    • The 'firewall', 'functions' and 'version' -file have been moved to /usr/share/shorewall.
      • -
    • The icmp.def file has been removed. If you -include it from /etc/shorewall/icmpdef, you will need to modify that -file.
      • - -
        - -
      -
    • If you followed the advice in FAQ #2 and call find_interface_address - in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
      -
      • - -
    - -
      - -
    - -

    Version 1.4.0

    - -
      -
    • The 'multi' interface option is no longer supported. -  Shorewall will generate rules for sending packets back out the same - interface that they arrived on in two cases:
      • - -
    - -
    -
      -
    • There is an explicit policy for the source zone to - or from the destination zone. An explicit policy names both zones and - does not use the 'all' reserved word.
      • - -
    - -
      -
    • There are one or more rules for traffic for the source zone - to or from the destination zone including rules that use the 'all' reserved - word. Exception: if the source zone and destination zone are the same - then the rule must be explicit - it must name the zone in both the SOURCE - and DESTINATION columns.
      • - -
    - -

    Version >= 1.3.14

    - -      Beginning in version 1.3.14, Shorewall treats entries - in /etc/shorewall/masq differently. - The change involves entries with an interface name in the SUBNET - (second) column:
    - + Note that NONE policies are generally used in pairs unless there +is asymetric routing where only the traffic on one direction flows through + the firewall and you are using a NONE polciy in the other direction. 
    + +

    Version 1.4.1
    +

    +
      -
    • Prior to 1.3.14, Shorewall would detect the FIRST -subnet on the interface (as shown by "ip addr show interface") -and would masquerade traffic from that subnet. Any other subnets that -routed through eth1 needed their own entry in /etc/shorewall/masq to -be masqueraded or to have SNAT applied.
      • -
    • Beginning with Shorewall 1.3.14, Shorewall uses the - firewall's routing table to determine ALL subnets routed through the - named interface. Traffic originating in ANY of those subnets is masqueraded - or has SNAT applied.
      • - +
    • In Version 1.4.1, Shorewall will never create rules to +deal with traffic from a given group back to itself. The multi + interface option is no longer available so if you want to route traffic +between two subnetworks on the same interface then I recommend that you +upgrade to Version 1.4.2 and use the 'routeback' interface or host option. 
      • +
    - You will need to make a change to your configuration if:
    - -
      -
    1. You have one or more entries in /etc/shorewall/masq - with an interface name in the SUBNET (second) column; and
      2. -
    2. That interface connects to more than one subnetwork.
      3. - -
    - Two examples:
    -
    -  Example 1 -- Suppose that your current config is - as follows:
    -   
    - -
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    - -
    In this case, the second entry in /etc/shorewall/masq is no longer - required.
    -
    - Example 2-- What if your current configuration is - like this?
    - -
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    - -
    In this case, you would want to change the entry in /etc/shorewall/masq - to:
    -
    - -
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + +

    Version >= 1.4.0

    + IMPORTANT: Shorewall >=1.4.0 requires the + iproute package ('ip' utility).
    +
    + Note: Unfortunately, some distributions call this package + iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
    +
    +      error: failed dependencies:iproute is needed by shorewall-1.4.0-1 +
    +
    + This may be worked around by using the --nodeps option of rpm +(rpm -Uvh --nodeps <shorewall rpm>).
    +
    + If you are upgrading from a version < 1.4.0, then:
    + +
      +
    • The noping and forwardping interface +options are no longer supported nor is the FORWARDPING option +in shorewall.conf. ICMP echo-request (ping) packets are treated just +like any other connection request and are subject to rules and policies.
      • +
    • Interface names of the form <device>:<integer> + in /etc/shorewall/interfaces now generate a Shorewall error at startup + (they always have produced warnings in iptables).
      • +
    • The MERGE_HOSTS variable has been removed from shorewall.conf. + Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone + contents are determined by BOTH the interfaces and hosts files when +there are entries for the zone in both files.
      • +
    • The routestopped option in the interfaces and + hosts file has been eliminated; use entries in the routestopped file + instead.
      • +
    • The Shorewall 1.2 syntax for DNAT and REDIRECT rules + is no longer accepted; you must convert to using the new syntax.
      • +
    • The ALLOWRELATED variable in shorewall.conf + is no longer supported. Shorewall 1.4 behavior is the same as 1.3 +with ALLOWRELATED=Yes.
      • +
    • Late-arriving DNS replies are now dropped + by default; there is no need for your own /etc/shorewall/common file + simply to avoid logging these packets.
      • +
    • The 'firewall', 'functions' and 'version' + file have been moved to /usr/share/shorewall.
      • +
    • The icmp.def file has been removed. If you + include it from /etc/shorewall/icmpdef, you will need to modify that + file.
      • + +
        + +
      +
    • If you followed the advice in FAQ #2 and call find_interface_address + in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
      +
      • + +
    + +
      + +
    + +

    Version 1.4.0

    + +
      +
    • The 'multi' interface option is no longer supported. +  Shorewall will generate rules for sending packets back out the same + interface that they arrived on in two cases:
      • + +
    + +
    +
      +
    • There is an explicit policy for the source zone +to or from the destination zone. An explicit policy names both zones +and does not use the 'all' reserved word.
      • + +
    + +
      +
    • There are one or more rules for traffic for the source +zone to or from the destination zone including rules that use the 'all' +reserved word. Exception: if the source zone and destination zone are +the same then the rule must be explicit - it must name the zone in both +the SOURCE and DESTINATION columns.
      • + +
    +
    + +

    Version >= 1.3.14

    -     Version 1.3.14 also introduced simplified ICMP echo-request - (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf - is used to specify that the old (pre-1.3.14) ping handling is to be - used (If the option is not set in your /etc/shorewall/shorewall.conf - then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the - old handling indefinitely so I urge current users to migrate to using -the new handling as soon as possible. See the 'Ping' -handling documentation for details.
    - -

    Version 1.3.10

    - If you have installed the 1.3.10 Beta 1 RPM and are now - upgrading to version 1.3.10, you will need to use the '--force' option:
    +      Beginning in version 1.3.14, Shorewall treats entries + in /etc/shorewall/masq differently. + The change involves entries with an interface name in the +SUBNET (second) column:
    + +
      +
    • Prior to 1.3.14, Shorewall would detect the FIRST + subnet on the interface (as shown by "ip addr show interface") + and would masquerade traffic from that subnet. Any other subnets that + routed through eth1 needed their own entry in /etc/shorewall/masq +to be masqueraded or to have SNAT applied.
      • +
    • Beginning with Shorewall 1.3.14, Shorewall uses +the firewall's routing table to determine ALL subnets routed through +the named interface. Traffic originating in ANY of those subnets +is masqueraded or has SNAT applied.
      • + +
    + You will need to make a change to your configuration if:
    + +
      +
    1. You have one or more entries in /etc/shorewall/masq + with an interface name in the SUBNET (second) column; and
      2. +
    2. That interface connects to more than one subnetwork.
      3. + +
    + Two examples:

    - -
    - 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +  Example 1 -- Suppose that your current config +is as follows:
    +   
    + +
    	[root@gateway test]# cat /etc/shorewall/masq
    	#INTERFACE              SUBNET                  ADDRESS
    	eth0                    eth2                    206.124.146.176
    	eth0                    192.168.10.0/24         206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    	[root@gateway test]# ip route show dev eth2
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254
    	[root@gateway test]#
    + +
    In this case, the second entry in /etc/shorewall/masq is no longer + required.
    - + Example 2-- What if your current configuration +is like this?
    + +
    	[root@gateway test]# cat /etc/shorewall/masq	
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    eth2                    206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE	
    	[root@gateway test]# ip route show dev eth2	
    	192.168.1.0/24  scope link
    	192.168.10.0/24  proto kernel  scope link  src 192.168.10.254	
    	[root@gateway test]#
    + +
    In this case, you would want to change the entry in /etc/shorewall/masq + to:
    +
    + +
    	#INTERFACE              SUBNET                  ADDRESS	
    	eth0                    192.168.1.0/24          206.124.146.176
    	#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    + +     Version 1.3.14 also introduced simplified ICMP echo-request + (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf + is used to specify that the old (pre-1.3.14) ping handling is to +be used (If the option is not set in your /etc/shorewall/shorewall.conf + then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting +the old handling indefinitely so I urge current users to migrate to using + the new handling as soon as possible. See the 'Ping' + handling documentation for details.
    + +

    Version 1.3.10

    + If you have installed the 1.3.10 Beta 1 RPM and are now + upgrading to version 1.3.10, you will need to use the '--force' option:
    +
    + +
    + 
    rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm 
    +
    +

    Version >= 1.3.9

    - The 'functions' file has moved to /usr/lib/shorewall/functions. - If you have an application that uses functions from that file, your - application will need to be changed to reflect this change of location.
    - + The 'functions' file has moved to /usr/lib/shorewall/functions. + If you have an application that uses functions from that file, +your application will need to be changed to reflect this change of +location.
    +

    Version >= 1.3.8

    - -

    If you have a pair of firewall systems configured for failover - or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall - versions >= 1.3.8. Beginning with version 1.3.8, - you must set NEWNOTSYN=Yes in your - /etc/shorewall/shorewall.conf file.

    - + +

    If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

    +

    Version >= 1.3.7

    - -

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf - will need to include the following - rules in their /etc/shorewall/icmpdef file (creating this - file if necessary):

    - + +

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following + rules in their /etc/shorewall/icmpdef file (creating this + file if necessary):

    + 
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    - -

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" - command from that file since the icmp.def file is now empty.

    - + +

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + command from that file since the icmp.def file is now empty.

    +

    Upgrading Bering to Shorewall >= 1.3.3

    - +

    To properly upgrade with Shorewall version 1.3.3 and later:

    - +
      -
    1. Be sure you have - a backup -- you will need to transcribe - any Shorewall configuration changes - that you have made to the new configuration.
      2. -
    2. Replace the shorwall.lrp - package provided on the Bering -floppy with the later one. If you did - not obtain the later version from Jacques's site, see additional - instructions below.
      3. -
    3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall - entry if present. Then do not forget - to backup root.lrp !
      4. - +
    4. Be sure you +have a backup -- you will need + to transcribe any Shorewall configuration + changes that you have made to the new + configuration.
      5. +
    5. Replace the +shorwall.lrp package provided on + the Bering floppy with the later one. If you did + not obtain the later version from Jacques's +site, see additional instructions below.
      6. +
    6. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall + entry if present. Then do not +forget to backup root.lrp !
      7. +
    - -

    The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions for setting up a two-interface - firewall plus you also need to add the following two Bering-specific - rules to /etc/shorewall/rules:

    - -
    + +

    The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions for setting up a two-interface + firewall plus you also need to add the following two Bering-specific + rules to /etc/shorewall/rules:

    + +
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    -
    - +
    +

    Version 1.3.6 and 1.3.7

    - -

    If you have a pair of firewall systems configured for - failover or if you have asymmetric routing, you will need to modify - your firewall setup slightly under Shorewall versions -1.3.6 and 1.3.7

    - + +

    If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions 1.3.6 + and 1.3.7

    +
      -
    1. - -

      Create the file /etc/shorewall/newnotsyn and in it add - the following rule
      -
      - run_iptables -A newnotsyn - -j RETURN # So that the connection tracking table can -be rebuilt
      -                                     # +

    2. + +

      Create the file /etc/shorewall/newnotsyn and in it add + the following rule
      +
      + run_iptables -A newnotsyn + -j RETURN # So that the connection tracking table can + be rebuilt
      +                                     # from non-SYN packets after takeover.
      -  

      -
      3. -
    3. -

      Create /etc/shorewall/common (if you don't already - have that file) and include the following:
      -
      - run_iptables -A common - -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept -Acks to rebuild connection
      -                                                                     - #tracking table.
      - . /etc/shorewall/common.def

      -
      4. - +  

      + +
    4. +

      Create /etc/shorewall/common (if you don't already + have that file) and include the following:
      +
      + run_iptables -A common + -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept + Acks to rebuild connection
      +                                                                     + #tracking table.
      + . /etc/shorewall/common.def

      +
      5. +
    - +

    Versions >= 1.3.5

    - -

    Some forms of pre-1.3.0 rules file syntax are no longer + +

    Some forms of pre-1.3.0 rules file syntax are no longer supported.

    - +

    Example 1:

    - -
    + +
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    -
    - +
    +

    Must be replaced with:

    - -
    + +
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    -
    - -
    +
    + +

    Example 2:

    -
    - -
    +
    + +
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    -
    - -
    +
    + +

    Must be replaced with:

    -
    - -
    +
    + +
    	REDIRECT	loc	3128	tcp	80
    -
    - +
    +

    Version >= 1.3.2

    - -

    The functions and versions files together with the 'firewall' - symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those - applications should be modified accordingly.

    - -

    Last updated 6/29/2003 - Tom -Eastep

    - -

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

    + +

    The functions and versions files together with the 'firewall' + symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those +applications should be modified accordingly.

    + +

    Last updated 6/29/2003 - Tom Eastep +

    + +

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

    +

    diff --git a/Shorewall/fallback.sh b/Shorewall/fallback.sh index f6da090fd..c28c9dd1a 100755 --- a/Shorewall/fallback.sh +++ b/Shorewall/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.4.6Beta1 +VERSION=1.4.6Beta2 usage() # $1 = exit status { diff --git a/Shorewall/install.sh b/Shorewall/install.sh index 6088c3593..133f2fb85 100755 --- a/Shorewall/install.sh +++ b/Shorewall/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.4.6Beta1 +VERSION=1.4.6Beta2 usage() # $1 = exit status { diff --git a/Shorewall/shorewall.spec b/Shorewall/shorewall.spec index 6efd9c858..5790cb91f 100644 --- a/Shorewall/shorewall.spec +++ b/Shorewall/shorewall.spec @@ -1,6 +1,6 @@ %define name shorewall %define version 1.4.6 -%define release 0Beta1 +%define release 0Beta2 %define prefix /usr Summary: Shoreline Firewall is an iptables-based firewall for Linux systems. @@ -105,6 +105,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Mon Jul 07 2003 Tom Eastep +- Changed version to 1.4.6-0Beta2 * Fri Jul 04 2003 Tom Eastep - Changed version to 1.4.6-0Beta1 * Tue Jun 17 2003 Tom Eastep diff --git a/Shorewall/uninstall.sh b/Shorewall/uninstall.sh index df4cd044a..1bcb70fea 100755 --- a/Shorewall/uninstall.sh +++ b/Shorewall/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.6Beta1 +VERSION=1.4.6Beta2 usage() # $1 = exit status {