diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm deleted file mode 100644 index 91a28b4ad..000000000 --- a/Shorewall-docs/Documentation.htm +++ /dev/null @@ -1,2868 +0,0 @@ - - - - - - - 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:

- -

/etc/shorewall/params

-

You may use the file /etc/shorewall/params file to set shell -variables that you can then use in some of the other configuration -files.

-

It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally -within the Shorewall programs

-

Example:

-
 	NET_IF=eth0
	NET_BCAST=130.252.100.255
	NET_OPTIONS=blacklist,norfc1918
-

Example (/etc/shorewall/interfaces record):

-
	net $NET_IF $NET_BCAST $NET_OPTIONS
-

The result will be the same as if the record had been written

-
	net eth0 130.252.100.255 blacklist,norfc1918
-

Variables may be used anywhere in the other configuration files.

-

/etc/shorewall/zones

-

This file is used to define the network zones. There is one entry in -/etc/shorewall/zones for each zone; Columns in an entry are:

- -

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

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

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

-

Warning 1: If you rename or delete a zone, you should perform -"shorewall stop; shorewall start" to install the change rather than -"shorewall restart".

-

Warning 2: The order of entries in the /etc/shorewall/zones file -is significant in some cases.

-

/etc/shorewall/interfaces

-

This file is used to tell the firewall which of your firewall's -network interfaces are connected to which zone. There will be one entry -in /etc/shorewall/interfaces for each of your interfaces. Columns in an -entry are:

- -

My recommendations concerning options:
-

- -

-

Example 1: You have a conventional firewall setup in which eth0 -connects to a Cable or DSL modem and eth1 connects to your local -network and eth0 gets its IP address via DHCP. You want to check all -packets entering from the -internet against the black list. Your -/etc/shorewall/interfaces file would be as follows:

-
- - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,norfc1918,blacklist
loceth1detect
-
-
-

Example 2: You have a standalone dialup GNU/Linux System. Your -/etc/shorewall/interfaces file would be:

-
- - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
netppp0
-
-
-
-

Example 3: You have local interface eth1 with two IP addresses - -192.168.1.1/24 and 192.168.12.1/24

-
- - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
loceth1192.168.1.255,192.168.12.255
-
-
-

/etc/shorewall/hosts -Configuration

-

For most applications, specifying zones entirely in terms of network -interfaces is sufficient. There may be times though where you need to -define -a zone to be a more general collection of hosts. This is the purpose of -the /etc/shorewall/hosts file.

-

WARNING: The only times that you -need entries -in /etc/shorewall/hosts are:
-

-
    -
  1. You have more than one zone connecting -through a single interface; or
    2. -
  2. You have a zone that has multiple subnetworks that connect -through a single interface and you want the Shorewall box to route -traffic between those subnetworks.
    -
    3. -
-IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS -THEN DON'T TOUCH THIS FILE!! -

Columns in this file are:

- -
-
    -
  1. An IP address (example - eth1:192.168.1.3)
    2. -
  2. A subnet in CIDR notation (example - -eth2:192.168.2.0/24)
    3. -
-

The interface name much match an entry in -/etc/shorewall/interfaces.
-

-

Warning: If you are -running a version of Shorewall earlier than 1.4.6, only a single -host/subnet address may be specified in an entry in -/etc/shorewall/hosts.
-

-
- -
-

routeback (Added in version 1.4.2) - This option causes -Shorewall to set up handling for routing packets sent by this host -group back back to the same group.
-
-maclist - Added in version 1.3.10. If specified, connection -requests from the hosts specified in this entry are subject to MAC Verification. This option is only -valid for ethernet interfaces.
-

-
-

If you don't define any hosts for a zone, the hosts in the zone -default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the -interfaces to the zone.

-

Note: You probably -DON'T want to specify any hosts for your internet zone since the hosts -that you specify will be the only ones that you will be able to access -without adding additional rules.

-

Example 1:

-

Your local interface is eth1 and you have two groups of local hosts -that you want to make into separate zones:

- -

Your /etc/shorewall/interfaces file might look like:

