diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm
deleted file mode 100644
index d66583d76..000000000
--- a/Shorewall-docs/shorewall_setup_guide.htm
+++ /dev/null
@@ -1,2377 +0,0 @@
-
-
-
-
-
-
-
- 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 (ARP)
- 4.5 RFC 1918
-
-5.0 Setting up your Network
-
- 5.1 Routed
- 5.2 Non-routed
-
- 5.2.1 SNAT
- 5.2.2 DNAT
- 5.2.3 Proxy ARP
- 5.2.4 One-to-one NAT
-
- 5.3 Rules
- 5.4 Odds and Ends
-
-6.0 DNS
-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.
-Shorewall requires that the iproute/iproute2 package be installed
-(on RedHat, the package is called iproute). You can
-tell if this package is installed by the presence of an ip
-program
-on your firewall system. As root, you can use the 'which' command to
-check for this program:
- [root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
-I recommend that you first read through the guide to familiarize
-yourself with what's involved then go back through it again making your
-configuration changes. Points at which configuration changes are
-recommended are flagged 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:
-
-
-
- | Name |
- Description |
-
-
- | net |
- The Internet |
-
-
- | loc |
- Your Local Network |
-
-
- | dmz |
- Demilitarized 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:
-
- - Identify the source zone.
- - Identify the destination zone.
- - 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.
- - 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.
-
- 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 Zone |
- Destination Zone |
- Policy |
- Log Level |
- Limit:Burst |
-
-
- | loc |
- net |
- ACCEPT |
- |
- |
-
-
- | net |
- all |
- DROP |
- info |
- |
-
-
- | all |
- all |
- REJECT |
- info |
- |
-
-
-
-
-The above policy will:
-
- - allow all connection requests from your local network to the
-internet
- - drop (ignore) all connection requests from the internet to your
-firewall or local network and log a message at the info level (here is a description of
-log levels).
- - 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.
-
-
- At this point, edit your /etc/shorewall/policy and
-make any changes that you wish.
-3.0 Network Interfaces
-For the remainder of this guide, we'll refer to the
-following diagram. While it may not look like your own network, it can
-be used to illustrate the important aspects of Shorewall configuration.
-In this diagram:
-
- - The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used
-to isolate your internet-accessible servers from your local systems so
-that if one of those servers is compromised, you still have the
-firewall between the compromised system and your local systems.
- - The Local Zone consists of systems Local 1, Local 2 and Local 3.
- - All systems from the ISP outward comprise the Internet Zone.
-
- 
-The simplest way to define zones is to simply associate
-the zone name (previously defined in /etc/shorewall/zones) with a
-network interface. This is done in the /etc/shorewall/interfaces file.
-The firewall illustrated above has three network
-interfaces. Where Internet connectivity is through a cable or DSL
-"Modem", the External Interface will be the Ethernet adapter
-that is connected to that "Modem" (e.g., eth0) unless
-you connect via
-Point-to-Point Protocol over Ethernet
-(PPPoE) or Point-to-Point Tunneling Protocol
-(PPTP) in which case the External Interface will be a ppp interface
-(e.g., ppp0). If you connect via a regular modem, your External
-Interface will also be ppp0. If you connect using ISDN, you
-external interface will be ippp0.
-
If your external interface is ppp0
-or ippp0 then you will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
-Your Local Interface will be an Ethernet
-adapter (eth0, eth1 or eth2) and will be connected to a hub or switch.
-Your local computers will be connected to the same switch (note: If you
-have
-only a single local system, you can connect the firewall directly to
-the computer using a cross-over cable).
-Your DMZ Interface will also be an Ethernet
-adapter (eth0, eth1 or eth2) and will be connected to a hub or switch.
-Your DMZ computers will be connected to the same switch (note: If you
-have only a single DMZ system, you can connect the firewall directly to
-the computer using a cross-over cable).
- Do not connect the internal and
-external interface to the same hub or switch except for testing AND you
-are running Shorewall version 1.4.7 or later. When using these
-recent
-versions, you can test using this kind of configuration if you specify
-the arp_filter
-option in /etc/shorewall/interfaces for all interfaces connected to the
-common hub/switch. Using such a setup with a production firewall is
-strongly recommended against.
-For the remainder of this Guide, we will assume that:
-
- -
-
The external interface is eth0.
-
- -
-
The Local interface is eth1.
-
- -
-
The DMZ interface is eth2.
-
-
-The Shorewall default configuration does not define the
-contents of any zone. To define the above configuration using the
-/etc/shorewall/interfaces file, that file would might contain:
-
-
-
-
- | Zone |
- Interface |
- Broadcast |
- Options |
-
-
- | net |
- eth0 |
- detect |
- norfc1918 |
-
-
- | loc |
- eth1 |
- detect |
- |
-
-
- | dmz |
- eth2 |
- detect |
- |
-
-
-
-
-
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:
-
-
-
-
- | Zone |
- Interface |
- Broadcast |
- Options |
-
-
- | net |
- eth0 |
- detect |
- norfc1918 |
-
-
- | loc |
- eth1 |
- detect |
- |
-
-
- | loc |
- eth2 |
- detect |
- dhcp |
-
-
-
-
-
-
When you have more than one interface to a zone, you
-will usually want a policy that permits intra-zone traffic:
-
-
-
-
-
- | Source Zone |
- Destination Zone |
- Policy |
- Log Level |
- Limit:Burst |
-
-
- | loc |
- loc |
- ACCEPT |
- |
- |
-
-
-
-
-
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:
-
- -
-
The number of addresses in the set is a power of 2;
-and
-
- -
-
The first address in the set is a multiple of the
-set size.
-
- -
-
The first address in the subnet is reserved and is
-referred to as the subnet address.
-
- -
-
The last address in the subnet is reserved as the subnet's
-broadcast address.
-
-
-As you can see by this definition, in each subnet of
-size n there are (n - 2) usable addresses (addresses
-that can be assigned to hosts). The first and last address in the
-subnet are used for the subnet address and subnet broadcast address
-respectively. Consequently, small subnetworks are more wasteful of IP
-addresses than are large ones.
-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:
-
-
-
-
- | n |
- log2 n |
- (32 - log2 n) |
-
-
- | 8 |
- 3 |
- 29 |
-
-
- | 16 |
- 4 |
- 28 |
-
-
- | 32 |
- 5 |
- 27 |
-
-
- | 64 |
- 6 |
- 26 |
-
-
- | 128 |
- 7 |
- 25 |
-
-
- | 256 |
- 8 |
- 24 |
-
-
- | 512 |
- 9 |
- 23 |
-
-
- | 1024 |
- 10 |
- 22 |
-
-
- | 2048 |
- 11 |
- 21 |
-
-
- | 4096 |
- 12 |
- 20 |
-
-
- | 8192 |
- 13 |
- 19 |
-
-
- | 16384 |
- 14 |
- 18 |
-
-
- | 32768 |
- 15 |
- 17 |
-
-
- | 65536 |
- 16 |
- 16 |
-
-
-
-
-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 Subnet |
- VLSM |
- Subnet Mask |
-
-
- | 8 |
- /29 |
- 255.255.255.248 |
-
-
- | 16 |
- /28 |
- 255.255.255.240 |
-
-
- | 32 |
- /27 |
- 255.255.255.224 |
-
-
- | 64 |
- /26 |
- 255.255.255.192 |
-
-
- | 128 |
- /25 |
- 255.255.255.128 |
-
-
- | 256 |
- /24 |
- 255.255.255.0 |
-
-
- | 512 |
- /23 |
- 255.255.254.0 |
-
-
- | 1024 |
- /22 |
- 255.255.252.0 |
-
-
- | 2048 |
- /21 |
- 255.255.248.0 |
-
-
- | 4096 |
- /20 |
- 255.255.240.0 |
-
-
- | 8192 |
- /19 |
- 255.255.224.0 |
-
-
- | 16384 |
- /18 |
- 255.255.192.0 |
-
-
- | 32768 |
- /17 |
- 255.255.128.0 |
-
-
- | 65536 |
- /16 |
- 255.255.0.0 |
-
-
- | 2 ** 24 |
- /8 |
- 255.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 Subnetwork |
- VLSM Length |
- Subnet Mask |
- CIDR Notation |
-
-
- | 1 |
- 32 |
- 255.255.255.255 |
- a.b.c.d/32 |
-
-
- | 2 ** 32 |
- 0 |
- 0.0.0.0 |
- 0.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.
-
-Beginning with Shorewall 1.4.6, /sbin/shorewall
-supports an
-ipcalc command that automatically calculates information about a
-[sub]network.
-
-Example 1:
-
-
- ipcalc 10.10.10.0/25
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
-
-Example 2
-
- ipcalc 10.10.10.0 255.255.255.128
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
-
-4.3 Routing
-One of the purposes of subnetting is that it forms the
-basis for routing. Here's the routing table on my firewall:
-
-
- [root@gateway root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas
206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3
192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3
192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0
[root@gateway root]#
-
-
The device texas is a GRE tunnel to a peer site
-in the Dallas, Texas area.
-
-The first three routes are host routes since they
-indicate how to get to a single host. In the 'netstat' output this
-can be seen by the "Genmask" (Subnet Mask) of 255.255.255.255 and
-the "H" in the Flags column. The remainder are 'net' routes since they
-tell the kernel how to route packets to a subnetwork. The last route
-is the default route and the gateway mentioned in that route is
-called the default gateway.
-When the kernel is trying to send a packet to IP
-address A, it starts at the top of the routing table and:
-
- -
-
A is logically ANDed with the 'Genmask'
-value in
-the table entry.
-
- -
-
The result is compared with the 'Destination' value
-in the table entry.
-
- -
-
If the result and the 'Destination' value are the
-same, then:
-
- -
-
If the 'Gateway' column is non-zero, the packet
-is sent to the gateway over the interface named in the 'Iface' column.
-
- -
-
Otherwise, the packet is sent directly to A
- over the interface named in the 'iface' column.
-
-
-
- -
-
Otherwise, the above steps are repeated on the next
-entry in the table.
-
-
-Since the default route matches any IP address (A
-land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other
-routing table entries are sent to the default gateway which is
-usually a router
-at your ISP.
-Lets take an example. Suppose that we want to route a
-packet to 192.168.1.5. That address clearly doesn't match any of the
-host routes in the table but if we logically and that address with
-255.255.255.0, the result is 192.168.1.0 which matches this routing
-table entry:
-
-
- 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
-
-
So to route a packet to 192.168.1.5, the packet is sent directly
-over eth2.
-
One more thing needs to be emphasized -- all outgoing
-packet are sent using the routing table and reply packets are not a
-special case. There seems to be a common mis-conception whereby people
-think that request packets are like salmon and contain a genetic code
-that is magically transferred to reply packets so that the replies
-follow the reverse route taken by the request. That isn't the case; the
-replies may take a totally different route back to the client than was
-taken by the requests -- they are totally independent.
-4.4 Address Resolution Protocol (ARP)
-When sending packets over Ethernet, IP addresses aren't
-used. Rather Ethernet addressing is based on Media Access Control
-(MAC) addresses. Each Ethernet device has it's own unique MAC
-address which is burned into a PROM on the device during manufacture.
-You can obtain the MAC of an Ethernet device using the 'ip' utility:
-
-
-
[root@gateway root]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
[root@gateway root]#
-
-
-
As you can see from the above output, the MAC is 6
-bytes (48 bits) wide. A card's MAC is usually also printed on a label
-attached to
-the card itself.
-
-
Because IP uses IP addresses and Ethernet uses MAC
-addresses, a mechanism is required to translate an IP address into a
-MAC address; that is the purpose of the Address Resolution Protocol
-(ARP). Here is ARP in action:
-
-
-
-
[root@gateway root]# tcpdump -nei eth2 arp
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0
2 packets received by filter
0 packets dropped by kernel
[root@gateway root]#
-
-
In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48)
-wants to know the MAC of the device with IP address 192.168.1.19. The
-system having that IP address is responding that the MAC address of the
-device with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.
-In order to avoid having to exchange ARP information
-each time that an IP packet is to be sent, systems maintain an ARP
-cache of IP<->MAC correspondences. You can see the ARP
-cache on your system (including your Windows system) using the 'arp'
-command:
-
-
-
[root@gateway root]# arp -na
? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
-
-The leading question marks are a result of my having
-specified the 'n' option (Windows 'arp' doesn't allow that option)
-which causes the 'arp' program to forego IP->DNS name translation.
-Had I not
-given that option, the question marks would have been replaced with
-the FQDN corresponding to each IP address. Notice that the last entry
-in the table records the information we saw using tcpdump above.
-4.5 RFC 1918
-IP addresses are allocated by the Internet Assigned Number Authority (IANA)
-who delegates allocations on a geographic basis to Regional
-Internet Registries (RIRs). For example, allocation for the
-Americas and for sub-Sahara Africa is delegated to the American Registry for Internet Numbers (ARIN).
-These RIRs may in turn delegate to national registries. Most of us
-don't deal with these registrars but rather get our IP addresses from
-our ISP.
-It's a fact of life that most of us can't afford as
-many Public IP addresses as we have devices to assign them to so we end
-up making use
-of Private IP addresses. RFC 1918 reserves several IP address
-ranges
-for this purpose:
-
-
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
-
-
The addresses reserved by RFC 1918 are sometimes
-referred to as non-routable because the Internet backbone
-routers
-don't forward packets which have an RFC-1918 destination address.
-This is understandable given that anyone can select any of these
-addresses for their private use.
-
-
When selecting addresses from these ranges, there's a
-couple of things to keep in mind:
-
-
- -
-
As the IPv4 address space becomes depleted, more
-and more organizations (including ISPs) are beginning to use RFC 1918
-addresses in their infrastructure.
-
- -
-
You don't want to use addresses that are being used
-by your ISP or by another organization with whom you want to establish
-a VPN relationship.
-
-
-
-
So it's a good idea to check with your ISP to see if
-they are using (or are planning to use) private addresses before you
-decide the addresses that you are going to use.
-
-
NOTE: In this
-document, external "real" IP addresses are of the form 192.0.2.x.
-192.0.2.0/24 is reserved by RFC 3330 for use as public IP addresses in
-printed examples. These addresses are not to be confused with addresses
-in 192.168.0.0/16; as described above, these addresses are reserved by
-RFC 1918 for private 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:
-
-
- -
-
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.
-
- -
-
Non-routed - Your ISP will send traffic to
-each of your addresses directly.
-
-
-
-
In the subsections that follow, we'll look at each of
-these separately.
-
-
Before we begin, there is one thing for you to check:
-
If you are using the Debian
-package, please check your
-shorewall.conf file to ensure that the following are set correctly;
-if they are not, change them appropriately:
-
-
- - NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
- - IP_FORWARDING=On
-
-
-
-
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.
-
-
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 One-to-one NAT.
-
-
-
-
Often a combination of these techniques is used. Each
-of these will be discussed in the sections that follow.
-
-
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).
-
-
-
-
-
-
-
- | INTERFACE |
- SUBNET |
- ADDRESS |
-
-
- | eth0 |
- 192.168.201.0/29 |
- 192.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.
-
-
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:
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL DESTINATION |
-
-
- | DNAT |
- net |
- loc:192.168.201.4 |
- tcp |
- www |
- - |
- 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.
-
-
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 us 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.
-
-
-
-
-
-
-
- | ADDRESS |
- INTERFACE |
- EXTERNAL |
- HAVE ROUTE |
-
-
- | 192.0.2.177 |
- eth2 |
- eth0 |
- No |
-
-
- | 192.0.2.178 |
- eth2 |
- eth0 |
- No |
-
-
-
-
-
-
Because the HAVE ROUTE column contains No, Shorewall
-will add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.
-
-
The ethernet interfaces on DMZ 1 and DMZ 2 should be
-configured to have the IP addresses shown but should have the same
-default gateway as the firewall itself -- namely 192.0.2.254. In other
-words, they should be configured just like they would be if they were
-parallel to the firewall rather than behind it.
-
-
NOTE: Do not add the Proxy ARP'ed
-address(es) (192.0.2.177 and 192.0.2.178 in the above example) to
-the external interface (eth0 in this example) of the firewall.
-
-
-
-
-
A word of warning is in order here. ISPs typically
-configure their routers with a long ARP cache timeout. If you move a
-system from parallel to your firewall to behind your firewall with
-Proxy
-ARP, it will probably be HOURS before that system can communicate with
-the internet. There are a couple of things that you can try:
-
-
- - (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
-Illustrated, Vol 1 reveals that a
-
-"gratuitous" ARP packet should cause the ISP's router to refresh their
-ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
-the MAC address for its own IP; in addition to ensuring that the IP
-address isn't a duplicate,...
-
-"if the host sending the gratuitous ARP has just changed its hardware
-address..., this packet causes any other host...that has an entry in
-its cache for the old hardware address to update its ARP cache entry
-accordingly."
-
-Which is, of course, exactly what you want to do when you switch a host
-from being exposed to the Internet to behind Shorewall using proxy ARP
-(or one-to-one NAT for that matter). Happily enough, recent versions
-of Redhat's iputils package include "arping", whose "-U" flag does just
-that:
-
- arping -U -I <net
-if> <newly proxied IP>
- arping -U -I eth0
-66.58.99.83 # for example
-
-Stevens goes on to mention that not all systems respond correctly to
-gratuitous ARPs, but googling for "arping -U" seems to support the idea
-that it works most of the time.
-
-
- - 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 ISP's gateway (which we
-will assume is 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.
-
-
With one-to-one NAT, you assign local systems RFC 1918
-addresses then establish a one-to-one mapping between those addresses
-and
-public IP addresses. For outgoing connections SNAT (Source Network
-Address Translation) occurs and on incoming connections DNAT
-(Destination Network Address Translation) occurs. Let's go back to our
-earlier example involving your daughter's web server running on system
-Local 3.
-
-
-
-
Recall that in this setup, the local network is using
-SNAT and is sharing the firewall external IP (192.0.2.176) for outbound
-connections. This is done with the following entry in
-/etc/shorewall/masq:
-
-
-
-
-
- | INTERFACE |
- SUBNET |
- ADDRESS |
-
-
- | eth0 |
- 192.168.201.0/29 |
- 192.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.
-
-
-
-
-
- | EXTERNAL |
- INTERFACE |
- INTERNAL |
- ALL INTERFACES |
- LOCAL |
-
-
- | 192.0.2.179 |
- eth0 |
- 192.168.201.4 |
- No |
- No |
-
-
-
-
-
-
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:
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL DESTINATION |
-
-
- | ACCEPT |
- net |
- loc:192.168.201.4 |
- tcp |
- www |
- |
- |
-
-
-
-
-
-
-
-
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
-one-to-one NAT, it will probably be HOURS before that system can
-communicate
-with the internet. There are a couple of things that you can try:
-
-
- - (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
-Illustrated, Vol 1 reveals that a
-
-"gratuitous" ARP packet should cause the ISP's router to refresh their
-ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
-the MAC address for its own IP; in addition to ensuring that the IP
-address isn't a duplicate,...
-
-"if the host sending the gratuitous ARP has just changed its hardware
-address..., this packet causes any other host...that has an entry in
-its cache for the old hardware address to update its ARP cache entry
-accordingly."
-
-Which is, of course, exactly what you want to do when you switch a host
-from being exposed to the Internet to behind Shorewall using proxy ARP
-(or one-to-one NAT for that matter). Happily enough, recent versions
-of Redhat's iputils package include "arping", whose "-U" flag does just
-that:
-
- arping -U -I <net
-if> <newly proxied IP>
- arping -U -I eth0
-66.58.99.83 # for example
-
-Stevens goes on to mention that not all systems respond correctly to
-gratuitous ARPs, but googling for "arping -U" seems to support the idea
-that it works most of the time.
-
-
- - 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 209.0.2.179. On the firewall,
-run tcpdump as follows:
-
-
tcpdump -nei eth0 icmp
-
-
-
Now from the 192.168.201.4, ping the ISP's gateway
-(which we will assume is 192.0.2.254):
-
-
-
-
-
We can now observe the tcpdump output:
-
-
-
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.179 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.179 : icmp: echo reply
-
-
-
Notice that the source MAC address in the echo request
-is different from the destination MAC address in the echo reply!!
-In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0
-NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other
-words, the gateway's ARP cache still associates 192.0.2.179 with
-the NIC in the local zone rather than with the firewall's eth0.
-
-
5.3 Rules
-
-
With the default policies, your local
-systems (Local 1-3) can access any servers on the internet and the DMZ
-can't access any other host (including the firewall). With the
-exception of
-DNAT rules which cause address translation and
-allow the translated connection request to pass through the firewall,
-the way to allow connection requests through your firewall is to
-use ACCEPT rules.
-
-
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:
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
-
-
- | ACCEPT |
- net |
- dmz |
- icmp |
- echo-request |
-
-
- | ACCEPT |
- net |
- loc |
- icmp |
- echo-request |
-
-
- | ACCEPT |
- dmz |
- loc |
- icmp |
- echo-request |
-
-
- | ACCEPT |
- loc |
- dmz |
- icmp |
- echo-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:
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- COMMENTS |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.178 |
- tcp |
- smtp |
- # Mail from the Internet |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.178 |
- tcp |
- pop3 |
- # Pop3 from the Internet |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.178 |
- tcp |
- smtp |
- # Mail from the Local Network |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.178 |
- tcp |
- pop3 |
- # Pop3 from the Local Network |
-
-
- | ACCEPT |
- fw |
- dmz:192.0.2.178 |
- tcp |
- smtp |
- # Mail from the Firewall |
-
-
- | ACCEPT |
- dmz:192.0.2.178 |
- net |
- tcp |
- smtp |
- # Mail to the Internet |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.177 |
- tcp |
- http |
- # WWW from the Net |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.177 |
- tcp |
- https |
- # Secure HTTP from the Net |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.177 |
- tcp |
- https |
- # 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:
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- COMMENTS |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.177 |
- udp |
- domain |
- # UDP DNS from the Internet |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.177 |
- tcp |
- domain |
- # TCP DNS from the internet |
-
-
- | ACCEPT |
- fw |
- dmz:192.0.2.177 |
- udp |
- domain |
- # UDP DNS from firewall |
-
-
- | ACCEPT |
- fw |
- dmz:192.0.2.177 |
- tcp |
- domain |
- # TCP DNS from firewall |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.177 |
- udp |
- domain |
- # UDP DNS from the local Net |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.177 |
- tcp |
- domain |
- # TCP DNS from the local Net |
-
-
- | ACCEPT |
- dmz:192.0.2.177 |
- net |
- udp |
- domain |
- # UDP DNS to the Internet |
-
-
- | ACCEPT |
- dmz:192.0.2.177 |
- net |
- tcp |
- domain |
- # 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.
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- COMMENTS |
-
-
- | ACCEPT |
- loc |
- dmz |
- tcp |
- ssh |
- # SSH to the DMZ |
-
-
- | ACCEPT |
- loc |
- fw |
- tcp |
- ssh |
- # SSH to the Firewall |
-
-
-
-
-
-
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).
-
-
-
-
-
- | Zone |
- Interface |
- Broadcast |
- Options |
-
-
- | net |
- eth0 |
- detect |
- norfc1918,routefilter |
-
-
- | loc |
- eth1 |
- detect |
- |
-
-
- | dmz |
- eth2 |
- detect |
- |
-
-
-
-
-
-
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.
-
-
-
-
-
- | Zone |
- Interface |
- Broadcast |
- Options |
-
-
- | net |
- eth0 |
- 192.0.2.255 |
- norfc1918,routefilter |
-
-
- | loc |
- eth1 |
- 192.168.201.7 |
- |
-
-
- | dmz |
- eth2 |
- 192.168.202.7 |
- |
-
-
-
-
-
-
/etc/shorewall/masq - Local subnet
-
-
-
-
-
- | INTERFACE |
- SUBNET |
- ADDRESS |
-
-
- | eth0 |
- 192.168.201.0/29 |
- 192.0.2.176 |
-
-
-
-
-
-
/etc/shorewall/proxyarp - DMZ
-
-
-
-
-
- | ADDRESS |
- INTERFACE |
- EXTERNAL |
- HAVE ROUTE |
-
-
- | 192.0.2.177 |
- eth2 |
- eth0 |
- No |
-
-
- | 192.0.2.178 |
- eth2 |
- eth0 |
- No |
-
-
-
-
-
-
/etc/shorewall/nat- Daughter's System
-
-
-
-
-
- | EXTERNAL |
- INTERFACE |
- INTERNAL |
- ALL INTERFACES |
- LOCAL |
-
-
- | 192.0.2.179 |
- eth0 |
- 192.168.201.4 |
- No |
- No |
-
-
-
-
-
-
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- COMMENTS |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.178 |
- tcp |
- smtp |
- # Mail from the Internet |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.178 |
- tcp |
- pop3 |
- # Pop3 from the Internet |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.178 |
- tcp |
- smtp |
- # Mail from the Local Network |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.178 |
- tcp |
- pop3 |
- # Pop3 from the Local Network |
-
-
- | ACCEPT |
- fw |
- dmz:192.0.2.178 |
- tcp |
- smtp |
- # Mail from the Firewall |
-
-
- | ACCEPT |
- dmz:192.0.2.178 |
- net |
- tcp |
- smtp |
- # Mail to the Internet |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.178 |
- tcp |
- http |
- # WWW from the Net |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.178 |
- tcp |
- https |
- # Secure HTTP from the Net |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.178 |
- tcp |
- https |
- # Secure HTTP from the Local Net |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.177 |
- udp |
- domain |
- # UDP DNS from the Internet |
-
-
- | ACCEPT |
- net |
- dmz:192.0.2.177 |
- tcp |
- domain |
- # TCP DNS from the internet |
-
-
- | ACCEPT |
- fw |
- dmz:192.0.2.177 |
- udp |
- domain |
- # UDP DNS from firewall |
-
-
- | ACCEPT |
- fw |
- dmz:192.0.2.177 |
- tcp |
- domain |
- # TCP DNS from firewall |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.177 |
- udp |
- domain |
- # UDP DNS from the local Net |
-
-
- | ACCEPT |
- loc |
- dmz:192.0.2.177 |
- tcp |
- domain |
- # TCP DNS from the local Net |
-
-
- | ACCEPT |
- dmz:192.0.2.177 |
- net |
- udp |
- domain |
- # UDP DNS to the Internet |
-
-
- | ACCEPT |
- dmz:192.0.2.177 |
- net |
- tcp |
- domain |
- # TCP DNS to the Internet |
-
-
- | ACCEPT |
- net |
- dmz |
- icmp |
- echo-request |
- # Ping |
-
-
- | ACCEPT |
- net |
- loc |
- icmp |
- echo-request |
- # " |
-
-
- | ACCEPT |
- dmz |
- loc |
- icmp |
- echo-request |
- # " |
-
-
- | ACCEPT |
- loc |
- dmz |
- icmp |
- echo-request |
- # " |
-
-
- | ACCEPT |
- loc |
- dmz |
- tcp |
- ssh |
- # SSH to the DMZ |
-
-
- | ACCEPT |
- loc |
- fw |
- tcp |
- ssh |
- # SSH to the Firewall |
-
-
-
-
-
-
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.0/8;
192.0.2.176/32;
192.0.2.178/32;
192.0.2.179/32;
192.0.2.180/32; };
#
# If this server can't complete the request, it should use outside
# servers to do so
#
recursion yes;
zone "." in {
type hint;
file "int/root.cache";
};
zone "foobar.net" in {
type master;
notify no;
allow-update { none; };
file "int/db.foobar";
};
zone "0.0.127.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.127.0.0";
};
zone "201.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.201";
};
zone "202.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.202";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.176";
};
(or status NAT for that matter)
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.206.124.146.179";
};
};
#
# This is the view that we present to the outside world
#
view "external" {
match-clients { any; };
#
# If we can't answer the query, we tell the client so
#
recursion no;
zone "foobar.net" in {
type master;
notify yes;
allow-update {none; };
allow-transfer { <secondary NS IP>; };
file "ext/db.foobar";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.176";
};
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.179";
};
};
-
-
-
Here are the files in /var/named (those not shown are
-usually included in your bind disbribution).
-
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 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 11/18/2003 - Tom Eastep
-Copyright 2002,
-2003 Thomas M. Eastep
-
-
-
-
-
diff --git a/Shorewall-docs/shorewall_setup_guide.xml b/Shorewall-docs/shorewall_setup_guide.xml
new file mode 100644
index 000000000..480dd2409
--- /dev/null
+++ b/Shorewall-docs/shorewall_setup_guide.xml
@@ -0,0 +1,3314 @@
+
+
+
+
+ Shorewall Setup Guide
+
+
+
+ Tom
+
+ Eastep
+
+
+
+ 2003-12-24
+
+
+ 2001-2003
+
+ Thomas M. Eastep
+
+
+
+ Permission is granted to copy, distribute and/or modify this
+ document under the terms of the GNU Free Documentation License, Version
+ 1.2 or any later version published by the Free Software Foundation; with
+ no Invariant Sections, with no Front-Cover, and with no Back-Cover
+ Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
+
+
+
+
+ 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. Shorewall requires that
+ the iproute/iproute2 package be installed (on RedHat, the package is
+ called iproute). You can tell if this package is installed by the
+ presence of an ip program on your
+ firewall system. As root, you can use the 'which' command to
+ check for this program:
+
+ [root@gateway root]# which ip
+ /sbin/ip
+ [root@gateway root]#
+
+
+ I recommend that you first read through the guide to familiarize
+ yourself with what's involved then go back through it again making
+ your configuration changes. Points at which configuration changes are
+ recommended are flagged 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.
+
+
+
+ Windows
+ Version of dos2unix
+
+
+
+ Linux
+ Version of dos2unix
+
+
+
+
+
+
+ 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:
+
+
+ Zones
+
+
+
+
+ Name
+
+ Description
+
+
+
+ net
+
+ The Internet
+
+
+
+ loc
+
+ Your Local Network
+
+
+
+ dmz
+
+ Demilitarized Zone
+
+
+
+
+
+ Zones are defined in the file /etc/shorewall/zones.
+
+ 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.
+
+
+
+ You express your default policy for connections from one zone to
+ another zone in the /etc/shorewall/policy
+ file.
+
+
+
+ You define exceptions to those default policies in the /etc/shorewall/rules.
+
+
+
+ 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:
+
+
+
+ Identify the source zone.
+
+
+
+ Identify destination zone.
+
+
+
+ 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.
+
+
+
+ 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.
+
+
+
+ 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:
+
+
+ /etc/shorewall/policy
+
+
+
+
+ SOURCE ZONE
+
+ DESTINATION ZONE
+
+ POLICY
+
+ LOG LEVEL
+
+ LIMIT:BURST
+
+
+
+ fw
+
+ net
+
+ ACCEPT
+
+
+
+
+
+
+
+ net
+
+ all
+
+ DROP
+
+ info
+
+
+
+
+
+ all
+
+ all
+
+ REJECT
+
+ info
+
+
+
+
+
+
+
+ The above policy will:
+
+
+
+ allow all connection requests from your local network to the
+ internet
+
+
+
+ drop (ignore) all connection requests from the internet to your
+ firewall or local network and log a message at the info level (here is
+ a description of log levels).
+
+
+
+ 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.
+
+
+
+ At this point, edit
+ your /etc/shorewall/policy and make any changes that you wish.
+
+
+
+ Network Interfaces
+
+ For the remainder of this guide, we'll refer to the following
+ diagram. While it may not look like your own network, it can be used to
+ illustrate the important aspects of Shorewall configuration.
+
+ In this diagram:
+
+
+
+ The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used
+ to isolate your internet-accessible servers from your local systems so
+ that if one of those servers is compromised, you still have the
+ firewall between the compromised system and your local systems.
+
+
+
+ The Local Zone consists of systems Local 1, Local 2 and Local 3.
+
+
+
+ All systems from the ISP outward comprise the Internet Zone.
+
+
+
+ ![]()
+
+ The simplest way to define zones is to simply associate the zone
+ name (previously defined in /etc/shorewall/zones) with a network
+ interface. This is done in the /etc/shorewall/interfaces
+ file. The firewall illustrated above has three network interfaces. Where
+ Internet connectivity is through a cable or DSL "Modem", the
+ External Interface will be the Ethernet adapter that
+ is connected to that "Modem" (e.g., eth0)
+ unless you connect via Point-to-Point Protocol over Ethernet (PPPoE) or
+ Point-to-Point Tunneling Protocol (PPTP) in which case the External
+ Interface will be a ppp interface (e.g., ppp0).
+ If you connect via a regular modem, your External Interface will also be
+ ppp0. If you connect using ISDN, you
+ external interface will be ippp0.
+
+ If your external
+ interface is ppp0 or ippp0 then you will want to set CLAMPMSS=yes in
+ /etc/shorewall/shorewall.conf.
+
+ Your Local Interface will be an Ethernet
+ adapter (eth0, eth1
+ or eth2) and will be connected to a hub
+ or switch. Your local computers will be connected to the same switch
+ (note: If you have only a single local system, you can connect the
+ firewall directly to the computer using a cross-over cable).
+
+ Your DMZ Interface will also be an Ethernet
+ adapter (eth0, eth1
+ or eth2) and will be connected to a hub
+ or switch. Your DMZ computers will be connected to the same switch (note:
+ If you have only a single DMZ system, you can connect the firewall
+ directly to the computer using a cross-over cable).
+
+
+ Do not connect the internal and external interface to the same hub
+ or switch except for testing AND you are running Shorewall version 1.4.7
+ or later. When using these recent versions, you can test using this kind
+ of configuration if you specify the arp_filter option in
+ /etc/shorewall/interfaces for all interfaces connected to the common
+ hub/switch. Using such a setup with a production firewall is strongly
+ recommended against.
+
+
+ For the remainder of this Guide, we will assume that:
+
+
+
+ The External Interface is eth0.
+
+
+
+ The Local Interface eth1.
+
+
+
+ The DMZ Interface eth2.
+
+
+
+ The Shorewall default configuration does not define the contents of
+ any zone. To define the above configuration using the /etc/shorewall/interfaces file,
+ that file would might contain:
+
+
+ /etc/shorewall/interfaces
+
+
+
+
+ ZONE
+
+ INTERFACE
+
+ BROADCAST
+
+ OPTIONS
+
+
+
+ net
+
+ eth0
+
+ detect
+
+ rfc1918
+
+
+
+ loc
+
+ eth1
+
+ detect
+
+
+
+
+
+ dmz
+
+ eth2
+
+ detect
+
+
+
+
+
+
+
+ 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:
+
+
+ /etc/shorewall/interfaces
+
+
+
+
+ ZONE
+
+ INTERFACE
+
+ BROADCAST
+
+ OPTIONS
+
+
+
+ net
+
+ eth0
+
+ detect
+
+ rfc1918
+
+
+
+ loc
+
+ eth1
+
+ detect
+
+
+
+
+
+ dmz
+
+ eth2
+
+ detect
+
+ dhcp
+
+
+
+
+
+ You may define more
+ complicated zones using the /etc/shorewall/hosts
+ file but in most cases, that isn't necessary.
+
+
+
+ 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.
+
+
+ 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.0Eor looking at
+ it as a 32-bit integer
+
+ C000020E
+
+
+
+ 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:
+
+
+
+ The number of addresses in the set is a power of 2; and
+
+
+
+ The first address in the set is a multiple of the set size.
+
+
+
+ The first address in the subnet is reserved and is referred to
+ as the subnet address.
+
+
+
+ The last address in the subnet is reserved as the subnet's
+ broadcast address.
+
+
+
+ As you can see by this definition, in each subnet of size n there
+ are (n - 2) usable addresses (addresses that can be assigned to hosts).
+ The first and last address in the subnet are used for the subnet address
+ and subnet broadcast address respectively. Consequently, small
+ subnetworks are more wasteful of IP addresses than are large ones.
+
+ 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:
+
+
+ Natural Logarithms
+
+
+
+
+ n
+
+ log2 n
+
+ (32 - log2 n)
+
+
+
+ 8
+
+ 3
+
+ 29
+
+
+
+ 16
+
+ 4
+
+ 28
+
+
+
+ 32
+
+ 5
+
+ 27
+
+
+
+ 64
+
+ 6
+
+ 26
+
+
+
+ 128
+
+ 7
+
+ 25
+
+
+
+ 256
+
+ 8
+
+ 24
+
+
+
+ 512
+
+ 9
+
+ 23
+
+
+
+ 1024
+
+ 10
+
+ 22
+
+
+
+ 2048
+
+ 11
+
+ 21
+
+
+
+ 4096
+
+ 12
+
+ 20
+
+
+
+ 8192
+
+ 13
+
+ 19
+
+
+
+ 16384
+
+ 14
+
+ 18
+
+
+
+ 32768
+
+ 15
+
+ 17
+
+
+
+ 65536
+
+ 16
+
+ 16
+
+
+
+
+
+ You will notice that the above table also contains a column for
+ (32 - log2 n). That number is the
+ Variable Length Subnet Mask (VLSM) for a network of
+ size n. From the above table, we can derive the following one which is a
+ little easier to use.
+
+
+ VLSM
+
+
+
+
+ Subnet Size
+
+ VLSM
+
+ Subnet Mask
+
+
+
+ 8
+
+ /29
+
+ 255.255.255.248
+
+
+
+ 16
+
+ /28
+
+ 255.255.255.240
+
+
+
+ 32
+
+ /27
+
+ 255.255.255.224
+
+
+
+ 64
+
+ /26
+
+ 255.255.255.192
+
+
+
+ 128
+
+ /25
+
+ 255.255.255.128
+
+
+
+ 256
+
+ /24
+
+ 255.255.255.0
+
+
+
+ 512
+
+ /23
+
+ 255.255.254.0
+
+
+
+ 1024
+
+ /22
+
+ 255.255.252.0
+
+
+
+ 2048
+
+ /21
+
+ 255.255.248.0
+
+
+
+ 4096
+
+ /20
+
+ 255.255.240.0
+
+
+
+ 8192
+
+ /19
+
+ 255.255.224.0
+
+
+
+ 16384
+
+ /18
+
+ 255.255.192.0
+
+
+
+ 32768
+
+ /17
+
+ 255.255.128.0
+
+
+
+ 65536
+
+ /16
+
+ 255.255.0.0
+
+
+
+ 2 ** 24
+
+ /8
+
+ 255.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.192The
+ 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
+
+
+
+
+ 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.
+
+
+ /32 and /0
+
+
+
+
+ Subnet Size
+
+ VLSM Length
+
+ Subnet Mask
+
+ CIDR Notation
+
+
+
+ 1
+
+ 32
+
+ 255.255.255.255
+
+ a.b.c.d/32
+
+
+
+ 32
+
+ 0
+
+ 0.0.0.0
+
+ 0.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.
+Beginning with Shorewall 1.4.6, /sbin/shorewall supports an
+ ipcalc command that automatically calculates information about a
+ [sub]network.
+
+ Example 1:shorewall ipcalc 10.10.10.0/25
+ CIDR=10.10.10.0/25
+ NETMASK=255.255.255.128
+ NETWORK=10.10.10.0
+ BROADCAST=10.10.10.127
+Example 2:shorewall ipcalc 10.10.10.0 255.255.255.128
+ CIDR=10.10.10.0/25
+ NETMASK=255.255.255.128
+ NETWORK=10.10.10.0
+ BROADCAST=10.10.10.127
+
+
+
+ Routing
+
+ One of the purposes of subnetting is that it forms the basis for
+ routing. Here's the routing table on my firewall:
+
+ [root@gateway root]# netstat -nr
+ Kernel IP routing table
+ Destination Gateway Genmask Flags MSS Window irtt Iface
+ 192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas
+ 206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
+ 206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3
+ 192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3
+ 192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
+ 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
+ 206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
+ 192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas
+ 127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
+ 0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0
+ [root@gateway root]#
+
+ The device texas is a GRE tunnel to a peer
+ site in the Dallas, Texas area.
+
+ The first three routes are host routes since
+ they indicate how to get to a single host. In the 'netstat'
+ output this can be seen by the "Genmask" (Subnet Mask) of
+ 255.255.255.255 and the "H" in the Flags column. The remainder
+ are 'net' routes since they tell the kernel
+ how to route packets to a subnetwork. The last route is the
+ default route and the gateway mentioned in that
+ route is called the default gateway.
+
+ When the kernel is trying to send a packet to IP address A, it starts at the top of the routing table and:
+
+
+
+ A is logically ANDed with the
+ 'Genmask' value in the table entry.
+
+
+
+ The result is compared with the 'Destination' value in
+ the table entry.
+
+
+
+ If the result and the 'Destination' value are the
+ same, then:
+
+
+
+ If the 'Gateway' column is non-zero, the packet is
+ sent to the gateway over the interface named in the
+ 'Iface' column.
+
+
+
+ Otherwise, the packet is sent directly to A over the interface named in the
+ 'iface' column.
+
+
+
+
+
+ Otherwise, the above steps are repeated on the next entry in
+ the table.
+
+
+
+ Since the default route matches any IP address (A LAND 0.0.0.0 = 0.0.0.0), packets that don't
+ match any of the other routing table entries are sent to the default
+ gateway which is usually a router at your ISP. Lets take an example.
+ Suppose that we want to route a packet to 192.168.1.5. That address
+ clearly doesn't match any of the host routes in the table but if we
+ logically and that address with 255.255.255.0, the result is 192.168.1.0
+ which matches this routing table entry:
+
+ 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
+
+ So 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.
+
+
+
+ Address Resolution Protocol (ARP)
+
+ When sending packets over Ethernet, IP addresses aren't used.
+ Rather Ethernet addressing is based on Media Access Control
+ (MAC) addresses. Each Ethernet device has it's own unique MAC
+ address which is burned into a PROM on the device during manufacture.
+ You can obtain the MAC of an Ethernet device using the 'ip'
+ utility:
+
+ [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 paquets received by filter
+ 0 paquets 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.
+
+
+
+ RFC 1918
+
+ IP addresses are allocated by the Internet Assigned Number Authority
+ (IANA) who delegates allocations on a geographic basis to Regional
+ Internet Registries (RIRs). For example, allocation for the Americas and
+ for sub-Sahara Africa is delegated to the American Registry for Internet Numbers
+ (ARIN). These RIRs may in turn delegate to national registries. Most of
+ us don't deal with these registrars but rather get our IP addresses
+ from our ISP. It's a fact of life that most of us can't afford
+ as many Public IP addresses as we have devices to assign them to so we
+ end up making use of Private IP addresses. RFC 1918 reserves several IP
+ address ranges for this purpose:
+
+ 10.0.0.0 - 10.255.255.255
+ 172.16.0.0 - 172.31.255.255
+ 192.168.0.0 - 192.168.255.255
+
+ The addresses reserved by RFC 1918 are sometimes referred to as
+ non-routable because the Internet backbone routers don't forward
+ packets which have an RFC-1918 destination address. This is
+ understandable given that anyone can select any of these addresses for
+ their private use.
+
+ When selecting addresses from these ranges, there's a couple
+ of things to keep in mind:
+
+
+
+ As the IPv4 address space becomes depleted, more and more
+ organizations (including ISPs) are beginning to use RFC 1918
+ addresses in their infrastructure.
+
+
+
+ You don't want to use addresses that are being used by
+ your ISP or by another organization with whom you want to establish
+ a VPN relationship.
+
+
+
+ So it's a good idea to check with your ISP to see if they are
+ using (or are planning to use) private addresses before you decide the
+ addresses that you are going to use.
+
+
+ In this document, external "real"
+ IP addresses are of the form 192.0.2.x. 192.0.2.0/24 is reserved by
+ RFC 3330 for use as public IP addresses in printed examples. These
+ addresses are not to be confused with addresses in 192.168.0.0/16; as
+ described above, these addresses are reserved by RFC 1918 for private
+ use.
+
+
+
+
+
+ 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:
+
+
+
+ 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.
+
+
+
+ Non-routed - Your ISP will send
+ traffic to each of your addresses directly.
+
+
+
+ In the subsections that follow, we'll look at each of these
+ separately.
+
+ Before we begin, there is one thing for you to check:
+
+ If you are using the
+ Debian package, please check your shorewall.conf file to ensure that the
+ following are set correctly; if they are not, change them appropriately:
+
+
+
+ NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)
+
+
+
+ IP_FORWARDING=On
+
+
+
+
+ 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.
+
+
+
+ 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 One-to-one NAT.
+
+
+
+ Often a combination of these techniques is used. Each of these
+ will be discussed in the sections that follow.
+
+
+ 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.
+
+
+
+
+
+
+ INTERFACE
+
+ SUBNET
+
+ ADDRESS
+
+
+
+
+
+ eth0
+
+ 192.168.201.0/29
+
+ 192.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.
+
+
+
+ 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:
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+ SOURCE PORT(S)
+
+ ORIGINAL DEST
+
+
+
+
+
+ DNAT
+
+ net
+
+ loc:192.168.201.4
+
+ tcp
+
+ www
+
+ -
+
+ 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.
+
+
+
+ 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 A andissues an ARP "who has"
+ request for an address in the subnetwork defined by M, the firewall will respond (with the MAC
+ if the firewall interface) to H.
+
+
+
+ Let us 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.
+
+
+
+
+
+ ADDRESS
+
+ EXTERNAL
+
+ INTERFACE
+
+ HAVE ROUTE
+
+
+
+
+
+ 192.0.2.177
+
+ eth2
+
+ eth0
+
+ No
+
+
+
+ 192.0.2.178
+
+ eth2
+
+ eth0
+
+ No
+
+
+
+
+
+ Because the HAVE ROUTE column contains No, Shorewall will add
+ host routes thru eth2 to 192.0.2.177 and 192.0.2.178. The ethernet
+ interfaces on DMZ 1 and DMZ 2 should be configured to have the IP
+ addresses shown but should have the same default gateway as the
+ firewall itself -- namely 192.0.2.254. In other words, they should be
+ configured just like they would be if they were parallel to the
+ firewall rather than behind it.
+
+
+ Do not add the Proxy ARP'ed
+ address(es) (192.0.2.177 and 192.0.2.178 in the above example) to
+ the external interface (eth0 in this example) of the firewall.
+
+
+ A word of warning is in order here. ISPs typically configure
+ their routers with a long ARP cache timeout. If you move a system from
+ parallel to your firewall to behind your firewall with Proxy ARP, it
+ will probably be HOURS before that system can communicate with the
+ internet. There are a couple of things that you can try:
+
+
+
+ (Courtesy of Bradey Honsinger) A reading of Stevens'
+ TCP/IP Illustrated, Vol 1 reveals that a
+
+
+ "gratuitous" ARP packet should cause the ISP's
+ router to refresh their ARP cache (section 4.7). A gratuitous
+ ARP is simply a host requesting the MAC address for its own IP;
+ in addition to ensuring that the IP address isn't a
+ duplicate,...
+
+ "if the host sending the gratuitous ARP has just
+ changed its hardware address..., this packet causes any other
+ host...that has an entry in its cache for the old hardware
+ address to update its ARP cache entry accordingly."
+
+
+ Which is, of course, exactly what you want to do when you
+ switch a host from being exposed to the Internet to behind
+ Shorewall using proxy ARP (or one-to-one NAT for that matter).
+ Happily enough, recent versions of Redhat's iputils package
+ include "arping", whose "-U" flag does just that:
+
+ arping -U -I <net if> <newly proxied IP>
+ arping -U -I eth0 66.58.99.83 # for exampleStevens
+ goes on to mention that not all systems respond correctly to
+ gratuitous ARPs, but googling for "arping -U" seems to
+ support the idea that it works most of the time.
+
+
+
+ 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 ISP's gateway (which we will
+ assume is 192.0.2.254):
+
+ ping 192.0.2.254
+
+ We can now observe the tcpdump output:
+
+ 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
+ 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo replyNotice
+ 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.
+
+
+
+ One-to-one NAT
+
+ With one-to-one NAT, you assign local systems RFC 1918 addresses
+ then establish a one-to-one mapping between those addresses and public
+ IP addresses. For outgoing connections SNAT (Source Network Address
+ Translation) occurs and on incoming connections DNAT (Destination
+ Network Address Translation) occurs. Let's go back to our earlier
+ example involving your daughter's web server running on system
+ Local 3.
+
+ ![]()
+
+ Recall that in this setup, the local network is using SNAT and
+ is sharing the firewall external IP (192.0.2.176) for outbound
+ connections. This is done with the following entry in
+ /etc/shorewall/masq:
+
+
+
+
+
+ INTERFACE
+
+ SUBNET
+
+ ADDRESS
+
+
+
+
+
+ eth0
+
+ 192.168.201.0/29
+
+ 192.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.
+
+
+
+
+
+ EXTERNAL
+
+ INTERFACE
+
+ INTERNAL
+
+ ALL INTERFACES
+
+ LOCAL
+
+
+
+
+
+ 192.0.2.179
+
+ eth0
+
+ 192.168.201.4
+
+ No
+
+ No
+
+
+
+
+
+ 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:
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+ SOURCE PORT(S)
+
+ ORIGINAL DEST
+
+
+
+
+
+ ACCEPT
+
+ net
+
+ loc:192.168.201.4
+
+ tcp
+
+ www
+
+
+
+
+
+
+
+
+
+ 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 one-to-one NAT,
+ it will probably be HOURS before that system can communicate with the
+ internet. There are a couple of things that you can try:
+
+
+
+ (Courtesy of Bradey Honsinger) A reading of Stevens'
+ TCP/IP Illustrated, Vol 1 reveals that a
+
+
+ "gratuitous" ARP packet should cause the ISP's
+ router to refresh their ARP cache (section 4.7). A gratuitous
+ ARP is simply a host requesting the MAC address for its own IP;
+ in addition to ensuring that the IP address isn't a
+ duplicate,...
+
+ "if the host sending the gratuitous ARP has just
+ changed its hardware address..., this packet causes any other
+ host...that has an entry in its cache for the old hardware
+ address to update its ARP cache entry accordingly."
+
+
+ Which is, of course, exactly what you want to do when you
+ switch a host from being exposed to the Internet to behind
+ Shorewall using one-to-one NAT. Happily enough, recent versions of
+ Redhat's iputils package include "arping", whose
+ "-U" flag does just that:
+
+ arping -U -I <net if> <newly proxied IP>
+ arping -U -I eth0 66.58.99.83 # for exampleStevens
+ goes on to mention that not all systems respond correctly to
+ gratuitous ARPs, but googling for "arping -U" seems to
+ support the idea that it works most of the time.
+
+
+
+ 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 ISP's gateway (which we will
+ assume is 192.0.2.254):
+
+ ping 192.0.2.254
+
+ We can now observe the tcpdump output:
+
+ 13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
+ 13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo replyNotice
+ 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.
+
+
+
+
+ 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.
+
+
+ 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:
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+
+
+
+
+ ACCEPT
+
+ net
+
+ dmz
+
+ icmp
+
+ echo-request
+
+
+
+ ACCEPT
+
+ net
+
+ loc
+
+ icmp
+
+ echo-request
+
+
+
+ ACCEPT
+
+ dmz
+
+ loc
+
+ icmp
+
+ echo-request
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz
+
+ icmp
+
+ echo-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:
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+ COMMENTS
+
+
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.178
+
+ tcp
+
+ smtp
+
+ # Mail from the Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.178
+
+ tcp
+
+ pop3
+
+ # Pop3 from the Internet
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.178
+
+ tcp
+
+ smtp
+
+ # Mail from the Local Network
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.178
+
+ tcp
+
+ pop3
+
+ # Pop3 from the Local Network
+
+
+
+ ACCEPT
+
+ fw
+
+ dmz:192.0.2.178
+
+ tcp
+
+ smtp
+
+ # Mail from the firewall
+
+
+
+ ACCEPT
+
+ dmz:192.0.2.178
+
+ net
+
+ tcp
+
+ smtp
+
+ # Mails to Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ tcp
+
+ http
+
+ # WWW from the Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ tcp
+
+ https
+
+ # Secure HTTP from the Internet
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.177
+
+ htp
+
+ https
+
+ # Secure HTTP from the Local Network
+
+
+
+
+
+ If you run a public DNS server on 192.0.2.177, you would need to
+ add the following rules:
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+ COMMENTS
+
+
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ udp
+
+ domain
+
+ # UDP DNS from the Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ tcp
+
+ domain
+
+ # TCP DNS from the Internet
+
+
+
+ ACCEPT
+
+ fw
+
+ dmz:192.0.2.177
+
+ udp
+
+ domain
+
+ # UDP DNS from the firewall
+
+
+
+ ACCEPT
+
+ fw
+
+ dmz:192.0.2.177
+
+ tcp
+
+ domain
+
+ # TCP DNS from the firewall
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.177
+
+ udp
+
+ domain
+
+ # UDP DNS from the Local Network
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.177
+
+ tcp
+
+ domain
+
+ # TCP DNS from the Local Network
+
+
+
+ ACCEPT
+
+ dmz:192.0.2.177
+
+ net
+
+ udp
+
+ domain
+
+ # UDP DNS to the Internet
+
+
+
+ ACCEPT
+
+ dmz:192.0.2.177
+
+ net
+
+ tcp
+
+ domain
+
+ # 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.
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+ COMMENTS
+
+
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz
+
+ tcp
+
+ ssh
+
+ # SSH to the DMZ
+
+
+
+ ACCEPT
+
+ loc
+
+ fw
+
+ tcp
+
+ ssh
+
+ # SSH to the firewall
+
+
+
+
+
+
+
+ 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).
+
+
+
+
+
+ ZONE
+
+ INTERFACE
+
+ BROADCAST
+
+ OPTIONS
+
+
+
+
+
+ net
+
+ eth0
+
+ detect
+
+ norfc1918,routefilter
+
+
+
+ loc
+
+ eth1
+
+ detect
+
+
+
+
+
+ dmz
+
+ eth2
+
+ detect
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+ ZONE
+
+ INTERFACE
+
+ BROADCAST
+
+ OPTIONS
+
+
+
+
+
+ net
+
+ eth0
+
+ 192.0.2.255
+
+ norfc1918,routefilter
+
+
+
+ loc
+
+ eth1
+
+ 192.168.201.7
+
+
+
+
+
+ dmz
+
+ eth2
+
+ 192.168.202.7
+
+
+
+
+
+
+
+ /etc/shorewall/masq - Local Subnet
+
+
+
+
+
+ INTERFACE
+
+ SUBNET
+
+ ADDRESS
+
+
+
+
+
+ eth0
+
+ 192.168.201.0/29
+
+ 192.0.2.176
+
+
+
+
+
+ /etc/shorewall/proxyarp - DMZ
+
+
+
+
+
+ ADDRESS
+
+ EXTERNAL
+
+ INTERFACE
+
+ HAVE ROUTE
+
+
+
+
+
+ 192.0.2.177
+
+ eth2
+
+ eth0
+
+ No
+
+
+
+ 192.0.2.178
+
+ eth2
+
+ eth0
+
+ No
+
+
+
+
+
+ /etc/shorewall/nat- Daughter's System
+
+
+
+
+
+ EXTERNAL
+
+ INTERFACE
+
+ INTERNAL
+
+ ALL INTERFACES
+
+ LOCAL
+
+
+
+
+
+ 192.0.2.179
+
+ eth0
+
+ 192.168.201.4
+
+ No
+
+ No
+
+
+
+
+
+ /etc/shorewall/rules
+
+
+
+
+
+ ACTION
+
+ SOURCE
+
+ DESTINATION
+
+ PROTOCOL
+
+ PORT(S)
+
+ COMMENTS
+
+
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.178
+
+ tcp
+
+ smtp
+
+ # Mail from the Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.178
+
+ tcp
+
+ pop3
+
+ # Pop3 from the Internet
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.178
+
+ tcp
+
+ smtp
+
+ # Mail from the Local Network
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.178
+
+ tcp
+
+ pop3
+
+ # Pop3 from the Local network
+
+
+
+ ACCEPT
+
+ fw
+
+ dmz:192.0.2.178
+
+ tcp
+
+ smtp
+
+ # Mail from the firewall
+
+
+
+ ACCEPT
+
+ dmz:192.0.2.178
+
+ net
+
+ tcp
+
+ smtp
+
+ # Mails to Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ tcp
+
+ http
+
+ # WWW from the Net
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ tcp
+
+ https
+
+ # Secure HTTP from the Net
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.177
+
+ htp
+
+ https
+
+ # Secure HTTP from the Local Network
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ udp
+
+ domain
+
+ # UDP DNS from the Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz:192.0.2.177
+
+ tcp
+
+ domain
+
+ # TCP DNS from the Internet
+
+
+
+ ACCEPT
+
+ fw
+
+ dmz:192.0.2.177
+
+ udp
+
+ domain
+
+ # UDP DNS from the firewall
+
+
+
+ ACCEPT
+
+ fw
+
+ dmz:192.0.2.177
+
+ tcp
+
+ domain
+
+ # TCP DNS depuis le firewall
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.177
+
+ udp
+
+ domain
+
+ # UDP DNS depuis le Réseau Local
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz:192.0.2.177
+
+ tcp
+
+ domain
+
+ # TCP DNS from the Local Network
+
+
+
+ ACCEPT
+
+ dmz:192.0.2.177
+
+ net
+
+ udp
+
+ domain
+
+ # UDP DNS to the Internet
+
+
+
+ ACCEPT
+
+ dmz:192.0.2.177
+
+ net
+
+ tcp
+
+ domain
+
+ # TCP DNS to the Internet
+
+
+
+ ACCEPT
+
+ net
+
+ dmz
+
+ icmp
+
+ echo-request
+
+ Ping
+
+
+
+ ACCEPT
+
+ dmz
+
+ net
+
+ icmp
+
+ echo-request
+
+ "
+
+
+
+ ACCEPT
+
+ dmz
+
+ loc
+
+ icmp
+
+ echo-request
+
+ "
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz
+
+ icmp
+
+ echo-request
+
+ "
+
+
+
+ ACCEPT
+
+ loc
+
+ dmz
+
+ tcp
+
+ ssh
+
+ # SSH to the DMZ
+
+
+
+ ACCEPT
+
+ loc
+
+ fw
+
+ tcp
+
+ ssh
+
+ # SSH to the firewall
+
+
+
+
+
+
+
+
+ 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.0/8;
+ 192.0.2.176/32;
+ 192.0.2.178/32;
+ 192.0.2.179/32;
+ 192.0.2.180/32; };
+ #
+ # If this server can't complete the request, it should use outside
+ # servers to do so
+ #
+ recursion yes;
+
+ zone "." in {
+ type hint;
+ file "int/root.cache";
+ };
+
+ zone "foobar.net" in {
+ type master;
+ notify no;
+ allow-update { none; };
+ file "int/db.foobar";
+ };
+
+ zone "0.0.127.in-addr.arpa" in {
+ type master;
+ notify no;
+ allow-update { none; };
+ file "int/db.127.0.0";
+ };
+
+ zone "201.168.192.in-addr.arpa" in {
+ type master;
+ notify no;
+ allow-update { none; };
+ file "int/db.192.168.201";
+ };
+
+ zone "202.168.192.in-addr.arpa" in {
+ type master;
+ notify no;
+ allow-update { none; };
+ file "int/db.192.168.202";
+ };
+
+ zone "176.2.0.192.in-addr.arpa" in {
+ type master;
+ notify no;
+ allow-update { none; };
+ file "db.192.0.2.176";
+ };
+
+ 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 - Reverse zone 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 - 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 - Reverse zone for Daughter's public web server
+
+ ; ############################################################
+; 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 - 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 network. 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 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>.
+
+
+
+ Starting and Stopping the 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.
+
+
+ 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 an
+ alternate configuration and test it using the
+ "shorewall try"
+ command.
+
+
+
\ No newline at end of file
diff --git a/Shorewall-docs/starting_and_stopping_shorewall.htm b/Shorewall-docs/starting_and_stopping_shorewall.htm
index 87d11131d..f13f33e81 100644
--- a/Shorewall-docs/starting_and_stopping_shorewall.htm
+++ b/Shorewall-docs/starting_and_stopping_shorewall.htm
@@ -208,9 +208,7 @@ for you.
The Shorewall State Diargram is depicted
below.
-
+
+