diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index fd1e8500f..e250081f8 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -1,285 +1,302 @@ - + - + - + Shorewall 1.4 Documentation - + + - + - + - + - - - - - - -
- -

Shorewall 1.4 Reference

-
- -

This documentation is intended primarily for reference. - Step-by-step instructions for configuring Shorewall - in common setups may be found in the QuickStart Guides.

- -

Components

- -

Shorewall consists of the following components:

- - - +

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:

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

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

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

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.

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

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

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

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

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

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

-
- -
+ are using (or are planning to use) private addresses before you decide + the addresses that you are going to use.

+
+ +

5.0 Setting up your Network

-
- -
+
+ +

The choice of how to set up your network depends primarily - on how many Public IP addresses you have vs. how many addressable -entities you have in your network. Regardless of how many addresses -you have, your ISP will handle that set of addresses in one of two + 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. +

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

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

    +
    4. +

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

    -
    5. - + of your addresses directly.

    + +
-
- -
+
+ +

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

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

- +     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
    • -
  • IP_FORWARDING=On
    -
    • - +
  • NAT_ENABLED=Yes
    • +
  • IP_FORWARDING=On
    +
    • +
-
- -
+
+ +

5.1 Routed

-
- -
+
+ +

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

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

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

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

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

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

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

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

    -
    • -
  • + also known as Port Forwarding.

    +
    • +

  • Proxy ARP.

    -
    • -
  • +
    • +

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

    -
    • - + to as Static NAT.

    + +
-
- -
+
+ +

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

-
- -
+
+ +

 5.2.1 SNAT

-
- -
+
+ +

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

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

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

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

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

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

-
- -
+ IP address) and the firewall will rewrite the destination IP address + to 192.168.201.4 (your daughter's system) and forward the request. + When your daughter's server responds, the firewall will rewrite the + source address back to 192.0.2.176 and send the response back to A.

+
+ +

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

-
- -
+
+ +

5.2.3 Proxy ARP

-
- -
+
+ +

The idea behind proxy ARP is that:

-
- -
+
+ +
    -
  • +

  • A host H behind your firewall is assigned one -of your public IP addresses (A) and is assigned the same netmask - (M) as the firewall's external interface.

    -
    • -
  • +of your public IP addresses (A) and is assigned the same netmask + (M) as the firewall's external interface.

    +
    • +

  • The firewall responds to ARP "who has" requests for A. -

    -
    • -
  • +

    +
    • +

  • When H issues an ARP "who has" request for an address in the subnetwork defined by A and M, the firewall will respond (with the MAC if the firewall interface to H).

    -
    • - + +
-
- -
+
+ +

Let suppose that we decide to use Proxy ARP on the DMZ in - our example network.

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

Because the HAVE ROUTE column contains No, Shorewall will - 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:
+ 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 static NAT for that matter). Happily enough, recent versions of -Redhat's iputils package include "arping", whose "-U" flag does just that:
    -
    -     arping -U -I <net if> <newly -proxied IP>
    -     arping -U -I eth0 66.58.99.83 # for -example
    -
    - Stevens goes on to mention that not all systems respond correctly -to gratuitous ARPs, but googling for "arping -U" seems to support the 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. - +
  3. (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP + Illustrated, Vol 1 reveals that a
    +
    + "gratuitous" ARP packet should cause the ISP's router to refresh +their ARP cache (section 4.7). A gratuitous ARP is simply a host requesting +the MAC address for its own IP; in addition to ensuring that the IP address + isn't a duplicate,...
    +
    + "if the host sending the gratuitous ARP has just changed its hardware + address..., this packet causes any other host...that has an entry in its + cache for the old hardware address to update its ARP cache entry accordingly."
    +
    + Which is, of course, exactly what you want to do when you switch + a host from being exposed to the Internet to behind Shorewall using proxy + ARP (or static NAT for that matter). Happily enough, recent versions of + Redhat's iputils package include "arping", whose "-U" flag does just that:
    +
    +     arping -U -I <net if> <newly + 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.
    +
    +
    4. +
  4. You can call your ISP and ask them to purge the stale ARP + cache entry but many either can't or won't purge individual entries.
    5. +
- You can determine if your ISP's gateway ARP cache is stale using - ping and tcpdump. Suppose that we suspect that the gateway router has - a stale ARP cache entry for 130.252.100.19. 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 130.252.100.19, ping the ISP's gateway (which we - will assume is 130.252.100.254):

-
- -
-
	ping 130.252.100.254
-
-
- -
+
+ +
+

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

+
+ +
+
	ping 192.0.2.254
+
+
+ +

We can now observe the tcpdump output:

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

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

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

+
+ +

5.2.4 Static NAT

-
- -
+
+ +

With static NAT, you assign local systems RFC 1918 addresses - then establish a one-to-one mapping between those addresses and public - IP addresses. For outgoing connections SNAT (Source Network Address - Translation) occurs and on incoming connections DNAT (Destination Network - Address Translation) occurs. Let's go back to our earlier example involving - your daughter's web server running on system Local 3.

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

-
- -
-
+ and is sharing the firewall external IP (192.0.2.176) for outbound + connections. This is done with the following entry in /etc/shorewall/masq:

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

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

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

With this entry in place, you daughter has her own IP address - 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:

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

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

A word of warning is in order here. ISPs typically configure + their routers with a long ARP cache timeout. If you move a system from + parallel to your firewall to behind your firewall with static NAT, +it will probably be HOURS before that system can communicate with 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 static NAT for that matter). Happily enough, recent versions of + Redhat's iputils package include "arping", whose "-U" flag does just that:
    +
    +     arping -U -I <net if> <newly + proxied IP>
    +     arping -U -I eth0 66.58.99.83 # for + example
    +
    + Stevens goes on to mention that not all systems respond correctly + to gratuitous ARPs, but googling for "arping -U" seems to support the +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.

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