-
- - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,norfc1918
-eth1192.168.1.127,192.168.1.255
-
-
-
-

The '-' in the ZONE column for eth1 tells Shorewall that eth1 -interfaces to multiple zones.

-

Your /etc/shorewall/hosts file might look like:

-
- - - - - - - - - - - - - - - - - - -
ZONE HOST(S) OPTIONS
loc1eth1:192.168.1.0/25
-
loc2eth1:192.168.1.128/25
-
-
-

Example 2:

-

Your local interface is eth1 and you have two groups of local hosts -that you want to consider as one zone and you want Shorewall to route -between them:

- -

Your /etc/shorewall/interfaces file might look like:

-
- - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
neteth0detectdhcp,norfc1918
loc
- 		eth1192.168.1.127,192.168.1.255
-
-
-
-

Your /etc/shorewall/hosts file might look like:

-
- - - - - - - - - - - - - - - - - - -
ZONE HOST(S) OPTIONS
loceth1:192.168.1.0/25
-
loceth1:192.168.1.128/25
-
-
-If you are running Shorewall 1.4.6 or later, your hosts file may look -like:
-
- - - - - - - - - - - - - -
ZONE HOST(S) OPTIONS
loceth1:192.168.1.0/25,192.168.1.128/25
-
-
-
-

Nested and Overlapping -Zones

-

The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow -you to define nested or overlapping zones. Such overlapping/nested -zones are allowed and Shorewall processes zones in the order -that they appear in the /etc/shorewall/zones file. So if -you have nested zones, you want the sub-zone to appear before -the super-zone and in the case of overlapping zones, the rules that -will apply to hosts that belong to both zones is determined by which -zone appears first in /etc/shorewall/zones.

-

Hosts that belong to more than one zone may be managed by the rules -of all of those zones. This is done through use of the special CONTINUE policy described below.

-

/etc/shorewall/policy -Configuration.

-

This file is used to describe the firewall policy regarding -establishment of connections. Connection establishment is described in -terms of clients who initiate connections and servers who -receive those connection requests. Policies defined in -/etc/shorewall/policy describe which zones are allowed to establish -connections with other zones.

-

Policies established in /etc/shorewall/policy can be viewed as -default policies. If no rule in /etc/shorewall/rules applies to a -particular connection request then the policy from -/etc/shorewall/policy is applied.

-

Four policies are defined:

- -

For each policy specified in /etc/shorewall/policy, you can -indicate that you want a message sent to your system log each time that -the policy is applied.

-

Entries in /etc/shorewall/policy have four columns as follows:

-
    -
  1. SOURCE - The name of a client zone (a zone defined in -the /etc/shorewall/zones file , the name of the firewall zone or "all").
    2. -
  2. DEST - The name of a destination zone (a zone defined -in the /etc/shorewall/zones file , the name of the firewall zone or "all"). Shorewall -automatically allows all traffic from the firewall to itself so the name of the firewall zone cannot appear in both the -SOURCE and DEST columns.
    3. -
  3. POLICY - The default policy for connection requests -from the SOURCE zone to the DESTINATION zone.
    4. -
  4. LOG LEVEL - Optional. If left empty, no log message is -generated when the policy is applied. Otherwise, this column should -contain an integer or name indicating a syslog level.
    5. -
  5. LIMIT:BURST - Optional. If left empty, TCP connection -requests from the SOURCE zone to the DEST zone will not -be rate-limited. Otherwise, this column specifies the maximum rate at -which TCP connection requests will be accepted followed by a colon -(":") followed by the maximum burst size that will be tolerated. -Example: 10/sec:40 specifies that the maximum rate of TCP -connection requests allowed will be -10 per second and a burst of 40 connections will be tolerated. -Connection requests in excess of these limits will be dropped. See the rules file documentation for an explaination of how -rate limiting works.
    -
    6. -
-

In the SOURCE and DEST columns, you can enter "all" to indicate all -zones.

-

The policy file installed by default is as follows:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDEST POLICY LOG LEVELLIMIT:BURST
locnetACCEPT
-
-
netallDROPinfo
-
allallREJECTinfo
-
-
-

