diff --git a/STABLE/changelog.txt b/STABLE/changelog.txt index d59040f24..6156439da 100644 --- a/STABLE/changelog.txt +++ b/STABLE/changelog.txt @@ -1,19 +1,18 @@ -Changes since 1.3.7 +Changes since 1.3.8 -1. Correct rules file handling bug introduced in 1.3.7. +1. DNAT rules that remap a port but leave the IP address unchanged are + now handled properly. -2. Correct handling of DNAT rule where source is $FW +2. The use of shell variables in the LOG LEVEL or SYNPARMS columns of + the policy file now works correctly. -3. Reverse order of RFC 1918 and DHCP filtering +3. Added support for /etc/shorewall/startup_disabled. -4. "shorewall refresh" fix for FORWARDPING=Yes +4. Added support for DNS names in config files. -5. Replace tab with space in blacklist output. - -6. Added NEWNOTSYN option - -7. Assume 'multi' if canonical chain exists. - -8. Add PROTOCOL and PORT columns to blacklist file +5. Don't insist on state NEW for protocols other than tcp, udp and + icmp. Workaround for conntrack glitches in other protocols. +6. Move 'functions', 'version' and 'firewall' to /usr/lib/shorewall. +7. Fix problems with oddball shells. diff --git a/STABLE/documentation/Documentation.htm b/STABLE/documentation/Documentation.htm index 8df5e20c0..c6b44de34 100644 --- a/STABLE/documentation/Documentation.htm +++ b/STABLE/documentation/Documentation.htm @@ -1,1088 +1,1103 @@ - + - + - + Shorewall 1.3 Documentation - + + - + - + - - - + + - - - + + + +
+

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

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

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

- + within the Shorewall programs

+

Example:

- + 
 	NET_IF=eth0
	NET_BCAST=130.252.100.255
	NET_OPTIONS=noping,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 noping,norfc1918
- +

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

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

- + in /etc/shorewall/zones for each zone; Columns in an entry are:

+ - +

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

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

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

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

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

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

- - - -

Additional Documentation

- -

The following documentation covers a variety of topics and supplements -the QuickStart Guides described -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 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.

+ + + +

Additional Documentation

+ +

The following documentation covers a variety of topics and supplements +the QuickStart Guides described +above.

+ + +

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

- +

Last modified 9/16/2002 - Tom Eastep

- +

Copyright 2002 Thomas M. Eastep

-
+
+
diff --git a/STABLE/documentation/shorewall_setup_guide.htm b/STABLE/documentation/shorewall_setup_guide.htm index fefe0e2ab..c73ff0c9e 100644 --- a/STABLE/documentation/shorewall_setup_guide.htm +++ b/STABLE/documentation/shorewall_setup_guide.htm @@ -1,2368 +1,2429 @@ + - - - - - -Shorewall Setup Guide - + + + + + + + + + Shorewall Setup Guide + + - - - + +

Shorewall Setup Guide

+

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

-
-

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

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

+ +
+

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

+
+

5.0 Setting up your Network

-
-

5.1 Routed
-5.2 Non-routed

-
-

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

-
-

5.3 Rules
-5.4 Odds and Ends

-
+ +
+

5.1 Routed
+ 5.2 Non-routed

+ +
+

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

+
+ +

5.3 Rules
+ 5.4 Odds and Ends

+
+

6.0 DNS
-7.0 Starting and Stopping the Firewall

+ 7.0 Starting and Stopping the Firewall

+

1.0 Introduction

-

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

-

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

-

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

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

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

-

    -If you edit your configuration files on a Windows system, you must save them as -Unix files if your editor supports that option 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.

+ +

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.

+ +

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

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

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

+ +

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

+ +

2.0 Shorewall Concepts

-

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

-

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

-

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

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

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

-

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

-

With the exception of fw, Shorewall attaches absolutely no meaning to -zone names. Zones are entirely what YOU make of them. That means that you should -not expect Shorewall to do something special "because this 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 in -terms of zones.

- -

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

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

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

-
- + +

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

+ +

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

+ +

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

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

The above policy will:

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

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

-

3.0 Network Interfaces

-

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

-

In this diagram:

- -

-

-

The 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 + Name + Description + + + net + The Internet + + + loc + Your Local Network + + + dmz + Demilitarized Zone + + + + + +

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

-

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

-

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

-

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

-

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

-

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

-

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

+ +

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

+ +

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

+ +

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

+ +

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

+ + +

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

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

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
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 (see "man +syslog").
    3. +
  3. reject all other connection requests and log a message at the info + level. When a request is rejected, the firewall will return an RST (if +the protocol is TCP) or an ICMP port-unreachable packet for other protocols.
    4. + +
+ +

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

+ +

3.0 Network Interfaces

+ +

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

+ +

In this diagram:

+ + + +

+

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ + + +

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

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

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

+ +

Example:

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

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

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

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

+ +

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, + you may go to the next section.

+ +

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

+ +

4.1 IP Addresses

+ +

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

+ +
+

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

+ +
+

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 +is largely a thing of the past.

+ +

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

+ +
    +
  1. +

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

    +
    2. +
  2. +

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

    +
    3. +
  3. +

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

    +
    4. +
  4. +

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

    +
    5. + +
+ +

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

+ +

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

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

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

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

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

+ +

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 useful in routing.

+ +

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

+ +

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

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
132255.255.255.255a.b.c.d/32
2 ** 3200.0.0.00.0.0.0/0
+
+ +

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

+ +

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

+ +

Example: 192.0.2.65/29

+ +

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

+ +

4.3 Routing

+ +

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

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

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

+ +

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

+ + + +

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

+ +

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

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

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

+
+ +

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

+ +

4.4 Address Resolution Protocol

+ +

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

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

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

+
+ +
+

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

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

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

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

+ +

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

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

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

+ +

4.5 RFC 1918

+ +

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

+ +

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

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

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

+
+ +
+

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

+
+ +
+ -

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

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

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

-

Example:

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

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

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

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.

-

    -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, -you may go to the next section.

-

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

-

4.1 IP Addresses

-

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

-
-

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

-
-

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 -- today, any system that -you are likely to work with will understand subnetting and Class-based networking is largely a -thing of the past.

-

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

+ +
+

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:

+
+ +
    -
  1. -

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

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

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

    -
    4. -
  4. -

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

    -
    5. -
  5. -

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

    +
  6. +

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

-

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

-

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

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

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

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

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

-

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 useful in routing.

-

For a subnetwork whose address is a.b.c.d and whose - Variable Length Subnet Mask is /v, we denote the subnetwork as "a.b.c.d/v" - using VLSM 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
VLSM Notation:10.10.10.0/25
-
-

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

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

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

-

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

-

Example: 192.0.2.65/29

-

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

-

4.3 Routing

-

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

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

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

-

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

-

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

+ +
+

5.1 Routed

+
+ +
+

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

+
+ +
+

+

+
+ +
+

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

+
+ +
+

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

+
+ +
+

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

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

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

+
+ +
+

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.

+
+ +
+

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.

+
+ +
    -
  • -

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

    +
  • +

    Source Network Address Translation (SNAT). +

    • -
  • -

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

    +
  • +

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

    • -
  • -

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

    -
      -
    • -

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

      -
      • -
    • -

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

      -
      • -
    +
  • +

    Proxy ARP.

    • -
  • -

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

    +
  • +

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

-

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

-

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

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

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

-

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

-

4.4 Address Resolution Protocol

-

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

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

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

+ +
+

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

-
-

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

 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.

-

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

-

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

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

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

-

4.5 RFC 1918

-

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

-

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

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

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

-
-

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

-
-
    -

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

    • -

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

    • -
-
-
-

So it's a good idea to check with your ISP to see if they are - using (or are planning to use) private addresses before you decide 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:

-
-
    -
  1. -

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

    2. -
  2. -

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

    3. -
-
-
-

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

-
-

5.1 Routed

-
-
-

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

-
-

-

-
-

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

-
-

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

-
-

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

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

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

-
-

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.

-
-

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) also - known as Port Forwarding.

    • -
  • -

    Proxy ARP.

    • -
  • -

    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.

-
-

 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.