-
- -
+ used in this section, they won't be shown

+
+ +

You probably want to allow ping between your zones:

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

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

-
- -
-
+ and a Web Server on DMZ 1. The rules that you would need are:

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

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

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

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

-
- -
-
+ and DMZ systems from the local network -- I recommend SSH which through + its scp utility can also do publishing and software update distribution.

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

5.4 Odds and Ends

-
- -
+
+ +

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

-
- -
+
+ +

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

-
- -
-
+ 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 
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
INTERFACESUBNETADDRESS
eth0192.168.201.0/29192.0.2.176
-
-
- -
+ +
+ +

/etc/shorewall/proxyarp - DMZ

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

/etc/shorewall/nat- Daughter's System

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

/etc/shorewall/rules

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

6.0 DNS

-
- -
+
+ +

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

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

+
+ +

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

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

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

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

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

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

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

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

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

	zone "176.2.0.192.in-addr.arpa" in {
		type master;
		notify no;
		allow-update { none; };
		file "db.192.0.2.176";
	};
 (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";
	};
};
-
-
-
- -
+
+ +
+ 
#
# 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).

- + included in your bind disbribution).

+

db.192.0.2.176 - This is the reverse zone for the firewall's - external interface

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

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

-
- -
+ Your Firewall +
+ +

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

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

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

-
- -
+     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 5/3/2003 - /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 6/7/2003 - Tom Eastep

- +

Copyright 2002, 2003 - Thomas M. Eastep

-
-
-
-
-
-
-
-
-
-
+ Thomas M. Easte
+


diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm index 27258896c..22495a654 100644 --- a/Shorewall-docs/sourceforge_index.htm +++ b/Shorewall-docs/sourceforge_index.htm @@ -2,420 +2,488 @@ - + Shoreline Firewall (Shorewall) 1.3 - + + - + - + - + - + + + - Shorewall 1.4 - - "iptables made -easy"
-
- - - - - - - - + +
+ + - -

Shorwall Logo + +

Shorewall 1.4 "iptables made easy"

+

+


+

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

What is it?

- -