This table may be interpreted as follows:

- -

WARNING:

-

The firewall script processes the -/etc/shorewall/policy file from top to bottom and uses the first -applicable policy that it finds. For example, in the following -policy file, the policy for (loc, loc) connections would be ACCEPT as -specified in the first entry even though the third entry in the file -specifies REJECT.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVELLIMIT:BURST
locallACCEPT
-
-
netallDROPinfo
-
loclocREJECTinfo
-
-
-

IntraZone Traffic

-Shorewall allows a zone to be associated with more than one interface -or with multiple networks that interface through a single interface. -Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all traffic from -a zone to itself provided that there is -no explicit policy governing traffic from that zone to itself (an -explicit policy does not specify "all" in either the SOURCE or DEST -column) and that there are no rules concerning connections from that -zone to itself. If there is an explicit policy or if there are one or -more rules, then traffic within the zone is handled just like traffic -between zones is.
-

Any time that you have multiple interfaces associated with a single -zone, you should ask yourself if you really want traffic routed between -those interfaces. Cases where you might not want that behavior are:
-

-
    -
  1. Multiple 'net' interfaces to different ISPs. You don't want to -route traffic from one ISP to the other through your firewall.
    2. -
  2. Multiple VPN clients. You don't necessarily want them to all be -able to communicate between themselves using your gateway/router.
    -
    3. -
-

The CONTINUE policy

-

Where zones are nested or overlapping , the -CONTINUE policy allows hosts that are within multiple zones to be -managed under the rules of all of these zones. Let's look at an example:

-

/etc/shorewall/zones:

-
- - - - - - - - - - - - - - - - - - - - - - - -
ZONE DISPLAY COMMENTS
samSamSam's system at home
netInternetThe Internet
locLocLocal Network
-
-

/etc/shorewall/interfaces:

-
- - - - - - - - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
-
-
-

/etc/shorewall/hosts:

-
- - - - - - - - - - - - - - - - - - -
ZONE HOST(S) OPTIONS
neteth0:0.0.0.0/0
-
sameth0:206.191.149.197
-
-
-

Note that Sam's home system is a member of both the sam -zone and the net zone and as described above -, that means that sam must be listed before net in -/etc/shorewall/zones.

-

/etc/shorewall/policy:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCE DEST POLICY LOG LEVEL
locnetACCEPT
-
samallCONTINUE
-
netallDROPinfo
allallREJECTinfo
-
-

The second entry above says that when Sam is the client, connection -requests should first be process under rules where the source zone is sam -and if there is no match then the connection request should be treated -under rules where the source zone is net. It is important that -this policy be listed BEFORE the next policy (net to all).

-

Partial /etc/shorewall/rules:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET
...
-
-
-
-
-
-
-
-
DNATsamloc:192.168.1.3tcpssh-
-
-
-
DNATnetloc:192.168.1.5tcpwww-
-
-
-
...
-
-
-
-
-
-
-
-
-
-

Given these two rules, Sam can connect to the firewall's internet -interface with ssh and the connection request will be forwarded to -192.168.1.3. Like all hosts in the net -zone, Sam can connect to the firewall's internet interface on TCP port -80 and the connection request will be forwarded to 192.168.1.5. The -order of the rules is not significant.

-

Sometimes it is necessary to suppress port -forwarding for a sub-zone. For example, suppose that all hosts can SSH -to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam -connects to the firewall's external IP, he should be connected to the -firewall itself. Because of the way that Netfilter is constructed, this -requires two rules as follows:

-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET

-
-
-
-
-
-
-
-
-
...
-
-
-
-
-
-
-
-
DNATsamfwtcpssh-
-
-
-
DNATnet!samloc:192.168.1.3tcpssh-
-
-
-
...
-
-
-
-
-
-
-
-
-
-

The first rule allows Sam SSH access to the firewall. The second -rule says that any clients from the net zone with the exception of -those in the 'sam' zone should have their connection port forwarded to -192.168.1.3. If you need to exclude more than one zone in this way, you -can list the zones separated by commas (e.g., net!sam,joe,fred). This -technique also may be used when the ACTION is REDIRECT.