-
-

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 (netmask - 255.255.255.248).
-
-  
-
-     The systems in - the local zone would be configured with a default gateway of 192.168.201.1 - (the IP address of the firewall's local interface).
-
-  
-
-     SNAT is - configured in Shorewall using the - /etc/shorewall/masq file.
-
-
- + +
+

+

+
+ +
The local zone has been subnetted as 192.168.201.0/29 +(netmask 255.255.255.248).
+ +
 
+ +
+    The systems in the local zone would be configured with a default gateway +of 192.168.201.1 (the IP address of the firewall's local interface).
+ +
 
+ +
+    SNAT is configured in Shorewall using the /etc/shorewall/masq file.
+ +
+
+
+ - - - - - - - - - -
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.

-
-

5.2.2 DNAT

-
-
-

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

-
-

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

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.

-
-

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 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.
-
-  
-
-     The Shorewall - configuration of Proxy ARP is done using the - /etc/shorewall/proxyarp file.
-
-
- - - - - - - - - - - - - - - - - - - -
ADDRESSINTERFACEEXTERNALHAVE ROUTE
192.0.2.177eth2eth0No
192.0.2.178eth2eth0No
-
-
-
-

Because the HAVE ROUTE column contains No, Shorewall will add - host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

-
-

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. 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. 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 default gateway (which we are - assuming 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.

-
-

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 occurs and on incoming connections - DNAT occurs. Let's go back to our earlier example involving your daughter's web - server running on system Local 3.

-
-

-
-

Recall that in this setup, the local network is using SNAT and - is sharing the firewall external IP (192.0.2.176) for outbound connections. - This is done with the following entry in /etc/shorewall/masq:

-
-
- - - - - - - - - - - -
INTERFACESUBNETADDRESS
eth0192.168.201.0/29192.0.2.176
-
-
-
-

    - Suppose now that you have decided to give your daughter her own IP address - (192.0.2.179) for both inbound and outbound connections. You would do that by - adding an entry in /etc/shorewall/nat.

-
-
- - - - - - - - - - - - - - - -
EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
192.0.2.179eth0192.168.201.4NoNo
-
-
-
-

With this entry in place, you daughter has her own IP address - and the other two local systems share the firewall's IP address.

-
-

    - Once the relationship between 192.0.2.179 and 192.168.201.4 is established by - the nat file entry above, it is no longer - appropriate to use a DNAT rule for you daughter's web server -- you would - rather just use an ACCEPT rule:

-
-
- - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
ACCEPTnetloc:192.168.201.4tcpwww  
-
-
-
-

5.3 Rules

-
-
-

    - With the default policies, your local systems (Local 1-3) can access any - servers on the internet and the DMZ can't access any other 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 - 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
-
-
-
-

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

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

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

5.4 Odds and Ends

-
-
-

The above discussion reflects my personal preference for using - Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I prefer - to use NAT only in cases where a system that is part of an RFC 1918 subnet - needs to have it's own public IP. 

-
-

    - If you haven't already, it would be a good idea to browse through - /etc/shorewall/shorewall.conf just to see - if there is anything there that might be of interest. You might also want to - look at the other configuration files that you haven't touched yet just to get - a feel for the other things that Shorewall can do.

-
-

In case you haven't been keeping score, here's the final set - of configuration files for our sample network. Only those that were modified - from the original installation are shown.

-
-

/etc/shorewall/interfaces (The "options" will be very - site-specific).

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + +
ZoneInterfaceBroadcastOptions
neteth0detectnorfc1918,routefilter
loceth1detect 
dmzeth2detect 
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.

-
-

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.

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

5.2.2 DNAT

+
+ +
+

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

+
+ +
+

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

+
+ +
+
+
ZoneInterfaceBroadcastOptions
neteth0192.0.2.255norfc1918,routefilter
loceth1192.168.201.7 
dmzeth2192.168.202.7 
+ + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
DNATnetloc:192.168.201.4tcpwww-192.0.2.176
-
+ +
+ +
+

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

-
-

/etc/shorewall/masq - Local subnet

-
-
- - - - - - - - - - - -
INTERFACESUBNETADDRESS
eth0192.168.201.0/29192.0.2.176
-
+ +
+

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.

-
-

/etc/shorewall/proxyarp - DMZ

-
-
- - - - - - - - - - - - - - - - - - - -
ADDRESSINTERFACEEXTERNALHAVE ROUTE
192.0.2.177eth2eth0No
192.0.2.178eth2eth0No
-
+ +
+

5.2.3 Proxy ARP

+
+ +
+

The idea behind proxy ARP is that:

-
-

/etc/shorewall/nat- Daughter's System

-
-
- - - - - - - - - - - - - - - -
EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
192.0.2.179eth0192.168.201.4NoNo
-
+ +
+
    +
  • +

    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.

-
-

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

+

-
-

6.0 DNS

+ +
Here, we've assigned the IP addresses 192.0.2.177 to +system DMZ 1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned +an arbitrary RFC 1918 IP address and subnet mask to the DMZ interface +on the firewall. That address and netmask isn't relevant - just be sure +it doesn't overlap another subnet that you've defined.
+ +
 
+ +
+    The Shorewall configuration of Proxy ARP is done using the /etc/shorewall/proxyarp file.
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +
ADDRESSINTERFACEEXTERNALHAVE ROUTE
192.0.2.177eth2eth0No
192.0.2.178eth2eth0No
+
+
+ +
+

Because the HAVE ROUTE column contains No, Shorewall will +add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.

-
-

Given the collection of RFC 1918 and public addresses in this - setup, it only makes sense to have separate internal and external DNS servers. - You can combine the two into a single BIND 9 server using Views. - - If you are not interested in Bind 9 views, you can - go to the next section.

-
-

Suppose that your domain is foobar.net and you want the two - DMZ systems named www.foobar.net and mail.foobar.net and you want the three - local systems named "winken.foobar.net, blinken.foobar.net and nod.foobar.net. - You want your firewall to be known as firewall.foobar.net externally and it's - interface to the local network to be know as gateway.foobar.net and its - interface to the dmz as dmz.foobar.net. Let's have the DNS server on - 192.0.2.177 which will also be known by the name ns1.foobar.net.

-
-

The /etc/named.conf file would look like this:

-
-
-
- 
options {
-	directory "/var/named";
-	listen-on { 127.0.0.1 ; 192.0.2.177; };
-};
-
-logging {
-	channel xfer-log {
-		file "/var/log/named/bind-xfer.log";
-		print-category yes;
-		print-severity yes;
-		print-time yes;
-		severity info;
-	};
-	category xfer-in { xfer-log; };
-	category xfer-out { xfer-log; };
-	category notify { xfer-log; };
-};
-
-
- 
#
-# This is the view presented to our internal systems
-#
-
-view "internal" {
-	#
-	# These are the clients that see this view
-	#
-	match-clients { 192.168.201.0/29;
-			192.168.202.0/29;
-			127.0.0/24;
-			192.0.2.176/32; 
-			192.0.2.178/32;
-			192.0.2.179/32;
-			192.0.2.180/32; };
-	#
-	# If this server can't complete the request, it should use outside
-	# servers to do so
-	#
-	recursion yes;
-
-	zone "." in {
-		type hint;
-		file "int/root.cache";
-	};
-
-	zone "foobar.net" in {
-		type master;
-		notify no;
-		allow-update { none; };
-		file "int/db.foobar";
-	};
-
-	zone "0.0.127.in-addr.arpa" in {
-		type master;
-		notify no;
-		allow-update { none; };
-		file "int/db.127.0.0";	
-	};
-
-	zone "201.168.192.in-addr.arpa" in {
-		type master;
-		notify no;
-		allow-update { none; };
-		file "int/db.192.168.201";
-	};
-
-	zone "202.168.192.in-addr.arpa" in {
-		type master;
-		notify no;
-		allow-update { none; };
-		file "int/db.192.168.202";
-	};
-
-	zone "176.2.0.192.in-addr.arpa" in {
-		type master;
-		notify no;
-		allow-update { none; };
-		file "db.192.0.2.176";
-	};
-
-	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";
-	};
-};
-
-
+ +
+

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

-
-

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 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.
-
-
+ +
+
	tcpdump -nei eth0 icmp
+
+ +
+

Now from 192.0.2.177, ping the default gateway (which we +are assuming is 192.0.2.254):

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

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

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 occurs and on incoming connections + DNAT occurs. Let's go back to our earlier example involving your daughter's +web server running on system Local 3.

+ +
+

+

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

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

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

-
-

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.
-
+ +
+
+ + + + + + + + + + + + + + + + + + +
EXTERNALINTERFACEINTERNALALL INTERFACES LOCAL
192.0.2.179eth0192.168.201.4NoNo
+
+
+ +
+

With this entry in place, you daughter has her own IP address + and the other two local systems share the firewall's IP address.

-
-

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

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

-
-

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.
-
-
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL DESTINATION
ACCEPTnetloc:192.168.201.4tcpwww  
+
+
+ +
+

5.3 Rules

+
+ +
+

+    With the default policies, your local systems (Local 1-3) can access +any servers on the internet and the DMZ can't access any other 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.

-
-

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

NOTE: Since the SOURCE PORT and ORIG. DEST. Columns aren't + used in this section, they won't be shown

-
-

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

You probably want to allow ping between your zones:

-
-

7.0 Starting and Stopping Your Firewall

+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORT
ACCEPTnetdmzicmpecho-request
ACCEPTnetlocicmpecho-request
ACCEPTdmzlocicmpecho-request
ACCEPTlocdmzicmpecho-request
+
+
+ +
+

Let's suppose that you run mail and pop3 servers on DMZ 2 +and a Web Server on DMZ 1. The rules that you would need are:

-
-

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

-
-

    - Edit the /etc/shorewall/routestopped file and configure those systems that you - want to be able to access the firewall when it is stopped.

-
-

WARNING: If you are connected to your firewall from the - internet, do not issue a "shorewall stop" command unless you have added an - entry for the IP address that you are connected from to - /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create an - alternate configuration and - test it using the "shorewall try" command.

- -

Last updated -8/18/2002 - Tom -Eastep

- -

Copyright 2002 Thomas M. Eastep

- - - - \ No newline at end of file + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
+
+
+ +
+

If you run a public DNS server on 192.0.2.177, you would +need to add the following rules:

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
+
+
+ +
+

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

5.4 Odds and Ends

+
+ +
+

The above discussion reflects my personal preference for +using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. +I prefer to use NAT only in cases where a system that is part of an RFC +1918 subnet needs to have it's own public IP. 

+
+ +
+

+    If you haven't already, it would be a good idea to browse through + /etc/shorewall/shorewall.conf just +to see if there is anything there that might be of interest. You might +also want to look at the other configuration files that you haven't touched +yet just to get a feel for the other things that Shorewall can do.

+
+ +
+

In case you haven't been keeping score, here's the final +set of configuration files for our sample network. Only those that were +modified from the original installation are shown.

+
+ +
+

/etc/shorewall/interfaces (The "options" will be very +site-specific).

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZoneInterfaceBroadcastOptions
neteth0detectnorfc1918,routefilter
loceth1detect 
dmzeth2detect 
+
+
+ +
+

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

/etc/shorewall/proxyarp - DMZ

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

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

6.0 DNS

+
+ +
+

Given the collection of RFC 1918 and public addresses in +this setup, it only makes sense to have separate internal and external +DNS servers. You can combine the two into a single BIND 9 server using +Views. If you are not interested in Bind 9 views, you can go to the next section.

+
+ +
+

Suppose that your domain is foobar.net and you want the two + DMZ systems named www.foobar.net and mail.foobar.net and you want the +three local systems named "winken.foobar.net, blinken.foobar.net and nod.foobar.net. + You want your firewall to be known as firewall.foobar.net externally and +it's interface to the local network to be know as gateway.foobar.net and +its interface to the dmz as dmz.foobar.net. Let's have the DNS server +on 192.0.2.177 which will also be known by the name ns1.foobar.net.

+
+ +
+

The /etc/named.conf file would look like this:

+
+ +
+
+
+ 
options {
	directory "/var/named";
	listen-on { 127.0.0.1 ; 192.0.2.177; };
};

logging {
	channel xfer-log {
		file "/var/log/named/bind-xfer.log";
		print-category yes;
		print-severity yes;
		print-time yes;
		severity info;
	};
	category xfer-in { xfer-log; };
	category xfer-out { xfer-log; };
	category notify { xfer-log; };
};
+
+ +
+ 
#
# This is the view presented to our internal systems
#

view "internal" {
	#
	# These are the clients that see this view
	#
	match-clients { 192.168.201.0/29;
			192.168.202.0/29;
			127.0.0/24;
			192.0.2.176/32; 
			192.0.2.178/32;
			192.0.2.179/32;
			192.0.2.180/32; };
	#
	# If this server can't complete the request, it should use outside
	# servers to do so
	#
	recursion yes;

	zone "." in {
		type hint;
		file "int/root.cache";
	};

	zone "foobar.net" in {
		type master;
		notify no;
		allow-update { none; };
		file "int/db.foobar";
	};

	zone "0.0.127.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "int/db.127.0.0";	
	};

	zone "201.168.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "int/db.192.168.201";
	};

	zone "202.168.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "int/db.192.168.202";
	};

	zone "176.2.0.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "db.192.0.2.176";
	};

	zone "177.2.0.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "db.192.0.2.177";
	};

	zone "178.2.0.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "db.192.0.2.178";
	};

	zone "179.2.0.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "db.206.124.146.179";
	};

};
#
# This is the view that we present to the outside world
#
view "external" {
	match-clients { any; };
	#
	# If we can't answer the query, we tell the client so
	#
	recursion no;

	zone "foobar.net" in {
		type master;
		notify yes;
		allow-update {none; };
		allow-transfer { <secondary NS IP>; };
		file "ext/db.foobar";
	};

	zone "176.2.0.192.in-addr.arpa" in {
 		type master;
		notify yes;
		allow-update { none; };
		allow-transfer { <secondary NS IP>; };
		file "db.192.0.2.176";
	};

	zone "177.2.0.192.in-addr.arpa" in {
		type master;
		notify yes;
		allow-update { none; };
		allow-transfer { <secondary NS IP>; };
		file "db.192.0.2.177";
	};

	zone "178.2.0.192.in-addr.arpa" in {
		type master;
		notify yes;
		allow-update { none; };
		allow-transfer { <secondary NS IP>; };
		file "db.192.0.2.178";
	};

	zone "179.2.0.192.in-addr.arpa" in {
		type master;
		notify yes;
		allow-update { none; };
		allow-transfer { <secondary NS IP>; };
		file "db.192.0.2.179";
	};
};
+
+
+
+ +
+

Here are the files in /var/named (those not shown are usually + included in your bind disbribution).

+

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 +
+ 
; ############################################################
; 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 +
+ 
; ############################################################
; 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 +
+ 
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
; Filename: db.192.0.2.179
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
			2001102303 ; serial
			10800 ; refresh (3 hour)
			3600 ; retry (1 hour)
			604800 ; expire (7 days)
			86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@	604800	IN NS	ns1.foobar.net.
@	604800	IN NS	<name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's) 
; ############################################################
179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
+
+
+
+ +
+

int/db.127.0.0 - The reverse zone for localhost

+
+ +
+
+ 
; ############################################################
; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
; Filename: db.127.0.0
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
				2001092901 ; serial
				10800 ; refresh (3 hour)
				3600 ; retry (1 hour)
				604800 ; expire (7 days)
				86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@	604800		IN NS	ns1.foobar.net.

; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1	86400		IN PTR	localhost.foobar.net.
+
+
+ +
+

int/db.192.168.201 - Reverse zone for the local net. This +is only shown to internal clients

+
+ +
+
+ 
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
; Filename: db.192.168.201
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
				2002032501 ; serial
				10800 ; refresh (3 hour)
				3600 ; retry (1 hour)
				604800 ; expire (7 days)
				86400 ) ; minimum (1 day)

; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@	604800		IN NS	ns1.foobar.net.

; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1	86400		IN PTR 	gateway.foobar.net.
2	86400		IN PTR	winken.foobar.net.
3	86400		IN PTR	blinken.foobar.net.
4	86400		IN PTR	nod.foobar.net.
+
+
+ +
+

int/db.192.168.202 - Reverse zone for the firewall's DMZ + interface

+
+ +
+
+
+ 
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
; Filename: db.192.168.202
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
				2002032501 ; serial
				10800 ; refresh (3 hour)
				3600 ; retry (1 hour)
				604800 ; expire (7 days)
				86400 ) ; minimum (1 day)

; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@		604800	IN NS	ns1.foobar.net.

; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 		86400 IN PTR	dmz.foobar.net.
+
+
+
+ +
+

int/db.foobar - Forward zone for use by internal clients.

+
+ +
+
+ 
;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
			2002071501 ; serial
			10800 ; refresh (3 hour)
			3600 ; retry (1 hour)
			604800 ; expire (7 days)
			86400 ); minimum (1 day)
;############################################################
; foobar.net Nameserver Records (NS)
;############################################################
@ 		604800	IN NS	ns1.foobar.net.

;############################################################
; Foobar.net Office Records (ADDRESS)
;############################################################
localhost	86400 	IN A 	127.0.0.1

firewall	86400	IN A	192.0.2.176
www		86400	IN A	192.0.2.177
ns1 		86400	IN A 	192.0.2.177
www		86400	IN A	192.0.2.177

gateway		86400	IN A 	192.168.201.1
winken		86400	IN A 	192.168.201.2
blinken		86400	IN A	192.168.201.3
nod		86400	IN A	192.168.201.4
+
+
+ +
+

ext/db.foobar - Forward zone for external clients

+
+ +
+
+
+ 
;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
			2002052901 ; serial
			10800 ; refresh (3 hour)
			3600 ; retry (1 hour)
			604800 ; expire (7 days)
			86400 ); minimum (1 day)
;############################################################
; Foobar.net Nameserver Records (NS)
;############################################################
@		86400	IN NS	ns1.foobar.net.
@		86400	IN NS	<secondary NS>.
;############################################################
; Foobar.net 	Foobar Wa Office Records (ADDRESS)
;############################################################
localhost	86400	IN A	127.0.0.1
;
; The firewall itself
;
firewall	86400	IN A	192.0.2.176
;
; The DMZ
;
ns1		86400	IN A	192.0.2.177
www		86400	IN A	192.0.2.177
mail		86400	IN A	192.0.2.178
;
; The Local Network
;
nod		86400	IN A	192.0.2.179

;############################################################
; Current Aliases for foobar.net (CNAME)
;############################################################

;############################################################
; foobar.net MX Records (MAIL EXCHANGER)
;############################################################
foobar.net.	86400	IN A	192.0.2.177
		86400 	IN MX 0 mail.foobar.net.
		86400	IN MX 1 <backup MX>.
+
+
+
+ +
+

7.0 Starting and Stopping +Your Firewall

+
+ +
+

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

+
+ +
+

+    Edit the /etc/shorewall/routestopped file and configure those systems +that you want to be able to access the firewall when it is stopped.

+
+ +
+

WARNING: If you are connected to your firewall from +the internet, do not issue a "shorewall stop" command unless you have +added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create +an alternate configuration +and test it using the "shorewall +try" command.

+
+ +

Last updated 9/19/2002 - Tom Eastep

+ +

Copyright 2002 Thomas +M. Eastep

+
+ + diff --git a/STABLE/documentation/standalone.htm b/STABLE/documentation/standalone.htm index c09af0eda..32a92a4b6 100644 --- a/STABLE/documentation/standalone.htm +++ b/STABLE/documentation/standalone.htm @@ -1,320 +1,426 @@ + - - - - - -Standalone Firewall + + + + + + + + + Standalone Firewall - - - - - - - + + +
- -

Standalone Firewall

- -
+ + + + + +
+

Standalone Firewall

+
- +

Version 2.0.1

-

Setting up Shorewall on a standalone Linux system is very easy if you understand the basics and follow the -documentation.

+ +

Setting up Shorewall on a standalone Linux system is very +easy if you understand the basics and follow the documentation.

+

This guide doesn't attempt to acquaint you with all of the features of -Shorewall. It rather focuses on what is required to configure Shorewall in one -of its -most common configurations:

+ Shorewall. It rather focuses on what is required to configure Shorewall in +one of its most common configurations:

+
    -
  • Linux system
    • -
  • Single external IP address
    • -
  • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
    • +
  • Linux system
    • +
  • Single external IP address
    • +
  • Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...
    • +
-

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

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

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

-

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

- -

Shorewall Concepts

-

