From b85e238754318999227fd6524fcfb2b93920d031 Mon Sep 17 00:00:00 2001 From: teastep Date: Thu, 25 Dec 2003 00:12:43 +0000 Subject: [PATCH] Convert shorewall_setup_guide.htm to XML Docbook git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@946 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/shorewall_setup_guide.htm | 2377 ------------ Shorewall-docs/shorewall_setup_guide.xml | 3314 +++++++++++++++++ .../starting_and_stopping_shorewall.htm | 4 +- 3 files changed, 3315 insertions(+), 2380 deletions(-) delete mode 100644 Shorewall-docs/shorewall_setup_guide.htm create mode 100644 Shorewall-docs/shorewall_setup_guide.xml 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:

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

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

-

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

-

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

-

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

-

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

- -

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

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

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

-

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

-

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

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

The above policy will:

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

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

-

3.0 Network Interfaces

-

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

-

In this diagram:

- -

-

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

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

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

-

Example:

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

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

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

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

-

4.0 Addressing, Subnets and -Routing

-

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

-

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

-

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

-

4.1 IP Addresses

-

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

-
-

C0.00.02.0E

-
-

or looking at it as a 32-bit integer

-
-

C000020E

-
-

4.2 Subnets

-

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

-
-

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

-

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

-

Class C - netmask 255.255.255.0, size = 256

-
-

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

-

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

-

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

-
    -
  1. -

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

    -
    2. -
  2. -

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

    -
    3. -
  3. -

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

    -
    4. -
  4. -

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

    -
    5. -
-

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

-

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

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

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

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

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

-

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

-
-

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

-
-

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

-

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

-

Example:

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

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

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

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

-

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

-

Example: 192.0.2.65/29

-

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

-

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:

- -

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:

-
-
- -
-
-

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:

-
-
-
    -
  1. -

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

    -
    2. -
  2. -

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

    -
    3. -
-
-
-

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

-

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

- -
-
-

5.1 Routed

-
-
-

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

-
-
-

-
-
-

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

-
-
-

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

-
-
-

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

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

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

-
-
-

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

-
-
-

5.2 Non-routed

-
-
-

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

-
-
-

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

-
-
-

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

-
-
-

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

-
-
- -
-
-

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

-
-
-

 5.2.1 SNAT

-
-
-

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

-
-
-

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

-
-
-

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

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

-
-
-

5.2.2 DNAT

-
-
-

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

-
-
-

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

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

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

-
-
-

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

-
-
-

5.2.3 Proxy ARP

-
-
-

The idea behind proxy ARP is that:

-
-
- -
-
-

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.
-
-
- - - - - - - - - - - - - - - - - - - - - -
ADDRESSINTERFACEEXTERNALHAVE ROUTE
192.0.2.177eth2eth0No
192.0.2.178eth2eth0No
-
-
-
-

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

-

The ethernet interfaces on DMZ 1 and DMZ 2 should be -configured to have the IP addresses shown but should have the same -default gateway as the firewall itself -- namely 192.0.2.254. In other -words, they should be configured just like they would be if they were -parallel to the firewall rather than behind it.
-

-

NOTE: Do not add the Proxy ARP'ed -address(es) (192.0.2.177 and 192.0.2.178 in the above example)  to -the external interface (eth0 in this example) of the firewall.
-

-
-
-
-

-
-
-
-

A word of warning is in order here. ISPs typically -configure their routers with a long ARP cache timeout. If you move a -system from parallel to your firewall to behind your firewall with -Proxy -ARP, it will probably be HOURS before that system can communicate with -the internet. There are a couple of things that you can try:
-