-

/etc/shorewall/rules

-

The /etc/shorewall/rules file defines exceptions to the policies -established in the /etc/shorewall/policy file. There is one entry in -/etc/shorewall/rules for each of these rules.
-

-

Shorewall automatically enables firewall->firewall traffic over -the loopback interface (lo) -- that traffic cannot be regulated using -rules and any rule that tries to regulate such traffic will generate a -warning and will be ignored.
-

-

Entries in the file have the following columns:

- -

Example 1. You wish to forward -all ssh connection requests from the internet to local system -192.168.1.3.  You wish to limit the number of connections to -4/minute with a burst of 8 (Shorewall 1.4.7 and later only):

-
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET
-
DNAT<4/min:8>netloc:192.168.1.3tcpssh
-
-
-
-
-
-

Example 2. You want to redirect all local www connection -requests EXCEPT those to your own http server (206.124.146.177) to a -Squid transparent proxy running on the firewall and listening on port -3128. Squid will of course require access to remote web servers. This -example shows yet another use for the ORIGINAL DEST column; here, -connection requests that were NOT (notice -the "!") originally destined to 206.124.146.177 are redirected to -local port 3128.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET
-
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
-
-
ACCEPTfwnettcpwww
-
-
-
-
-
-

Example 3. You want to run a web server at 155.186.235.222 -in your DMZ and have it accessible remotely and locally. the DMZ is -managed by Proxy ARP or by classical sub-netting.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET
ACCEPTnetdmz:155.186.235.222tcpwww-
-
-
-
ACCEPTlocdmz:155.186.235.222tcpwww
-
-
-
-
-
-

Example 4. You want to run wu-ftpd on 192.168.2.2 in your -masqueraded DMZ. Your internet interface address is 155.186.235.151 and -you want the FTP server to be accessible from the internet in addition -to the local 192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks. Note -that since the server is in the 192.168.2.0/24 subnetwork, we can -assume that access to the server from that subnet will not involve the -firewall (but see FAQ 2). Note that unless -you have more than one external IP address, you can leave the ORIGINAL -DEST column blank in the first rule. You cannot leave it blank in the -second rule though because then all ftp connections originating -in the local subnet 192.168.1.0/24 would be sent to 192.168.2.2 -regardless of the site that the user was trying to connect to. That -is clearly not what you want .

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET
DNATnetdmz:192.168.2.2tcpftp
-
-
-
-
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-155.186.235.151
-
-
-
-

If you are running wu-ftpd, you should restrict the range of passive -in your /etc/ftpaccess file. I only need a few simultaneous FTP -sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry -is appropriate:

-
-

passive ports 0.0.0.0/0 65500 65534

-
-

If you are running pure-ftpd, you would include "-p 65500:65534" on -the pure-ftpd runline.

-

The important point here is to ensure that the port range used for -FTP passive connections is unique and will not overlap with any usage -on the firewall system.

-

Example 5. You wish to allow unlimited DMZ access to the -host with MAC address 02:00:08:E3:FA:55.