The configuration files for Shorewall are contained in the directory -/etc/shorewall -- for simple setups, you only need to deal with a few of -these as described in this guide. After you have installed Shorewall, -download the one-interface sample, un-tar it -(tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall -(they will replace files with the same names that were placed in /etc/shorewall -during Shorewall installation).

-

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

-

Shorewall views the network where it is running as being composed of a set of -zones. In the one-interface sample configuration, only one zone is -defined:

- - - - - - - - - -
NameDescription
netThe Internet
-

Shorewall zones are defined in -/etc/shorewall/zones.

-

Shorewall also recognizes the firewall system as its own zone - by default, -the firewall itself is known as fw.

-

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

- -

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

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

+ +
     [root@gateway root]# which ip
     /sbin/ip
     [root@gateway root]#
-request is applied. If that policy is REJECT or DROP  the request is first -checked against the rules in /etc/shorewall/common (the samples provide that -file for you).

-

The /etc/shorewall/policy file included with the one-interface sample has the -following policies:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
fwnetACCEPT  
netnetDROPinfo 
allallREJECTinfo 
-
-
     fw		net	ACCEPT
-     net	all	DROP	info
-     all	all	REJECT	info
-

The above policy will:

-
    -
  1. allow all connection requests from the firewall to the internet
    2. -
  2. drop (ignore) all connection requests from the internet to your firewall
    3. -
  3. reject all other connection requests (Shorewall requires this catchall - policy).
    4. -
-

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

-

External Interface

-

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

-

    The Shorewall one-interface sample configuration assumes that -the external interface is eth0. -If your configuration is different, you will have to modify the sample -/etc/shorewall/interfaces file accordingly. While you are there, you may wish to -review the list of options that are specified for the interface. Some hints:

+

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

+ +

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

+
    -
  • -

    If your external interface is ppp0 or ippp0, you can replace the - "detect" in the second column with "-".

    • -
  • -

    If your external interface is ppp0 or ippp0 or if you have a static IP - address, you can remove "dhcp" from the option list.

    • +
  • Windows Version +of dos2unix
    • +
  • Linux Version +of dos2unix
    • +
-
-

IP Addresses

-
-
-

RFC 1918 reserves several Private IP address ranges for -use in private networks:

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

These addresses are sometimes referred to as non-routable - because the Internet backbone routers will not forward a packet whose - destination address is reserved by RFC 1918. In some cases though, ISPs are - assigning these addresses then using Network Address Translation to - rewrite packet headers when forwarding to/from the internet.

-

     - Before starting Shorewall, you should look at the IP address of your external - interface and if it is one of the above ranges, you should remove the - 'norfc1918' option from the entry in /etc/shorewall/interfaces.

-
-

Enabling other Connections

-
-
-

If you wish to enable connections from the internet to your firewall, the general format is:

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

Shorewall Concepts

+ +

The configuration files for Shorewall are contained in the directory +/etc/shorewall -- for simple setups, you only need to deal with a few of + these as described in this guide. After you have installed +Shorewall, download the one-interface sample, +un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall + (they will replace files with the same names that were placed in /etc/shorewall + during Shorewall installation).

+ +

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

+ +

Shorewall views the network where it is running as being composed of a +set of zones. In the one-interface sample configuration, only one +zone is defined:

+ +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
+ + + + + + + + + + + +
NameDescription
netThe Internet
+ +

Shorewall zones are defined in /etc/shorewall/zones.

+ +

Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

+ +

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

+ + + +

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

+ +

The /etc/shorewall/policy file included with the one-interface sample has +the following policies:

+ +
+ + + + + + + + - - - - - - + + + + -
SOURCE ZONEDESTINATION ZONEPOLICYLOG LEVELLIMIT:BURST
ACCEPTnet fw<protocol><port>  netACCEPT  
+ + net + net + DROP + info +   + + + all + all + REJECT + info +   + + + +
-
-
-

Example - You want to run a Web Server and a POP3 Server on your firewall - system:

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp80  
ACCEPTnetfwtcp110  
-
-
-
-

If you don't know what port and protocol a particular - application uses, see here.

-
-

Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want shell - access to your firewall from the internet, use SSH:

-
-
- - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
-
-
-
- 
     ACCEPT	net	fw	tcp	22
-
-
-

    At this point, edit - /etc/shorewall/rules to add other connections as desired.

-
-

Starting and Stopping Your Firewall

-
-
-

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

-
-

WARNING: If you are connected to your firewall from the - internet, do not issue a "shorewall stop" command unless you have added an - entry for the IP address that you are connected from to - /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create an - alternate configuration and - test it using the "shorewall try" command.

-

Last updated -7/23/2002 - Tom -Eastep

- -

Copyright 2002 Thomas M. Eastep

- + +
     fw		net	ACCEPT
     net	all	DROP	info
     all	all	REJECT	info
+ +

The above policy will:

+ +
    +
  1. allow all connection requests from the firewall to the internet
    2. +
  2. drop (ignore) all connection requests from the internet to your firewall
    3. +
  3. reject all other connection requests (Shorewall requires this catchall + policy).
    4. + +
+ +

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

+ +

External Interface

+ +

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

+ +

+     The Shorewall one-interface sample configuration assumes that the external +interface is eth0. If your configuration is different, you will have +to modify the sample /etc/shorewall/interfaces file accordingly. While you +are there, you may wish to review the list of options that are specified +for the interface. Some hints:

+ +
    +
  • +

    If your external interface is ppp0 or ippp0, +you can replace the "detect" in the second column with "-".

    +
    • +
  • +

    If your external interface is ppp0 or ippp0 +or if you have a static IP address, you can remove "dhcp" from the option +list.

    +
    • + +
+ +
+

IP Addresses

+
+ +
+

RFC 1918 reserves several Private IP address ranges +for use in private networks:

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

These addresses are sometimes referred to as non-routable + because the Internet backbone routers will not forward a packet whose + destination address is reserved by RFC 1918. In some cases though, ISPs +are assigning these addresses then using Network Address Translation +to rewrite packet headers when forwarding to/from the internet.

+ +

+      Before starting Shorewall, you should look at the IP address of +your external interface and if it is one of the above ranges, you should +remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.

+
+ +
+

Enabling other Connections

+
+ +
+

If you wish to enable connections from the internet to your +firewall, the general format is:

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfw<protocol><port>  
+
+
+ +
+

Example - You want to run a Web Server and a POP3 Server on +your firewall system:

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp80  
ACCEPTnetfwtcp110  
+
+
+ +
+

If you don't know what port and protocol a particular application +uses, see here.

+
+ +
+

Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want +shell access to your firewall from the internet, use SSH:

+
+ +
+
+ + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
+
+
+ +
+
     ACCEPT	net	fw	tcp	22
+
+ +
+

+     At this point, edit /etc/shorewall/rules to add other connections +as desired.

+
+ +
+

Starting and Stopping Your Firewall

+
+ +
+

Arrow +     The installation procedure configures +your system to start Shorewall at system boot but beginning with Shorewall +version 1.3.9 startup is disabled so that your system won't try to start +Shorewall before configuration is complete. Once you have completed configuration +of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
+

+ +

IMPORTANT: Users of the .deb +package must edit /etc/default/shorewall and set 'startup=1'.
+

+
+ +
+

The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, routing +is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. +If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

+
+ +
+

WARNING: If you are connected to your firewall from +the internet, do not issue a "shorewall stop" command unless you have added +an entry for the IP address that you are connected from to /etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create +an alternate configuration +and test it using the "shorewall try" +command.

+
+ +

Last updated 9/26/2002 - Tom Eastep

+ +

Copyright 2002 Thomas +M. Eastep

+
+
- - \ No newline at end of file + diff --git a/STABLE/documentation/starting_and_stopping_shorewall.htm b/STABLE/documentation/starting_and_stopping_shorewall.htm index 67cc82150..f216e4f9e 100644 --- a/STABLE/documentation/starting_and_stopping_shorewall.htm +++ b/STABLE/documentation/starting_and_stopping_shorewall.htm @@ -1,183 +1,225 @@ + - - - - - -Starting and Stopping Shorewall + + + + + + + + + Starting and Stopping Shorewall - - - - - - - - - -
-

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.

- - - -

- - Important Note:

- - - -

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

- - - -

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

- -
    -
  • shorewall start - starts the firewall
    • -
  • shorewall stop - stops the firewall
    • -
  • shorewall restart - stops the firewall (if it's running) and - then starts it again
    • -
  • shorewall reset - reset the packet and byte counters in the -firewall
    • -
  • shorewall clear - remove all rules and chains installed by -Shoreline Firewall
    • -
  • shorewall refresh - refresh the rules involving the broadcast addresses - of firewall interfaces and the black and white lists.
    • -
- - - -

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

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

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

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

Starting/Stopping and Monitoring +the Firewall

+ +
+ + + -
- -

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

- +

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.

- -

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

    Important Notes:
    +

    + +
      +
    1. Shorewall startup is disabled by default. Once you have configured +your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. +Note: Users of the .deb package must edit /etc/default/shorewall and set +'startup=1'.
      +
      2. +
    2. 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.
      3. + +
    + +

    +

    + + + + +

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

    + + +
      +
    • shorewall start - starts the firewall
      • +
    • shorewall stop - stops the firewall
      • +
    • shorewall restart - stops the firewall (if it's running) +and then starts it again
      • +
    • shorewall reset - reset the packet and byte counters + in the firewall
      • +
    • shorewall clear - remove all rules and chains installed +by Shoreline Firewall
      • +
    • shorewall refresh - refresh the rules involving the broadcast + addresses of firewall interfaces and the black and white lists.
      • +
    - -

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

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

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

      - Updated 8/8/2002 - Tom -Eastep -

      + +

      The shorewall start, shorewall restart, shorewall check  and + shorewall try commands allow you to specify which 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 used.

      - -

      Copyright - © 2001, 2002 Thomas M. Eastep.

      + + +

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

      - - - - \ No newline at end of file + + +
        + +
      • 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.

      + + + + +

      When the new configuration works then just

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

      Updated 9/26/2002 - Tom Eastep +

      + + + +

      Copyright + © 2001, 2002 Thomas M. Eastep.

      + + +
      +
      + + diff --git a/STABLE/documentation/support.htm b/STABLE/documentation/support.htm index 81b759efb..f22c2bd51 100644 --- a/STABLE/documentation/support.htm +++ b/STABLE/documentation/support.htm @@ -1,88 +1,85 @@ - + - + - + - + Support - + - + - - - + + - - - + + + +
      +

      Shorewall Support

      -
      - -

      "It -is easier to post a problem than to use your own brain" -- Weitse Venema (creator of Postfix)

      - -

      "Any sane computer with tell you how it works -- you -just have to ask it the right questions" -- Tom Eastep

      - + +

      "It is +easier to post a problem than to use your own brain" -- Wietse Venema (creator of Postfix)

      + +

      "Any sane computer will tell you how it works -- you just + have to ask it the right questions" -- Tom Eastep

      +
      -

      "It irks me when people believe that -free software comes at no cost. The cost is incredibly high." -- Weitse Venema

      - + +

      "It irks me when people believe that + free software comes at no cost. The cost is incredibly high." +- Wietse Venema

      +

      Before Reporting a Problem

      - +

      There are a number of sources for problem solution information.

      - +
        -
      • The FAQ has solutions to common problems.
        • -
      • The Troubleshooting Information contains -a number of tips to help you solve common problems.
        • -
      • The Errata has links to download updated - components.
        • -
      • The Mailing List Archives are a useful source of problem solving - information.
        • - +
      • The FAQ has solutions to common problems.
        • +
      • The Troubleshooting Information +contains a number of tips to help you solve common problems.
        • +
      • The Errata has links to download updated + components.
        • +
      • The Mailing List Archives search facility can locate posts about + similar problems:
        • +
      -
      -

      The archives from the mailing List are at http://www.shorewall.net/pipermail/shorewall-users.

      - -

      Search the Mailing List Archives at Shorewall.net

      - -
      -

      Match: - +

      Mailing List Archive Search

      + + +

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

      -
      - +

      Problem Reporting Guidelines

      - +
        -
      • When reporting a problem, give as much information as you can. Reports -that say "I tried XYZ and it didn't work" are not at all helpful.
        • -
      • 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.
        • -
      • Do you see any "Shorewall" messages in /var/log/messages when -you exercise the function that is giving you problems?
        • -
      • Have you looked at the packet flow with a tool like tcpdump to -try to understand what is going on?
        • -
      • Have you tried using the diagnostic capabilities of the application -that isn't working? For example, if "ssh" isn't able to connect, using -the "-v" option gives you a lot of valuable diagnostic information.
        • -
      • 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 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.
        • - +
      • When reporting a problem, give as much information as you can. +Reports that say "I tried XYZ and it didn't work" are not at all helpful.
        • +
      • 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.
        • +
      • Do you see any "Shorewall" messages in /var/log/messages when + you exercise the function that is giving you problems?
        • +
      • Have you looked at the packet flow with a tool like tcpdump + to try to understand what is going on?
        • +
      • Have you tried using the diagnostic capabilities of the application + that isn't working? For example, if "ssh" isn't able to connect, using + the "-v" option gives you a lot of valuable diagnostic information.
        • +
      • 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 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.
        • +
      - +

      Where to Send your Problem Report or to Ask for Help

      - -

      If you run Shorewall under Bering -- please - post your question or problem to the If you run Shorewall under Bering -- please + post your question or problem to the LEAF Users mailing list.

      - +

      Otherwise, please post your question or problem to the Shorewall users mailing list; - there are lots of folks there who are willing to help you. Your question/problem - description and their responses will be placed in the mailing list archives -to help people who have a similar question or problem in the future.

      - -

      I don't look at problems sent to me directly but I try to spend some amount - of time each day responding to problems posted on the mailing list.

      - + href="mailto:shorewall-users@shorewall.net">Shorewall users mailing list; + there are lots of folks there who are willing to help you. Your question/problem + description and their responses will be placed in the mailing list archives + to help people who have a similar question or problem in the future.

      + +

      I don't look at problems sent to me directly but I try to spend some amount + of time each day responding to problems posted on the mailing list.

      +

      -Tom

      - +

      To Subscribe to the mailing list go to http://www.shorewall.net/mailman/listinfo/shorewall-users - .

      - -

      Last Updated 9/14/2002 - Tom Eastep

      - + href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users + .

      + +

      Last Updated 9/27/2002 - Tom Eastep

      +

      Copyright © 2001, 2002 Thomas M. Eastep.

      +
      +

      +
      diff --git a/STABLE/documentation/three-interface.htm b/STABLE/documentation/three-interface.htm index 59dec79e5..f6c767173 100644 --- a/STABLE/documentation/three-interface.htm +++ b/STABLE/documentation/three-interface.htm @@ -1,1080 +1,1102 @@ - + - + - + - + Three-Interface Firewall - + - - - + + - - - + + + +
      +

      Three-Interface Firewall

      -
      - +

      Version 2.0.1

      - -

      Setting up a Linux system as a firewall for a small network -with DMZ is a fairly straight-forward task if you understand the basics -and follow the documentation.

      - -

      This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall + +

      Setting up a Linux system as a firewall for a small network + with DMZ is a fairly straight-forward task if you understand the basics + and follow the documentation.

      + +

      This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall in one of its more popular configurations:

      - +
        -
      • Linux system used as a firewall/router for a small local network.
        • -
      • Single public IP address.
        • -
      • DMZ connected to a separate ethernet interface.
        • -
      • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, ...
        • - +
      • Linux system used as a firewall/router for a small local network.
        • +
      • Single public IP address.
        • +
      • DMZ connected to a separate ethernet interface.
        • +
      • Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, + ...
        • +
      - +

      Here is a schematic of a typical installation.

      - +

      -

      - -

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

      - +

      + +

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

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

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

      - + +

      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. Similarly, if you copy a configuration -file from your Windows hard drive to a floppy disk, you must run dos2unix -against the copy before using it with Shorewall.

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

      + - +

      Shorewall Concepts

      - -

      The configuration files for Shorewall are contained in the directory /etc/shorewall --- for simple setups, you will only need to deal with a few of these as -described in this guide. After you have installed -Shorewall, download the three-interface -sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the -files to /etc/shorewall (the files will replace files with the same names + +

      The configuration files for Shorewall are contained in the directory +/etc/shorewall -- for simple setups, you will only need to deal with a few +of these as described in this guide. After you have installed Shorewall, download the three-interface + sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the +files to /etc/shorewall (the files will replace files with the same names that were placed in /etc/shorewall when Shorewall was installed).

      - -

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

      - -

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

      - + +

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

      + +

      Shorewall views the network where it is running as being composed of a + set of zones. In the three-interface sample configuration, the following + zone names are used:

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

      Zone names are defined in /etc/shorewall/zones.

      - -

      Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

      - -

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

      - + +

      Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

      + +

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

      + - -

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

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

      - -

      The /etc/shorewall/policy file included with the three-interface sample -has the following policies:

      - -
      + +

      The /etc/shorewall/policy file included with the three-interface sample + has the following policies:

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

      In the three-interface sample, the line below is included but commented -out. If you want your firewall system to have full access to servers on +

      + +
      +

      In the three-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers on the internet, uncomment that line.

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

      The above policy will:

      - +
        -
      1. allow all connection requests from your local network to the internet
        2. -
      2. drop (ignore) all connection requests from the internet to your firewall - or local network
        3. -
      3. optionally accept all connection requests from the firewall to the - internet (if you uncomment the additional policy)
        4. -
      4. reject all other connection requests.
        5. - +
      5. allow all connection requests from your local network to the internet
        6. +
      6. drop (ignore) all connection requests from the internet to your +firewall or local network
        7. +
      7. optionally accept all connection requests from the firewall to +the internet (if you uncomment the additional policy)
        8. +
      8. reject all other connection requests.
        9. +
      - +

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

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

      +

      Network Interfaces

      - +

      -

      - -

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

      - +

      + +

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

      +

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

      - -

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

      - -

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

      + +

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

      + +

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

      - +

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

      - +

      -    The Shorewall three-interface sample configuration assumes that the -external interface is eth0, the local interface is eth1 and - the DMZ interface is eth2. If your configuration is different, -you will have to modify the sample /etc/shorewall/interfaces file accordingly. -While you are there, you may wish to review the list of options that are -specified for the interfaces. Some hints:

      - +     The Shorewall three-interface sample configuration assumes that the + external interface is eth0, the local interface is eth1 and + the DMZ interface is eth2. If your configuration is different, +you will have to modify the sample /etc/shorewall/interfaces file accordingly. + While you are there, you may wish to review the list of options that are + specified for the interfaces. Some hints:

      +
        -
      • -

        If your external interface is ppp0 or ippp0, -you can replace the "detect" in the second column with "-".

        -
        • -
      • -

        If your external interface is ppp0 or ippp0 -or if you have a static IP address, you can remove "dhcp" from the option -list.

        -
        • +
      • +

        If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

        +
        • +
      • +

        If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the option + list.

        +
        • +
      - +

      IP Addresses

      - -

      Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic -Host Configuration Protocol (DHCP) or as part of establishing your connection - when you dial in (standard modem) or establish your PPP connection. In rare - cases, your ISP may assign you a static IP address; that means that -you configure your firewall's external interface to use that address permanently. -Regardless of how the address is assigned, it will be shared by all of -your systems when you access the Internet. You will have to assign your -own addresses for your internal network (the local and DMZ Interfaces on -your firewall plus your other computers). RFC 1918 reserves several Private -IP address ranges for this purpose:

      - -
      + +

      Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you a single + Public IP address. This address may be assigned via the Dynamic + Host Configuration Protocol (DHCP) or as part of establishing your connection + when you dial in (standard modem) or establish your PPP connection. In +rare cases, your ISP may assign you a static IP address; that means +that you configure your firewall's external interface to use that address +permanently. Regardless of how the address is assigned, it will be +shared by all of your systems when you access the Internet. You will have +to assign your own addresses for your internal network (the local and DMZ +Interfaces on your firewall plus your other computers). RFC 1918 reserves +several Private IP address ranges for this purpose:

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

      -    Before starting Shorewall, you should look at the IP address of your -external interface and if it is one of the above ranges, you should remove -the 'norfc1918' option from the external interface's entry in /etc/shorewall/interfaces.

      -
      - -
      -

      You will want to assign your local addresses from one - sub-network or subnet and your DMZ addresses from another subnet. -For our purposes, we can consider a subnet to consists of a range of addresses -x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet Mask of 255.255.255.0. -The address x.y.z.0 is reserved as the Subnet Address and x.y.z.255 -is reserved as the Subnet Broadcast Address. In Shorewall, -a subnet is described using Variable-Length - Subnet Mask (VLSM) notation with consists of the subnet address -followed by "/24". The "24" refers to the number of consecutive "1" +     Before starting Shorewall, you should look at the IP address of +your external interface and if it is one of the above ranges, you should +remove the 'norfc1918' option from the external interface's entry in + /etc/shorewall/interfaces.

      +
      + +
      +

      You will want to assign your local addresses from one + sub-network or subnet and your DMZ addresses from another +subnet. For our purposes, we can consider a subnet to consists of a range +of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet +Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet +Address and x.y.z.255 is reserved as the Subnet Broadcast Address. +In Shorewall, a subnet is described using Classless +InterDomain Routing (CIDR) notation with consists of the subnet address +followed by "/24". The "24" refers to the number of consecutive "1" bits from the left of the subnet mask.

      -
      - -
      +
      + +

      Example sub-network:

      -
      - -
      -
      +
      + +
      +
      - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
      Range:10.10.10.0 - 10.10.10.255
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.255
      VLSM Notation:10.10.10.0/24
      Range:10.10.10.0 - 10.10.10.255
      Subnet Address:10.10.10.0
      Broadcast Address:10.10.10.255
      CIDR Notation:10.10.10.0/24
      -
      -
      - -
      -

      It is conventional to assign the internal interface either -the first usable address in the subnet (10.10.10.1 in the above example) -or the last usable address (10.10.10.254).

      -
      - -
      -

      One of the purposes of subnetting is to allow all computers -in the subnet to understand which other computers can be communicated -with directly. To communicate with systems outside of the subnetwork, -systems send packets through a  gateway  (router).

      -
      - -
      + +
      + +
      +

      It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

      +
      + +
      +

      One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated +with directly. To communicate with systems outside of the subnetwork, systems +send packets through a  gateway  (router).

      +
      + +

      -    Your local computers (Local Computers 1 & 2) should be configured -with their default gateway set to the IP address of the firewall's -internal interface and your DMZ computers ( DMZ Computers 1 & 2) should -be configured with their default gateway set to the IP address of the +     Your local computers (Local Computers 1 & 2) should be configured + with their default gateway set to the IP address of the firewall's + internal interface and your DMZ computers ( DMZ Computers 1 & 2) should + be configured with their default gateway set to the IP address of the firewall's DMZ interface.  

      -
      - -

      The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning more -about IP addressing and routing, I highly recommend "IP Fundamentals: -What Everyone Needs to Know about Addressing & Routing", Thomas +

      + +

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

      - -

      The remainder of this quide will assume that you have configured - your network as shown here:

      - + +

      The remainder of this quide will assume that you have configured + your network as shown here:

      +

      -

      - -

      The default gateway for the DMZ computers would be 10.10.10.254 - and the default gateway for the Local computers would be 10.10.10.254.

      - +

      + +

      The default gateway for the DMZ computers would be 10.10.10.254 + and the default gateway for the Local computers would be 10.10.10.254.

      +

      IP Masquerading (SNAT)

      - -

      The addresses reserved by RFC 1918 are sometimes referred -to as non-routable because the Internet backbone routers don't forward -packets which have an RFC-1918 destination address. When one of your local -systems (let's assume local computer 1) sends a connection request to an -internet host, the firewall must perform Network Address Translation -(NAT). The firewall rewrites the source address in the packet to be -the address of the firewall's external interface; in other words, the firewall -makes it look as if the firewall itself is initiating the connection.  This -is necessary so that the destination host will be able to route return packets -back to the firewall (remember that packets whose destination address is -reserved by RFC 1918 can't be routed accross the internet). When the firewall -receives a return packet, it rewrites the destination address back to 10.10.10.1 -and forwards the packet on to local computer 1.

      - -

      On Linux systems, the above process is often referred to -as IP Masquerading and you will also see the term Source Network -Address Translation (SNAT) used. Shorewall follows the convention used -with Netfilter:

      - + +

      The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't forward + packets which have an RFC-1918 destination address. When one of your local + systems (let's assume local computer 1) sends a connection request to an + internet host, the firewall must perform Network Address Translation +(NAT). The firewall rewrites the source address in the packet to be the +address of the firewall's external interface; in other words, the firewall +makes it look as if the firewall itself is initiating the connection.  This +is necessary so that the destination host will be able to route return packets + back to the firewall (remember that packets whose destination address is + reserved by RFC 1918 can't be routed accross the internet). When the firewall + receives a return packet, it rewrites the destination address back to 10.10.10.1 + and forwards the packet on to local computer 1.

      + +

      On Linux systems, the above process is often referred to as + IP Masquerading and you will also see the term Source Network Address + Translation (SNAT) used. Shorewall follows the convention used with + Netfilter:

      +
        -
      • -

        Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

        -
        • -
      • -

        SNAT refers to the case when you explicitly specify -the source address that you want outbound packets from your local network -to use.

        -
        • +
      • +

        Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

        +
        • +
      • +

        SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local network + to use.

        +
        • +
      - -

      In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file.

      - + +

      In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file.

      +

      -    If your external firewall interface is eth0, your local interface -eth1 and your DMZ interface is eth2 then you do not need to -modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq -and change it to match your configuration.

      - +     If your external firewall interface is eth0, your local interface + eth1 and your DMZ interface is eth2 then you do not need to + modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq + and change it to match your configuration.

      +

      -    If your external IP is static, you can enter it in the third column -in the /etc/shorewall/masq entry if you like although your firewall will -work fine if you leave that column empty. Entering your static IP in column -3 makes processing outgoing packets a little more efficient.

      - +     If your external IP is static, you can enter it in the third column + in the /etc/shorewall/masq entry if you like although your firewall will + work fine if you leave that column empty. Entering your static IP in column + 3 makes processing outgoing packets a little more efficient.

      +

      Port Forwarding (DNAT)

      - -

      One of your goals will be to run one or more servers on your -DMZ computers. Because these computers have RFC-1918 addresses, it is not - possible for clients on the internet to connect directly to them. It is -rather necessary for those clients to address their connection requests -to your firewall who rewrites the destination address to the address of -your server and forwards the packet to that server. When your server responds, -the firewall automatically performs SNAT to rewrite the source address in + +

      One of your goals will be to run one or more servers on your + DMZ computers. Because these computers have RFC-1918 addresses, it is not + possible for clients on the internet to connect directly to them. It is +rather necessary for those clients to address their connection requests to +your firewall who rewrites the destination address to the address of your +server and forwards the packet to that server. When your server responds, +the firewall automatically performs SNAT to rewrite the source address in the response.

      - -

      The above process is called Port Forwarding or -Destination Network Address Translation (DNAT). You configure port forwarding -using DNAT rules in the /etc/shorewall/rules file.

      - -

      The general form of a simple port forwarding rule in /etc/shorewall/rules -is:

      - -
      + +

      The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

      + +

      The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:<server local ip address> [:<server port>]<protocol><port>  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:<server local ip address> [:<server +port>]<protocol><port>  
      -
      - -

      If you don't specify the <server port>, it is assumed to -be the same as <port>.

      - -

      Example - you run a Web Server on DMZ 2 and you want to forward incoming - TCP port 80 to that system:

      - -
      +
      + +

      If you don't specify the <server port>, it is assumed to be +the same as <port>.

      + +

      Example - you run a Web Server on DMZ 2 and you want to forward incoming + TCP port 80 to that system:

      + +
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
      ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2tcp80# Forward port 80from the internet
      ACCEPTlocdmz:10.10.11.2tcp80#Allow connections from the local network
      -
      - +
      +

      A couple of important points to keep in mind:

      - +
        -
      • When you are connecting to your server from your local systems, you -must use the server's internal IP address (10.10.11.2).
        • -
      • Many ISPs block incoming connection requests to port 80. If you have - problems connecting to your web server, try the following rule and try - connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your -external IP).
        • - +
      • When you are connecting to your server from your local systems, +you must use the server's internal IP address (10.10.11.2).
        • +
      • Many ISPs block incoming connection requests to port 80. If you +have problems connecting to your web server, try the following rule and +try connecting to port 5000 (e.g., connect to http://w.x.y.z:5000 where w.x.y.z is your + external IP).
        • +
      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp5000  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp5000  
      -
      - -

      If you want to be able to access your server from the local network using -your external address, then if you have a static external IP you can replace -the loc->dmz rule above with:

      - -
      +
      + +

      If you want to be able to access your server from the local network using + your external address, then if you have a static external IP you can replace + the loc->dmz rule above with:

      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp80-<external IP>
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp80-<external IP>
      -
      - -

      If you have a dynamic ip then you must ensure that your external interface -is up before starting Shorewall and you must take steps as follows (assume -that your external interface is eth0):

      - +
      + +

      If you have a dynamic ip then you must ensure that your external interface + is up before starting Shorewall and you must take steps as follows (assume + that your external interface is eth0):

      +
        -
      1. Include the following in /etc/shorewall/params:
        -
        - ETH0_IP=`find_interface_address eth0`
        -  
        2. -
      2. Make your loc->dmz rule:
        3. - +
      3. Include the following in /etc/shorewall/params:
        +
        + ETH0_IP=`find_interface_address eth0`
        +  
        4. +
      4. Make your loc->dmz rule:
        5. +
      - -
      + +
      - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp80-$ETH0_IP
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      DNATnetdmz:10.10.11.2:80tcp80-$ETH0_IP
      -
      - -

      If you want to access your server from the DMZ using your external IP - address, see FAQ 2a.

      - +
      + +

      If you want to access your server from the DMZ using your external IP +address, see FAQ 2a.

      +

      -    At this point, add the DNAT and ACCEPT rules for your servers.

      - +     At this point, add the DNAT and ACCEPT rules for your servers.

      +

      Domain Name Server (DNS)

      - -

      Normally, when you connect to your ISP, as part of getting -an IP address your firewall's Domain Name Service (DNS) resolver -will be automatically configured (e.g., the /etc/resolv.conf file will be -written). Alternatively, your ISP may have given you the IP address of a -pair of DNS name servers for you to manually configure as your primary -and secondary name servers. It is your responsibility to configure + +

      Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver +will be automatically configured (e.g., the /etc/resolv.conf file will be +written). Alternatively, your ISP may have given you the IP address of a +pair of DNS name servers for you to manually configure as your primary +and secondary name servers. It is your responsibility to configure the resolver in your internal systems. You can take one of two approaches:

      - +
        -
      • -

        You can configure your internal systems to use your ISP's -name servers. If you ISP gave you the addresses of their servers or if -those addresses are available on their web site, you can configure your -internal systems to use those addresses. If that information isn't available, -look in /etc/resolv.conf on your firewall system -- the name servers are -given in "nameserver" records in that file.

        -
        • -
      • +
      • +

        You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers or if + those addresses are available on their web site, you can configure your + internal systems to use those addresses. If that information isn't available, + look in /etc/resolv.conf on your firewall system -- the name servers are + given in "nameserver" records in that file.

        +
        • +

      • -    You can configure a Caching Name Server on your firewall or -in your DMZ. Red Hat has an RPM for a caching name server (which also - requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. -If you take this approach, you configure your internal systems to use -the caching name server as their primary (and only) name server. You use -the internal IP address of the firewall (10.10.10.254 in the example above) -for the name server address if you choose to run the name server on your -firewall. To allow your local systems to talk to your caching name server, -you must open port 53 (both UDP and TCP) from the local network to the +     You can configure a Caching Name Server on your firewall +or in your DMZ. Red Hat has an RPM for a caching name server (which +also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp. +If you take this approach, you configure your internal systems to use the +caching name server as their primary (and only) name server. You use the +internal IP address of the firewall (10.10.10.254 in the example above) + for the name server address if you choose to run the name server on your + firewall. To allow your local systems to talk to your caching name server, + you must open port 53 (both UDP and TCP) from the local network to the server; you do that by adding the rules in /etc/shorewall/rules.

        -
        • + +
      - -
      -

      If you run the name server on the firewall: + +

      +

      If you run the name server on the firewall: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp53  
      ACCEPTlocfwudp53  
      ACCEPTdmzfwtcp53  
      ACCEPTdmzfwudp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocfwtcp53  
      ACCEPTlocfwudp53  
      ACCEPTdmzfwtcp53  
      ACCEPTdmzfwudp53  
      -

      -
      - -
      -
      +

      +
      + +
      +

      Run name server on DMZ computer 1

      - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocdmz:10.10.11.1tcp53  
      ACCEPTlocdmz:10.10.11.1udp53  
      ACCEPTfwdmz:10.10.10.1tcp53  
      ACCEPTfwdmz:10.10.10.1udp53  
      ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
      ACCEPTlocdmz:10.10.11.1tcp53  
      ACCEPTlocdmz:10.10.11.1udp53  
      ACCEPTfwdmz:10.10.10.1tcp53  
      ACCEPTfwdmz:10.10.10.1udp53  
      -
      -
      - -
      +
      +
+ +

Other Connections

-
- -
+
+ +

The three-interface sample includes the following rules:

-
- -
-
+
+ +
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTfwnetudp53  
ACCEPTfwnettcp53  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTfwnetudp53  
ACCEPTfwnettcp53  
-
-
- -
-

Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing -all connections from the firewall to the internet.

-
- -
+ +
+ +
+

Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

+
+ +

The sample also includes:

-
- -
-
+
+ +
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp22  
ACCEPTlocdmztcp22  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp22  
ACCEPTlocdmztcp22  
-
-
- -
-

That rule allows you to run an SSH server on your firewall -and in each of your DMZ systems and to connect to those servers from -your local systems.

-
- -
-

If you wish to enable other connections between your systems, -the general format is:

-
- -
-
+
+
+ +
+

That rule allows you to run an SSH server on your firewall + and in each of your DMZ systems and to connect to those servers from + your local systems.

+
+ +
+

If you wish to enable other connections between your systems, + the general format is:

+
+ +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPT<source zone><destination zone><protocol><port>  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPT<source zone><destination zone><protocol><port>  
-
-
- -
-

Example - You want to run a publicly-available DNS server -on your firewall system:

-
- -
-
+
+
+ +
+

Example - You want to run a publicly-available DNS server + on your firewall system:

+
+ +
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
ACCEPTnetfwtcp53#Allow DNS accessfrom the internet
-
-
- -
-

Those two rules would of course be in addition to the rules - listed above under "If you run the name server on your firewall".

-
- -
-

If you don't know what port and protocol a particular -application uses, look here.

-
- -
-

Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want -shell access to your firewall from the internet, use SSH:

-
- -
-
+
+
+ +
+

Those two rules would of course be in addition to the rules + listed above under "If you run the name server on your firewall".

+
+ +
+

If you don't know what port and protocol a particular application +uses, look here.

+
+ +
+

Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

+
+ +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
-
-
- -
+ +
+ +

-    Now modify /etc/shorewall/rules to add or remove other connections -as required.

-
- -
+     Now modify /etc/shorewall/rules to add or remove other connections + as required.

+
+ +

Starting and Stopping Your Firewall

-
+
+ +
+

Arrow +     The installation procedure configures +your system to start Shorewall at system boot  but beginning with Shorewall +version 1.3.9 startup is disabled so that your system won't try to start +Shorewall before configuration is complete. Once you have completed configuration +of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
+

-
-

The installation procedure configures -your system to start Shorewall at system boot.

-
- -
-

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

-
- -
+

IMPORTANT: Users of the .deb package must edit /etc/default/shorewall +and set 'startup=1'.
+

+
+ +
+

The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, routing + is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

+
+ +

-    The three-interface sample assumes that you want to enable routing -to/from eth1 (your local network) and eth2 (DMZ) when Shorewall -is stopped. If these two interfaces don't connect to your local network -and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped - accordingly.

-
- -
-

WARNING: If you are connected to your firewall from -the internet, do not issue a "shorewall stop" command unless you have +     The three-interface sample assumes that you want to enable routing + to/from eth1 (your local network) and eth2 (DMZ) when Shorewall + is stopped. If these two interfaces don't connect to your local network + and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped + accordingly.

+
+ +
+

WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create -an alternate configuration -and test it using the "shorewall + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

-
- -

Last updated 9/16/2002 - + +

Last updated 9/26/2002 - Tom Eastep

- -

Copyright 2002 Thomas -M. Eastep

+ +

Copyright 2002 Thomas + M. Eastep

+
+

+
diff --git a/STABLE/documentation/two-interface.htm b/STABLE/documentation/two-interface.htm index 829a2f6cc..c3ede11b8 100644 --- a/STABLE/documentation/two-interface.htm +++ b/STABLE/documentation/two-interface.htm @@ -1,898 +1,919 @@ - + - + - + - + Two-Interface Firewall - + - + - - - + + - - - + + + +
+

Basic Two-Interface Firewall

-
- -

Setting up a Linux system as a firewall for a small network -is a fairly straight-forward task if you understand the basics and follow -the documentation.

- -

This guide doesn't attempt to acquaint you with all of the features of - Shorewall. It rather focuses on what is required to configure Shorewall + +

Setting up a Linux system as a firewall for a small network + is a fairly straight-forward task if you understand the basics and follow + the documentation.

+ +

This guide doesn't attempt to acquaint you with all of the features of + Shorewall. It rather focuses on what is required to configure Shorewall in its most common configuration:

- +
    -
  • Linux system used as a firewall/router for a small local network.
    • -
  • Single public IP address.
    • -
  • Internet connection through cable modem, DSL, ISDN, Frame Relay, dial-up - ...
    • - +
  • Linux system used as a firewall/router for a small local network.
    • +
  • Single public IP address.
    • +
  • Internet connection through cable modem, DSL, ISDN, Frame Relay, + dial-up ...
    • +
- +

Here is a schematic of a typical installation.

- +

-

- -

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

- +

+ +

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

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

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

- + +

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. Similarly, if you copy a configuration -file from your Windows hard drive to a floppy disk, you must run dos2unix -against the copy before using it with Shorewall.

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

+ - +

Shorewall Concepts

- -

The configuration files for Shorewall are contained in the directory /etc/shorewall --- for simple setups, you will only need to deal with a few of these as -described in this guide. After you have installed -Shorewall, download the two-interface sample, -un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall - (these files will replace files with the same name).

- -

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

- -

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

- + +

The configuration files for Shorewall are contained in the directory +/etc/shorewall -- for simple setups, you will only need to deal with a few +of these as described in this guide. After you have installed Shorewall, download the two-interface sample, + un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall + (these files will replace files with the same name).

+ +

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

+ +

Shorewall views the network where it is running as being composed of a + set of zones. In the two-interface sample configuration, the following + zone names are used:

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

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

- -

Shorewall also recognizes the firewall system as its own zone - by default, - the firewall itself is known as fw.

- -

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

- + +

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

+ +

Shorewall also recognizes the firewall system as its own zone - by default, + the firewall itself is known as fw.

+ +

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

+ - -

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

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

- -

The /etc/shorewall/policy file included with the two-interface sample -has the following policies:

- -
+ +

The /etc/shorewall/policy file included with the two-interface sample has +the following policies:

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

In the two-interface sample, the line below is included but commented -out. If you want your firewall system to have full access to servers on +

+ +
+

In the two-interface sample, the line below is included but commented + out. If you want your firewall system to have full access to servers on the internet, uncomment that line.

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

The above policy will:

- +
    -
  1. allow all connection requests from your local network to the internet
    2. -
  2. drop (ignore) all connection requests from the internet to your firewall - or local network
    3. -
  3. optionally accept all connection requests from the firewall to the - internet (if you uncomment the additional policy)
    4. -
  4. reject all other connection requests.
    5. - +
  5. allow all connection requests from your local network to the internet
    6. +
  6. drop (ignore) all connection requests from the internet to your +firewall or local network
    7. +
  7. optionally accept all connection requests from the firewall to +the internet (if you uncomment the additional policy)
    8. +
  8. reject all other connection requests.
    9. +
- +

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

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

+

Network Interfaces

- +

-

- -

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

- +

+ +

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

+

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

- -

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

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

+ +

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

+

-Do not connect the internal and external interface to the same hub -or switch (even for testing). It won't work the way that you think that it -will and you will end up confused and believing that Shorewall doesn't work -at all.

- + Do not connect the internal and external interface to the same + hub or switch (even for testing). It won't work the way that you think that + it will and you will end up confused and believing that Shorewall doesn't + work at all.

+

-    The Shorewall two-interface sample configuration assumes that the external -interface is eth0 and the internal interface is eth1. If your -configuration is different, you will have to modify the sample /etc/shorewall/interfaces file accordingly. -While you are there, you may wish to review the list of options that are -specified for the interfaces. Some hints:

- +     The Shorewall two-interface sample configuration assumes that the +external interface is eth0 and the internal interface is eth1. + If your configuration is different, you will have to modify the sample +/etc/shorewall/interfaces file +accordingly. While you are there, you may wish to review the list of options +that are specified for the interfaces. Some hints:

+
    -
  • -

    If your external interface is ppp0 or ippp0, -you can replace the "detect" in the second column with "-".

    -
    • -
  • -

    If your external interface is ppp0 or ippp0 -or if you have a static IP address, you can remove "dhcp" from the option -list.

    -
    • +
  • +

    If your external interface is ppp0 or ippp0, + you can replace the "detect" in the second column with "-".

    +
    • +
  • +

    If your external interface is ppp0 or ippp0 + or if you have a static IP address, you can remove "dhcp" from the option + list.

    +
    • +
- +

IP Addresses

- -

Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic -Host Configuration Protocol (DHCP) or as part of establishing your connection - when you dial in (standard modem) or establish your PPP connection. In rare - cases, your ISP may assign you a static IP address; that means that -you configure your firewall's external interface to use that address permanently. -However your external address is assigned, it will be shared by all of -your systems when you access the Internet. You will have to assign your -own addresses in your internal network (the Internal Interface on your firewall -plus your other computers). RFC 1918 reserves several Private IP -address ranges for this purpose:

- -
+ +

Before going further, we should say a few words about Internet + Protocol (IP) addresses. Normally, your ISP will assign you a single + Public IP address. This address may be assigned via the Dynamic + Host Configuration Protocol (DHCP) or as part of establishing your connection + when you dial in (standard modem) or establish your PPP connection. In +rare cases, your ISP may assign you a static IP address; that means +that you configure your firewall's external interface to use that address +permanently. However your external address is assigned, it will be +shared by all of your systems when you access the Internet. You will have +to assign your own addresses in your internal network (the Internal Interface +on your firewall plus your other computers). RFC 1918 reserves several +Private IP address ranges for this purpose:

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

-    Before starting Shorewall, you should look at the IP address of your -external interface and if it is one of the above ranges, you should remove -the 'norfc1918' option from the external interface's entry in /etc/shorewall/interfaces.

-
- -
-

You will want to assign your addresses from the same - sub-network (subnet).  For our purposes, we can consider a subnet - to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet -will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 is -reserved as the Subnet Address and x.y.z.255 is reserved as the -Subnet Broadcast Address. In Shorewall, a subnet is described -using Variable-Length Subnet Mask (VLSM) -notation with consists of the subnet address followed by "/24". The -"24" refers to the number of consecutive leading "1" bits from the left -of the subnet mask.

-
- -
+     Before starting Shorewall, you should look at the IP address of +your external interface and if it is one of the above ranges, you should +remove the 'norfc1918' option from the external interface's entry in + /etc/shorewall/interfaces.

+
+ +
+

You will want to assign your addresses from the same + sub-network (subnet).  For our purposes, we can consider a subnet + to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet + will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 is + reserved as the Subnet Address and x.y.z.255 is reserved as the + Subnet Broadcast Address. In Shorewall, a subnet is described + using Classless InterDomain Routing (CIDR) + notation with consists of the subnet address followed by "/24". The + "24" refers to the number of consecutive leading "1" bits from the left + of the subnet mask.

+
+ +

Example sub-network:

-
- -
-
+
+ +
+
- - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
Range:10.10.10.0 - 10.10.10.255
Subnet Address:10.10.10.0
Broadcast Address:10.10.10.255
VLSM Notation:10.10.10.0/24
Range:10.10.10.0 - 10.10.10.255
Subnet Address:10.10.10.0
Broadcast Address:10.10.10.255
CIDR Notation:10.10.10.0/24
-
-
- -
-

It is conventional to assign the internal interface either -the first usable address in the subnet (10.10.10.1 in the above example) -or the last usable address (10.10.10.254).

-
- -
-

One of the purposes of subnetting is to allow all computers -in the subnet to understand which other computers can be communicated -with directly. To communicate with systems outside of the subnetwork, -systems send packets through a  gateway  (router).

-
- -
+ +
+ +
+

It is conventional to assign the internal interface either + the first usable address in the subnet (10.10.10.1 in the above example) + or the last usable address (10.10.10.254).

+
+ +
+

One of the purposes of subnetting is to allow all computers + in the subnet to understand which other computers can be communicated +with directly. To communicate with systems outside of the subnetwork, systems +send packets through a  gateway  (router).

+
+ +

-    Your local computers (computer 1 and computer 2 in the above diagram) -should be configured with their default gateway to be the IP address -of the firewall's internal interface.     

-
- -

The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning more -about IP addressing and routing, I highly recommend "IP Fundamentals: -What Everyone Needs to Know about Addressing & Routing", Thomas +     Your local computers (computer 1 and computer 2 in the above diagram) + should be configured with their default gateway to be the IP address + of the firewall's internal interface.     

+
+ +

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

- -

The remainder of this quide will assume that you have configured - your network as shown here:

- + +

The remainder of this quide will assume that you have configured + your network as shown here:

+

-

- +

+

The default gateway for computer's 1 & 2 would be 10.10.10.254.

- +

IP Masquerading (SNAT)

- -

The addresses reserved by RFC 1918 are sometimes referred -to as non-routable because the Internet backbone routers don't forward -packets which have an RFC-1918 destination address. When one of your local -systems (let's assume computer 1) sends a connection request to an internet -host, the firewall must perform Network Address Translation (NAT). -The firewall rewrites the source address in the packet to be the address -of the firewall's external interface; in other words, the firewall makes -it look as if the firewall itself is initiating the connection.  This is -necessary so that the destination host will be able to route return packets -back to the firewall (remember that packets whose destination address is -reserved by RFC 1918 can't be routed across the internet so the remote host -can't address its response to computer 1). When the firewall receives a + +

The addresses reserved by RFC 1918 are sometimes referred + to as non-routable because the Internet backbone routers don't forward + packets which have an RFC-1918 destination address. When one of your local + systems (let's assume computer 1) sends a connection request to an internet + host, the firewall must perform Network Address Translation (NAT). + The firewall rewrites the source address in the packet to be the address + of the firewall's external interface; in other words, the firewall makes + it look as if the firewall itself is initiating the connection.  This is + necessary so that the destination host will be able to route return packets + back to the firewall (remember that packets whose destination address is + reserved by RFC 1918 can't be routed across the internet so the remote host + can't address its response to computer 1). When the firewall receives a return packet, it rewrites the destination address back to 10.10.10.1 and forwards the packet on to computer 1.

- -

On Linux systems, the above process is often referred to -as IP Masquerading but you will also see the term Source Network -Address Translation (SNAT) used. Shorewall follows the convention used -with Netfilter:

- + +

On Linux systems, the above process is often referred to as + IP Masquerading but you will also see the term Source Network Address + Translation (SNAT) used. Shorewall follows the convention used with + Netfilter:

+
    -
  • -

    Masquerade describes the case where you let your - firewall system automatically detect the external interface address. -

    -
    • -
  • -

    SNAT refers to the case when you explicitly specify -the source address that you want outbound packets from your local network -to use.

    -
    • +
  • +

    Masquerade describes the case where you let your + firewall system automatically detect the external interface address. +

    +
    • +
  • +

    SNAT refers to the case when you explicitly specify + the source address that you want outbound packets from your local network + to use.

    +
    • +
- -

In Shorewall, both Masquerading and SNAT are configured with - entries in the /etc/shorewall/masq file. You will normally use Masquerading -if your external IP is dynamic and SNAT if the IP is static.

- + +

In Shorewall, both Masquerading and SNAT are configured with + entries in the /etc/shorewall/masq file. You will normally use Masquerading + if your external IP is dynamic and SNAT if the IP is static.

+

-    If your external firewall interface is eth0, you do not need -to modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq -and change the first column to the name of your external interface and the -second column to the name of your internal interface.

- +     If your external firewall interface is eth0, you do not need + to modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq + and change the first column to the name of your external interface and the + second column to the name of your internal interface.

+

-    If your external IP is static, you can enter it in the third column -in the /etc/shorewall/masq entry if you like although your firewall will -work fine if you leave that column empty. Entering your static IP in column -3 makes processing outgoing packets a little more efficient.

- +     If your external IP is static, you can enter it in the third column + in the /etc/shorewall/masq entry if you like although your firewall will + work fine if you leave that column empty. Entering your static IP in column + 3 makes processing outgoing packets a little more efficient.

+

Port Forwarding (DNAT)

- -

One of your goals may be to run one or more servers on your - local computers. Because these computers have RFC-1918 addresses, it is -not possible for clients on the internet to connect directly to them. It -is rather necessary for those clients to address their connection requests -to the firewall who rewrites the destination address to the address of your -server and forwards the packet to that server. When your server responds, -the firewall automatically performs SNAT to rewrite the source address in -the response.

- -

The above process is called Port Forwarding or -Destination Network Address Translation (DNAT). You configure port forwarding -using DNAT rules in the /etc/shorewall/rules file.

- -

The general form of a simple port forwarding rule in /etc/shorewall/rules -is:

- -
+ +

One of your goals may be to run one or more servers on your + local computers. Because these computers have RFC-1918 addresses, it is +not possible for clients on the internet to connect directly to them. It +is rather necessary for those clients to address their connection requests +to the firewall who rewrites the destination address to the address of your + server and forwards the packet to that server. When your server responds, + the firewall automatically performs SNAT to rewrite the source address in + the response.

+ +

The above process is called Port Forwarding or + Destination Network Address Translation (DNAT). You configure port + forwarding using DNAT rules in the /etc/shorewall/rules file.

+ +

The general form of a simple port forwarding rule in /etc/shorewall/rules + is:

+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:<server local ip address> [:<server port>]<protocol><port>  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:<server local ip address> [:<server +port>]<protocol><port>  
-
- -

Example - you run a Web Server on computer 2 and you want to forward incoming - TCP port 80 to that system:

- -
+
+ +

Example - you run a Web Server on computer 2 and you want to forward incoming + TCP port 80 to that system:

+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.2tcp80  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.2tcp80  
-
- +
+

A couple of important points to keep in mind:

- +
    -
  • You must test the above rule from a client outside of your local network - (i.e., don't test from a browser running on computers 1 or 2 or on the - firewall). If you want to be able to access your web server using the -IP address of your external interface, see Shorewall -FAQ #2.
    • -
  • Many ISPs block incoming connection requests to port 80. If you have - problems connecting to your web server, try the following rule and try - connecting to port 5000.
    • - +
  • You must test the above rule from a client outside of your local + network (i.e., don't test from a browser running on computers 1 or 2 +or on the firewall). If you want to be able to access your web server +using the IP address of your external interface, see Shorewall FAQ #2.
    • +
  • Many ISPs block incoming connection requests to port 80. If you +have problems connecting to your web server, try the following rule and +try connecting to port 5000.
    • +
- -
+ +
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.2:80tcp5000  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
DNATnetloc:10.10.10.2:80tcp5000  
-
- +
+

-    At this point, modify /etc/shorewall/rules to add any DNAT rules that -you require.

- +     At this point, modify /etc/shorewall/rules to add any DNAT rules +that you require.

+

Domain Name Server (DNS)

- -

Normally, when you connect to your ISP, as part of getting -an IP address your firewall's Domain Name Service (DNS) resolver -will be automatically configured (e.g., the /etc/resolv.conf file will be -written). Alternatively, your ISP may have given you the IP address of a -pair of DNS name servers for you to manually configure as your primary -and secondary name servers. Regardless of how DNS gets configured on your -firewall, it is your responsibility to configure the resolver in your + +

Normally, when you connect to your ISP, as part of getting + an IP address your firewall's Domain Name Service (DNS) resolver +will be automatically configured (e.g., the /etc/resolv.conf file will be +written). Alternatively, your ISP may have given you the IP address of a +pair of DNS name servers for you to manually configure as your primary +and secondary name servers. Regardless of how DNS gets configured on your +firewall, it is your responsibility to configure the resolver in your internal systems. You can take one of two approaches:

- +
    -
  • -

    You can configure your internal systems to use your ISP's -name servers. If you ISP gave you the addresses of their servers or if -those addresses are available on their web site, you can configure your -internal systems to use those addresses. If that information isn't available, -look in /etc/resolv.conf on your firewall system -- the name servers are -given in "nameserver" records in that file.

    -
    • -
  • +
  • +

    You can configure your internal systems to use your ISP's + name servers. If you ISP gave you the addresses of their servers or if + those addresses are available on their web site, you can configure your + internal systems to use those addresses. If that information isn't available, + look in /etc/resolv.conf on your firewall system -- the name servers are + given in "nameserver" records in that file.

    +
    • +

  • -    You can configure a Caching Name Server on your firewall. - Red Hat has an RPM for a caching name server (the RPM also requires -the 'bind' RPM) and for Bering users, there is dnscache.lrp. If you take -this approach, you configure your internal systems to use the firewall - itself as their primary (and only) name server. You use the internal IP - address of the firewall (10.10.10.254 in the example above) for the name - server address. To allow your local systems to talk to your caching name - server, you must open port 53 (both UDP and TCP) from the local network -to the firewall; you do that by adding the following rules in /etc/shorewall/rules. -

    -
    • +     You can configure a Caching Name Server on your firewall. + Red Hat has an RPM for a caching name server (the RPM also requires + the 'bind' RPM) and for Bering users, there is dnscache.lrp. If you take + this approach, you configure your internal systems to use the firewall + itself as their primary (and only) name server. You use the internal IP + address of the firewall (10.10.10.254 in the example above) for the name + server address. To allow your local systems to talk to your caching name + server, you must open port 53 (both UDP and TCP) from the local network + to the firewall; you do that by adding the following rules in /etc/shorewall/rules. +

    + +
- -
+ +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp53  
ACCEPTlocfwudp53  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp53  
ACCEPTlocfwudp53  
-
- -
+
+ +

Other Connections

-
- -
+
+ +

The two-interface sample includes the following rules:

-
- -
-
+
+ +
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTfwnettcp53  
ACCEPTfwnetudp53  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTfwnettcp53  
ACCEPTfwnetudp53  
-
-
- -
-

Those rules allow DNS access from your firewall and may be - removed if you commented out the line in /etc/shorewall/policy allowing -all connections from the firewall to the internet.

-
- -
+ +
+ +
+

Those rules allow DNS access from your firewall and may be + removed if you commented out the line in /etc/shorewall/policy allowing + all connections from the firewall to the internet.

+
+ +

The sample also includes:

-
- -
-
+
+ +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp22  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTlocfwtcp22  
-
-
- -
-

That rule allows you to run an SSH server on your firewall -and connect to that server from your local systems.

-
- -
-

If you wish to enable other connections between your firewall - and other systems, the general format is:

-
- -
-
+
+
+ +
+

That rule allows you to run an SSH server on your firewall + and connect to that server from your local systems.

+
+ +
+

If you wish to enable other connections between your firewall + and other systems, the general format is:

+
+ +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPT<source zone><destination zone><protocol><port>  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPT<source zone><destination zone><protocol><port>  
-
-
- -
-

Example - You want to run a Web Server on your firewall - system:

-
- -
-
+
+
+ +
+

Example - You want to run a Web Server on your firewall + system:

+
+ +
+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp80#Allow web accessfrom the internet
ACCEPTlocfwtcp80#Allow web accessfrom the local network
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp80#Allow web accessfrom the internet
ACCEPTlocfwtcp80#Allow web accessfrom the local network
-
-
- -
-

Those two rules would of course be in addition to the rules - listed above under "You can configure a Caching Name Server on your firewall"

-
- -
-

If you don't know what port and protocol a particular -application uses, look here.

-
- -
-

Important: I don't recommend enabling telnet to/from - the internet because it uses clear text (even for login!). If you want -shell access to your firewall from the internet, use SSH:

-
- -
-
+
+
+ +
+

Those two rules would of course be in addition to the rules + listed above under "You can configure a Caching Name Server on your firewall"

+
+ +
+

If you don't know what port and protocol a particular application +uses, look here.

+
+ +
+

Important: I don't recommend enabling telnet to/from + the internet because it uses clear text (even for login!). If you want + shell access to your firewall from the internet, use SSH:

+
+ +
+
- - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
ACCEPTnetfwtcp22  
-
-
- -
+ +
+ +

-    Now edit your /etc/shorewall/rules file to add or delete other connections -as required.

-
- -
+     Now edit your /etc/shorewall/rules file to add or delete other +connections as required.

+
+ +

Starting and Stopping Your Firewall

-
+
+ +
+

Arrow +     The installation procedure configures + your system to start Shorewall at system boot  but beginning with Shorewall +version 1.3.9 startup is disabled so that your system won't try to start +Shorewall before configuration is complete. Once you have completed configuration +of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
+

-
-

The installation procedure configures -your system to start Shorewall at system boot.

-
- -
-

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

-
- -
+

IMPORTANT: Users of the .deb package must edit /etc/default/shorewall +and set 'startup=1'.
+

+
+ +
+

The firewall is started using the "shorewall start" command + and stopped using "shorewall stop". When the firewall is stopped, routing + is enabled on those hosts that have an entry in /etc/shorewall/routestopped. A + running firewall may be restarted using the "shorewall restart" command. + If you want to totally remove any trace of Shorewall from your Netfilter + configuration, use "shorewall clear".

+
+ +

-    The two-interface sample assumes that you want to enable routing to/from -eth1 (the local network) when Shorewall is stopped. If your local -network isn't connected to eth1 or if you wish to enable access -to/from other hosts, change /etc/shorewall/routestopped accordingly.

-
- -
-

WARNING: If you are connected to your firewall from -the internet, do not issue a "shorewall stop" command unless you have +     The two-interface sample assumes that you want to enable routing + to/from eth1 (the local network) when Shorewall is stopped. If + your local network isn't connected to eth1 or if you wish to enable + access to/from other hosts, change /etc/shorewall/routestopped accordingly.

+
+ +
+

WARNING: If you are connected to your firewall from + the internet, do not issue a "shorewall stop" command unless you have added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using "shorewall restart"; it is better to create -an alternate configuration -and test it using the "shorewall + href="Documentation.htm#Routestopped">/etc/shorewall/routestopped. + Also, I don't recommend using "shorewall restart"; it is better to create + an alternate configuration + and test it using the "shorewall try" command.

-
- -

Last updated 9/16/2002 - + +

Last updated 9/26/2002 - Tom Eastep

- -

Copyright 2002 Thomas -M. Eastep

+ +

Copyright 2002 Thomas + M. Eastep

+
+

+
diff --git a/STABLE/documentation/upgrade_issues.htm b/STABLE/documentation/upgrade_issues.htm index 1e292ef03..d815e38dd 100644 --- a/STABLE/documentation/upgrade_issues.htm +++ b/STABLE/documentation/upgrade_issues.htm @@ -1,145 +1,172 @@ - - + + Upgrade Issues - + - + - - + - - - - - -
-

Upgrade Issues

-
- -

For upgrade instructions see the - Install/Upgrade page.

- -

Version >= 1.3.7

- -

Users specifying ALLOWRELATED=No in - /etc/shorewall.conf will need to include the - following rules in their /etc/shorewall/icmpdef - file (creating this file if necessary):

- - 
	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
-	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
-

Users having an /etc/shorewall/icmpdef file may remove the ". - /etc/shorewall/icmp.def" command from that file since the icmp.def file is now - empty.

-

Upgrading Bering to - Shorewall >= 1.3.3

- -

To properly upgrade with Shorewall version - 1.3.3 and later:

- -
    -
  1. Be sure you have a backup -- you will need - to transcribe any Shorewall configuration - changes that you have made to the new - configuration.
    2. -
  2. Replace the shorwall.lrp package provided on - the Bering floppy with the later one. If you did - not obtain the later version from Jacques's - site, see additional instructions below.
    3. -
  3. Edit the /var/lib/lrpkg/root.exclude.list - file and remove the /var/lib/shorewall entry if - present. Then do not forget to backup root.lrp !
    4. -
-

The .lrp that I release isn't set up for a two-interface firewall like - Jacques's. You need to follow the instructions for - setting up a two-interface firewall plus you also need to add the following - two Bering-specific rules to /etc/shorewall/rules:

-
- 
# Bering specific rules:
-# allow loc to fw udp/53 for dnscache to work
-# allow loc to fw tcp/80 for weblet to work
-#
-ACCEPT loc fw udp 53
-ACCEPT loc fw tcp 80
-
- -

Version >= 1.3.6

- -

If you have a pair of firewall systems configured for - failover, you will need to modify your firewall setup slightly under - Shorewall versions >= 1.3.6.

- -
    -
  1. - -

    Create the file /etc/shorewall/newnotsyn and in it add - the following rule
    -
    - run_iptables -A newnotsyn -j RETURN # So that the - connection tracking table can be rebuilt
    -                                    - # from non-SYN packets after takeover.
    - 

    2. -
  2. - -

    Create /etc/shorewall/common (if you don't already - have that file) and include the following:
    -
    - run_iptables -A common -p tcp --tcp-flags - ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
    -                                                                    - #tracking table.
    - . /etc/shorewall/common.def

    3. + + + + + + + + + +
    +

    Upgrade Issues

    +
    + +

    For upgrade instructions see the Install/Upgrade page.

    + +

    Version >= 1.3.9

    + The 'functions' file has moved to /usr/lib/shorewall/functions. If you have +an application that uses functions from that file, your application will need +to be changed to reflect this change of location.
    + +

    Version >= 1.3.8

    + +

    If you have a pair of firewall systems configured for failover + or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall + versions >= 1.3.8. Beginning with version 1.3.8, + you must set NEWNOTSYN=Yes in your + /etc/shorewall/shorewall.conf file.

    + +

    Version >= 1.3.7

    + +

    Users specifying ALLOWRELATED=No in /etc/shorewall.conf + will need to include the following rules in + their /etc/shorewall/icmpdef file (creating + this file if necessary):

    + +
    	run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
    	run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
    + +

    Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def" + command from that file since the icmp.def file is now empty.

    + +

    Upgrading Bering to + Shorewall >= 1.3.3

    + +

    To properly upgrade with Shorewall version + 1.3.3 and later:

    + +
      +
    1. Be sure you have a backup -- you +will need to transcribe any Shorewall configuration + changes that you have made to the new + configuration.
      2. +
    2. Replace the shorwall.lrp package +provided on the Bering floppy with the +later one. If you did not obtain the later +version from Jacques's site, see additional +instructions below.
      3. +
    3. Edit the /var/lib/lrpkg/root.exclude.list + file and remove the /var/lib/shorewall entry + if present. Then do not forget to backup + root.lrp !
      4. +
    - -

    Versions >= 1.3.5

    - -

    Some forms of pre-1.3.0 rules file syntax are no - longer supported.

    - -

    Example 1:

    - -
    - 
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    -
    - -

    Must be replaced with:

    - -
    - 
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    -
    -
    -

    Example 2:

    -
    - 
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    -
    -
    -

    Must be replaced with:

    -
    - 
    	REDIRECT	loc	3128	tcp	80
    -
    - -

    Version >= 1.3.2

    - -

    The functions and versions files together with the - 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. - If you have applications that access these files, those applications - should be modified accordingly.

    - -

    - Last updated 9/13/2002 - - Tom Eastep

    - -

    Copyright - © 2001, 2002 Thomas M. Eastep.

    - + +

    The .lrp that I release isn't set up for a two-interface firewall like + Jacques's. You need to follow the instructions + for setting up a two-interface firewall plus you also need to add the + following two Bering-specific rules to /etc/shorewall/rules:

    + +
    + 
    # Bering specific rules:
    # allow loc to fw udp/53 for dnscache to work
    # allow loc to fw tcp/80 for weblet to work
    #
    ACCEPT loc fw udp 53
    ACCEPT loc fw tcp 80
    +
    + +

    Version 1.3.6 and 1.3.7

    + +

    If you have a pair of firewall systems configured for + failover or if you have asymmetric routing, you will need to modify + your firewall setup slightly under Shorewall versions 1.3.6 and + 1.3.7

    + +
      +
    1. +

      Create the file /etc/shorewall/newnotsyn and in it add + the following rule
      +
      + run_iptables -A newnotsyn -j RETURN # +So that the connection tracking table can be rebuilt
      +                                     # from non-SYN packets +after takeover.
      +  

      +
      2. +
    2. +

      Create /etc/shorewall/common (if you don't already + have that file) and include the following:
      +
      + run_iptables -A common -p tcp --tcp-flags + ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
      +                                                                     + #tracking table.
      + . /etc/shorewall/common.def

      +
      3. + +
    + +

    Versions >= 1.3.5

    + +

    Some forms of pre-1.3.0 rules file syntax are no + longer supported.

    + +

    Example 1:

    + +
    +
    	ACCEPT    net    loc:192.168.1.12:22    tcp    11111    -    all
    +
    + +

    Must be replaced with:

    + +
    +
    	DNAT	net	loc:192.168.1.12:22	tcp	11111
    +
    + +
    +

    Example 2:

    +
    + +
    +
    	ACCEPT	loc	fw::3128	tcp	80	-	all
    +
    + +
    +

    Must be replaced with:

    +
    + +
    +
    	REDIRECT	loc	3128	tcp	80
    +
    + +

    Version >= 1.3.2

    + +

    The functions and versions files together with the + 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall. + If you have applications that access these files, those applications + should be modified accordingly.

    + +

    Last updated 9/30/2002 - + Tom Eastep

    + +

    Copyright + © 2001, 2002 Thomas M. Eastep.

    +
    +
    +
    +
    - \ No newline at end of file + diff --git a/STABLE/fallback.sh b/STABLE/fallback.sh index f76eb41a3..1a5aa1179 100755 --- a/STABLE/fallback.sh +++ b/STABLE/fallback.sh @@ -28,7 +28,7 @@ # shown below. Simply run this script to revert to your prior version of # Shoreline Firewall. -VERSION=1.3.8 +VERSION=1.3.9a usage() # $1 = exit status { @@ -57,7 +57,10 @@ fi echo "Backing Out Installation of Shorewall $VERSION" -if [ -L /var/lib/shorewall/firewall ]; then +if [ -L /usr/lib/shorewall/firewall ]; then + FIREWALL=`ls -l /usr/lib/shorewall/firewall | sed 's/^.*> //'` + restore_file $FIREWALL +elif [ -L /var/lib/shorewall/firewall ]; then FIREWALL=`ls -l /var/lib/shorewall/firewall | sed 's/^.*> //'` restore_file $FIREWALL fi @@ -69,6 +72,7 @@ restore_file /sbin/shorewall restore_file /etc/shorewall/shorewall.conf restore_file /etc/shorewall/functions +restore_file /usr/lib/shorewall/functions restore_file /var/lib/shorewall/functions restore_file /etc/shorewall/common.def @@ -109,8 +113,11 @@ restore_file /etc/shorewall/whitelist restore_file /etc/shorewall/rfc1918 -if [ -f /var/lib/shorewall/version-${VERSION}.bkout ]; then - restore_file /var/shorewall/version +if [ -f /usr/lib/shorewall/version-${VERSION}.bkout ]; then + restore_file /usr/lib/shorewall/version + oldversion="`cat /usr/lib/shorewall/version`" +elif [ -f /var/lib/shorewall/version-${VERSION}.bkout ]; then + restore_file /var/lib/shorewall/version oldversion="`cat /var/lib/shorewall/version`" else restore_file /etc/shorewall/version diff --git a/STABLE/firewall b/STABLE/firewall index 783dc0fa2..292677dfd 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -74,14 +74,14 @@ list_search() # $1 = element to search for , $2-$n = list # Function to count list elements # ############################################################################### list_count() { - local temp=`separate_list $1` + local temp="`separate_list $1`" echo $temp | wc -w } ############################################################################### # Mutual exclusion -- These functions are jackets for the mutual exclusion # -# routines in /var/lib/shorewall/functions. They invoke # +# routines in /usr/lib/shorewall/functions. They invoke # # the corresponding function in that file if the user did # # not specify "nolock" on the runline. # ############################################################################### @@ -592,7 +592,7 @@ validate_rule() { # Ensure that the passed comma-separated list has 15 or fewer elements # validate_list() { - local temp=`separate_list $1` + local temp="`separate_list $1`" [ `echo $temp | wc -w` -le 15 ] } @@ -609,10 +609,13 @@ validate_rule() { [ -n "$client" ] && case "$client" in -) ;; + *:*) + cli="-i ${client%:*} -s ${client#*:}" + ;; ~*) cli=`mac_match $client` ;; - [0-9]*|![0-9]*) + *.*.*) # # IP Address, address or subnet # @@ -632,7 +635,7 @@ validate_rule() { -) serv= ;; - [0-9]*|![0-9]*) + *.*.*) serv=$server ;; ~*) @@ -669,6 +672,7 @@ validate_rule() { state="-m state --state RELATED" ;; *) + state= [ -n "$port" ] && [ "x${port}" != "x-" ] && \ startup_error "Port number not allowed with protocol " \ "\"$proto\"; rule: \"$rule\"" @@ -775,7 +779,7 @@ validate_rule() { clientzone="$clients" clients= else - clientzone="${clients%:*}" + clientzone="${clients%%:*}" clients="${clients#*:}" [ -z "$clientzone" -o -z "$clients" ] && \ startup_error "Error: Empty source zone or qualifier: rule \"$rule\"" @@ -1141,10 +1145,10 @@ setup_tunnels() # $1 = name of tunnels file setup_one_ipsec() # $1 = gateway $2 = gateway zone { options="-m state --state NEW -j ACCEPT" - addrule $inchain -p 50 -s $1 $options - addrule $outchain -p 50 -d $1 $options - run_iptables -A $inchain -p 51 -s $1 $options - run_iptables -A $outchain -p 51 -d $1 $options + addrule $inchain -p 50 -s $1 -j ACCEPT + addrule $outchain -p 50 -d $1 -j ACCEPT + run_iptables -A $inchain -p 51 -s $1 -j ACCEPT + run_iptables -A $outchain -p 51 -d $1 -j ACCEPT run_iptables -A $inchain -p udp -s $1 --sport 500 --dport 500 $options run_iptables -A $outchain -p udp -d $1 --dport 500 --sport 500 $options @@ -1162,9 +1166,8 @@ setup_tunnels() # $1 = name of tunnels file setup_one_other() # $1 = TYPE, $2 = gateway, $3 = protocol { - options="-m state --state NEW -j ACCEPT" - addrule $inchain -p $3 -s $2 $options - addrule $outchain -p $3 -d $2 $options + addrule $inchain -p $3 -s $2 -j ACCEPT + addrule $outchain -p $3 -d $2 -j ACCEPT echo " $1 tunnel to $gateway defined." } @@ -1381,7 +1384,7 @@ process_tc_rule() if [ "x$source" != "x-" ]; then case $source in - [0-9]*) + *.*.*) r="-s $source " ;; ~*) @@ -1624,7 +1627,10 @@ add_a_rule() [ -n "$client" ] && case "$client" in -) ;; - [0-9]*|![0-9]*) + *:*) + cli="-i ${client%:*} -s ${client#*:}" + ;; + *.*.*) cli="-s $client" ;; ~*) @@ -1643,7 +1649,7 @@ add_a_rule() -) serv= ;; - [0-9]*|![0-9]*) + *.*.*) serv=$server ;; *) @@ -1698,6 +1704,7 @@ add_a_rule() state="-m state --state RELATED" ;; *) + state= [ -n "$port" ] && [ "x${port}" != "x-" ] && \ fatal_error "Port number not allowed with protocol " \ "\"$proto\"; rule: \"$rule\"" @@ -1820,7 +1827,7 @@ process_rule() { clientzone="$clients" clients= else - clientzone="${clients%:*}" + clientzone="${clients%%:*}" clients="${clients#*:}" [ -z "$clientzone" -o -z "$clients" ] && \ fatal_error "Error: Empty source zone or qualifier: rule \"$rule\"" @@ -1967,7 +1974,7 @@ process_tos_rule() { fi [ -n "$src" ] && case "$src" in - [0-9]*|![0-9]*) + *.*.*) # # IP Address or subnet # @@ -2010,7 +2017,7 @@ process_tos_rule() { fi [ -n "$dst" ] && case "$dst" in - [0-9]*|![0-9]*) + *.*.*) # # IP Address or subnet # @@ -2416,7 +2423,7 @@ setup_masq() iface= case $subnet in - [0-9]*|![0-9]*) + *.*.*) source="$subnet" subnet="-s $subnet" ;; @@ -2783,12 +2790,17 @@ initialize_netfilter () { setpolicy INPUT DROP setpolicy OUTPUT DROP setpolicy FORWARD DROP - + deleteallchains setcontinue FORWARD setcontinue INPUT setcontinue OUTPUT + # + # Allow DNS lookups during startup for FQDNs + # + run_iptables -A OUTPUT -p udp --dport 53 -j ACCEPT + run_iptables -A FORWARD -p udp --dport 53 -j ACCEPT [ -n "$CLAMPMSS" ] && \ run_iptables -A FORWARD -p tcp \ @@ -3245,6 +3257,9 @@ activate_rules() run_iptables -D INPUT 1 run_iptables -D OUTPUT 1 run_iptables -D FORWARD 1 + + run_iptables -D OUTPUT -p udp --dport 53 -j ACCEPT + run_iptables -D FORWARD -p udp --dport 53 -j ACCEPT } ################################################################################ @@ -3252,6 +3267,16 @@ activate_rules() ################################################################################ define_firewall() # $1 = Command (Start or Restart) { + if [ -f /etc/shorewall/startup_disabled ]; then + echo " Shorewall Startup is disabled -- to enable startup" + echo " after you have completed Shorewall configuration," + echo " remove the file /etc/shorewall/startup_disabled" + + [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR + my_mutex_off + exit 2 + fi + echo "${1}ing Shorewall..." verify_os_version @@ -3329,7 +3354,7 @@ define_firewall() # $1 = Command (Start or Restart) createchain shorewall no - date > /var/lib/shorewall/restarted + date > $STATEDIR/restarted report "Shorewall ${1}ed" @@ -3512,7 +3537,7 @@ do_initialize() { trap "rm -rf $TMP_DIR; my_mutex_off; exit 2" 1 2 3 4 5 6 9 - functions=/var/lib/shorewall/functions + functions=/usr/lib/shorewall/functions if [ -f $functions ]; then . $functions @@ -3520,7 +3545,7 @@ do_initialize() { startup_error "$functions does not exist!" fi - version_file=/var/lib/shorewall/version + version_file=/usr/lib/shorewall/version [ -f $version_file ] && version=`cat $version_file` # @@ -3536,6 +3561,7 @@ do_initialize() { [ -d $STATEDIR ] || mkdir -p $STATEDIR + [ -z "$FW" ] && FW=fw ALLOWRELATED="`added_param_value_yes ALLOWRELATED $ALLOWRELATED`" @@ -3623,6 +3649,7 @@ case "$command" in if qt iptables -L shorewall -n ; then [ -n "$SUBSYSLOCK" ] && touch $SUBSYSLOCK echo "Shorewall Already Started" + [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR my_mutex_off exit 0; fi @@ -3652,7 +3679,7 @@ case "$command" in reset) iptables -L -n -Z -v report "Shorewall Counters Reset" - date > /var/lib/shorewall/restarted + date > $STATEDIR/restarted ;; refresh) @@ -3660,6 +3687,7 @@ case "$command" in my_mutex_on if ! qt iptables -L shorewall -n ; then echo "Shorewall Not Started" + [ -n "$TMP_DIR" ] && rm -rf $TMP_DIR my_mutex_off exit 2; fi diff --git a/STABLE/functions b/STABLE/functions index acb07f38f..e8d0c797d 100644 --- a/STABLE/functions +++ b/STABLE/functions @@ -1,6 +1,6 @@ #!/bin/sh # -# Shorewall 1.3 -- /var/lib/shorewall/functions +# Shorewall 1.3 -- /usr/lib/shorewall/functions # # Suppress all output for a command diff --git a/STABLE/install.sh b/STABLE/install.sh index f3c4f4616..6dd828f79 100755 --- a/STABLE/install.sh +++ b/STABLE/install.sh @@ -54,7 +54,7 @@ # /etc/rc.d/rc.local file is modified to start the firewall. # -VERSION=1.3.8 +VERSION=1.3.9a usage() # $1 = exit status { @@ -254,9 +254,10 @@ fi echo -e "\nShorewall script installed in ${PREFIX}${DEST}/$FIREWALL" # -# Create /etc/shorewall and /var/shorewall if needed +# Create /etc/shorewall, /usr/lib/shorewall and /var/shorewall if needed # mkdir -p ${PREFIX}/etc/shorewall +mkdir -p ${PREFIX}/usr/lib/shorewall mkdir -p ${PREFIX}/var/lib/shorewall # # Install the config file @@ -280,7 +281,12 @@ fi # # Install the functions file # -install_file_with_backup functions ${PREFIX}/var/lib/shorewall/functions 0444 +if [ -f ${PREFIX}/etc/shorewall/functions ]; then + backup_file ${PREFIX}/var/lib/shorewall/functions + rm -f ${PREFIX}/var/lib/shorewall/functions +fi + +install_file_with_backup functions ${PREFIX}/usr/lib/shorewall/functions 0444 echo -e "\nCommon functions installed in ${PREFIX}/var/lib/shorewall/functions" # @@ -443,19 +449,19 @@ fi # Backup the version file # if [ -z "$PREFIX" ]; then - if [ -f /var/lib/shorewall/version ]; then - backup_file /var/lib/shorewall/version + if [ -f /usr/lib/shorewall/version ]; then + backup_file /usr/lib/shorewall/version elif [ -n "$oldversion" ]; then - echo $oldversion > /var/lib/shorewall/version-${VERSION}.bkout + echo $oldversion > /usr/lib/shorewall/version-${VERSION}.bkout else - echo "Unknown" > /var/lib/shorewall/version-${VERSION}.bkout + echo "Unknown" > /usr/lib/shorewall/version-${VERSION}.bkout fi fi # # Create the version file # -echo "$VERSION" > ${PREFIX}/var/lib/shorewall/version -chmod 644 ${PREFIX}/var/lib/shorewall/version +echo "$VERSION" > ${PREFIX}/usr/lib/shorewall/version +chmod 644 ${PREFIX}/usr/lib/shorewall/version # # Remove and create the symbolic link to the firewall script # @@ -463,12 +469,13 @@ chmod 644 ${PREFIX}/var/lib/shorewall/version if [ -z "$PREFIX" ]; then rm -f /etc/shorewall/firewall rm -f /var/lib/shorewall/firewall - ln -s ${DEST}/${FIREWALL} /var/lib/shorewall/firewall + rm -f /usr/lib/shorewall/firewall + ln -s ${DEST}/${FIREWALL} /usr/lib/shorewall/firewall else - pushd ${PREFIX}/var/lib/shorewall/ >> /dev/null && ln -s ../../..${DEST}/${FIREWALL} firewall && popd >> /dev/null + pushd ${PREFIX}/usr/lib/shorewall/ >> /dev/null && ln -s ../../..${DEST}/${FIREWALL} firewall && popd >> /dev/null fi -echo -e "\n${PREFIX}/var/lib/shorewall/firewall linked to ${PREFIX}$DEST/$FIREWALL" +echo -e "\n${PREFIX}/usr/lib/shorewall/firewall linked to ${PREFIX}$DEST/$FIREWALL" if [ -z "$PREFIX" -a -n "$first_install" ]; then if [ -x /sbin/insserv -o -x /usr/sbin/insserv ]; then @@ -493,7 +500,13 @@ if [ -z "$PREFIX" -a -n "$first_install" ]; then else modify_rclocal fi + + echo \ +"######################################################################## +# REMOVE THIS FILE AFTER YOU HAVE CONFIGURED SHOREWALL # +########################################################################" > /etc/shorewall/startup_disabled fi + # # Report Success # diff --git a/STABLE/masq b/STABLE/masq index 69894ddbb..3b0edea3e 100644 --- a/STABLE/masq +++ b/STABLE/masq @@ -37,7 +37,9 @@ # WARNING: Do NOT specify ADD_SNAT_ALIASES=Yes if # the address given in this column is the primary # IP address for the interface in the INTERFACE -# column. +# column. +# +# This column may not contain a DNS Name. # # Example 1: # diff --git a/STABLE/nat b/STABLE/nat index db85e4114..7b6ba5b20 100644 --- a/STABLE/nat +++ b/STABLE/nat @@ -14,10 +14,10 @@ # # EXTERNAL External IP Address - this should NOT be the primary # IP address of the interface named in the next -# column. +# column and must not be a DNS Name. # INTERFACE Interface that we want to EXTERNAL address to appear # on -# INTERNAL Internal Address +# INTERNAL Internal Address (must not be a DNS Name). # ALL INTERFACES If Yes or yes (or left empty), NAT will be effective # from all hosts. If No or no then NAT will be effective # only through the interface named in the INTERFACE diff --git a/STABLE/releasenotes.txt b/STABLE/releasenotes.txt index 3a256ef7d..d398a9346 100644 --- a/STABLE/releasenotes.txt +++ b/STABLE/releasenotes.txt @@ -3,20 +3,14 @@ fixes. New features include: -1. 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). +1. DNS Names are now allowed in Shorewall config files. +2. The connection SOURCE may now be qualified by both interface + and IP address in a Shorewall rule. -2. 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: +3. Shorewall startup is now disabled after initial installation until + the file /etc/shorewall/startup_disabled is removed. - a. There is a policy for za to zb. - b. There is at least one rule for za to zb. - -3. 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. +4. 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. diff --git a/STABLE/rules b/STABLE/rules index 8e686d040..39a81eb4d 100644 --- a/STABLE/rules +++ b/STABLE/rules @@ -56,9 +56,12 @@ # MAC address 00:A0:C9:15:39:78. # # Alternatively, clients may be specified by interface -# by appending ":" followed by the interface name. For -# example, loc:eth1 specifies a client that -# communicates with the firewall system through eth1. +# by appending ":" to the zone name followed by the +# interface name. For example, loc:eth1 specifies a +# client that communicates with the firewall system +# through eth1. This may be optionally followed by +# another colon (":") and an IP/MAC/subnet address +# as described above (e.g., loc:eth1:192.168.1.5). # # DEST Location of Server. May be a zone defined in # /etc/shorewall/zones or $FW to indicate the firewall @@ -68,6 +71,13 @@ # subnet, host or interface by appending ":" and the # subnet, host or interface. See above. # +# Restrictions: +# +# 1. MAC addresses are not allowed. +# 2. In DNAT rules, only IP addresses are +# allowed; no FQDNs or subnet addresses +# are permitted. +# # The port that the server is listening on may be # included and separated from the server's IP address by # ":". If omitted, the firewall will not modifiy the diff --git a/STABLE/shorewall b/STABLE/shorewall index 196b838cd..aa39becab 100755 --- a/STABLE/shorewall +++ b/STABLE/shorewall @@ -312,6 +312,8 @@ monitor_firewall() # $1 = timeout -- if negative, prompt each time that echo -e "Dropped/Rejected Packet Log\\n" + show_reset + rejects=`iptables -L -v -n | grep 'LOG'` if [ "$rejects" != "$oldrejects" ]; then @@ -384,6 +386,8 @@ logwatch() # $1 = timeout -- if negative, prompt each time that echo -e "Dropped/Rejected Packet Log\\n" + show_reset + rejects=`iptables -L -v -n | grep 'LOG'` if [ "$rejects" != "$oldrejects" ]; then @@ -437,8 +441,8 @@ usage() # $1 = exit status # Display the time that the counters were last reset # ################################################################################# show_reset() { - [ -f /var/lib/shorewall/restarted ] && \ - echo -e "Counters reset `cat /var/lib/shorewall/restarted`\\n" + [ -f $STATEDIR/restarted ] && \ + echo -e "Counters reset `cat $STATEDIR/restarted`\\n" } ################################################################################# @@ -491,7 +495,7 @@ fi [ -n "$SHOREWALL_DIR" ] && export SHOREWALL_DIR -functions=/var/lib/shorewall/functions +functions=/usr/lib/shorewall/functions if [ -f $functions ]; then . $functions @@ -500,7 +504,7 @@ else exit 2 fi -firewall=/var/lib/shorewall/firewall +firewall=/usr/lib/shorewall/firewall if [ ! -f $firewall ]; then echo "ERROR: Shorewall is not properly installed" @@ -508,7 +512,7 @@ if [ ! -f $firewall ]; then echo " $firewall is a symbolic link to a" echo " non-existant file" else - echo " The file /var/lib/shorewall/firewall does not exist" + echo " The file /usr/lib/shorewall/firewall does not exist" fi exit 2 @@ -516,13 +520,13 @@ fi PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin -version_file=/var/lib/shorewall/version +version_file=/usr/lib/shorewall/version if [ -f $version_file ]; then version=`cat $version_file` else echo "ERROR: Shorewall is not properly installed" - echo " The file /var/lib/shorewall/version does not exist" + echo " The file /usr/lib/shorewall/version does not exist" exit 1 fi @@ -546,6 +550,7 @@ case "$1" in iptables -t nat -L -n -v ;; tos|mangle) + get_config echo -e "Shorewall-$version TOS at $HOSTNAME - `date`\\n" show_reset iptables -t mangle -L -n -v @@ -553,6 +558,7 @@ case "$1" in log) get_config echo -e "Shorewall-$version Log at $HOSTNAME - `date`\\n" + show_reset host=`echo $HOSTNAME | sed 's/\..*$//'` packet_log 20 ;; @@ -561,6 +567,7 @@ case "$1" in show_tc ;; *) + get_config echo -e "Shorewall-$version Chain $2 at $HOSTNAME - `date`\\n" show_reset iptables -L $2 -n -v diff --git a/STABLE/shorewall.spec b/STABLE/shorewall.spec index 383d1f72c..835551c25 100644 --- a/STABLE/shorewall.spec +++ b/STABLE/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.3.8 +%define version 1.3.9a %define release 1 %define prefix /usr @@ -40,16 +40,40 @@ export GROUP=`id -n -g` ;\ rm -rf $RPM_BUILD_ROOT %post -if [ -x /sbin/insserv ]; then /sbin/insserv /etc/rc.d/shorewall; elif [ -x /sbin/chkconfig ]; then /sbin/chkconfig --add shorewall; fi + +if [ $1 -eq 1 ]; then + echo \ +"######################################################################## +# REMOVE THIS FILE AFTER YOU HAVE CONFIGURED SHOREWALL # +########################################################################" \ + > /etc/shorewall/startup_disabled + + if [ -x /sbin/insserv ]; then + /sbin/insserv /etc/rc.d/shorewall + elif [ -x /sbin/chkconfig ]; then + /sbin/chkconfig --add shorewall; + fi +fi %preun -if [ $1 = 0 ]; then if [ -x /sbin/insserv ]; then /sbin/insserv -r /etc/init.d/shorewall ; elif [ -x /sbin/chkconfig ]; then /sbin/chkconfig --del shorewall; fi ; fi + +if [ $1 = 0 ]; then + if [ -x /sbin/insserv ]; then + /sbin/insserv -r /etc/init.d/shorewall + elif [ -x /sbin/chkconfig ]; then + /sbin/chkconfig --del shorewall + fi + + rm -f /etc/shorewall/startup_disabled + +fi %files /etc/init.d/shorewall %attr(0700,root,root) %dir /etc/shorewall +%attr(0700,root,root) %dir /usr/lib/shorewall %attr(0700,root,root) %dir /var/lib/shorewall -%attr(0600,root,root) /var/lib/shorewall/version +%attr(0600,root,root) /usr/lib/shorewall/version %attr(0600,root,root) /etc/shorewall/common.def %attr(0600,root,root) /etc/shorewall/icmp.def %attr(0600,root,root) %config(noreplace) /etc/shorewall/shorewall.conf @@ -70,12 +94,16 @@ if [ $1 = 0 ]; then if [ -x /sbin/insserv ]; then /sbin/insserv -r /etc/init.d/s %attr(0600,root,root) %config(noreplace) /etc/shorewall/blacklist %attr(0600,root,root) %config(noreplace) /etc/shorewall/rfc1918 %attr(0544,root,root) /sbin/shorewall -%attr(0444,root,root) /var/lib/shorewall/functions -/var/lib/shorewall/firewall +%attr(0444,root,root) /usr/lib/shorewall/functions +/usr/lib/shorewall/firewall %doc documentation %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Mon Sep 30 2002 Tom Eastep +- Changed version to 1.3.9a +* Thu Sep 18 2002 Tom Eastep +- Changed version to 1.3.8 * Mon Sep 16 2002 Tom Eastep - Changed version to 1.3.8 * Mon Sep 02 2002 Tom Eastep diff --git a/STABLE/uninstall.sh b/STABLE/uninstall.sh index cbe3edf56..3062b966d 100755 --- a/STABLE/uninstall.sh +++ b/STABLE/uninstall.sh @@ -26,7 +26,7 @@ # You may only use this script to uninstall the version # shown below. Simply run this script to remove Seattle Firewall -VERSION=1.3.8 +VERSION=1.3.9a usage() # $1 = exit status { @@ -78,9 +78,15 @@ if qt iptables -L shorewall -n; then /sbin/shorewall clear fi -if [ -L /var/lib/shorewall/firewall ]; then +if [ -L /usr/lib/shorewall/firewall ]; then + FIREWALL=`ls -l /usr/lib/shorewall/firewall | sed 's/^.*> //'` +elif [ -L /var/lib/shorewall/firewall ]; then FIREWALL=`ls -l /var/lib/shorewall/firewall | sed 's/^.*> //'` +else + FIREWALL= +fi +if [ -n "$FIREWALL" ]; then if [ -x /sbin/insserv -o -x /usr/sbin/insserv ]; then insserv -r $FIREWALL elif [ -x /sbin/chkconfig -o -x /usr/sbin/chkconfig ]; then @@ -97,6 +103,7 @@ if [ -n "$VERSION" ]; then fi rm -rf /etc/shorewall +rm -rf /usr/lib/shorewall rm -rf /var/lib/shorewall echo "Shorewall Uninstalled" diff --git a/Shorewall/fallback.sh b/Shorewall/fallback.sh index 9cedf4340..1a5aa1179 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.3.9 +VERSION=1.3.9a usage() # $1 = exit status { diff --git a/Shorewall/install.sh b/Shorewall/install.sh index 8febc4b62..6dd828f79 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.3.9 +VERSION=1.3.9a usage() # $1 = exit status { diff --git a/Shorewall/shorewall.spec b/Shorewall/shorewall.spec index d1d449c28..835551c25 100644 --- a/Shorewall/shorewall.spec +++ b/Shorewall/shorewall.spec @@ -1,5 +1,5 @@ %define name shorewall -%define version 1.3.9 +%define version 1.3.9a %define release 1 %define prefix /usr @@ -100,6 +100,8 @@ fi %doc COPYING INSTALL changelog.txt releasenotes.txt tunnel %changelog +* Mon Sep 30 2002 Tom Eastep +- Changed version to 1.3.9a * Thu Sep 18 2002 Tom Eastep - Changed version to 1.3.8 * Mon Sep 16 2002 Tom Eastep diff --git a/Shorewall/uninstall.sh b/Shorewall/uninstall.sh index a1f385034..3062b966d 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.3.9 +VERSION=1.3.9a usage() # $1 = exit status {