The Shoreline Firewall, more commonly known as "Shorewall", is - a Netfilter - (iptables) based firewall that can be used -on a dedicated firewall system, a multi-function - gateway/router/server or on a standalone GNU/Linux system.

- - - - -

This program is free software; you can redistribute it and/or modify - it - under the terms of Version 2 of the GNU -General Public License as published by the Free Software - Foundation.
- -
- - This program is distributed in the hope - that it will be useful, but WITHOUT ANY - WARRANTY; without even the implied warranty - of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License - for more details.
- -
- - You should have received a copy of the - GNU General Public License along - with this program; if not, write to the Free - Software Foundation, Inc., 675 Mass - Ave, Cambridge, MA 02139, USA

- - - - -

Copyright 2001, 2002, 2003 Thomas M. Eastep

+ +

The Shoreline Firewall, more commonly known as "Shorewall", is + a Netfilter + (iptables) based firewall that can be used + on a dedicated firewall system, a multi-function + gateway/router/server or on a standalone GNU/Linux system.

+

This program is free software; you can redistribute it and/or modify + it + under the terms of Version 2 of the +GNU General Public License as published by the Free Software + Foundation.
+ +
+ + This program is distributed in the + hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS +FOR A PARTICULAR PURPOSE. See the GNU General + Public License for more details.
+ +
+ + You should have received a copy of + the GNU General Public License + along with this program; if not, write to + the Free Software Foundation, Inc., + 675 Mass Ave, Cambridge, MA 02139, USA

+ + + + +

Copyright 2001, 2002, 2003 Thomas M. Eastep

+ + + + +

Running Shorewall on Mandrake with a two-interface setup?

- If so, almost NOTHING on this site will apply directly to -your setup. If you want to use the documentation that you find here, it -is best if you uninstall what you have and install a setup that matches -the documentation on this site. See the Two-interface -QuickStart Guide for details.
- + If so, almost NOTHING on this site will apply directly + to your setup. If you want to use the documentation that you find here, + it is best if you uninstall what you have and install a setup that matches + the documentation on this site. See the Two-interface + QuickStart Guide for details.
+ +

Getting Started with Shorewall

- New to Shorewall? Start by selecting the QuickStart Guide that most closely - match your environment and follow the step by step instructions.
+ New to Shorewall? Start by selecting the QuickStart Guide that most closely + match your environment and follow the step by step instructions.
- + +

News

- + - -

5/27/2003 - Shorewall-1.4.4a 6/17/2003 - Shorewall-1.4.5 (New) +

+ +

Problems Corrected:
+

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

New Features:
+

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

6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8 + (New) +

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

6/8/2003 - Updated Samples (New) -

- The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed out - that the code in 1.4.4 restricts the length of short zone names to 4 characters. - I've produced version 1.4.4a that restores the previous 5-character limit - by conditionally omitting the log rule number when the LOGFORMAT doesn't -contain '%d'. -

5/23/2003 - Shorewall-1.4.4 (New) -

- I apologize for the rapid-fire releases but since there is a potential - configuration change required to go from 1.4.3a to 1.4.4, I decided to make - it a full release rather than just a bug-fix release.
-
-     Problems corrected:
- +

+ +

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

+ +

5/29/2003 - Shorewall-1.4.4b

+ +

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

+ +

5/27/2003 - Shorewall-1.4.4a

+ The Fireparse --log-prefix fiasco continues. Tuomo Soini has pointed + out that the code in 1.4.4 restricts the length of short zone names to +4 characters. I've produced version 1.4.4a that restores the previous 5-character + limit by conditionally omitting the log rule number when the LOGFORMAT +doesn't contain '%d'. +

5/23/2003 - Shorewall-1.4.4 +