-
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
-PORT(S)		SOURCE
-PORT(S)		ORIGINAL
-DEST		RATE
-LIMIT
- 		USER
-SET
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-
-
-
-
-
-
-Example 6. You wish to allow access to the SMTP server in your -DMZ from all zones.
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
-PORT(S)
- 		SOURCE
-PORT(S)
- 		ORIGINAL
-DEST
- 		RATE
-LIMIT
- 		USER
-SET
ACCEPT
- 		all
- 		dmz
- 		tcp
- 		25
-
-
-
-
-
-
-Note: When 'all' is used as a source or destination, intra-zone traffic -is not affected. In this example, if there were two DMZ interfaces then -the above rule would NOT enable SMTP traffic between -hosts on these interfaces.
-
-Example 7. Your firewall's external interface has several IP -addresses but you only want to accept SSH connections on address -206.124.146.176.
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
-PORT(S)
- 		SOURCE
-PORT(S)
- 		ORIGINAL
-DEST
- 		RATE
-LIMIT
- 		USER
-SET
ACCEPT
- 		net
- 		fw:206.124.146.176
- 		tcp
- 		22
-
-
-
-
-
-
-Example 8 (For advanced users running Shorewall version 1.3.13 or -later). From the internet, you with to forward tcp port 25 -directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your -DMZ. You also want to allow access from the internet directly to tcp -port 25 on 192.0.2.177.
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
-PORT(S)
- 		SOURCE
-PORT(S)
- 		ORIGINAL
-DEST
- 		RATE
-LIMIT
- 		USER
-SET
DNAT-
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
- 		0
- 		192.0.2.178
-
-
-
DNAT-
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
- 		0
- 		192.0.2.179
-
-
-
ACCEPT
- 		net
- 		dmz:192.0.2.177
- 		tcp
- 		25
-
-
-
-
-
-
-Using "DNAT-" rather than "DNAT" avoids two extra copies of the third -rule from being generated.
-
-Example 9 (Shorewall version 1.4.6 or later). You have 9 -http servers behind a Shorewall firewall and you want connection -requests to be distributed among your servers. The servers are -192.168.1.101-192.168.1.109.
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
-PORT(S)
- 		SOURCE
-PORT(S)
- 		ORIGINAL
-DEST
- 		RATE
-LIMIT
- 		USER
-SET
DNAT
- 		net
- 		loc:192.168.1.101-192.168.1.109
- 		tcp
- 		80
-
-
-
-
-
-
-

Look here for information on other services. -

-

/etc/shorewall/common

-

Shorewall allows definition of rules that apply between all zones. -By default, these rules are defined in the file -/etc/shorewall/common.def but may be modified to suit individual -requirements. Rather than modify /etc/shorewall/common.def, you should -copy that file to /etc/shorewall/common and modify that file.

-

The /etc/shorewall/common file is expected to contain iptables -commands; rather than running iptables directly, you should run it -indirectly using the Shorewall function 'run_iptables'. That way, if -iptables encounters an error, the firewall will be safely stopped.

-

/etc/shorewall/masq

-

The /etc/shorewall/masq file is used to define classical IP -Masquerading and Source Network Address Translation (SNAT). There is -one entry in the file for each subnet that you want to masquerade. In -order to make use of this feature, you must have NAT -enabled .

-

Columns are:

- -

Example 1: You have eth0 connected to a cable modem and -eth1 connected to your local subnetwork 192.168.9.0/24. Your -/etc/shorewall/masq file would look like:

-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.9.0/24
-
-
-

Example 2: You have a number of IPSEC tunnels through ipsec0 -and you want to masquerade traffic from your 192.168.9.0/24 subnet to -the remote subnet 10.1.0.0/16 only.

-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
ipsec0:10.1.0.0/16192.168.9.0/24
-
-
-

Example 3: You have a DSL line connected on eth0 and a local -network (192.168.10.0/24) connected to eth1. You want all local->net -connections to use source address 206.124.146.176.

-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24206.124.146.176
-
-

Example 4: Same as example 3 except that you wish to -exclude 192.168.10.44 and 192.168.10.45 -from the SNAT rule.

-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
-
-Example 5 (Shorewall version >= 1.3.14): You have a second -IP address (206.124.146.177) assigned to you and wish to use it for -SNAT of the subnet 192.168.12.0/24. You want to give that address the -name eth0:0. You must have ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0:0192.168.12.0/24206.124.146.177
-
-Example 6 (Shorewall version >= -1.4.7): You want to use both 206.124.146.177 and -206.124.146.179 for SNAT of the subnet 192.168.12.0/24. Each address -will be used on alternate outbound connections.
-
- - - - - - - - - - - - - -
INTERFACE SUBNETADDRESS
eth0192.168.12.0/24206.124.146.177,206.124.146.179
-
-

/etc/shorewall/proxyarp

-

