diff --git a/Shorewall-docs2/shorewall_setup_guide.xml b/Shorewall-docs2/shorewall_setup_guide.xml index c103901d6..78f1caeb3 100644 --- a/Shorewall-docs2/shorewall_setup_guide.xml +++ b/Shorewall-docs2/shorewall_setup_guide.xml @@ -15,7 +15,7 @@ - 2004-07-31 + 2004-10-24 2001-2004 @@ -29,7 +29,8 @@ 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. + GNU Free Documentation + License. @@ -60,8 +61,8 @@ 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 + 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 . @@ -81,8 +82,9 @@ - Linux - Version of dos2unix + Linux Version + of dos2unix @@ -96,18 +98,25 @@ 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.Note to Debian UsersIf - you install using the .deb, you will find that your /etc/shorewall directory is empty. This is - intentional. The released configuration file skeletons may be found on - your system in the directory /usr/share/doc/shorewall/default-config. - Simply copy the files you need from that directory to /etc/shorewall and modify the copies.Note - that you must copy /usr/share/doc/shorewall/default-config/shorewall.conf - and /usr/share/doc/shorewall/default-config/modules to /etc/shorewall even if you do not modify - those files. + Skeleton files are created during the Shorewall Installation Process. + Note to Debian Users + + If you install using the .deb, you will find that your /etc/shorewall directory is empty. This + is intentional. The released configuration file skeletons may be found + on your system in the directory /usr/share/doc/shorewall/default-config. + Simply copy the files you need from that directory to /etc/shorewall and modify the + copies. + + Note that you must copy /usr/share/doc/shorewall/default-config/shorewall.conf + and /usr/share/doc/shorewall/default-config/modules to /etc/shorewall even if you do not modify + those files. + As each file is introduced, I suggest that you look through the actual file on your system -- each file contains detailed configuration @@ -125,7 +134,8 @@ Name - Description + Description @@ -153,18 +163,21 @@ url="Documentation.htm#Zones">/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. + 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. + 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. @@ -172,13 +185,15 @@ You express your default policy for connections from one zone to - another zone in the /etc/shorewall/policy + another zone in the /etc/shorewall/policy file. You define exceptions to those default policies in the - /etc/shorewall/rules. + /etc/shorewall/rules. @@ -201,15 +216,15 @@ - 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 + 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. + That rule is expressed in terms of the client's zone and the server's + zone. @@ -218,14 +233,16 @@ 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. + then establishes its own separate connection from the firewall to zone + B. For each connection request entering the firewall, the request is first checked against the /etc/shorewall/rules file. If no rule in that file matches the connection request then the first policy in /etc/shorewall/policy that matches the request is applied. If that policy is REJECT or DROP the request is first - checked against the rules in /etc/shorewall/common.def. + checked against the rules in + /etc/shorewall/common.def. The default /etc/shorewall/policy file has the following policies: @@ -247,7 +264,8 @@ all all REJECT info 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). + url="shorewall_logging.html">here is a description of log + levels). @@ -260,14 +278,14 @@ all all REJECT info - At this point, edit your /etc/shorewall/policy and - make any changes that you wish. + At this point, edit your /etc/shorewall/policy + and make any changes that you wish.
Network Interfaces - For the remainder of this guide, we'll refer to the following + 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. @@ -282,11 +300,13 @@ all all REJECT info - The Local Zone consists of systems Local 1, Local 2 and Local 3. + The Local Zone consists of systems Local 1, Local 2 and Local + 3. - All systems from the ISP outward comprise the Internet Zone. + All systems from the ISP outward comprise the Internet + Zone. @@ -294,8 +314,9 @@ all all REJECT info 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 + 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., 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. + 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. + 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, @@ -323,35 +347,39 @@ all all REJECT info 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). + class="devicefile">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. + 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 External Interface is eth0. - The Local Interface eth1. + The Local Interface eth1. - The DMZ Interface eth2. + The DMZ Interface eth2. @@ -386,14 +414,14 @@ loc eth2 detect You may define more complicated zones using the /etc/shorewall/hosts file - but in most cases, that isn't necessary. + 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 + 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. @@ -404,7 +432,7 @@ loc eth2 detect 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, + Know about Addressing & Routing, Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
@@ -413,7 +441,8 @@ loc eth2 detect 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: + 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 @@ -450,10 +479,10 @@ loc eth2 detect (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. + 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 @@ -465,7 +494,8 @@ loc eth2 detect - The first address in the set is a multiple of the set size. + The first address in the set is a multiple of the set + size. @@ -474,7 +504,7 @@ loc eth2 detect - The last address in the subnet is reserved as the subnet's + The last address in the subnet is reserved as the subnet's broadcast address. @@ -483,7 +513,8 @@ loc eth2 detect 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. + 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 @@ -761,10 +792,11 @@ loc eth2 detect 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. + 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 + 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 @@ -777,10 +809,11 @@ loc eth2 detect 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: + 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 @@ -806,7 +839,8 @@ loc eth2 detect - Broadcast Address: + Broadcast + Address: 10.10.10.127 @@ -863,14 +897,19 @@ loc eth2 detectSo 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. + 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. + A Shorewall user has contributed a useful + graphical summary of the above information. + + 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. 192.0.2.65/29 @@ -880,7 +919,8 @@ loc eth2 detect Beginning with Shorewall 1.4.6, /sbin/shorewall supports an ipcalc - command that automatically calculates information about a [sub]network. + command that automatically calculates information about a + [sub]network. Using the <command>ipcalc </command>command @@ -908,7 +948,7 @@ loc eth2 detect Routing One of the purposes of subnetting is that it forms the basis for - routing. Here's the routing table on my firewall (compressed for + routing. Here's the routing table on my firewall (compressed for PDF): [root@gateway root]# netstat -nr @@ -939,7 +979,8 @@ Destination Gateway Genmask Flgs MSS Win irtt Iface 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: + role="bold">A, it starts at the top of the routing table + and: @@ -978,11 +1019,11 @@ Destination Gateway Genmask Flgs MSS Win irtt Iface Since the default route matches any IP address (A LAND 0.0.0.0 = 0.0.0.0), packets that don't + role="bold">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 + 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: @@ -996,23 +1037,23 @@ Destination Gateway Genmask Flgs MSS Win irtt Iface 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. + 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: + 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 +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 @@ -1021,8 +1062,8 @@ inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0 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 + 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: @@ -1044,10 +1085,10 @@ tcpdump: listening on eth2 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: + 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 @@ -1058,12 +1099,12 @@ tcpdump: listening 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. + 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.
@@ -1074,26 +1115,26 @@ tcpdump: listening on eth2 (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: + url="http://www.arin.net/">American Registry for Internet + Numbers (ARIN). These RIRs may in turn delegate to national + registries. Most of us don't deal with these registrars but rather get + our IP addresses from our ISP. It's a fact of life that most of us can't + afford as many Public IP addresses as we have devices to assign them to + so we end up making use of Private IP addresses. RFC 1918 reserves + several IP address ranges for this purpose: 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. + 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: + When selecting addresses from these ranges, there's a couple of + things to keep in mind: @@ -1103,23 +1144,23 @@ tcpdump: listening on eth2 - 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. + 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 + 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. + 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.
@@ -1138,7 +1179,7 @@ tcpdump: listening on eth2 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. + the IP address of your firewall/router's external interface. @@ -1147,7 +1188,7 @@ tcpdump: listening on eth2 - In the subsections that follow, we'll look at each of these + In the subsections that follow, we'll look at each of these separately. Before we begin, there is one thing for you to check: @@ -1171,13 +1212,13 @@ tcpdump: listening on eth2
Routed - Let's assume that your ISP has assigned you the subnet + 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. + 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. @@ -1194,7 +1235,7 @@ tcpdump: listening on eth2 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 + 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: @@ -1204,21 +1245,22 @@ 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. + 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 + 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. + 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.
@@ -1229,17 +1271,18 @@ Destination Gateway Genmask Flags MSS Window irtt Iface 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 + 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. + 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 + 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. @@ -1271,18 +1314,19 @@ Destination Gateway Genmask Flags MSS Window irtt Iface 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. + 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. + 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. @@ -1293,13 +1337,13 @@ Destination Gateway Genmask Flags MSS Window irtt Iface 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). + 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 + SNAT is configured in Shorewall using the /etc/shorewall/masq file. @@ -1328,25 +1372,25 @@ eth0 192.168.201.0/29 192.0.2.176 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: + /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST DNAT net loc:192.168.201.4 tcp www - 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. + 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. + 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.
@@ -1358,8 +1402,8 @@ DNAT net loc:192.168.201.4 tcp www 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 + role="bold">A), and is assigned the same netmask + (M) as the firewall's external interface. @@ -1380,18 +1424,19 @@ DNAT net loc:192.168.201.4 tcp www For a more complete description of how Proxy ARP works, please - see the Shorewall Proxy Documentation. + see the Shorewall Proxy + Documentation. 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 + 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 firewall. That address and netmask isn't relevant - just be sure + it doesn't overlap another subnet that you've defined. @@ -1412,9 +1457,9 @@ DNAT net loc:192.168.201.4 tcp www 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. + 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 @@ -1425,30 +1470,31 @@ DNAT net loc:192.168.201.4 tcp www - (Courtesy of Bradey Honsinger) A reading of Stevens' - TCP/IP Illustrated, Vol 1 reveals that a + (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 + 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,... + 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. + 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 + 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 <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 @@ -1458,19 +1504,19 @@ DNAT net loc:192.168.201.4 tcp www 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. + 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: + 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 + 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 @@ -1478,15 +1524,15 @@ DNAT net loc:192.168.201.4 tcp www 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) + 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 + 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: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. + gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1 + rather than with the firewall's eth0.
@@ -1496,9 +1542,9 @@ DNAT net loc:192.168.201.4 tcp www 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. + Network Address Translation) occurs. Let's go back to our earlier + example involving your daughter's web server running on system Local + 3. @@ -1514,20 +1560,22 @@ 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. + 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. + 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: + to use a DNAT rule for you daughter's web server -- you would rather + just use an ACCEPT rule: #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT(S) PORT(S) DEST @@ -1541,29 +1589,30 @@ ACCEPT net loc:192.168.201.4 tcp www - (Courtesy of Bradey Honsinger) A reading of Stevens' - TCP/IP Illustrated, Vol 1 reveals that a + (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 + 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,... + 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. + 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 + Redhat's iputils package include arping, whose -U flag does just that: - arping -U -I <net if> <newly proxied IP> + 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 @@ -1573,19 +1622,19 @@ ACCEPT net loc:192.168.201.4 tcp www 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. + 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: + 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 + 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 @@ -1593,15 +1642,15 @@ ACCEPT net loc:192.168.201.4 tcp www 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) + 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 + 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: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. + gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1 + rather than with the firewall's eth0.
@@ -1611,15 +1660,15 @@ ACCEPT net loc:192.168.201.4 tcp www 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. + 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(S) and ORIG. DEST. Columns aren't used - in this section, they won't be shown + Since the SOURCE PORT(S) and ORIG. DEST. Columns aren't used in + this section, they won't be shown You probably want to allow ping between your zones: @@ -1631,8 +1680,8 @@ 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: + 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 DEST PROTO DEST COMMENTS # PORT(S) @@ -1680,7 +1729,8 @@ ACCEPT dmz:192.0.2.177 net tcp domain #TCPP DNS to 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. + scp utility can also do publishing and software update + distribution. #ACTION SOURCE DEST PROTO DEST COMMENTS # PORT(S) @@ -1695,19 +1745,20 @@ ACCEPT net fw tcp ssh #SSH to the 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. + 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 + 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 + 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 + 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 @@ -1720,9 +1771,10 @@ 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. + 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 rfc1918 @@ -1740,7 +1792,7 @@ eth0 192.168.201.0/29 192.0.2.176 192.0.2.177 eth2 eth0 No 192.0.2.178 eth2 eth0 No - /etc/shorewall/nat- Daughter's System + /etc/shorewall/nat- Daughter's System #EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL 192.0.2.179 eth0 192.168.201.4 No No @@ -1753,7 +1805,7 @@ ACCEPT net dmz icmp echo-request ACCEPT net loc icmp echo-request ACCEPT dmz loc icmp echo-request ACCEPT loc dmz icmp echo-request -ACCEPT net loc:192.168.201.4 tcp www #Daughter's +ACCEPT net loc:192.168.201.4 tcp www #Daughter's #Server ACCEPT net dmz:192.0.2.178 tcp smtp #Mail from #Internet @@ -1806,25 +1858,26 @@ ACCEPT net fw tcp ssh #SSH to the 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 + 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. + 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: + The /etc/named.conf file would look like + this: options { - directory "/var/named"; + directory "/var/named"; listen-on { 127.0.0.1 ; 192.0.2.177; }; }; logging { channel xfer-log { - file "/var/log/named/bind-xfer.log"; + file "/var/log/named/bind-xfer.log"; print-category yes; print-severity yes; print-time yes; @@ -1840,7 +1893,7 @@ logging { # This is the view presented to our internal systems # -view "internal" { +view "internal" { # # These are the clients that see this view # @@ -1852,129 +1905,130 @@ view "internal" { 192.0.2.179/32; 192.0.2.180/32; }; # - # If this server can't complete the request, it should use + # If this server can't complete the request, it should use # outside servers to do so # recursion yes; - zone "." in { + zone "." in { type hint; - file "int/root.cache"; + file "int/root.cache"; }; - zone "foobar.net" in { + zone "foobar.net" in { type master; notify no; allow-update { none; }; - file "int/db.foobar"; + file "int/db.foobar"; }; - zone "0.0.127.in-addr.arpa" in { + zone "0.0.127.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "int/db.127.0.0"; + file "int/db.127.0.0"; }; - zone "201.168.192.in-addr.arpa" in { + zone "201.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "int/db.192.168.201"; + file "int/db.192.168.201"; }; - zone "202.168.192.in-addr.arpa" in { + zone "202.168.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "int/db.192.168.202"; + file "int/db.192.168.202"; }; - zone "176.2.0.192.in-addr.arpa" in { + zone "176.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "db.192.0.2.176"; + file "db.192.0.2.176"; }; - zone "177.2.0.192.in-addr.arpa" in { + zone "177.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "db.192.0.2.177"; + file "db.192.0.2.177"; }; - zone "178.2.0.192.in-addr.arpa" in { + zone "178.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "db.192.0.2.178"; + file "db.192.0.2.178"; }; - zone "179.2.0.192.in-addr.arpa" in { + zone "179.2.0.192.in-addr.arpa" in { type master; notify no; allow-update { none; }; - file "db.206.124.146.179"; + file "db.206.124.146.179"; }; }; # # This is the view that we present to the outside world # -view "external" { +view "external" { match-clients { any; }; # - # If we can't answer the query, we tell the client so + # If we can't answer the query, we tell the client so # recursion no; - zone "foobar.net" in { + zone "foobar.net" in { type master; notify yes; allow-update {none; }; - allow-transfer { <secondary NS IP>; }; - file "ext/db.foobar"; + allow-transfer { <secondary NS IP>; }; + file "ext/db.foobar"; }; - zone "176.2.0.192.in-addr.arpa" in { + 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"; + allow-transfer { <secondary NS IP>; }; + file "db.192.0.2.176"; }; - zone "177.2.0.192.in-addr.arpa" in { + 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"; + allow-transfer { <secondary NS IP>; }; + file "db.192.0.2.177"; }; - zone "178.2.0.192.in-addr.arpa" in { + 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"; + allow-transfer { <secondary NS IP>; }; + file "db.192.0.2.178"; }; - zone "179.2.0.192.in-addr.arpa" in { + 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"; + 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). + 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 + the firewall's external interface ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32 @@ -1991,10 +2045,10 @@ view "external" { ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. -@ 604800 IN NS <name of secondary ns>. +@ 604800 IN NS <name of secondary ns>. ; ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; Iverse Address Arpa Records (PTR's) ; ############################################################ 176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net. @@ -2015,10 +2069,10 @@ view "external" { ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. -@ 604800 IN NS <name of secondary ns>. +@ 604800 IN NS <name of secondary ns>. ; ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; Iverse Address Arpa Records (PTR's) ; ############################################################ 177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net. @@ -2040,15 +2094,15 @@ view "external" { ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. -@ 604800 IN NS <name of secondary ns>. +@ 604800 IN NS <name of secondary ns>. ; ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; 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 + 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 @@ -2065,14 +2119,15 @@ view "external" { ; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA) ; ############################################################ @ 604800 IN NS ns1.foobar.net. -@ 604800 IN NS <name of secondary ns>. +@ 604800 IN NS <name of secondary ns>. ; ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; 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 + int/db.127.0.0 - Reverse zone for + localhost ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8 @@ -2090,7 +2145,7 @@ view "external" { @ 604800 IN NS ns1.foobar.net. ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR localhost.foobar.net. @@ -2113,7 +2168,7 @@ view "external" { ; ############################################################ @ 604800 IN NS ns1.foobar.net. ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR gateway.foobar.net. 2 86400 IN PTR winken.foobar.net. @@ -2121,7 +2176,7 @@ view "external" { 4 86400 IN PTR nod.foobar.net. int/db.192.168.202 - Reverse zone for the - firewall's DMZ Interface + firewall's DMZ Interface ; ############################################################ ; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29 @@ -2140,7 +2195,7 @@ view "external" { @ 604800 IN NS ns1.foobar.net. ; ############################################################ -; Iverse Address Arpa Records (PTR's) +; Iverse Address Arpa Records (PTR's) ; ############################################################ 1 86400 IN PTR dmz.foobar.net. @@ -2196,7 +2251,7 @@ dmz 86400 IN A 192.168.202.1 ; Foobar.net Nameserver Records (NS) ;############################################################ @ 86400 IN NS ns1.foobar.net. -@ 86400 IN NS <secondary NS>. +@ 86400 IN NS <secondary NS>. ;############################################################ ; Foobar.net Foobar Wa Office Records (ADDRESS) ;############################################################ @@ -2225,7 +2280,7 @@ nod 86400 IN A 192.0.2.179 ;############################################################ foobar.net. 86400 IN A 192.0.2.177 86400 IN MX 0 mail.foobar.net. - 86400 IN MX 1 <backup MX>. + 86400 IN MX 1 <backup MX>.
@@ -2238,18 +2293,18 @@ foobar.net. 86400 IN A 192.0.2.177 external IP address does not mean that the request will be associated with the external interface or the net zone. Any traffic that you generate from the local network will be associated - with your local interface and will be treated as loc->fw traffic. + with your local interface and will be treated as loc->fw + traffic. IP addresses are properties of systems, not of interfaces. It is a mistake to believe that your firewall is able to forward packets just because you can ping the IP - address of all of the firewall's interfaces from the local - network. The only conclusion you can draw from such pinging success is - that the link between the local system and the firewall works and that - you probably have the local system's default gateway set - correctly. + address of all of the firewall's interfaces from the local network. + The only conclusion you can draw from such pinging success is that the + link between the local system and the firewall works and that you + probably have the local system's default gateway set correctly. @@ -2257,8 +2312,9 @@ foobar.net. 86400 IN A 192.0.2.177 interfaces are in the $FW (fw) zone. If 192.168.1.254 is the IP address of your internal interface then you can write $FW:192.168.1.254 in a - rule but you may not write loc:192.168.1.254. - Similarly, it is nonsensical to add 192.168.1.254 to the loc:192.168.1.254. Similarly, it is + nonsensical to add 192.168.1.254 to the loc zone using an entry in /etc/shorewall/hosts. @@ -2292,26 +2348,31 @@ foobar.net. 86400 IN A 192.0.2.177 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. + /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 + 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 + 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.