+ I apologize for the rapid-fire releases but since there is a potential + configuration change required to go from 1.4.3a to 1.4.4, I decided to +make it a full release rather than just a bug-fix release.
+
+     Problems corrected:
+
None.
-
-     New Features:
- + +     New Features:
+
    -
  1. A REDIRECT- rule target has been added. This target behaves - for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter - nat table REDIRECT rule is added but not the companion filter table ACCEPT - rule.
    -
    -
    2. -
  2. The LOGMARKER variable has been renamed LOGFORMAT and has -been changed to a 'printf' formatting template which accepts three arguments -(the chain name, logging rule number and the disposition). To use LOGFORMAT -with fireparse (http://www.fireparse.com), - set it as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT - string (up to but not including the first '%') to find log messages in -the 'show log', 'status' and 'hits' commands. This part should not be omitted - (the LOGFORMAT should not begin with "%") and the leading part should be - sufficiently unique for /sbin/shorewall to identify Shorewall messages.
    -
    -
    3. -
  3. When logging is specified on a DNAT[-] or REDIRECT[-] rule, - the logging now takes place in the nat table rather than in the filter table. - This way, only those connections that actually undergo DNAT or redirection - will be logged.
    4. - +
  4. A REDIRECT- rule target has been added. This target behaves + for REDIRECT in the same way as DNAT- does for DNAT in that the Netfilter + nat table REDIRECT rule is added but not the companion filter table ACCEPT + rule.
    +
    +
    5. +
  5. The LOGMARKER variable has been renamed LOGFORMAT and +has been changed to a 'printf' formatting template which accepts three +arguments (the chain name, logging rule number and the disposition). To +use LOGFORMAT with fireparse (http://www.fireparse.com), + set it as:
    +  
    +        LOGFORMAT="fp=%s:%d a=%s "
    +  
    + CAUTION: /sbin/shorewall uses the leading part of the +LOGFORMAT string (up to but not including the first '%') to find log messages +in the 'show log', 'status' and 'hits' commands. This part should not +be omitted (the LOGFORMAT should not begin with "%") and the leading part +should be sufficiently unique for /sbin/shorewall to identify Shorewall +messages.
    +
    +
    6. +
  6. When logging is specified on a DNAT[-] or REDIRECT[-] +rule, the logging now takes place in the nat table rather than in the filter +table. This way, only those connections that actually undergo DNAT or redirection + will be logged.
    7. +
- -

5/20/2003 - Shorewall-1.4.3a -
-

- This version primarily corrects the documentation included in the .tgz - and in the .rpm. In addition:
- + +

5/20/2003 - Shorewall-1.4.3a +
+

+ This version primarily corrects the documentation included in the + .tgz and in the .rpm. In addition:
+ +
    -
  1. (This change is in 1.4.3 but is not documented) If you are - running iptables 1.2.7a and kernel 2.4.20, then Shorewall will return reject - replies as follows:
    -    a) tcp - RST
    -    b) udp - ICMP port unreachable
    -    c) icmp - ICMP host unreachable
    -    d) Otherwise - ICMP host prohibited
    - If you are running earlier software, Shorewall will follow it's traditional - convention:
    -    a) tcp - RST
    -    b) Otherwise - ICMP port unreachable
    2. -
  2. UDP port 135 is now silently dropped in the common.def chain. - Remember that this chain is traversed just before a DROP or REJECT policy - is enforced.
    -
    3. - +
  3. (This change is in 1.4.3 but is not documented) If +you are running iptables 1.2.7a and kernel 2.4.20, then Shorewall will +return reject replies as follows:
    +    a) tcp - RST
    +    b) udp - ICMP port unreachable
    +    c) icmp - ICMP host unreachable
    +    d) Otherwise - ICMP host prohibited
    + If you are running earlier software, Shorewall will follow it's + traditional convention:
    +    a) tcp - RST
    +    b) Otherwise - ICMP port unreachable
    4. +
  4. UDP port 135 is now silently dropped in the common.def + chain. Remember that this chain is traversed just before a DROP or REJECT + policy is enforced.
    +
    5. + +
- + +

5/18/2003 - Shorewall 1.4.3
-

-     Problems Corrected:
- +