If you want to use proxy ARP on an entire sub-network, I suggest -that you look at -http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. If you decide to -use the technique described in that HOWTO, you can set the proxy_arp -flag for an interface (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) -by including the proxyarp option in the interface's record in /etc/shorewall/interfaces. When using Proxy -ARP sub-netting, you do NOT include any entries in -/etc/shorewall/proxyarp.

-

The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for -enabling Proxy ARP on a -small set of systems -since you need -one entry in this file for each system using proxy ARP. Columns are:

- -

Note: After you have made a change to the -/etc/shorewall/proxyarp file, you may need to flush the ARP cache of -all routers on the LAN segment connected to the interface specified in -the EXTERNAL column of the change/added entry(s). If you are having -problems communicating between an individual host (A) on that segment -and a system whose entry has changed, you may need to flush the ARP -cache on host A as well.

-

ISPs typically have ARP configured with -long TTL (hours!) so if your ISPs router has a stale cache entry (as -seen using "tcpdump -nei <external interface> host <IP -addr>"), it may take a long -while to time out. I personally have had to contact my ISP and ask them -to delete a stale entry in order to restore a system to working order -after -changing my proxy ARP settings.

-

Example: You have public IP addresses 155.182.235.0/28. You -configure your firewall as follows:

- -

In your DMZ, you want to install a Web/FTP server with public -address 155.186.235.4. On the Web server, you subnet just like the -firewall's eth0 and you configure 155.186.235.1 as the default gateway. -In your /etc/shorewall/proxyarp file, you will have:

-
- - - - - - - - - - - - - - - -
ADDRESS INTERFACE EXTERNALHAVEROUTE
155.186.235.4eth2eth0No
-
-

Note: You may want to configure the servers in your DMZ with a -subnet that is smaller than the subnet of your internet interface. See -the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) -for details. In this case you will want to place "Yes" in the HAVEROUTE -column.

-

Warning: Do not use Proxy ARP -and FreeS/Wan -on the same system unless you are prepared to suffer the consequences. -If you start or restart Shorewall with an IPSEC tunnel active, the -proxied IP addresses are mistakenly assigned to the IPSEC tunnel device -(ipsecX) rather than to the interface that you specify in the INTERFACE -column of /etc/shorewall/proxyarp. I haven't had the time to debug this -problem so I can't say if it is a bug in the Kernel or in FreeS/Wan.

-

You might be able to work around this problem using the -following (I haven't tried it):

-

In /etc/shorewall/init, include:

-

qt service ipsec stop

-

In /etc/shorewall/start, include:

-

qt service ipsec start

-

/etc/shorewall/nat

-

The /etc/shorewall/nat file is used to define one-to-one NAT. There -is -one entry in the file for each one-to-one NAT relationship that you -wish to -define. In order to make use of this feature, you must have NAT enabled .

-

IMPORTANT: If all you want to do is -forward ports to servers behind your firewall, you do NOT want to use -one-to-one NAT. Port forwarding can be accomplished with simple entries -in -the rules file. Also, in most cases Proxy ARP provides a superior solution to -one-to-one NAT because the internal systems are accessed using the same -IP address -internally and externally.

-

Columns in an entry are:

- -

Look here for additional information and an -example.

-

/etc/shorewall/tunnels

-

The /etc/shorewall/tunnels file allows you to define IPSec, GRE, -IPIP, OpenVPN, PPTP and -6to4.tunnels with end-points on your firewall. To use ipsec, you must -install version 1.9, 1.91 or the current FreeS/WAN development -snapshot. -

-

Note: For kernels 2.4.4 and above, you will need to use version -1.91 or a development snapshot as patching with version 1.9 results in -kernel compilation errors.

-

Instructions for setting up IPSEC tunnels -may be found here, instructions for IPIP -and GRE tunnels are here, instructions -for OpenVPN tunnels are here, instructions -for PPTP tunnels are here, instructions for -6to4 tunnels are here and instructions -for integrating Shorewall with other types of tunnels are here.
-

-

/etc/shorewall/shorewall.conf

-

This file is used to set the following firewall parameters:

- -

/etc/shorewall/modules Configuration

-

The file /etc/shorewall/modules contains commands for loading the -kernel modules required by Shorewall-defined firewall rules. Shorewall -will source this file during start/restart provided that it exists and -that the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).