-
    -
  1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP -Illustrated, Vol 1 reveals that a
    -
    -"gratuitous" ARP packet should cause the ISP's router to refresh their -ARP cache (section 4.7). A gratuitous ARP is simply a host requesting -the MAC address for its own IP; in addition to ensuring that the IP -address isn't a duplicate,...
    -
    -"if the host sending the gratuitous ARP has just changed its hardware -address..., this packet causes any other host...that has an entry in -its cache for the old hardware address to update its ARP cache entry -accordingly."
    -
    -Which is, of course, exactly what you want to do when you switch a host -from being exposed to the Internet to behind Shorewall using proxy ARP -(or 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.
    -
    -
    2. -
  2. You can call your ISP and ask them to purge the stale ARP cache -entry but many either can't or won't purge individual -entries.
    3. -
-You can determine if your ISP's gateway ARP cache is stale using ping -and tcpdump. Suppose that we suspect that the gateway -router has a stale ARP cache entry for 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 reply
-
-
-

Notice that the source MAC address in the echo request -is different from the destination MAC address in the echo reply!! -In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 -NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other -words, the gateway's ARP cache still associates 192.0.2.177 with -the NIC in DMZ 1 rather than with the firewall's eth0.

-
-
-

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

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

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

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

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

-
-
-

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

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

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

-
    -
  1. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP -Illustrated, Vol 1 reveals that a
    -
    -"gratuitous" ARP packet should cause the ISP's router to refresh their -ARP cache (section 4.7). A gratuitous ARP is simply a host requesting -the MAC address for its own IP; in addition to ensuring that the IP -address isn't a duplicate,...
    -
    -"if the host sending the gratuitous ARP has just changed its hardware -address..., this packet causes any other host...that has an entry in -its cache for the old hardware address to update its ARP cache entry -accordingly."
    -
    -Which is, of course, exactly what you want to do when you switch a host -from being exposed to the Internet to behind Shorewall using proxy ARP -(or 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.
    -
    -
    2. -
  2. You can call your ISP and ask them to purge the stale ARP cache -entry but many either can't or won't purge individual entries.
    3. -
-You can determine if your ISP's gateway ARP cache is stale using ping -and tcpdump. Suppose that we suspect that the gateway -router has a stale ARP cache entry for 209.0.2.179. On the firewall, -run tcpdump as follows:
-
-
	tcpdump -nei eth0 icmp
-
-
-

Now from the 192.168.201.4, ping the ISP's gateway -(which we will assume is 192.0.2.254):

-
-
-
	ping 192.0.2.254
-
-
-
-

We can now observe the tcpdump output:

-
-
-
	13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.179 > 192.0.2.254: icmp: echo request (DF)
	13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.179 : icmp: echo reply
-
-
-

Notice that the source MAC address in the echo request -is different from the destination MAC address in the echo reply!! -In this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 -NIC while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other -words, the gateway's ARP cache still associates 192.0.2.179 with -the NIC in the local zone rather than with the firewall's eth0.

-
-

5.3 Rules

-
-
-

    With the default policies, your local -systems (Local 1-3) can access any servers on the internet and the DMZ -can't access any other host (including the firewall). With the -exception of -DNAT rules which cause address translation and -allow the translated connection request to pass through the firewall, -the way to allow connection requests through your firewall is to -use ACCEPT rules.

-
-
-

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

-
-
-

You probably want to allow ping between your zones:

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

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

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
ACCEPTnetdmz:192.0.2.177tcphttp# WWW from the Net
ACCEPTnetdmz:192.0.2.177tcphttps# Secure HTTP from the Net
ACCEPTlocdmz:192.0.2.177tcphttps# Secure HTTP from the Local Net
-
-
-
-

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

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

You probably want some way to communicate with your -firewall and DMZ systems from the local network -- I recommend SSH -which -through its scp utility can also do publishing and software update -distribution.

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
ACCEPTlocdmztcpssh# SSH to the DMZ
ACCEPTlocfwtcpssh# SSH to the Firewall
-
-
-
-

5.4 Odds and Ends

-
-
-

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

-
-
-

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

-
-
-

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

-
-
-

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

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
ZoneInterfaceBroadcastOptions
neteth0detectnorfc1918,routefilter
loceth1detect 
dmzeth2detect 
-
-
-
-

The setup described here requires that your network -interfaces be brought up before Shorewall can start. This opens a short -window during which you have no firewall protection. If you replace -'detect' with the actual broadcast addresses in the entries above, you -can bring up Shorewall before you bring up your network interfaces.

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
ZoneInterfaceBroadcastOptions
neteth0192.0.2.255norfc1918,routefilter
loceth1192.168.201.7 
dmzeth2192.168.202.7 
-
-
-
-

/etc/shorewall/masq - Local subnet

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

/etc/shorewall/proxyarp - DMZ

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

/etc/shorewall/nat- Daughter's System

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

/etc/shorewall/rules

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDESTINATIONPROTOCOLPORTCOMMENTS
ACCEPTnetdmz:192.0.2.178tcpsmtp# Mail from the Internet
ACCEPTnetdmz:192.0.2.178tcppop3# Pop3 from the Internet
ACCEPTlocdmz:192.0.2.178tcpsmtp# Mail from the Local Network
ACCEPTlocdmz:192.0.2.178tcppop3# Pop3 from the Local Network
ACCEPTfwdmz:192.0.2.178tcpsmtp# Mail from the Firewall
ACCEPTdmz:192.0.2.178nettcpsmtp# Mail to the Internet
ACCEPTnetdmz:192.0.2.178tcphttp# WWW from the Net
ACCEPTnetdmz:192.0.2.178tcphttps# Secure HTTP from the Net
ACCEPTlocdmz:192.0.2.178tcphttps# Secure HTTP from the Local Net
ACCEPTnetdmz:192.0.2.177udpdomain# UDP DNS from the Internet
ACCEPTnetdmz:192.0.2.177tcpdomain# TCP DNS from the internet
ACCEPTfwdmz:192.0.2.177udpdomain# UDP DNS from firewall
ACCEPTfwdmz:192.0.2.177tcpdomain# TCP DNS from firewall
ACCEPTlocdmz:192.0.2.177udpdomain# UDP DNS from the local Net
ACCEPTlocdmz:192.0.2.177tcpdomain# TCP DNS from the local Net
ACCEPTdmz:192.0.2.177netudpdomain# UDP DNS to the Internet
ACCEPTdmz:192.0.2.177nettcpdomain# TCP DNS to the Internet
ACCEPTnetdmzicmpecho-request# Ping
ACCEPTnetlocicmpecho-request#  "
ACCEPTdmzlocicmpecho-request# "
ACCEPTlocdmzicmpecho-request# "
ACCEPTlocdmztcpssh# SSH to the DMZ
ACCEPTlocfwtcpssh# SSH to the Firewall
-
-
-
-

6.0 DNS

-
-
-

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

-
-
-

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

-
-
-

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

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

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

view "internal" {
	#
	# These are the clients that see this view
	#
	match-clients { 192.168.201.0/29;
			192.168.202.0/29;
			127.0.0.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 installation procedure -configures your system to start Shorewall at system boot.

-
-
-

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

-
-
-

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

-
-
-

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

-
-

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

-
(State Diagram)
+
+