+     Problems Corrected:
+ +
    -
  1. There were several cases where Shorewall would fail to -remove a temporary directory from /tmp. These cases have been corrected.
    2. -
  2. The rules for allowing all traffic via the loopback interface - have been moved to before the rule that drops status=INVALID packets. -This insures that all loopback traffic is allowed even if Netfilter connection - tracking is confused.
    3. - -
-     New Features:
- -
    -
  1.  IPV6-IPV4 (6to4) - tunnels are now supported in the /etc/shorewall/tunnels file.
    2. -
  2. You may now change the leading portion of the - --log-prefix used by Shorewall using the LOGMARKER variable in shorewall.conf. - By default, "Shorewall:" is used.
    -
    3. - -
- -

5/10/2003 - Shorewall Mirror in Asia
-

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

5/8/2003 - Shorewall Mirror in Chile  

- - -

Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
-

+
  • There were several cases where Shorewall would fail + to remove a temporary directory from /tmp. These cases have been corrected.
    • +
  • The rules for allowing all traffic via the loopback + interface have been moved to before the rule that drops status=INVALID + packets. This insures that all loopback traffic is allowed even if Netfilter + connection tracking is confused.
    • -

    4/26/2003 - lists.shorewall.net Downtime  

    + +     New Features:
    +     + +
      +
    1.  IPV6-IPV4 + (6to4) tunnels are now supported in the /etc/shorewall/tunnels +file.
      2. +
    2. You may now change the leading portion +of the --log-prefix used by Shorewall using the LOGMARKER variable in +shorewall.conf. By default, "Shorewall:" is used.
      +
      3. - -

      The list server will be down this morning for upgrade to RH9.0.
      -

      + +
    - -

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

    + +

    5/10/2003 - Shorewall Mirror in Asia
    +

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

    5/8/2003 - Shorewall Mirror in Chile  

    - -

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

    + +

    Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago Chile.
    +

    -

    4/12/2002 - Greater Seattle Linux Users Group Presentation -

    +

    4/26/2003 - lists.shorewall.net Downtime  

    - + +

    The list server will be down this morning for upgrade to RH9.0.
    +

    + + + +

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

    + + + +

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

    + + + +

    4/12/2002 - Greater Seattle Linux Users Group Presentation +

    + + +
    This morning, I gave a Shorewall presentation to GSLUG. The presentation - is in HTML format but was generated from Microsoft PowerPoint and - is best viewed using Internet Explorer (although Konqueror also seems - to work reasonably well as does Opera 7.1.0). Neither Opera 6 nor Netscape - work well to view the presentation.
    + target="_top">a Shorewall presentation to GSLUG. The presentation + is in HTML format but was generated from Microsoft PowerPoint +and is best viewed using Internet Explorer (although Konqueror also +seems to work reasonably well as does Opera 7.1.0). Neither Opera +6 nor Netscape work well to view the presentation. - +

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

    - + - +

    More News

    - + - +

    - + - +

    (Leaf Logo) - Jacques Nilo and Eric Wolzak have - a LEAF (router/firewall/gateway on a floppy, - CD or compact flash) distribution called - Bering that features -Shorewall-1.3.14 and Kernel-2.4.20. You can find - their work at: Jacques Nilo and Eric Wolzak + have a LEAF (router/firewall/gateway +on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.3.14 and Kernel-2.4.20. You + can find their work at: http://leaf.sourceforge.net/devel/jnilo

    - Congratulations to Jacques and Eric - on the recent release of Bering 1.2!!!
    - + Congratulations to Jacques and + Eric on the recent release of Bering 1.2!!! +
    + +

    SourceForge Logo -

    - + + - +

    - + - +

    This site is hosted by the generous folks at SourceForge.net

    - + - +

    Donations

    -     		- + + +
    + action="http://lists.shorewall.net/cgi-bin/htsearch"> - +


    - Note:     - Search is unavailable Daily 0200-0330 - GMT.
    -  

    + Note: + Search is unavailable Daily 0200-0330 + GMT.
    +  

    - + +

    Quick Search
    - - +

    - -
    + value="[http://lists.shorewall.net/pipermail/*]"> + - +

    Extended Search

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

    -

    +

    - -

    Shorewall is free but -if you try it and find it useful, please consider making a donation - to - Starlight - Children's Foundation. Thanks!

    + +


    + Shorewall is free but if you try it and find + it useful, please consider making a donation + to Starlight Children's + Foundation. Thanks!

    -
    - -

    Updated 5/27/2003 - Tom Eastep -
    -

    -
    -
    -
    + +

    Updated 6/17/2003 - Tom Eastep +
    +

    diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm index 368f20fa9..486c59c19 100644 --- a/Shorewall-docs/support.htm +++ b/Shorewall-docs/support.htm @@ -1,81 +1,81 @@ - + - + Shorewall Support Guide - + - - - + + - - - + + + + +
    - +
    +

    Shorewall Support Guide -

    -
    - +

    Before Reporting a Problem or Asking a Question
    -

    - There -are a number of sources of Shorewall information. Please try these -before you post. + + There + are a number of sources of Shorewall information. Please try these + before you post.
      -
    • Shorewall versions earlier -that 1.3.0 are no longer supported.
      -
      • -
    • More than half of the questions posted on the support - list have answers directly accessible from the Documentation - Index
      -
      • -
    • - The FAQ has -solutions to more than 20 common problems.
      • -
    • The - Troubleshooting - Information contains a number of tips to help - you solve common problems.
      • -
    • The - Errata has links - to download updated components.
      • -
    • The Site - and Mailing List Archives search facility can locate documents - and posts about similar problems:
      • - +
    • Shorewall versions earlier + that 1.3.0 are no longer supported.
      +
      • +
    • More than half of the questions posted on the support + list have answers directly accessible from the Documentation + Index
      +
      • +
    • + The FAQ has + solutions to more than 20 common problems.
      • +
    • The + Troubleshooting + Information contains a number of tips to +help you solve common problems.
      • +
    • The + Errata has links + to download updated components.
      • +
    • The + Site and Mailing List Archives search facility can locate + documents and posts about similar problems:
      • +
    - +

    Site and Mailing List Archive Search

    - -
    + +
    Match: - + action="http://lists.shorewall.net/cgi-bin/htsearch"> Match: + - Format: - + Format: + - Sort by: - + Sort by: + - Include Mailing List Archives: - + size="-1"> Include Mailing List Archives: + -
    - Search:
    + Search:
    - -
    - + +
    +

    Problem Reporting Guidelines
    -

    - + +
      -
    • Please remember we only know what - is posted in your message. Do not leave out any information - that appears to be correct, or was mentioned in a previous post. - There have been countless posts by people who were sure that -some part of their configuration was correct when it actually -contained a small error. We tend to be skeptics where detail is -lacking.
      -
      -
      • -
    • Please keep in mind that you're -asking for free technical support. Any -help we offer is an act of generosity, not an obligation. Try - to make it easy for us to help you. Follow good, courteous practices - in writing and formatting your e-mail. Provide details that we need -if you expect good answers. Exact quoting of error messages, - log entries, command output, and other output is better than a paraphrase - or summary.
      -
      -
      • -
    • - Please don't describe your environment and then ask us - to send you custom configuration files. We're here - to answer your questions but we can't do your -job for you.
      -
      -
      • -
    • When reporting a problem, ALWAYS - include this information:
      • - +
    • Please remember we only know +what is posted in your message. Do not leave out any information + that appears to be correct, or was mentioned in a previous + post. There have been countless posts by people who were sure + that some part of their configuration was correct when it actually + contained a small error. We tend to be skeptics where detail + is lacking.
      +
      +
      • +
    • Please keep in mind that you're + asking for free technical support. + Any help we offer is an act of generosity, not an obligation. + Try to make it easy for us to help you. Follow good, courteous + practices in writing and formatting your e-mail. Provide details that + we need if you expect good answers. Exact quoting of +error messages, log entries, command output, and other output is better + than a paraphrase or summary.
      +
      +
      • +
    • + Please don't describe your environment and then ask + us to send you custom configuration files. We're + here to answer your questions but we can't do +your job for you.
      +
      +
      • +
    • When reporting a problem, ALWAYS + include this information:
      • +
    - +
      - +
        -
      • the exact version of Shorewall - you are running.
        -
        - shorewall - version
        -
        -
        • - +
      • the exact version of Shorewall + you are running.
        +
        + shorewall + version
        +
        +
        • +
      - +
        -
      • the exact kernel version you -are running
        -
        - uname --a
        -
        -
        • - +
      • the exact kernel version you + are running
        +
        + uname + -a
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip addr - show
        -
        -
        • - +
      • the complete, exact output +of
        +
        + ip +addr show
        +
        +
        • +
      - +
        -
      • the complete, exact output of
        -
        - ip route - show
        -
        -
        • - +
      • the complete, exact output +of
        +
        + ip +route show
        +
        +
        • +
      - +
        -
      • If your kernel is modularized, - the exact output from
        -
        - lsmod
        -
        • +
      • If your kernel is modularized, + the exact output from
        +
        + lsmod
        +
        • +
      - +
    - +
      - +
        -
      • If you are having connection - problems of any kind then:
        -
        - 1. /sbin/shorewall/reset
        -
        - 2. Try the connection that is failing.
        -
        - 3. /sbin/shorewall status - > /tmp/status.txt
        -
        - 4. Post the /tmp/status.txt file as an attachment.
        -
        -
        • -
      • the exact wording of any If you are having + connection problems of any kind then:
        +
        + 1. /sbin/shorewall reset
        +
        + 2. Try the connection that is failing.
        +
        + 3. /sbin/shorewall status + > /tmp/status.txt
        +
        + 4. Post the /tmp/status.txt file as an attachment.
        +
        +
        • +
      • the exact wording of any ping failure responses
        -
        -
        • -
      • If you installed Shorewall using one of the QuickStart - Guides, please indicate which one.
        -
        -
        • -
      • If you are running Shorewall under Mandrake using -the Mandrake installation of Shorewall, please say so.
        -
        -
        • - +
        + +
      • If you installed Shorewall using one of the QuickStart + Guides, please indicate which one.
        +
        +
        • +
      • If you are running Shorewall under Mandrake using + the Mandrake installation of Shorewall, please say so.
        +
        +
        • +
      -
    • As - a general matter, please do not edit the diagnostic -information in an attempt to conceal your IP address, -netmask, nameserver addresses, domain name, etc. These aren't -secrets, and concealing them often misleads us (and 80% of the time, -a hacker could derive them anyway from information contained in -the SMTP headers of your post).
      -
      -
      • -
    • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when - you exercise the function that is giving you problems? If -so, include the message(s) in your post along with a copy of your -/etc/shorewall/interfaces file.
      -
      -
      • -
    • Please include any of the Shorewall configuration - files (especially the /etc/shorewall/hosts file -if you have modified that file) that you think are - relevant. If you include /etc/shorewall/rules, please include -/etc/shorewall/policy as well (rules are meaningless unless + +
    • As a general matter, please do not edit the diagnostic + information in an attempt to conceal your IP address, + netmask, nameserver addresses, domain name, etc. These aren't + secrets, and concealing them often misleads us (and 80% of the time, + a hacker could derive them anyway from information contained +in the SMTP headers of your post).
      +
      +
      • +
    • Do you see any "Shorewall" messages ("/sbin/shorewall show log") when + you exercise the function that is giving you problems? If +so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces + file.
      +
      +
      • +
    • Please include any of the Shorewall configuration + files (especially the /etc/shorewall/hosts file + if you have modified that file) that you think are + relevant. If you include /etc/shorewall/rules, please include + /etc/shorewall/policy as well (rules are meaningless unless one also knows the policies).
      -
      -
      • -
    • If an error occurs when you try to "shorewall start", include a trace - (See the Troubleshooting - section for instructions).
      -
      -
      • -
    • The list server limits posts to 120kb so don't - post GIFs of your network layout, etc. -to the Mailing List -- your post will be rejected.
      • - +
      + +
    • If an error occurs when you try to "shorewall start", include a trace + (See the Troubleshooting + section for instructions).
      +
      +
      • +
    • The list server limits posts to 120kb so don't + post GIFs of your network layout, etc. + to the Mailing List -- your post will be rejected.
      • +
    - -
    The author gratefully acknowleges that the above list was - heavily plagiarized from the excellent LEAF document by Ray - Olszewski found at The author gratefully acknowleges that the above list was + heavily plagiarized from the excellent LEAF document by Ray + Olszewski found at http://leaf-project.org/pub/doc/docmanager/docid_1891.html.
    -
    - + +

    When using the mailing list, please post in plain text

    - -
    A growing number of MTAs serving list subscribers are rejecting - all HTML traffic. At least one MTA has gone so far as to blacklist - shorewall.net "for continuous abuse" because it has been my policy - to allow HTML in list posts!!
    -
    - I think that blocking all HTML is - a Draconian way to control spam and that the ultimate losers - here are not the spammers but the list subscribers whose -MTAs are bouncing all shorewall.net mail. As one list subscriber - wrote to me privately "These e-mail admin's need to get a (expletive - deleted) life instead of trying to rid the planet of HTML -based e-mail". Nevertheless, to allow subscribers to receive -list posts as must as possible, I have now configured the list - server at shorewall.net to strip all HTML from outgoing posts.
    -
    - + +
    A growing number of MTAs serving list subscribers are +rejecting all HTML traffic. At least one MTA has gone so far as to +blacklist shorewall.net "for continuous abuse" because it has been +my policy to allow HTML in list posts!!
    +
    + I think that blocking all HTML + is a Draconian way to control spam and that the ultimate + losers here are not the spammers but the list subscribers + whose MTAs are bouncing all shorewall.net mail. As one list +subscriber wrote to me privately "These e-mail admin's need + to get a (expletive deleted) life instead of trying to +rid the planet of HTML based e-mail". Nevertheless, to allow +subscribers to receive list posts as must as possible, I have now + configured the list server at shorewall.net to strip all HTML from + outgoing posts.
    +
    + If you run your own outgoing mail server +and it doesn't have a valid DNS PTR record, your email won't reach the lists +unless/until the postmaster notices that your posts are being rejected. To +avoid this problem, you should configure your MTA to forward posts to shorewall.net +through an MTA that does have a valid PTR record (such as the one +at your ISP).
    +

    Where to Send your Problem Report or to Ask for Help

    - -
    + +

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

    - If you run Shorewall under MandrakeSoft - Multi Network Firewall (MNF) and you have not purchased -an MNF license from MandrakeSoft then you can post non MNF-specific - Shorewall questions to the Shorewall users mailing - list. Do not expect to get free MNF support on the list.
    - -

    Otherwise, please post your question or problem to the Shorewall users mailing - list .

    - + style="font-weight: 400;">please post your question or problem + to the LEAF Users mailing + list. + If you run Shorewall under +MandrakeSoft Multi Network Firewall (MNF) and you have +not purchased an MNF license from MandrakeSoft then you can + post non MNF-specific Shorewall questions to the Shorewall users mailing + list. Do not expect to get free MNF support on the list.
    + +

    If you have a question, you may post it on the Shorewall Forum: + DO NOT USE THE FORUM FOR REPORTING PROBLEMS OR +ASKING FOR HELP WITH PROBLEMS.
    +
    + Otherwise, please post your question or problem to the Shorewall users mailing + list .

    +

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

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

    +
    +

    For information on other Shorewall mailing lists, go to http://lists.shorewall.net
    -

    - -

    Last Updated 5/19/2003 - Tom Eastep

    - +

    + +

    Last Updated 6/14/2003 - Tom Eastep

    +

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