-

The file that is released with Shorewall calls the Shorewall -function "loadmodule" for the set of modules that I load.

-

The loadmodule function is called as follows:

-
-

loadmodule <modulename> [ <module -parameters> ]

-
-

where

-
-

<modulename>

-
-

is the name of the modules without the trailing ".o" (example -ip_conntrack).

-
-

<module parameters>

-
-

Optional parameters to the insmod utility.

-
-
-

The function determines if the module named by <modulename> - is already loaded and if not then the function determines if the -".o" file corresponding to the module exists in the moduledirectory; -if so, then the following command is executed:

-
-

insmod moduledirectory/<modulename>.o <module -parameters>

-
-

If the file doesn't exist, the function determines of the ".o.gz" -file corresponding to the module exists in the moduledirectory. -If -it does, the function assumes that the running configuration supports -compressed modules and execute the following command:

-
-

insmod moduledirectory/<modulename>.o.gz <module -parameters>

-
-

/etc/shorewall/tos Configuration

-

The /etc/shorewall/tos file allows you to set the Type of Service -field in packet headers based on packet source, packet destination, -protocol, source port and destination port. In order for this file to -be processed by Shorewall, you must have mangle -support enabled .

-

Entries in the file have the following columns:

- -
-
-

Minimize-Delay (16)
-Maximize-Throughput (8)
-Maximize-Reliability (4)
-Minimize-Cost (2)
-Normal-Service (0)

-
-
-

The /etc/shorewall/tos file that is included with Shorewall -contains the following entries.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPROTOCOLSOURCE
-PORT(S)		DEST PORT(S)TOS
allalltcp-ssh16
allalltcpssh-16
allalltcp-ftp16
allalltcpftp-16
allalltcp-ftp-data8
allalltcpftp-data-8
-
-

WARNING: Users have reported that odd routing problems -result from adding the ESP and AH protocols to the /etc/shorewall/tos -file.

-

/etc/shorewall/blacklist

-

Each line in /etc/shorewall/blacklist contains an IP address, a MAC -address in Shorewall Format -or subnet address. Example:

-
      130.252.100.69
      206.124.146.0/24
-

Packets from hosts listed in the blacklist file will -be disposed of according to the value assigned to the BLACKLIST_DISPOSITION -and BLACKLIST_LOGLEVEL variables in -/etc/shorewall/shorewall.conf. Only packets arriving on interfaces that -have the 'blacklist' option in -/etc/shorewall/interfaces are checked against the blacklist. The black -list is designed to prevent listed hosts/subnets from accessing -services on your network.
-

-

Beginning with Shorewall 1.3.8, the blacklist file has three columns:
-

- -

Shorewall also has a dynamic -blacklist capability.

-

IMPORTANT: The Shorewall blacklist file is NOT -designed to police your users' web browsing -- to do that, I suggest -that you install and configure Squid (http://www.squid-cache.org) with -SquidGuard (http://www.squidguard.org/). -

-

/etc/shorewall/rfc1918 (Added in Version -1.3.1)

-

This file lists the subnets affected by the norfc1918 -interface option. Columns in the file are:

- -

/etc/shorewall/routestopped (Added in -Version 1.3.4)

-

This file defines the hosts that are accessible from the firewall -when the firewall is stopped. Columns in the file are:

- -

Example: When your firewall is stopped, you want firewall -accessibility from local hosts 192.168.1.0/24 and from your DMZ. Your -DMZ interfaces through eth1 and your local hosts through eth2.

-
- - - - - - - - - - - - - - - -
INTERFACEHOST(S)
eth2192.168.1.0/24
eth1-
-
-

/etc/shorewall/maclist (Added in Version -1.3.10)

-This file is described in the MAC -Validation Documentation.
-

/etc/shorewall/ecn (Added in Version 1.4.0)

-This file is described in the ECN Control -Documentation.
-

Updated 12/08/2003 - Tom -Eastep -

-

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

- -