- .| + |
Shorewall 1.3 Reference- |
-
Shorewall consists of the following components:
+ + + + + +Shorewall consists of the following components:
+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.
- + 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
- + within the Shorewall programs +Example:
- +NET_IF=eth0- +
NET_BCAST=130.252.100.255
NET_OPTIONS=noping,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 noping,norfc1918- +
Variables may be used anywhere in the other configuration - files.
- + files. +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:
- + 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 | -
| net | -Net | -Internet | -
| loc | -Local | -Local networks | -
| dmz | -DMZ | -Demilitarized zone | -
| ZONE | +DISPLAY | +COMMENTS | +
| net | +Net | +Internet | +
| loc | +Local | +Local networks | +
| dmz | +DMZ | +Demilitarized 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.
- + 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".
- + 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.
- + significant in some cases. +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:
- + 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: + blacklist - This option causes incoming packets on this
interface to be checked against the blacklist.
-
- dhcp - The interface is assigned an IP address via DHCP or is
- used by a DHCP server running on the firewall. The firewall will
- be configured to allow DHCP traffic to and from the interface even
- when the firewall is stopped. You may also wish to use this option if you
- have a static IP but you are on a LAN segment that has a lot of Laptops
- that use DHCP and you select the norfc1918 option (see below).
noping - ICMP echo-request (ping) packets addressed to
- the firewall will be ignored by this interface.
-
- filterping - ICMP echo-request (ping) packets addressed to the
- firewall will be handled according to the /etc/shorewall/rules and
-/etc/shorewall/policy file. If the applicable policy is DROP or REJECT and
-you have supplied your own /etc/shorewall/icmpdef file then these 'ping'
-requests will be passed through the rules in that file before being dropped
-or rejected. If neither noping nor filterping is specified
-then the firewall will automatically ACCEPT these 'ping' requests. If both
- noping and filterping are specified, filterping
-takes precedence.
routestopped - Beginning with Shorewall 1.3.4, this option - is deprecated in favor of the /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from this interface - will be accepted and routing will occur between this interface and - other routestopped interfaces.
- + is deprecated in favor of the /etc/shorewall/routestopped + file. When the firewall is stopped, traffic to and from this interface + will be accepted and routing will occur between this interface and + other routestopped interfaces. + + norfc1918 - Packets arriving on this interface and that
- have a source address that is reserved in RFC 1918 or in other RFCs will
- be dropped after being optionally logged. If packet mangling
- is enabled in /etc/shorewall/shorewall.conf , then packets arriving
- on this interface that have a destination address that is reserved by
- one of these RFCs will also be logged and dropped.
-
- Addresses blocked by the standard rfc1918 file
- include those addresses reserved by RFC1918 plus other ranges reserved
- by the IANA or by other RFCs.
Beware that as IPv4 addresses become in increasingly short supply, - ISPs are beginning to use RFC 1918 addresses within their own infrastructure. - Also, many cable and DSL "modems" have an RFC 1918 address that can be - used through a web browser for management and monitoring functions. If - you want to specify norfc1918 on your external interface but need - to allow access to certain addresses from the above list, see norfc1918 on your external interface but need + to allow access to certain addresses from the above list, see FAQ 14.
- + +routefilter - Invoke the Kernel's route filtering - (anti-spoofing) facility on this interface. The kernel will reject - any packets incoming on this interface that have a source address -that would be routed outbound through another interface on the firewall. - Warning: If you specify this option - for an interface then the interface must be up prior to starting the - firewall.
- + (anti-spoofing) facility on this interface. The kernel will reject + any packets incoming on this interface that have a source address + that would be routed outbound through another interface on the firewall. + Warning: If you specify this option + for an interface then the interface must be up prior to starting the + firewall. + +multi - The interface has multiple addresses and - you want to be able to route between them. Example: you have two addresses - on your single local interface eth1, one each in subnets 192.168.1.0/24 - and 192.168.2.0/24 and you want to route between these subnets. Because - you only have one interface in the local zone, Shorewall won't normally - create a rule to forward packets from eth1 to eth1. Adding "multi" -to the entry for eth1 will cause Shorewall to create the loc2loc chain - and the appropriate forwarding rule.
- + you want to be able to route between them. Example: you have two +addresses on your single local interface eth1, one each in subnets +192.168.1.0/24 and 192.168.2.0/24 and you want to route between these +subnets. Because you only have one interface in the local zone, Shorewall +won't normally create a rule to forward packets from eth1 to eth1. +Adding "multi" to the entry for eth1 will cause Shorewall to create +the loc2loc chain and the appropriate forwarding rule. +dropunclean - Packets from this interface that
are selected by the 'unclean' match target in iptables will
be optionally logged and then dropped.
- Warning: This feature requires
- that UNCLEAN match support be configured in your kernel,
- either in the kernel itself or as a module. UNCLEAN support
- is broken in some versions of the kernel but appears
- to work ok in 2.4.17-rc1.
-
- Update 12/17/2001: The unclean match patch
- from 2.4.17-rc1 is Warning: This feature requires
+ that UNCLEAN match support be configured in your kernel,
+ either in the kernel itself or as a module. UNCLEAN
+ support is broken in some versions of the kernel but appears
+ to work ok in 2.4.17-rc1.
+
+ Update 12/17/2001: The unclean match
+patch from 2.4.17-rc1 is available
- for download. I am currently running this patch
-applied to kernel 2.4.16.
Update 12/20/2001: I've - seen a number of tcp connection requests with OPT (020405B40000080A...) - being dropped in the badpkt chain. This appears - to be a bug in the remote TCP stack whereby it is 8-byte - aligning a timestamp (TCP option 8) but rather than padding - with 0x01 it is padding with 0x00. It's a tough call -whether to deny people access to your servers because -of this rather minor bug in their networking software. -If you wish to disable the check that causes these connections - to be dropped, here's + seen a number of tcp connection requests with OPT +(020405B40000080A...) being dropped in the + badpkt chain. This appears to be a bug in +the remote TCP stack whereby it is 8-byte aligning +a timestamp (TCP option 8) but rather than padding with 0x01 + it is padding with 0x00. It's a tough call whether to deny + people access to your servers because of this rather minor + bug in their networking software. If you wish to disable +the check that causes these connections to be dropped, + here's a kernel patch against 2.4.17-rc2.
- +logunclean - This option works like dropunclean - with the exception that packets selected by the 'unclean' - match target in iptables are logged but not dropped. - The level at which the packets are logged is determined - by the setting of LOGUNCLEAN - and if LOGUNCLEAN has not been set, "info" is assumed.
- + with the exception that packets selected by the 'unclean' + match target in iptables are logged but not dropped. + The level at which the packets are logged is determined + by the setting of LOGUNCLEAN + and if LOGUNCLEAN has not been set, "info" is assumed. +proxyarp (Added in version 1.3.5) - This option causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp - and is used when implementing Proxy ARP Sub-netting -as described at http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do not set this option if you are implementing Proxy ARP through entries in - /etc/shorewall/proxyarp.
-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 ignore ping requests from the - internet and 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 -- -net -eth0 -detect -dhcp,noping,norfc1918,blacklist -- - - - - -loc -eth1 -detect --
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 ignore ping requests from the + internet and you want to check all packets entering from + the internet against the black list. + Your /etc/shorewall/interfaces file would be as follows:
-Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:
- - -+- -+- +
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- +net -ppp0 -- - ZONE +INTERFACE +BROADCAST +OPTIONS + ++ +net +eth0 +detect +dhcp,noping,norfc1918,blacklist ++ - +loc +eth1 +detect ++
Example 3: You have local interface eth1 with two IP - addresses - 192.168.1.1/24 and 192.168.12.1/24
- -+ +- +Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces + file would be:
+ + +- + +- -
- -ZONE -INTERFACE -BROADCAST -OPTIONS -- + +loc -eth1 -192.168.1.255,192.168.12.255 -- + +ZONE +INTERFACE +BROADCAST +OPTIONS ++ - - + + +net +ppp0 ++ + 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 ++ + + + +loc +eth1 +192.168.1.255,192.168.12.255 ++ /etc/shorewall/hosts - Configuration
- + 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: 90% of Shorewall users don't need to put entries in this file and 80% of those who try to add such entries do it wrong. Unless you are ABSOLUTELY SURE that you need entries in this file, don't touch it.
- +Columns in this file are:
- +-
- -- ZONE - A zone defined in the /etc/shorewall/zones - file.
-- HOST(S) - The name of a network interface followed by - a colon (":") followed by either:
- +- ZONE - A zone defined in the /etc/shorewall/zones + file.
+- HOST(S) - The name of a network interface followed +by a colon (":") followed by either:
+- -- -- -
- - -- An IP address (example - eth1:192.168.1.3)
- -- A subnet in the form <subnet address>/<width> - (example - eth2:192.168.2.0/2)
- - -The interface name much match an entry in /etc/shorewall/interfaces.
--
- - +- OPTIONS - A comma-separated list of options. Currently - only a single option is defined:
- -++ ++ +
+ + +- An IP address (example - eth1:192.168.1.3)
+ +- A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
+ + +The interface name much match an entry in /etc/shorewall/interfaces.
++
+ + +- OPTIONS - A comma-separated list of options.
+ +++ this host (these hosts) will be accepted and routing will occur between + this host and other routestopped interfaces and hosts.routestopped - Beginning with Shorewall 1.3.4, this option is deprecated in favor of the /etc/shorewall/routestopped file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will occur between - this host and other routestopped interfaces and hosts.
-
+
+ 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.
+ to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces + to the zone. - +Note 1: 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.
- +Note 2: The setting of the MERGE_HOSTS variable - in /etc/shorewall/shorewall.conf - has an important effect on how the host file is - processed. Please read the description of that + in /etc/shorewall/shorewall.conf + has an important effect on how the host file +is processed. Please read the description of that variable carefully.
- +Example:
- +Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:
- + you want to make into separate zones: +Your /etc/shorewall/interfaces file might look like:
- -+ +- -- - -- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -net -eth0 -detect -dhcp,noping,norfc1918 -- - - - - -- -eth1 -detect -- 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 -- -loc1 -eth1:192.168.1.0/25 -- - - - - - -loc2 -eth1:192.168.1.128/25 -routestopped -Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.
- - -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:
- - --
- - -- ACCEPT - The connection is allowed.
-- DROP - The connection request is ignored.
-- REJECT - The connection request is rejected with an -RST (TCP) or an ICMP destination-unreachable packet being returned -to the client.
-- CONTINUE - The connection is neither ACCEPTed, DROPped - nor REJECTed. CONTINUE may be used when one or both of the zones named - in the entry are sub-zones of or intersect with another zone. For more - information, see below.
- -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:
- - -- -
- - -- SOURCE - The name of a client - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
- -- DEST - The name of a destination - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
- -- POLICY - The default policy - for connection requests from the SOURCE zone to the DESTINATION zone.
- -- 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. See the syslog.conf man page for a description of -each log level.
- -- 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.
- - -In the SOURCE and DEST columns, you can enter "all" to indicate all - zones.
- - -The policy file installed by default is as follows:
- - -- -+- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- -loc -net -ACCEPT -- - - - -net -all -DROP -info -- - +all -all -REJECT -info -- ZONE +INTERFACE +BROADCAST +OPTIONS + ++ +net +eth0 +detect +dhcp,noping,norfc1918 ++ - +- +eth1 +detect ++
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.
- -+ ++ + +The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.
+ + +Your /etc/shorewall/hosts file might look like:
+ + ++- -- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- -loc -all -ACCEPT -- - - -net -all -DROP -info -- - + +loc -loc -REJECT -info -- + +ZONE +HOST(S) +OPTIONS ++ +loc1 +eth1:192.168.1.0/25 ++ + - +loc2 +eth1:192.168.1.128/25 +routestopped +- 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:
- -++ + +Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.
+ + +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:
+ + ++
+ + +- ACCEPT - The connection is allowed.
+- DROP - The connection request is ignored.
+- REJECT - The connection request is rejected with an + RST (TCP) or an ICMP destination-unreachable packet being returned + to the client.
+- CONTINUE - The connection is neither ACCEPTed, DROPped + nor REJECTed. CONTINUE may be used when one or both of the zones named + in the entry are sub-zones of or intersect with another zone. For +more information, see below.
+ +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:
+ + ++ +
+ + +- SOURCE - The name of a +client zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all").
+ +- DEST - The name of a destination + zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all").
+ +- POLICY - The default policy + for connection requests from the SOURCE zone to the DESTINATION zone.
+ +- 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. See the syslog.conf man page for a description of +each log level.
+ +- 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.
+ + +In the SOURCE and DEST columns, you can enter "all" to indicate all + zones.
+ + +The policy file installed by default is as follows:
+ + +++- -
-- -ZONE -DISPLAY -COMMENTS -- -sam -Sam -Sam's system at home -- -net -Internet -The Internet -- + +loc -Loc -Local Network -+ +SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST ++ +loc +net +ACCEPT ++ + + + +net +all +DROP +info ++ + - +all +all +REJECT +info ++
This table may be interpreted as follows:
+ +/etc/shorewall/interfaces:
+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.
+ ++- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -- -eth0 -detect -dhcp,noping,norfc1918 -- + +loc -eth1 -detect -routestopped -+ +SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST ++ +loc +all +ACCEPT ++ + + +net +all +DROP +info ++ + - +loc +loc +REJECT +info ++
/etc/shorewall/hosts:
++-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 -HOST(S) -OPTIONS -- -net -eth0:0.0.0.0/0 -- - + +sam -eth0:206.191.149.197 -routestopped -+ +ZONE +DISPLAY +COMMENTS ++ +sam +Sam +Sam's system at home ++ +net +Internet +The Internet ++ - +loc +Loc +Local Network +
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/interfaces:
-/etc/shorewall/policy:
- -+-+- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -- -loc -net -ACCEPT -- - -sam -all -CONTINUE -- - -net -all -DROP -info -- + +all -all -REJECT -info -+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +- +eth0 +detect +dhcp,noping,norfc1918 ++ - - +loc +eth1 +detect +routestopped +
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).
+/etc/shorewall/hosts:
-Partial /etc/shorewall/rules:
- -+-+- -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- -... -- - - - - - - -DNAT -sam -loc:192.168.1.3 -tcp -ssh -- -- - -DNAT -net -loc:192.168.1.5 -tcp -www -- -- - + +... -- - - - - - + +ZONE +HOST(S) +OPTIONS ++ +net +eth0:0.0.0.0/0 ++ + - +sam +eth0:206.191.149.197 +routestopped +
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:
- --+- 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:
+ ++ face="Century Gothic, Arial, Helvetica">- -
- +ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- -- - - - - - - - -... -- - - - - - - -DNAT -sam -fw -tcp -ssh -- -- - -DNAT -net!sam -loc:192.168.1.3 -tcp -ssh -- -- - +... -- - - - - - SOURCE +DEST +POLICY +LOG LEVEL + ++ +loc +net +ACCEPT ++ + +sam +all +CONTINUE ++ + +net +all +DROP +info ++ - - + + + +all +all +REJECT +info +
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:
+ +++ ++ +
++ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ +... ++ + + + + + + +DNAT +sam +loc:192.168.1.3 +tcp +ssh +- ++ + +DNAT +net +loc:192.168.1.5 +tcp +www +- ++ + + + + + + + +... ++ + + + + +
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:
+ ++++ +
+ +
++ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ ++ + + + + + + + +... ++ + + + + + + +DNAT +sam +fw +tcp +ssh +- ++ + +DNAT +net!sam +loc:192.168.1.3 +tcp +ssh +- ++ + + + + + +... ++ + + + + +
The first rule allows Sam SSH access to the firewall. The second rule says that any clients from the @@ -1106,387 +1135,392 @@ be listed before net 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.
+ 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. +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.
+ in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules + for each of these rules. - +Entries in the file have the following columns:
- +The ACTION may optionally be followed by ":" and a syslogd log
- level (example: REJECT:info). This causes the packet to be logged at
-the specified level prior to being processed according to the specified
-ACTION.
-
- The use of DNAT or REDIRECT requires that you have
+
+ The use of DNAT or REDIRECT requires that you have NAT enabled.
-
Example 1. You wish to forward all - ssh connection requests from the internet to local system 192.168.1.3.
- + ssh connection requests from the internet to local system 192.168.1.3. ++ face="Century Gothic, Arial, Helvetica">- -- -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- - - - - - - -DNAT -net -loc:192.168.1.3 -tcp -ssh -- -
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.
- --- -- +
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL +
- DESTACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL
+ DEST- -REDIRECT -loc -3128 -tcp -www -- !206.124.146.177 -- - - - - - - -ACCEPT -fw -net -tcp -www -- -
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.
- --- - -- -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- -ACCEPT -net -dmz:155.186.235.222 -tcp -www -- -- - +ACCEPT -loc -dmz:155.186.235.222 -tcp -www -- - + - +DNAT +net +loc:192.168.1.3 +tcp +ssh ++ +
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
-
- .
++ +
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.
+ ++ +- -
+- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- -DNAT -net -dmz:192.168.2.2 -tcp -ftp -- - - + +DNAT -loc:192.168.1.0/24 -dmz:192.168.2.2 -tcp -ftp -- -155.186.235.151 -+ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ +REDIRECT +loc +3128 +tcp +www ++ !206.124.146.177 ++ + + + +ACCEPT +fw +net +tcp +www ++ +
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.
+ + +++ + + ++ +
-+ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ +ACCEPT +net +dmz:155.186.235.222 +tcp +www +- ++ + + + +ACCEPT +loc +dmz:155.186.235.222 +tcp +www ++ +
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
+ .
++ + ++ +
++ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ +DNAT +net +dmz:192.168.2.2 +tcp +ftp ++ + + - + + + + +DNAT +loc:192.168.1.0/24 +dmz:192.168.2.2 +tcp +ftp +- +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:
+ 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 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.
+ 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 @@ -1494,51 +1528,51 @@ though because then 02:00:08:E3:FA:55.
- ++ face="Century Gothic, Arial, Helvetica">+ - +- -
-- +ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- +ACCEPT -loc:~02-00-08-E3-FA-55 -dmz -all -- - - ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL + +
+ DEST+ - - + +ACCEPT +loc:~02-00-08-E3-FA-55 +dmz +all ++ + +
Look here for information on other services. -
+ - +Shorewall allows definition of rules that apply between all zones. @@ -1548,157 +1582,160 @@ though because then 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.
+ 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.
+ 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. - +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 .
+ 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:
+ connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq + file would look like: - +- +- - -- -
-- -INTERFACE -SUBNET -ADDRESS -- - - - - - - -eth0 -192.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 -SUBNET -ADDRESS -- +ipsec0:10.1.0.0/16 -192.168.9.0/24 -- INTERFACE +SUBNET +ADDRESS + ++ + -eth0 +192.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 +SUBNET +ADDRESS ++ + + + + + + + +ipsec0:10.1.0.0/16 +192.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 + network (192.168.10.0/24) + connected to eth1. You want all local->net connections to use source address 206.124.146.176.
- -+ +- ++- -
-- +INTERFACE -SUBNET -ADDRESS -- +eth0 -192.168.10.0/24 -206.124.146.176 -INTERFACE +SUBNET +ADDRESS + ++ - - + +eth0 +192.168.10.0/24 +206.124.146.176 +
Example 4: Same as example 3 except that you wish @@ -1708,34 +1745,34 @@ all local->net the SNAT rule.
- +- ++ - +- -
-- +INTERFACE -SUBNET -ADDRESS -- +eth0 -192.168.10.0/24!192.168.10.44,192.168.10.45 -206.124.146.176 -INTERFACE +SUBNET +ADDRESS + ++ - - + +eth0 +192.168.10.0/24!192.168.10.44,192.168.10.45 +206.124.146.176 +
If you want to use proxy ARP on an entire sub-network, @@ -1744,30 +1781,30 @@ all local->net 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 + 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. -
+ 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 @@ -1775,47 +1812,47 @@ record in - + 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.
+ 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 @@ -1824,92 +1861,94 @@ 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:
- + 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:
+ 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 -EXTERNAL -HAVEROUTE -- + + +155.186.235.4 -eth2 -eth0 -No -+ +ADDRESS +INTERFACE +EXTERNAL +HAVEROUTE ++ + - +155.186.235.4 +eth2 +eth0 +No +
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.
- + for details. In this case you will want to place "Yes" in the HAVEROUTE + column. +To learn how I use Proxy ARP in my DMZ, see my configuration files.
- +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.
- + 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):
- + (I haven't tried it): +In /etc/shorewall/init, include:
- +qt service ipsec stop
- +In /etc/shorewall/start, include:
- +qt service ipsec start
- +The /etc/shorewall/nat file is used to define static NAT. There is one - entry in the file for each static NAT relationship that you wish to define. - In order to make use of this feature, you must have NAT enabled .
- +IMPORTANT: If @@ -1921,9 +1960,9 @@ I can't say if it is a bug in the Kernel or in FreeS/Wan. static NAT. Port forwarding can be accomplished - with simple - entries in - the rules file. Also, in most @@ -1938,387 +1977,397 @@ be accomplished are accessed using the same IP address internally - and externally.
+ and externally. - +Columns in an entry are:
- +Look here for additional information and an example. -
+ - +The /etc/shorewall/tunnels file allows you to define IPSec, GRE and - IPIP tunnels with end-points on your firewall. To use ipsec, you must -install version 1.9, 1.91 or the current The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP +and PPTP 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.
+ 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 and instructions for IPIP - tunnels are here . Look here for information - about setting up PPTP - tunnels under - Shorewall.
+ be found here, instructions for IPIP and +GRE tunnels are here and instructions for +PPTP tunnels are here. + +This file is used to set the following firewall parameters:
- +| ZONE | +HOSTS | +BROADCAST | +OPTIONS | +
| ZONE | -HOSTS | -BROADCAST | -OPTIONS | -
| loc | -eth1 | -- | -dhcp | -
| - | -ppp+ | -- | - | loc | +eth1 | +- | +dhcp | + +
| - | +ppp+ | ++ | + |
- Hosts File:
-
| ZONE | +HOSTS | +
| ZONE | -HOSTS | -
| loc | -ppp+:192.168.12.0/24 | -loc | +ppp+:192.168.12.0/24 | + + +
- With MERGE_HOSTS=No, the loc zone consists of only ppp+:192.168.12.0/24;
- with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 and ppp+:192.168.12.0/24.
-
Rules not meeting those criteria will continue to generate an individual - rule for each listed port or port range.
-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).
+ 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.
+ "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:
+ 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: - +- ++ parameters> + - +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 @@ -2504,391 +2553,399 @@ it does, the function assumes that the running configuration supports compress - +
- ++ parameters> + - +insmod moduledirectory/<modulename>.o.gz <module - parameters>
-
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 + 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:
- +- ++ Maximize-Throughput (8)- +-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.
+ the following entries. - -+ +- ++- + -
-- -SOURCE -DEST -PROTOCOL -SOURCE -
- PORT(S)DEST PORT(S) -TOS -- -all -all -tcp -- -ssh -16 -- -all -all -tcp -ssh -- -16 -- -all -all -tcp -- -ftp -16 -- -all -all -tcp -ftp -- -16 -- -all -all -tcp -- -ftp-data -8 -- +all -all -tcp -ftp-data -- -8 -+ +SOURCE +DEST +PROTOCOL +SOURCE +
+ PORT(S)DEST PORT(S) +TOS ++ +all +all +tcp +- +ssh +16 ++ +all +all +tcp +ssh +- +16 ++ +all +all +tcp +- +ftp +16 ++ +all +all +tcp +ftp +- +16 ++ +all +all +tcp +- +ftp-data +8 ++ - + - +all +all +tcp +ftp-data +- +8 +
WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos file.
+ adding the ESP and AH protocols to the /etc/shorewall/tos file. - +Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall - Format - or - subnet - address. - Example:
+ 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
+ the
+ blacklist
+ file
+ will
+ be
+ disposed
- of
- according
- to
- the
- value
- assigned
+ of
+ according
+ to
+ the
+ value
+ assigned
- to
- the BLACKLIST_DISPOSITION
- and
- BLACKLIST_LOGLEVEL variables
- in
- /etc/shorewall/shorewall.conf.
+ to
+ the BLACKLIST_DISPOSITION
- Only
- packets
- arriving
- on
- interfaces
+and BLACKLIST_LOGLEVEL variables
+ in
+ /etc/shorewall/shorewall.conf.
+
+ Only
+ packets
+ arriving
+ on
+ interfaces
that
have
the
'blacklist'
- option
- in
- /etc/shorewall/interfaces
- are
+ option
+ in
+ /etc/shorewall/interfaces
+ are
- checked
- against
- the
- blacklist. The black list is
+ 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.
+ 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). -
+ designed to police your users' web browsing -- to do that, I suggest that + you install and configure Squid (http://www.squid-cache.org). + - +This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:
+ interface option. Columns in the file are: - +This fine defines the hosts that are accessible from the firewall when - the firewall is stopped. Columns in the file are:
+ +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.
+ from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces through + eth1 and your local hosts through eth2. - +- ++ - -- -
-+ +- + -INTERFACE +INTERFACE -HOST(S) +HOST(S) -+ - + -eth2 +eth2 -192.168.1.0/24 +192.168.1.0/24 -+ - + - - + +eth1 +eth1 -- +- -
Updated 9/28/2002 - Tom Eastep -
+ +Updated 10/28/2002 - Tom Eastep +
- +Copyright - © 2001, 2002 Thomas M. Eastep.
+ © 2001, 2002 Thomas M. Eastep. -| + |
+
Shorewall FAQs- |
-
1a. Ok -- I followed those instructions - but it doesn't work.
- - - - - -3. I want to use Netmeeting/MSN -Messenger with Shorewall. What do I do?
- - - -4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports as open!!!!
- -5. I've installed Shorewall and now -I can't ping through the firewall
- -6. Where are the log messages - written and how do I change the destination?
- -6a. Are there any log parsers - that work with Shorewall?
- - - -8. When I try to start Shorewall -on RedHat 7.x, I get messages about insmod failing -- what's wrong?
- -9. Why can't Shorewall detect -my interfaces properly?
- -10. What distributions does -it work with?
- -11. What features does it -support?
- + + + +1a. Ok -- I followed those instructions
+ but it doesn't work.
+
1b. I'm still having problems with +port forwarding
+ + + + + +3. I want to use Netmeeting/MSN + Messenger with Shorewall. What do I do?
+ + + +4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as open!!!!
+ +5. I've installed Shorewall and now + I can't ping through the firewall
+ +6. Where are the log messages + written and how do I change the destination?
+ +6a. Are there any log parsers + that work with Shorewall?
+ + + +8. When I try to start Shorewall + on RedHat 7.x, I get messages about insmod failing -- what's wrong?
+ +9. Why can't Shorewall detect + my interfaces properly?
+ +10. What distributions does + it work with?
+ +11. What features does it + support?
+ - +13. Why do you call it "Shorewall"?
- - - - - -15. My local systems can't see -out to the net
- -16. Shorewall is writing log messages - all over my console making it unusable!
- -15. My local systems can't see + out to the net
+ +16. Shorewall is writing log messages
+ all over my console making it unusable!
+
Answer: The first example in the rules file documentation shows how to -do port forwarding under Shorewall. Assuming that you have a dynamic external -IP address, the format of a port-forwarding rule to a local system is as follows:
- -+ href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a port-forwarding +rule to a local system is as follows: + ++ +- -- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -net -loc:<local IP address>[:<local port>] -<protocol> -<port #> -- - + +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +net +loc:<local IP address>[:<local port>] +<protocol> +<port #> ++
++
+So to forward UDP port 7777 to internal system 192.168.1.5, -the rule is:
- -++ +So to forward UDP port 7777 to internal system 192.168.1.5, + the rule is:
+ +- -- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -net -loc:192.168.1.5 -udp -7777 -- - + +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +net +loc:192.168.1.5 +udp +7777 ++
++
++ + ++ +- -DNAT net loc:192.168.1.5 udp 7777-If you want to forward requests directed to a particular -address ( <external IP> ) on your firewall to an internal system:
- -+If you want to forward requests directed to a particular address +( <external IP> ) on your firewall to an internal system:
+ +- -- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -net -loc:<local IP address>[:<local port>] -<protocol> -<port #> -- -<external IP> -+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +net +loc:<local IP address>[:<local port>] +<protocol> +<port #> +- +<external IP> +1a. Ok -- I followed those instructions -but it doesn't work
- +
Answer: That is usually the result of one of two things:
- +Answer: I have two objections to this setup.
- +If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that your external interface is -eth0 and your internal interface is eth1 and that eth1 has IP address 192.168.1.254 -with subnet 192.168.1.0/24, do the following:
- -a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1.
- -If you insist on an IP solution to the accessibility problem + rather than a DNS solution, then assuming that your external interface + is eth0 and your internal interface is eth1 and that eth1 has IP address + 192.168.1.254 with subnet 192.168.1.0/24, do the following:
+ +a) In /etc/shorewall/interfaces, specify "multi" as an option + for eth1 (No longer required as of Shorewall version 1.3.9).
+ +b) In /etc/shorewall/rules, add:
-+
-- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -loc:192.168.1.0/24 -loc:192.168.1.5 -tcp -www -- -130.151.100.69:192.168.1.254 -+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +loc:192.168.1.0/24 +loc:192.168.1.5 +tcp +www +- +130.151.100.69:192.168.1.254 +
DNAT loc:192.168.1.0/24 loc:192.168.1.5 tcp www - 130.151.100.69:192.168.1.254-
That rule only works of course if you have a static external -IP address. If you have a dynamic IP address and are running Shorewall 1.3.4 -or later then include this in /etc/shorewall/params:
-DNAT loc:192.168.1.0/24 loc:192.168.1.5 tcp www - 130.151.100.69:192.168.1.254+
That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and are running Shorewall + 1.3.4 or later then include this in /etc/shorewall/params:
+ETH0_IP=`find_interface_address eth0`-
and make your DNAT rule:
-+
-- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -loc:192.168.1.0/24 -loc:192.168.1.5 -tcp -www -- -$ETH0_IP:192.168.1.254 -+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +loc:192.168.1.0/24 +loc:192.168.1.5 +tcp +www +- +$ETH0_IP:192.168.1.254 +
Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each time that you get a new IP - address.
-Answer: This is another problem that is best solved -using Bind Version 9 "views". It allows both external and internal clients -to access a NATed host using the host's DNS name.
- -Another good way to approach this problem is to switch from - static NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918 addresses -and can be accessed externally and internally using the same address.
- -If you don't like those solutions and prefer routing all Z->Z -traffic through your firewall then:
- -a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces.
- b) Set the Z->Z policy to ACCEPT.
- c) Masquerade Z to itself.
-
- Example:
Using this technique, you will want to configure your DHCP/PPPoE + client to automatically restart Shorewall each time that you get a +new IP address.
+Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both external and internal clients + to access a NATed host using the host's DNS name.
+ +Another good way to approach this problem is to switch from + static NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918 addresses + and can be accessed externally and internally using the same address. +
+ +If you don't like those solutions and prefer routing all +Z->Z traffic through your firewall then:
+ +a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces
+(If you are running a Shorewall version earlier than 1.3.9).
+ b) Set the Z->Z policy to ACCEPT.
+ c) Masquerade Z to itself.
+
+ Example:
Zone: dmz
- Interface: eth2
- Subnet: 192.168.2.0/24
In /etc/shorewall/interfaces:
- -+ ++- +- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- - - + +dmz -eth2 -192.168.2.255 -multi -+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ + +dmz +eth2 +192.168.2.255 +multi +
In /etc/shorewall/policy:
- -+ ++ +- -- -
-- -SOURCE -DESTINATION -POLICY -LIMIT:BURST -- - - + +dmz -dmz -ACCEPT -- + +SOURCE +DESTINATION +POLICY +LIMIT:BURST ++ + +dmz +dmz +ACCEPT ++
+-- +dmz dmz ACCEPT-
dmz dmz ACCEPT+
In /etc/shorewall/masq:
- -+ ++ +- -- -
-- -INTERFACE -SUBNET -ADDRESS -- - - + +eth2 -192.168.2.0/24 -- + +INTERFACE +SUBNET +ADDRESS ++ + +eth2 +192.168.2.0/24 ++
+3. I want to use Netmeeting/MSN Messenger -with Shorewall. What do I do?
- +
Answer: There is an H.323 connection -tracking/NAT module that may help. Also check the Netfilter mailing list -archives at http://netfilter.samba.org. -
- -Answer: The common.def included with version 1.3.x -always rejects connection requests on TCP port 113 rather than dropping -them. This is necessary to prevent outgoing connection problems to services -that use the 'Auth' mechanism for identifying requesting users. Shorewall -also rejects TCP ports 135, 137 and 139 as well as UDP ports 137-139. These -are ports that are used by Windows (Windows can be configured to -use the DCE cell locator on port 135). Rejecting these connection requests -rather than dropping them cuts down slightly on the amount of Windows chatter -on LAN segments connected to the Firewall.
- -If you are seeing port 80 being 'closed', that's probably -your ISP preventing you from running a web server in violation of your -Service Agreement.
- -Answer: Take a deep breath and read the nmap man page -section about UDP scans. If nmap gets nothing back from your firewall -then it reports the port as open. If you want to see which UDP ports are -really open, temporarily change your net->all policy to REJECT, restart -Shorewall and do the nmap UDP scan again.
- -Answer: If you want your firewall to be totally open -for "ping":
- + href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help. Also check the Netfilter mailing + list archives at http://netfilter.samba.org. + + +Answer: The common.def included with version 1.3.x + always rejects connection requests on TCP port 113 rather than dropping + them. This is necessary to prevent outgoing connection problems to + services that use the 'Auth' mechanism for identifying requesting +users. Shorewall also rejects TCP ports 135, 137 and 139 as well as +UDP ports 137-139. These are ports that are used by Windows (Windows +can be configured to use the DCE cell locator on port 135). +Rejecting these connection requests rather than dropping them cuts +down slightly on the amount of Windows chatter on LAN segments connected + to the Firewall.
+ +If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web server in violation of +your Service Agreement.
+ +Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing back from your + firewall then it reports the port as open. If you want to see which + UDP ports are really open, temporarily change your net->all policy + to REJECT, restart Shorewall and do the nmap UDP scan again.
+ +Answer: If you want your firewall to be totally open + for "ping":
+a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
- b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
- c) Add the following to /etc/shorewall/icmpdef:
-- -run_iptables -A icmpdef -p ICMP --icmp-type echo-request --j ACCEPT
-
Answer: NetFilter uses the kernel's equivalent of syslog -(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility -(see "man openlog") and you get to choose the log level (again, see "man -syslog") in your policies and rules. The destination for messaged logged -by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). When -you have changed /etc/syslog.conf, be sure to restart syslogd (on a RedHat -system, "service syslog restart").
- -By default, older versions of Shorewall ratelimited log messages -through settings in /etc/shorewall/shorewall.conf --- If you want to log all messages, set:
- -++ +run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
+
Answer: NetFilter uses the kernel's equivalent of +syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern) +facility (see "man openlog") and you get to choose the log level (again, +see "man syslog") in your policies + and rules. The destination for messaged + logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). + When you have changed /etc/syslog.conf, be sure to restart syslogd (on + a RedHat system, "service syslog restart").
+ +By default, older versions of Shorewall ratelimited log messages + through settings in /etc/shorewall/shorewall.conf + -- If you want to log all messages, set:
+ +LOGLIMIT=""-
LOGBURST=""
Answer: Here are several links that may be helpful: -
- -+
Answer: Here are several links that may be helpful: +
+ +- -http://www.shorewall.net/pub/shorewall/parsefw/
-
- http://www.fireparse.com
- http://cert.uni-stuttgart.de/projects/fwlogwatch
The 'stop' command is intended to place your firewall into -a safe state whereby only those interfaces/hosts having the 'routestopped' -option in /etc/shorewall/interfaces and /etc/shorewall/hosts are activated. -If you want to totally open up your firewall, you must use the 'shorewall -clear' command.
- -Answer: The output you will see looks something like -this:
- + http://www.fireparse.comThe 'stop' command is intended to place your firewall into + a safe state whereby only those interfaces/hosts having the 'routestopped' + option in /etc/shorewall/interfaces and /etc/shorewall/hosts are activated. + If you want to totally open up your firewall, you must use the 'shorewall + clear' command.
+ +Answer: The output you will see looks something like + this:
+/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy- -
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
This is usually cured by the following sequence of commands: -
- -This is usually cured by the following sequence of commands: +
+ +service ipchains stop-
chkconfig --delete ipchains
rmmod ipchains
Also, be sure to check the errata -for problems concerning the version of iptables (v1.2.3) shipped with RH7.2.
-I just installed Shorewall and when I issue the start command, - I see the following:
- -Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) shipped with + RH7.2.
+I just installed Shorewall and when I issue the start command, + I see the following:
+ +Processing /etc/shorewall/shorewall.conf ...-
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
Local Zone: eth1:0.0.0.0/0
Deleting user chains...
Creating input Chains...
...
Why can't Shorewall detect my interfaces properly?
-Answer: The above output is perfectly normal. The Net - zone is defined as all hosts that are connected through eth0 and the local - zone is defined as all hosts connected through eth1
-Shorewall works with any GNU/Linux distribution that includes - the proper prerequisites.
- +Answer: The above output is perfectly normal. The +Net zone is defined as all hosts that are connected through eth0 and the +local zone is defined as all hosts connected through eth1
+Shorewall works with any GNU/Linux distribution that includes + the proper prerequisites.
+Answer: See the Shorewall -Feature List.
- + +Answer: See the Shorewall + Feature List.
+Answer: Every time I've started to work on one, I find -myself doing other things. I guess I just don't care enough if Shorewall -has a GUI to invest the effort to create one myself. There are several -Shorewall GUI projects underway however and I will publish links to -them when the authors feel that they are ready.
- + +Answer: Every time I've started to work on one, I +find myself doing other things. I guess I just don't care enough if +Shorewall has a GUI to invest the effort to create one myself. There +are several Shorewall GUI projects underway however and I will publish +links to them when the authors feel that they are ready.
+Answer: Shorewall is a concatenation of "Shoreline" -(the city where I live) -and "Firewall".
- -Is there any way it can add a rule before the rfc1918 blocking -that will let all traffic to and from the 192.168.100.1 address of the modem -in/out but still block all other rfc1918 addresses.
- -Answer: If you are running a version of Shorewall earlier -than 1.3.1, create /etc/shorewall/start and in it, place the following:
- -Answer: Shorewall is a concatenation of "Shoreline" + (the city where I live) + and "Firewall".
+ +Is there any way it can add a rule before the rfc1918 blocking + that will let all traffic to and from the 192.168.100.1 address of +the modem in/out but still block all other rfc1918 addresses.
+ +Answer: If you are running a version of Shorewall +earlier than 1.3.1, create /etc/shorewall/start and in it, place the +following:
+ +run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT-
If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:
-+
If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:
+-- -
-- -SUBNET -TARGET -- - - + +192.168.100.1 -RETURN -+ +SUBNET +TARGET ++ + +192.168.100.1 +RETURN +
Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
-The solution is the same as FAQ 14 above. Simply substitute - the IP address of your ISPs DHCP server.
-Answer: Every time I read "systems can't see out to -the net", I wonder where the poster bought computers with eyes and what those -computers will "see" when things are working properly. That aside, the most -common causes of this problem are:
- + +Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
+
Note: If you add a second IP address to your external firewall
+ interface to correspond to the modem address, you must also make an entry
+ in /etc/shorewall/rfc1918 for that address. For example, if you configure
+ the address 192.168.100.2 on your firewall, then you would add two entries
+ to /etc/shorewall/rfc1918:
+
+++ +
++ +SUBNET +
+TARGET +
++ +192.168.100.1 +
+RETURN +
++ + + +192.168.100.2 +
+RETURN +
+
The solution is the same as FAQ 14 above. Simply substitute + the IP address of your ISPs DHCP server.
+Answer: Every time I read "systems can't see out to + the net", I wonder where the poster bought computers with eyes and +what those computers will "see" when things are working properly. That +aside, the most common causes of this problem are:
+The default gateway on each local system isn't set to -the IP address of the local firewall interface.
-The entry for the local network in the /etc/shorewall/masq - file is wrong or missing.
-The DNS settings on the local systems are wrong or the - user is running a DNS server on the firewall and hasn't enabled UDP and -TCP port 53 from the firewall to the internet.
-The default gateway on each local system isn't set to + the IP address of the local firewall interface.
+The entry for the local network in the /etc/shorewall/masq + file is wrong or missing.
+The DNS settings on the local systems are wrong or the + user is running a DNS server on the firewall and hasn't enabled UDP + and TCP port 53 from the firewall to the internet.
+Answer: "man dmesg" -- add a suitable 'dmesg' command
+ to your startup scripts or place it in /etc/shorewall/start. Under
+ RedHat, the max log level that is sent to the console is specified
+in /etc/sysconfig/init in the LOGLEVEL variable.
+
Answer: "man dmesg" -- add a suitable 'dmesg' command -to your startup scripts or place it in /etc/shorewall/start. Under RedHat, -the max log level that is sent to the console is specified in /etc/sysconfig/init -in the LOGLEVEL variable.
- -Last updated 9/23/2002 - 18. Is there any way to use aliased ip addresses
+ with Shorewall, and maintain separate rulesets for different IPs?
+ Answer: Yes. You simply use the IP address in your rules (or if
+you use NAT, use the local IP address in your rules). Note: The ":n"
+notation (e.g., eth0:0) is deprecated and will disappear eventually. Neither
+ iproute (ip and tc) nor iptables supports that notation so neither does
+ Shorewall. Last updated 11/09/2002 - Tom Eastep Copyright
- © 2001, 2002 Thomas M. Eastep. Copyright
+ © 2001, 2002 Thomas M. Eastep. 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 Suppose that we have the following sutuation:
- We want systems
-in the 192.168.1.0/24 sub-network to be able to communicate with systems
-in the 10.0.0.0/8 network. To make this work, we need to do two things: a) Open the firewall so that the IPSEC tunnel can be established
-(allow the ESP and AH protocols and UDP Port 500). b) Allow traffic through the tunnel. Opening the firewall for the IPSEC tunnel is accomplished by
-adding an entry to the /etc/shorewall/tunnels file. In /etc/shorewall/tunnels
-on system A, we need the following In /etc/shorewall/tunnels
-on system B, we would have: You need to define a zone for the remote subnet or include
- it in your local zone. In this example, we'll assume that you have created a
- zone called "vpn" to represent the remote subnet. At both
-systems, ipsec0 would be included in /etc/shorewall/interfaces as a "vpn"
-interface: You will need to allow traffic between the "vpn" zone and
- the "loc" zone -- if you simply want to admit all traffic in both
- directions, you can use the policy file: Once
-you have these entries in place, restart Shorewall (type shorewall restart);
-you are now ready to configure the tunnel in
- FreeS/WAN
- . Suppose that you have
-a laptop system (B) that you take with you when you travel and you want to
-be able to establish a secure connection back to your local network.
- You need to define a zone for the laptop or include it in
- your local zone. In this example, we'll assume that you have created a zone
- called "vpn" to represent the remote host. In this
-instance, the mobile system (B) has IP address 134.28.54.2 but that cannot
-be determined in advance. In the /etc/shorewall/tunnels file on system A,
-the following entry should be made: 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 Suppose that we have the following sutuation: We want systems in the 192.168.1.0/24 sub-network to be able
+to communicate with systems in the 10.0.0.0/8 network. To make this work, we need to do two things: a) Open the firewall so that the IPSEC tunnel can be established
+ (allow the ESP and AH protocols and UDP Port 500). b) Allow traffic through the tunnel. Opening the firewall for the IPSEC tunnel is accomplished
+by adding an entry to the /etc/shorewall/tunnels file. In /etc/shorewall/tunnels on system A, we need the following Note that the GATEWAY
-ZONE column contains the name of the zone corresponding to peer subnetworks. This indicates that the
-gateway system itself comprises the peer subnetwork; in other words, the
-remote gateway is a standalone system. You will need to configure /etc/shorewall/interfaces and establish
- your "through the tunnel" policy as shown under the first example above. Last
-updated 8/20/2002 -
- Tom Eastep
+ In /etc/shorewall/tunnels on system B, we would have: Note: If either of the endpoints is behind a NAT gateway
+then the tunnels file entry on the other endpoint should specify
+a tunnel type of ipsecnat rather than ipsec and the GATEWAY
+address should specify the external address of the NAT gateway. You need to define a zone for the remote subnet or include
+ it in your local zone. In this example, we'll assume that you have created
+a zone called "vpn" to represent the remote subnet. At both systems, ipsec0 would be included in /etc/shorewall/interfaces
+as a "vpn" interface: You will need to allow traffic between the "vpn" zone and
+ the "loc" zone -- if you simply want to admit all traffic in both
+ directions, you can use the policy file: Once you have these entries in place, restart Shorewall (type
+shorewall restart); you are now ready to configure the tunnel in FreeS/WAN . Suppose that you have a laptop system (B) that you take with you when you
+travel and you want to be able to establish a secure connection back to your
+local network.
+ You need to define a zone for the laptop or include it in
+ your local zone. In this example, we'll assume that you have created
+a zone called "vpn" to represent the remote host. In this instance, the mobile system (B) has IP address 134.28.54.2
+but that cannot be determined in advance. In the /etc/shorewall/tunnels file
+on system A, the following entry should be made: Note that the GATEWAY ZONE column contains the name of the zone corresponding
+to peer subnetworks. This indicates that the gateway system itself comprises
+the peer subnetwork; in other words, the remote gateway is a standalone system. You will need to configure /etc/shorewall/interfaces and establish
+ your "through the tunnel" policy as shown under the first example above.
- Copyright © 2001, 2002 Thomas M. Eastep. Last updated 10/23/2002 -
+ Tom Eastep
+ Copyright © 2001, 2002 Thomas M. Eastep. Before upgrading, be sure to review the
-Upgrade Issues Before upgrading, be sure to review the Upgrade Issues Install using RPM To install Shorewall using the RPM: If you have RedHat 7.2 and are running iptables version 1.2.3 (at a shell
-prompt, type "/sbin/iptables --version"), you must upgrade to version 1.2.4
-either from the
-RedHat update
-site or from the Shorewall Errata page before
-attempting to start Shorewall. If you have RedHat 7.2 and are running iptables version 1.2.3 (at a
+shell prompt, type "/sbin/iptables --version"), you must upgrade to version
+1.2.4 either from the RedHat update
+ site or from the Shorewall Errata page before
+ attempting to start Shorewall. To
- install Shorewall using the tarball and install
- script: To install Shorewall using the tarball
+and install script: If you already have the Shorewall RPM installed and are upgrading to a new
-version: If you are upgrading from a 1.2 version of Shorewall to a 1.3 version and you
-have entries in the /etc/shorewall/hosts file then please check your
-/etc/shorewall/interfaces file to be sure that it contains an entry for each
-interface mentioned in the hosts file. Also, there are certain 1.2 rule forms
-that are no longer supported under 1.3 (you must use the new 1.3 syntax). See
-the upgrade issues for details. You can check your rules and
-host file for 1.3 compatibility using the "shorewall check" command after
-installing the latest version of 1.3. If you already have the Shorewall RPM installed
+and are upgrading to a new version: If you are upgrading from a 1.2 version of Shorewall to a 1.3 version and
+you have entries in the /etc/shorewall/hosts file then please check your
+ /etc/shorewall/interfaces file to be sure that it contains an entry for
+each interface mentioned in the hosts file. Also, there are certain 1.2
+rule forms that are no longer supported under 1.3 (you must use the new
+1.3 syntax). See the upgrade issues for details.
+You can check your rules and host file for 1.3 compatibility using the "shorewall
+check" command after installing the latest version of 1.3.
- Note: Some SuSE users have encountered a problem whereby rpm reports a
- conflict with kernel <= 2.2 even though a 2.4 kernel is installed. If this
- happens, simply use the --nodeps option to rpm (rpm -Uvh --nodeps <shorewall
- rpm>). Note: Some SuSE users have encountered a problem whereby
+rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel is
+installed. If this happens, simply use the --nodeps option to rpm (rpm
+-Uvh --nodeps <shorewall rpm>). If you already have Shorewall installed and are upgrading to a new version
-using the tarball: If you are upgrading from a 1.2 version of Shorewall to a 1.3 version and you
-have entries in the /etc/shorewall/hosts file then please check your
-/etc/shorewall/interfaces file to be sure that it contains an entry for each
-interface mentioned in the hosts file. Also, there are certain 1.2 rule
-forms that are no longer supported under 1.3 (you must use the new 1.3 syntax).
-See the upgrade issues for details. You can check your rules
-and host file for 1.3 compatibility using the "shorewall check" command after
-installing the latest version of 1.3. If you already have Shorewall installed and
+are upgrading to a new version using the tarball: If you are upgrading from a 1.2 version of Shorewall to a 1.3 version and
+you have entries in the /etc/shorewall/hosts file then please check your
+ /etc/shorewall/interfaces file to be sure that it contains an entry for
+each interface mentioned in the hosts file. Also, there are certain 1.2
+rule forms that are no longer supported under 1.3 (you must use the new
+1.3 syntax). See the upgrade issues for
+details. You can check your rules and host file for 1.3 compatibility using
+the "shorewall check" command after installing the latest version of 1.3. You will need to edit some or all of these configuration files to match your
-setup. In most cases, the Shorewall
-QuickStart Guides contain all of the information you need. You will need to edit some or all of these configuration files to match
+your setup. In most cases, the Shorewall
+ QuickStart Guides contain all of the information you need. Updated 9/13/2002 - Tom
-Eastep Updated 10/28/2002 - Tom Eastep
+ Copyright
-© 2001, 2002 Thomas M. Eastep. 9/28/2002 - Shorewall 1.3.9 In this version: 11/09/2002 - Shorewall 1.3.10 In this version: 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored 10/24/2002 - Shorewall is now in Gentoo Linux 9/18/2002 - Debian 1.3.8 Packages Available 10/23/2002 - Shorewall 1.3.10 Beta 1 10/10/2002 - Debian 1.3.9b Packages Available Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html. 10/9/2002 - Shorewall 1.3.9b 10/6/2002 - Shorewall.net now running on RH8.0 9/30/2002 - TUNNELS Broken in 1.3.9!!! 9/16/2002 - Shorewall 1.3.8 9/28/2002 - Shorewall 1.3.9 In this version: 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
+ Restored 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
+ Restored 9/18/2002 - Debian 1.3.8 Packages Available Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html. 9/16/2002 - Shorewall 1.3.8 In this version: 9/11/2002 - Debian 1.3.7c Packages Available Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html. 9/2/2002 - Shorewall 1.3.7c This is a role up of a fix for "DNAT" rules where the source zone is $FW
- (fw). 8/31/2002 - I'm not available I'm currently on vacation -- please respect my need for a couple of
weeks free of Shorewall problem reports. -Tom 8/26/2002 - Shorewall 1.3.7b This is a role up of the "shorewall refresh" bug fix and the change which
- reverses the order of "dhcp" and "norfc1918" checking. 8/26/2002 - French FTP Mirror is Operational ftp://france.shorewall.net/pub/mirrors/shorewall
- is now available. 8/25/2002 - Shorewall Mirror in France Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored
- at http://france.shorewall.net. 8/25/2002 - Shorewall 1.3.7a Debian Packages Available Lorenzo Martignoni reports that the packages for version 1.3.7a are available
- at http://security.dsi.unimi.it/~lorenzo/debian.html. 8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author
- -- Shorewall 1.3.7a released 1.3.7a corrects problems occurring in rules file processing when starting
- Shorewall 1.3.7. 8/22/2002 - Shorewall 1.3.7 Released 8/13/2002 Features in this release include: I would like to thank John Distler for his valuable input regarding TCP
- SYN and ICMP treatment in Shorewall. That input has led to marked improvement
- in Shorewall in the last two releases. 8/13/2002 - Documentation in the CVS Repository The Shorewall-docs project now contains just the HTML and image files
- the Frontpage files have been removed. 8/7/2002 - STABLE branch added to CVS Repository This branch will only be updated after I release a new version of Shorewall
- so you can always update from this branch to get the latest stable
-tree. 8/7/2002 - Upgrade Issues section
added to the Errata Page Now there is one place to go to look for issues involved with upgrading
- to recent versions of Shorewall. 8/7/2002 - Shorewall 1.3.6 This is primarily a bug-fix rollup with a couple of new features: 7/30/2002 - Shorewall 1.3.5b Released This interim release: 7/29/2002 - New Shorewall Setup Guide Available The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm.
- The guide is intended for use by people who are setting up Shorewall
- to manage multiple public IP addresses and by people who want to learn
- more about Shorewall than is described in the single-address guides.
-Feedback on the new guide is welcome. 7/28/2002 - Shorewall 1.3.5 Debian Package Available Lorenzo Martignoni reports that the packages are version 1.3.5a and are
- available at http://security.dsi.unimi.it/~lorenzo/debian.html. 7/27/2002 - Shorewall 1.3.5a Released This interim release restores correct handling of REDIRECT rules. 7/26/2002 - Shorewall 1.3.5 Released This will be the last Shorewall release for a while. I'm going to be
focusing on rewriting a lot of the documentation. In this version: 7/16/2002 - New Mirror in Argentina Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in
- Argentina. Thanks Buanzo!!! 7/16/2002 - Shorewall 1.3.4 Released In this version: 7/8/2002 - Shorewall 1.3.3 Debian Package Available Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html. 7/6/2002 - Shorewall 1.3.3 Released In this version: 6/25/2002 - Samples Updated for 1.3.2 The comments in the sample configuration files have been updated to reflect
- new features introduced in Shorewall 1.3.2. 6/25/2002 - Shorewall 1.3.1 Debian Package Available Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html. 6/19/2002 - Documentation Available in PDF Format Thanks to Mike Martinez, the Shorewall Documentation is now available
for download in Adobe PDF format. 6/16/2002 - Shorewall 1.3.2 Released In this version: 6/6/2002 - Why CVS Web access is Password Protected Last weekend, I installed the CVS Web package to provide brower-based
access to the Shorewall CVS repository. Since then, I have had several
instances where my server was almost unusable due to the high load generated
by website copying tools like HTTrack and WebStripper. These mindless tools: These tools/weapons are particularly damaging when combined with CVS Web
- because they doggedly follow every link in the cgi-generated HTML resulting
- in 1000s of executions of the cvsweb.cgi script. Yesterday, I spend
-several hours implementing measures to block these tools but unfortunately,
-these measures resulted in my server OOM-ing under even moderate load. Until I have the time to understand the cause of the OOM (or until I buy
- more RAM if that is what is required), CVS Web access will remain Password
- Protected. 6/5/2002 - Shorewall 1.3.1 Debian Package Available Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html. 6/2/2002 - Samples Corrected The 1.3.0 samples configurations had several serious problems that prevented
- DNS and SSH from working properly. These problems have been corrected
- in the 1.3.1 samples. 6/1/2002 - Shorewall 1.3.1 Released Hot on the heels of 1.3.0, this release: 5/29/2002 - Shorewall 1.3.0 Released In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0
includes: 5/23/2002 - Shorewall 1.3 RC1 Available In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92)
incorporates the following: 5/19/2002 - Shorewall 1.3 Beta 2 Available In addition to the changes in Beta 1, this release which carries the
designation 1.2.91 adds: 5/17/2002 - Shorewall 1.3 Beta 1 Available Beta 1 carries the version designation 1.2.90 and implements the following
- features: 5/4/2002 - Shorewall 1.2.13 is Available In this version: 4/30/2002 - Shorewall Debian News Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the
Debian
Testing Branch and the Debian
Unstable Branch. 4/20/2002 - Shorewall 1.2.12 is Available 4/17/2002 - Shorewall Debian News Lorenzo Marignoni reports that: Thanks, Lorenzo! 4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE Thanks to Stefan Mohr, there
- is now a Shorewall 1.2.11
- SuSE RPM available. 4/13/2002 - Shorewall 1.2.11 Available In this version: 4/13/2002 - Hamburg Mirror now has FTP Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall.
- Thanks Stefan! 4/12/2002 - New Mirror in Hamburg Thanks to Stefan Mohr, there
- is now a mirror of the Shorewall website at http://germany.shorewall.net.
4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available Version 1.1 of the QuickStart
- Guide is now available. Thanks to those who have read version 1.0
- and offered their suggestions. Corrections have also been made to the
- sample scripts. 4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available Version 1.0 of the QuickStart
- Guide is now available. This Guide and its accompanying sample
-configurations are expected to provide a replacement for the recently
-withdrawn parameterized samples. 4/8/2002 - Parameterized Samples Withdrawn Although the parameterized
- samples have allowed people to get a firewall up and running quickly,
- they have unfortunately set the wrong level of expectation among those
- who have used them. I am therefore withdrawing support for the samples
- and I am recommending that they not be used in new Shorewall installations. 4/2/2002 - Updated Log Parser John Lodge has provided an updated
- version of his CGI-based log parser
- with corrected date handling. 3/30/2002 - Shorewall Website Search Improvements The quick search on the home page now excludes the mailing list archives.
- The Extended Search allows excluding
- the archives or restricting the search to just the archives. An archive
- search form is also available on the mailing
- list information page. 3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni) 3/25/2002 - Log Parser Available John Lodge has provided a CGI-based log parser for Shorewall. Thanks
- John. 3/20/2002 - Shorewall 1.2.10 Released In this version: 3/11/2002 - Shorewall 1.2.9 Released In this version: 3/1/2002 - 1.2.8 Debian Package is Available See http://security.dsi.unimi.it/~lorenzo/debian.html 2/25/2002 - New Two-interface Sample I've enhanced the two interface sample to allow access from the firewall
- to servers in the local zone -
- http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz 2/23/2002 - Shorewall 1.2.8 Released Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects
problems associated with the lock file used to prevent multiple state-changing
- operations from occuring simultaneously. My apologies for any inconvenience
- my carelessness may have caused. 2/22/2002 - Shorewall 1.2.7 Released In this version: 2/18/2002 - 1.2.6 Debian Package is Available See http://security.dsi.unimi.it/~lorenzo/debian.html 2/8/2002 - Shorewall 1.2.6 Released In this version: 2/4/2002 - Shorewall 1.2.5 Debian Package Available see http://security.dsi.unimi.it/~lorenzo/debian.html 2/1/2002 - Shorewall 1.2.5 Released Due to installation problems with Shorewall 1.2.4, I have released Shorewall
- 1.2.5. Sorry for the rapid-fire development. In version 1.2.5: 1/28/2002 - Shorewall 1.2.4 Released 1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html 1/20/2002 - Corrected firewall script available Corrects a problem with BLACKLIST_LOGLEVEL. See the
- errata for details. 1/19/2002 - Shorewall 1.2.3 Released This is a minor feature and bugfix release. The single new feature is: The following problems were corrected: 1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution
- that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo
- for details. 1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2
- Shorewall Debian package is now available. There is a link to Lorenzo's
- site from the Shorewall download page. 1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores
- the "shorewall status" command to health. 1/8/2002 - Shorewall 1.2.2 Released In version 1.2.2 1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates
- to the previously-released samples. There are two new rules added: See the README file for upgrade instructions. 1/1/2002 - Shorewall Mailing List Moving The Shorewall mailing list hosted at
- Sourceforge is moving to Shorewall.net. If you are a current subscriber
- to the list at Sourceforge, please is moving to Shorewall.net. If you are a current
+subscriber to the list at Sourceforge, please see these instructions.
- If you would like to subscribe to the new list, visit http://www.shorewall.net/mailman/listinfo/shorewall-users. 12/31/2001 - Shorewall 1.2.1 Released In version 1.2.1: 12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist
releasing 1.2 on 12/21/2001 Version 1.2 contains the following new features: For the next month or so, I will continue to provide corrections to version
- 1.1.18 as necessary so that current version 1.1.x users will not be forced
- into a quick upgrade to 1.2.0 just to have access to bug fixes. For those of you who have installed one of the Beta RPMS, you will need
- to use the "--oldpackage" option when upgrading to 1.2.0: rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm 12/19/2001 - Thanks to Steve
- Cowles, there is now a Shorewall mirror in Texas. This web site
- is mirrored at , there is now a Shorewall mirror in Texas. This web
+site is mirrored at http://www.infohiiway.com/shorewall and the ftp site is
at ftp://ftp.infohiiway.com/pub/mirrors/shorewall. 11/30/2001 - A new set of the parameterized Sample
Configurations has been released. In this version: 11/20/2001 - The current version of Shorewall is 1.1.18. In this version: 11/19/2001 - Thanks to Juraj
- Ontkanin, there is now a Shorewall mirror in the Slovak Republic.
- The website is now mirrored at , there is now a Shorewall mirror in the Slovak Republic.
+ The website is now mirrored at http://www.nrg.sk/mirror/shorewall
- and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall. 11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations.
- There are three sample configurations: Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17
- . See the README file for instructions. 11/1/2001 - The current version of Shorewall is 1.1.17. I intend
- this to be the last of the 1.1 Shorewall releases. In this version: 10/22/2001 - The current version of Shorewall is 1.1.16. In this
- version: 10/15/2001 - The current version of Shorewall is 1.1.15. In this
- version: 10/4/2001 - The current version of Shorewall is 1.1.14. In this
- version 9/12/2001 - The current version of Shorewall is 1.1.13. In this
- version 8/28/2001 - The current version of Shorewall is 1.1.12. In this
- version 7/28/2001 - The current version of Shorewall is 1.1.11. In this
- version 7/6/2001 - The current version of Shorewall is 1.1.10. In this
version 6/23/2001 - The current version of Shorewall is 1.1.9. In this
version 6/18/2001 - The current version of Shorewall is 1.1.8. In this
version 6/2/2001 - The current version of Shorewall is 1.1.7. In this version 5/25/2001 - The current version of Shorewall is 1.1.6. In this
version 5/20/2001 - The current version of Shorewall is 1.1.5. In this
version 5/10/2001 - The current version of Shorewall is 1.1.4. In this
version 4/28/2001 - The current version of Shorewall is 1.1.3. In this
version 4/12/2001 - The current version of Shorewall is 1.1.2. In this
version 4/8/2001 - Shorewall is now affiliated with the Leaf Project 4/5/2001 - The current version of Shorewall is 1.1.1. In this version: 3/25/2001 - The current version of Shorewall is 1.1.0. In this version: 3/19/2001 - The current version of Shorewall is 1.0.4. This version: 3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix
- release with no new features. 3/8/2001 - The current version of Shorewall is 1.0.2. It supports an
- additional "gw" (gateway) zone for tunnels and it supports IPSEC tunnels
- with end-points on the firewall. There is also a .lrp available now. Updated 9/23/2002 - Tom Eastep
- Updated 11/09/2002 - Tom Eastep
+
Copyright © 2001, 2002 Thomas M. Eastep. Shorewall easily supports PPTP in a number of configurations: I will try to give you an idea of how to set up a PPTP server
-on your firewall system. This isn't a detailed HOWTO but rather an example of
-how I have set up a working PPTP server on my own firewall. I will try to give you an idea of how to set up a PPTP server on your firewall
+system. This isn't a detailed HOWTO but rather an example of how I have set
+up a working PPTP server on my own firewall. The steps involved are: To run pppd on a 2.4 kernel, you need the pppd 2.4.1 or later. The primary
-site for releases of pppd is ftp://ftp.samba.org/pub/ppp. You will need the following patches: You may also want the following patch if you want to require remote hosts to
-use encryption: You may also want the following patch if you want to require remote hosts
+to use encryption: Un-tar the pppd source and uncompress the patches into one directory (the
-patches and the ppp-2.4.1 directory are all in a single parent directory): You will need to install the resulting binary on your firewall system. To do
-that, I NFS mount my source filesystem and use "make install" from the
+
+ You will need to install the resulting binary on your firewall system.
+To do that, I NFS mount my source filesystem and use "make install" from the
ppp-2.4.1 directory. You will need one of the following patches depending on your kernel version: Uncompress the patch into the same directory where your top-level kernel
-source is located and: Now configure your kernel. Here is my ppp configuration: You will need a WINS server (Samba configured to run as a WINS server is
-fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3) is: You will need a WINS server (Samba configured to run as a WINS server is
+ fine). Global section from /etc/samba/smb.conf on my WINS server (192.168.1.3)
+is: Here is a copy of my /etc/ppp/options.poptop file: ipparam PoPToP Notes: Here's my /etc/ppp/chap-secrets: Secrets for authentication using CHAP I am the only user who connects to the server but I may connect either with
-or without a domain being specified. The system I connect from is my laptop so I
-give it the same IP address when tunneled in as it has when it is in its docking
-station. I am the only user who connects to the server but I may connect either
+with or without a domain being specified. The system I connect from is my
+laptop so I give it the same IP address when tunneled in at it has when I
+use its wireless LAN card around the house. You will also want the following in /etc/modules.conf: PoPTop (pptpd) is available from http://poptop.lineo.com/. Here is a copy of my /etc/pptpd.conf file: option /etc/ppp/options.poptop Notes: I use this file to start/stop pptpd -- I have this in /etc/init.d/pptpd: #!/bin/sh I consider hosts connected to my PPTP server to be just like local systems.
-My key Shorewall entries are: Note: I have multiple ppp interfaces on my firewall. If you
- have a single ppp interface, you probably want: and no entries in /etc/shorewall/hosts. If you have a single external IP address, add the following to your
- /etc/shorewall/rules file: If you have multiple external IP address and you want to forward a single <external
-address>, add the following to your /etc/shorewall/rules file: You shouldn't have to take any special action for this case unless you wish
-to connect multiple clients to the same external server. In that case, you will
-need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html.
-I recommend that you also add these two lines to your /etc/shorewall/modules
-file:
- loadmodule ip_conntrack_pptp The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.
-Rather than use the configuration script that comes with the client, I built my
-own. I also build my own kernel as described above
-rather than using the mppe package that is available with the client. My
-/etc/ppp/options file is mostly unchanged from what came with the client (see
-below). The key elements of this setup are as follows:
- Here are examples from my setup: /etc/shoreawll/tunnels (For Shorewall versions 1.3.10
+and later) I use the combination of interface and hosts file to define the 'cpq' zone
-because I also run a PPTP server on my firewall (see above). Using this
-technique allows me to distinguish clients of my own PPTP server from arbitrary
-hosts at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients and
-Compaq doesn't use that RFC1918 Class C subnet.
- I use this script in /etc/init.d to control the client. The reason that I
-disable ECN when connecting is that the Compaq tunnel servers don't do ECN yet
-and reject the initial TCP connection request if I enable ECN :-(
+ and no entries in /etc/shorewall/hosts. If you have a single external IP address, add the following to your /etc/shorewall/rules
+file: If you have multiple external IP address and you want to forward a single
+<external address>, add the following to your /etc/shorewall/rules
+file:
+ You shouldn't have to take any special action for this case unless you
+wish to connect multiple clients to the same external server. In that case,
+you will need to follow the instructions at http://www.impsec.org/linux/masquerade/ip_masq_vpn.html.
+ I recommend that you also add these two lines to your /etc/shorewall/modules
+ file: loadmodule ip_conntrack_pptp The PPTP GNU/Linux client is available at http://sourceforge.net/projects/pptpclient/.
+ Rather than use the configuration script that comes with the client, I built
+my own. I also build my own kernel as described above
+ rather than using the mppe package that is available with the client. My
+/etc/ppp/options file is mostly unchanged from what came with the client
+(see below). The key elements of this setup are as follows: Here are examples from my setup: /etc/shorewall/tunnels (For Shorewall versions 1.3.10 and later) #!/bin/sh Here's my /etc/ppp/options file:
- # My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq
-traffic through the PPTP tunnel:
- #/bin/sh Finally, I run the following script every five minutes under crond to
- restart the tunnel if it fails: Here's a script
- and corresponding ip-up.local from Jerry
- Vonau that controls two PPTP connections. Last modified 7/11/2002 - Tom
-Eastep
-Copyright © 2001, 2002 Thomas M. Eastep.
\ No newline at end of file
+
+ I use the combination of interface and hosts file to define the 'cpq' zone
+because I also run a PPTP server on my firewall (see above). Using this technique
+allows me to distinguish clients of my own PPTP server from arbitrary hosts
+at Compaq; I assign addresses in 192.168.1.0/24 to my PPTP clients and Compaq
+doesn't use that RFC1918 Class C subnet. I use this script in /etc/init.d to control the client. The reason that
+I disable ECN when connecting is that the Compaq tunnel servers don't do ECN
+yet and reject the initial TCP connection request if I enable ECN :-( #!/bin/sh Here's my /etc/ppp/options file: # My /etc/ppp/ip-up.local file sets up the routes that I need to route Compaq
+ traffic through the PPTP tunnel: #/bin/sh Finally, I run the following script every five minutes under crond to
+ restart the tunnel if it fails: Here's a script
+ and corresponding ip-up.local from Jerry Vonau that controls two PPTP connections. Last modified 10/23/2002 - Tom Eastep Copyright
+© 2001, 2002 Thomas M. Eastep. Copyright © 2001, 2002 Thomas M. Eastep. Shorewall supports two different forms of blacklisting; static and dynamic. Shorewall static blacklisting support has the following configuration
-parameters: Shorewall static blacklisting support has the following configuration parameters: Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting
- doesn't use any configuration parameters but is rather controlled using
- /sbin/shorewall commands: Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting
+ doesn't use any configuration parameters but is rather controlled using
+/sbin/shorewall commands: Example 1: Drops packets from hosts 192.0.2.124 and 192.0.2.125 Example 2: Reenables access from 192.0.2.125. Last updated 9/16/2002 - Tom Eastep Copyright
+
+ Last updated 10/7/2002 - Tom Eastep Copyright
© 2002 Thomas M. Eastep. Warning: If you copy or edit your
- configuration files on a system running Microsoft Windows, you must
- run them through dos2unix
-before you use them with Shorewall. Shorewall's configuration files are in the directory /etc/shorewall. You may place comments in configuration files by making the first non-whitespace
- character a pound sign ("#"). You may also place comments at the end
-of any line, again by delimiting the comment from the rest of the line
-with a pound sign. Examples: You may continue lines in the configuration files using the usual backslash
-("\") followed immediately by a new line character. Example: WARNING: I personally recommend strongly against
- using DNS names in Shorewall configuration files. If you use DNS names and
- you are called out of bed at 2:00AM because Shorewall won't start as a result
-of DNS problems then don't say that you were not forewarned. -Tom Beginning with Shorwall 1.3.9, Host addresses in Shorewall
-configuration files may be specified either as IP addresses or as DNS Names. If your firewall rules include DNS names then: Each DNS name much be fully qualified and include a minumum
-of two periods (although one may be trailing). This restriction is imposed
-by Shorewall to insure backward compatibility with existing configuration
-files. Where specifying an IP address, a subnet or an interface, you can
- precede the item with "!" to specify the complement of the item. For
- example, !192.168.1.4 means "any host but 192.168.1.4". Comma-separated lists are allowed in a number of contexts within the
- configuration files. A comma separated list: Unless otherwise specified, when giving a port number you can use
- either an integer or a service name from /etc/services. If you need to specify a range of ports, the proper syntax is <low
- port number>:<high port number>. 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: Warning: If you copy or edit your
+ configuration files on a system running Microsoft Windows, you must
+ run them through dos2unix
+ before you use them with Shorewall. The result will be the same as if the record had been written Variables may be used anywhere in the other configuration
-files. Shorewall's configuration files are in the directory /etc/shorewall. You may place comments in configuration files by making the first non-whitespace
+ character a pound sign ("#"). You may also place comments at the end
+ of any line, again by delimiting the comment from the rest of the
+line with a pound sign. Examples: You may continue lines in the configuration files using the usual backslash
+ ("\") followed immediately by a new line character. Example: WARNING: I personally recommend strongly against
+ using DNS names in Shorewall configuration files. If you use DNS names and
+ you are called out of bed at 2:00AM because Shorewall won't start as a
+result of DNS problems then don't say that you were not forewarned. -Tom Beginning with Shorwall 1.3.9, Host addresses in Shorewall
+ configuration files may be specified either as IP addresses or as DNS Names. If your firewall rules include DNS names then: Each DNS name much be fully qualified and include a minumum
+ of two periods (although one may be trailing). This restriction is imposed
+ by Shorewall to insure backward compatibility with existing configuration
+ files. Where specifying an IP address, a subnet or an interface, you can
+ precede the item with "!" to specify the complement of the item. For
+ example, !192.168.1.4 means "any host but 192.168.1.4". There must
+be no white space following the "!". Comma-separated lists are allowed in a number of contexts within the
+ configuration files. A comma separated list: Unless otherwise specified, when giving a port number you can use
+ either an integer or a service name from /etc/services. If you need to specify a range of ports, the proper syntax is <low
+ port number>:<high port number>. For example,
+ if you want to forward the range of tcp ports 4000 through 4100 to local
+host 192.168.1.3, the entry in /etc/shorewall/rules is: You may use the /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: The result will be the same as if the record had been written Variables may be used anywhere in the other configuration
+ files. Media Access Control (MAC) addresses can be used to specify packet
-source in several of the configuration files. To use this feature,
-your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
-included. MAC addresses are 48 bits wide and each Ethernet Controller has a
- unique MAC address. Media Access Control (MAC) addresses can be used to specify packet
+ source in several of the configuration files. To use this feature,
+ your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
+ included. MAC addresses are 48 bits wide and each Ethernet Controller has a
+ unique MAC address. Note: It is not necessary to use the special Shorewall notation
+in the /etc/shorewall/maclist file. Shorewall allows you to have configuration directories other than /etc/shorewall.
-The shorewall start and restart
- commands allow you to specify an alternate configuration directory and
- Shorewall will use the files in the alternate directory rather than the corresponding
- files in /etc/shorewall. The alternate directory need not contain a complete
- configuration; those files not in the alternate directory will be read from
- /etc/shorewall. This facility permits you to easily create a test or temporary configuration
- by: Shorewall allows you to have configuration directories other than /etc/shorewall.
+ The shorewall start and restart
+ commands allow you to specify an alternate configuration directory and
+ Shorewall will use the files in the alternate directory rather than the
+ corresponding files in /etc/shorewall. The alternate directory need not
+contain a complete configuration; those files not in the alternate directory
+will be read from /etc/shorewall. This facility permits you to easily create a test or temporary configuration
+ by: Updated 9/24/2002 - Tom Eastep
- Updated 10/24/2002 - Tom Eastep
+ Copyright
- © 2001, 2002 Thomas M. Eastep. Copyright
+ © 2001, 2002 Thomas M. Eastep. Specify the "dhcp" option on each interface to be
- served by your server in the /etc/shorewall/interfaces
- file. When starting "dhcpd", you need to list those
- interfaces on the run line. On a RedHat system, this is done by modifying
- /etc/sysconfig/dhcpd. Specify the "dhcp" option on each interface to be
+ served by your server in the /etc/shorewall/interfaces
+ file. This will generate rules that will allow DHCP to and from your
+firewall system. When starting "dhcpd", you need to list those interfaces
+on the run line. On a RedHat system, this is done by modifying /etc/sysconfig/dhcpd.
+ Specify the "dhcp" option for this interface in
- the /etc/shorewall/interfaces
- file. If you know that the dynamic address is always going to be
- in the same subnet, you can specify the subnet address in the interface's
- entry in the /etc/shorewall/interfaces
- file. If you don't know the subnet address in advance, you should
- specify "detect" for the interface's subnet address in the /etc/shorewall/interfaces
- file and start Shorewall after the interface has started. In the event that the subnet address might change while
- Shorewall is started, you need to arrange for a "shorewall
- refresh" command to be executed when a new dynamic IP address gets
- assigned to the interface. Check your DHCP client's documentation. Specify the "dhcp" option for this interface in the
+ /etc/shorewall/interfaces
+ file. This will generate rules that will allow DHCP to and from your firewall
+system. If you know that the dynamic address is always going
+to be in the same subnet, you can specify the subnet address in the interface's
+ entry in the /etc/shorewall/interfaces
+ file. If you don't know the subnet address in advance, you
+should specify "detect" for the interface's subnet address in the /etc/shorewall/interfaces file
+and start Shorewall after the interface has started. In the event that the subnet address might change while
+ Shorewall is started, you need to arrange for a "shorewall refresh"
+command to be executed when a new dynamic IP address gets assigned to
+the interface. Check your DHCP client's documentation. Last updated 1/26/2002 - Tom
-Eastep Copyright
-© 2001, 2002 Thomas M. Eastep. Last updated 11/03/2002 - Tom Eastep Copyright
+ © 2001, 2002 Thomas M. Eastep. I strongly urge you to read and print a copy of the Shorewall QuickStart Guide
- for the configuration that most closely matches your own. Once you've done that, download one of the modules: The documentation in HTML format is included in the .tgz and .rpm files
-and there is an documentation .deb that also contains the documentation. Please verify the version that you have downloaded -- during the
-release of a new version of Shorewall, the links below may point to
-a newer or an older version than is shown below. Once you have verified the version, check the
- errata to see if there are updates that apply to the version
-that you have downloaded. WARNING - YOU CAN NOT SIMPLY
-INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
-IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
-of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. Download Latest Version (1.3.9): Remember that updates to the
-mirrors occur 1-12 hours after an update to the primary site. The documentation in HTML format is included in the .tgz and .rpm files
+ and there is an documentation .deb that also contains the documentation. Please verify the version that you have downloaded -- during the
+ release of a new version of Shorewall, the links below may point
+ to a newer or an older version than is shown below. Once you have verified the version, check the
+ errata to see if there are updates that apply to the version
+ that you have downloaded. WARNING - YOU CAN NOT SIMPLY
+ INSTALL THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
+ IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
+ of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled. Download Latest Version (1.3.10): Remember that updates to the
+ mirrors occur 1-12 hours after an update to the primary site. Browse Download Sites: CVS: The CVS repository at
-cvs.shorewall.net contains the latest snapshots of the each Shorewall
-component. There's no guarantee that what you find there will work at all. Last Updated 9/26/2002 - CVS repository at
+ cvs.shorewall.net contains the latest snapshots of the each Shorewall
+ component. There's no guarantee that what you find there will work at
+all. Last Updated 11/9/2002 - Tom Eastep Copyright
- © 2001, 2002 Thomas M. Eastep. Copyright
+ © 2001, 2002 Thomas M. Eastep. IMPORTANT If you use a Windows system to download
- a corrected script, be sure to run the script through dos2unix after you have moved
- it to your Linux system. If you are installing Shorewall for the
first time and plan to use the .tgz and install.sh script, you can
untar the archive, replace the 'firewall' script in the untarred directory
- with the one you downloaded below, and then run install.sh. When the instructions say to install a corrected
- firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall
-or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite
-the existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall
- or /var/lib/shorewall/firewall before you do that. /etc/shorewall/firewall
- and /var/lib/shorewall/firewall are symbolic links that point
- to the 'shorewall' file used by your system initialization scripts to
- start Shorewall during boot. It is that file that must be overwritten
- with the corrected script. DO NOT INSTALL CORRECTED COMPONENTS
+ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. For example,
+do NOT install the 1.3.9a firewall script if you are running 1.3.7c. DNAT rules where the source zone is 'fw' ($FW)
result in an error message. Installing
this corrected firewall script in /var/lib/shorewall/firewall
- as described above corrects this problem. "shorewall refresh" is not creating the proper
rule for FORWARDPING=Yes. Consequently, after
"shorewall refresh", the firewall will not forward
@@ -111,325 +154,348 @@ port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 tcp 25 - 10.1.1.1")
this corrected firewall script in /var/lib/shorewall/firewall
- as described above corrects this problem. If "norfc1918" and "dhcp" are both specified as
options on a given interface then RFC 1918
checking is occurring before DHCP checking. This
means that if a DHCP client broadcasts using an
RFC 1918 source address, then the firewall will
reject the broadcast (usually logging it). This
- has two problems:
This version of the 1.3.7a firewall script
- corrects the problem. It must be installed
- in /var/lib/shorewall as described above. Version 1.3.7 dead on arrival -- please use
version 1.3.7a and check your version against
these md5sums -- if there's a difference, please
download again. In other words, type "md5sum <whatever package you downloaded>
- and compare the result with what you see above. I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the
- .7 version in each sequence from now on. If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf,
- an error occurs when the firewall script attempts to add an SNAT
- alias. The logunclean and dropunclean options
cause errors during startup when Shorewall is run with iptables
- 1.2.7. These problems are fixed in
this correct firewall script which must be installed in
/var/lib/shorewall/ as described above. These problems are also
corrected in version 1.3.7. A line was inadvertently deleted from the "interfaces
file" -- this line should be added back in if the version that you
- downloaded is missing it: net eth0 detect routefilter,dhcp,norfc1918 If you downloaded two-interfaces-a.tgz then the above
line should already be in the file. The new 'proxyarp' interface option doesn't work :-(
This is fixed in
this corrected firewall script which must be installed in
/var/lib/shorewall/ as described above. Prior to version 1.3.4, host file entries such as the
following were allowed: That capability was lost in version 1.3.4 so that it is only
- possible to include a single host specification on each line. This
- problem is corrected by this
- modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall
- as instructed above. This problem is corrected in version 1.3.5b. REDIRECT rules are broken in this version. Install
this corrected firewall script in /var/lib/pub/shorewall/firewall
- as instructed above. This problem is corrected in version 1.3.5a. The "shorewall start" and "shorewall restart" commands
to not verify that the zones named in the /etc/shorewall/policy
file have been previously defined in the /etc/shorewall/zones
file. The "shorewall check" command does perform this verification
so it's a good idea to run that command after you have made configuration
- changes. If you have upgraded from Shorewall 1.2 and after
"Activating rules..." you see the message: "iptables: No chains/target/match
- by that name" then you probably have an entry in /etc/shorewall/hosts
- that specifies an interface that you didn't include in /etc/shorewall/interfaces.
- To correct this problem, you must add an entry to /etc/shorewall/interfaces.
- Shorewall 1.3.3 and later versions produce a clearer error message
- in this case. Until approximately 2130 GMT on 17 June 2002, the
download sites contained an incorrect version of the .lrp file. That
file can be identified by its size (56284 bytes). The correct
version has a size of 38126 bytes. Both problems are corrected in
this script which should be installed in /var/lib/shorewall
- as described above. The IANA have just announced the allocation of subnet
- 221.0.0.0/8. This
updated rfc1918 file reflects that allocation. These problems are corrected in
this firewall script which should be installed in /etc/shorewall/firewall
- as described above. The upgrade issues have moved to a separate page. There are a couple of serious bugs in iptables 1.2.3 that
- prevent it from working with Shorewall. Regrettably, RedHat released
- this buggy iptables in RedHat 7.2. I have built a
- corrected 1.2.3 rpm which you can download here and I have also built
- an and I have also built
+ an
iptables-1.2.4 rpm which you can download here. If you are currently
- running RedHat 7.1, you can install either of these RPMs before
- you upgrade to RedHat 7.2. Update 11/9/2001: RedHat
- has released an iptables-1.2.4 RPM of their own which you can download
-from http://www.redhat.com/support/errata/RHSA-2001-144.html.
- I have installed this RPM on my firewall and it works fine. If you would like to patch iptables 1.2.3 yourself,
- the patches are available for download. This patch
- which corrects a problem with parsing of the --log-level specification
- while this patch
- corrects a problem in handling the TOS target. To install one of the above patches: To install one of the above patches: Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
- may experience the following: The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in
- the Netfilter 'mangle' table. You can correct the problem by installing
-
- this iptables RPM. If you are already running a 1.2.5 version of
- iptables, you will need to specify the --oldpackage option to rpm (e.g.,
- "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm"). If you find that rpm complains about a conflict
with kernel <= 2.2 yet you have a 2.4 kernel
installed, simply use the "--nodeps" option to
rpm. Installing: rpm -ivh --nodeps <shorewall rpm> Upgrading: rpm -Uvh --nodeps <shorewall rpm> The iptables 1.2.7 release of iptables has made
an incompatible change to the syntax used to
specify multiport match rules; as a consequence,
if you install iptables 1.2.7 you must be running
Shorewall 1.3.7a or later or: Last updated 9/28/2002 -
+
+ Last updated 10/9/2002 -
Tom Eastep Last updated 8/23/2002 17:16 GMT -
-Tom
-Eastep
-
-Copyright © 2002 Thomas M. Eastep. Last updated 11/3/2002 16:00 GMT - Tom Eastep Copyright © 2002 Thomas M. Eastep. I have DSL service and have 5 static IP addresses (206.124.146.176-180).
- My DSL "modem" (Fujitsu Speedport)
-is connected to eth0. I have a local network connected to eth2 (subnet 192.168.1.0/24)
- and a DMZ connected to eth1 (192.168.2.0/24). I have DSL service and have 5 static IP addresses (206.124.146.176-180).
+ My DSL "modem" (Fujitsu Speedport)
+ is connected to eth0. I have a local network connected to eth2 (subnet
+192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). I use: The firewall runs on a 128MB PII/233 with RH7.2 and Kernel 2.4.20-pre6. Wookie runs Samba and acts as the a WINS server. Wookie is in its
-own 'whitelist' zone called 'me'. My laptop (eastept1) is connected to eth3 using a cross-over cable.
-It runs its own Sygate firewall software
-and is managed by Proxy ARP. It connects to the local network through the
-PopTop server running on my firewall. The single system in the DMZ (address 206.124.146.177) runs postfix,
-Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP server
- (Pure-ftpd). The system also runs fetchmail to fetch our email from our
- old and current ISPs. That server is managed through Proxy ARP. The firewall system itself runs a DHCP server that serves the local
- network. Wookie runs Samba and acts as the a WINS server. Wookie is in its
+ own 'whitelist' zone called 'me'. My laptop (eastept1) is connected to eth3 using a cross-over cable.
+ It runs its own Sygate firewall software
+ and is managed by Proxy ARP. It connects to the local network through
+the PopTop server running on my firewall. The single system in the DMZ (address 206.124.146.177) runs postfix,
+ Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP server
+ (Pure-ftpd). The system also runs fetchmail to fetch our email from our
+ old and current ISPs. That server is managed through Proxy ARP. The firewall system itself runs a DHCP server that serves the local
+ network. All administration and publishing is done using ssh/scp. I run an SNMP server on my firewall to serve MRTG running
-in the DMZ. The ethernet interface in the Server is configured
- with IP address 206.124.146.177, netmask
- 255.255.255.0. The server's default gateway is
- 206.124.146.254 (Router at my ISP. This is the same
- default gateway used by the firewall itself). On the firewall,
- Shorewall automatically adds a host route to
- 206.124.146.177 through eth1 (192.168.2.1) because
-of the entry in /etc/shorewall/proxyarp (see below). A similar setup is used on eth3 (192.168.3.1) which
- interfaces to my laptop (206.124.146.180). Note: My files
- use features not available before Shorewall version
-1.3.4. This is set up so that I can start the firewall before bringing up my
-Ethernet interfaces. The ethernet interface in the Server is configured
+ with IP address 206.124.146.177, netmask
+ 255.255.255.0. The server's default gateway is
+ 206.124.146.254 (Router at my ISP. This is the same
+ default gateway used by the firewall itself). On the firewall,
+ Shorewall automatically adds a host route to
+ 206.124.146.177 through eth1 (192.168.2.1) because
+ of the entry in /etc/shorewall/proxyarp (see
+below). A similar setup is used on eth3 (192.168.3.1) which
+ interfaces to my laptop (206.124.146.180). Note: My files
+ use features not available before Shorewall
+version 1.3.4. This is set up so that I can start the firewall before bringing up
+my Ethernet interfaces. Although most of our internal systems use static NAT, my wife's system
- (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with laptops. Although most of our internal systems use static NAT, my wife's system
+ (192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with
+laptops. Also, I masquerade wookie to the peer subnet in Texas. Last updated 9/19/2002 -
- Tom Eastep
- Last updated 10/14/2002 -
+ Tom Eastep
+ In addition to those applications described in the
-/etc/shorewall/rules documentation, here are some other
-services/applications that you may need to configure your firewall to accommodate. In addition to those applications described in the /etc/shorewall/rules documentation, here
+are some other services/applications that you may need to configure your firewall
+to accommodate. NTP (Network Time Protocol) UDP Port 123 rdate rdate TCP Port 37 UseNet (NNTP) UseNet (NNTP) TCP Port 119 DNS UDP Port 53. If you are configuring a DNS client, you will probably want to
- open TCP Port 53 as well. ICQ UDP Port 4000. You will also need to open a range of TCP ports which you
- can specify to your ICQ client. By default, clients use 4000-4100. UDP Port 53. If you are configuring a DNS client, you will probably want
+to open TCP Port 53 as well. ICQ UDP Port 4000. You will also need to open a range of TCP ports which
+you can specify to your ICQ client. By default, clients use 4000-4100. PPTP Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more
- information here). Protocol 47 (NOT port 47) and TCP Port 1723 (Lots more information here). IPSEC Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port 500.
- These should be opened in both directions. Protocols 50 and 51 (NOT ports 50 and 51) and UDP Port
+500. These should be opened in both directions. SMTP TCP Port 25. TCP Port 25. POP3 TCP Port 110. TELNET TCP Port 23. SSH TCP Port 22. Auth (identd) TCP Port 113 Web Access Web Access TCP Ports 80 and 443. FTP Server configuration is covered on in the
- /etc/shorewall/rules documentation, FTP Server configuration is covered on in the /etc/shorewall/rules documentation, For a client, you must open outbound TCP port 21 and be sure that your
- kernel is compiled to support FTP connection tracking. If you build this
- support as a module, Shorewall will automatically load the module from
- /var/lib/<kernel version>/kernel/net/ipv4/netfilter. SMB/NMB (Samba/Windows Browsing/File Sharing) If you run an FTP server on a nonstandard port or you need to access
+such a server, then you must specify that port in /etc/shorewall/modules.
+For example, if you run an FTP server that listens on port 49 then you would
+have: loadmodule ip_conntrack_ftp ports=21,49 Note that you MUST include port 21 in the ports list or you may
+have problems accessing regular FTP servers. If there is a possibility that these modules might be loaded before Shorewall
+starts, then you should include the port list in /etc/modules.conf: options ip_conntrack_ftp ports=21,49 SMB/NMB (Samba/Windows Browsing/File Sharing) TCP Ports 137, 139 and 445. Traceroute Traceroute UDP ports 33434 through 33434+<max number of hops>-1 NFS There's some good information at
-
- http://nfs.sourceforge.net/nfs-howto/security.html Didn't find what you are looking for -- have you looked in your own
- /etc/services file? Still looking? Try
-
- http://www.networkice.com/advice/Exploits/Ports Last updated 8/21/2002 -
-Tom
-Eastep NFS There's some good information at http://nfs.sourceforge.net/nfs-howto/security.html Didn't find what you are looking for -- have you looked in your own /etc/services
+file? Still looking? Try http://www.networkice.com/advice/Exploits/Ports Last updated 10/22/2002 - Tom Eastep "I just installed Shorewall after weeks of messing with ipchains/iptables
+
+ "I just installed Shorewall after weeks of messing with ipchains/iptables
and I had it up and running in under 20 minutes!" -- JL, Ohio "I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1 without
-any problems. Your documentation is great and I really appreciate your
-network configuration info. That really helped me out alot. THANKS!!!"
+ Minutes instead of months! Congratulations and thanks for such a simple
+and well documented thing for something as huge as iptables." -- JV, Spain.
+
+ "I downloaded Shorewall 1.2.0 and installed it on Mandrake 8.1 without
+any problems. Your documentation is great and I really appreciate your
+network configuration info. That really helped me out alot. THANKS!!!"
-- MM. "[Shorewall is a] great, great project. I've used/tested may firewall
-scripts but this one is till now the best." -- B.R, Netherlands
- "Never in my +12 year career as a sys admin have I witnessed someone
-so relentless in developing a secure, state of the art, save and useful
-product as the Shorewall firewall package for no cost or obligation
- involved." -- Mario Kericki, Toronto "one time more to report, that your great shorewall in the latest
- release 1.2.9 is working fine for me with SuSE Linux 7.3! I now
-have 7 machines up and running with shorewall on several versions -
-starting with 1.2.2 up to the new 1.2.9 and I never have encountered
-any problems!" -- SM, Germany "You have the best support of any other package I've ever used."
+
+ "[Shorewall is a] great, great project. I've used/tested may firewall
+scripts but this one is till now the best." -- B.R, Netherlands
+ "Never in my +12 year career as a sys admin have I witnessed someone
+so relentless in developing a secure, state of the art, safe and useful
+product as the Shorewall firewall package for no cost or obligation
+involved." -- Mario Kerecki, Toronto "one time more to report, that your great shorewall in the latest
+ release 1.2.9 is working fine for me with SuSE Linux 7.3! I now have
+7 machines up and running with shorewall on several versions - starting
+with 1.2.2 up to the new 1.2.9 and I never have encountered any problems!"
+-- SM, Germany "You have the best support of any other package I've ever used."
-- SE, US "Because our company has information which has been classified by the
- national government as secret, our security doesn't stop by putting a fence
- around our company. Information security is a hot issue. We also make use
-of checkpoint firewalls, but not all of the internet servers are guarded
-by checkpoint, some of them are running....Shorewall." -- Name withheld
-by request, Europe "thanx for all your efforts you put into shorewall - this product stands
-out against a lot of commercial stuff i´ve been working with in terms of
+
+ "Because our company has information which has been classified by the
+national government as secret, our security doesn't stop by putting a fence
+ around our company. Information security is a hot issue. We also make use
+of checkpoint firewalls, but not all of the internet servers are guarded
+by checkpoint, some of them are running....Shorewall." -- Name withheld by
+request, Europe "thanx for all your efforts you put into shorewall - this product stands
+out against a lot of commercial stuff i´ve been working with in terms of
flexibillity, quality & support" -- RM, Austria "I have never seen such a complete firewall package that is so easy to
- configure. I searched the Debian package system for firewall scripts and
+
+ "I have never seen such a complete firewall package that is so easy to
+ configure. I searched the Debian package system for firewall scripts and
Shorewall won hands down." -- RG, Toronto "My respects... I've just found and installed Shorewall 1.3.3-1 and it
-is a wonderful piece of software. I've just sent out an email to about 30
+
+ "My respects... I've just found and installed Shorewall 1.3.3-1 and it
+is a wonderful piece of software. I've just sent out an email to about 30
people recommending it. :-) Updated 9/24/2002
-- Tom Eastep
- Copyright
- © 2001, 2002 Thomas M. Eastep. Updated 10/9/2002
+- Tom Eastep
+ Copyright
+ © 2001, 2002 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. Copyright 2001, 2002 Thomas M. Eastep 9/28/2002 - Shorewall 1.3.9 In this version: 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored 9/18/2002 - Debian 1.3.8 Packages Available Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html 9/16/2002 - Shorewall 1.3.8 In this version: 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. Copyright 2001, 2002 Thomas M. Eastep 11/09/2002 - Shorewall 1.3.10 In this version: 10/24/2002 - Shorewall is now in Gentoo Linux 10/23/2002 - Shorewall 1.3.10 Beta 1 10/10/2002 - Debian 1.3.9b Packages Available
+ Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html. 10/9/2002 - Shorewall 1.3.9b 9/30/2002 - Shorewall 1.3.9a
+ 9/30/2002 - TUNNELS Broken in 1.3.9!!!
+ In this version: 9/11/2002 - Debian 1.3.7c Packages Available Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html. 9/2/2002 - Shorewall 1.3.7c This is a role up of a fix for "DNAT" rules where the source zone
- is $FW (fw). 8/26/2002 - Shorewall 1.3.7b This is a role up of the "shorewall refresh" bug fix and the change
- which reverses the order of "dhcp" and "norfc1918" checking. 8/26/2002 - French FTP Mirror is Operational ftp://france.shorewall.net/pub/mirrors/shorewall
- is now available. 8/25/2002 - Shorewall Mirror in France Thanks to a Shorewall user in Paris, the Shorewall web site is now
- mirrored at http://france.shorewall.net. Shorewall is free but
-if you try it and find it useful, please consider making a donation
- to Shorewall is free
+but if you try it and find it useful, please consider making a donation
+ to Starlight Children's Foundation. Thanks! Updated 9/27/2002 - Tom Eastep
+
+
- Updated 11/9/2002 - Tom Eastep
+
+ Tom on the Pacific Crest Trail north of Stevens Pass,
- Washington -- Sept 1991. I am currently a member of the design team for the next-generation
- operating system from the NonStop Enterprise Division of HP. I became interested in Internet Security when I established a home office
-in 1999 and had DSL service installed in our home. I investigated ipchains
-and developed the scripts which are now collectively known as Seattle Firewall. Expanding
-on what I learned from Seattle Firewall, I then designed and wrote
-Shorewall. I telework from our home in Shoreline,
- Washington where I live with my wife Tarry. Our current home network consists of: Tarry & Tom -- August 2002 I am currently a member of the design team for the next-generation
+ operating system from the NonStop Enterprise Division of HP. I became interested in Internet Security when I established a home office
+ in 1999 and had DSL service installed in our home. I investigated
+ipchains and developed the scripts which are now collectively known as Seattle Firewall. Expanding
+ on what I learned from Seattle Firewall, I then designed and wrote
+ Shorewall. I telework from our home in Shoreline,
+ Washington where I live with my wife Tarry. Our current home network consists of: For more about our network see my Shorewall Configuration. All of our other systems are made by Compaq (part of the new HP).. All of our Tulip NICs are Netgear FA310TXs. Last updated 10/28/2002 - Tom Eastep Load this certificate into your browser
-to use SSL to the Shorewall Site Last updated
-8/10/2002 - Tom
-Eastep Copyright
-© 2001, 2002 Thomas M. Eastep. Last updated 7/14/2002 - Tom
-Eastep
-Copyright © 2001,2002 Thomas M. Eastep. Last updated 11/09/2002 - Tom Eastep Copyright © 2001,2002 Thomas M. Eastep. With thanks to Richard who reminded me once again that we
must all first walk before we can run. These guides provide step-by-step instructions for configuring Shorewall
-in common firewall setups. The following guides are for users who have a single public IP address: The following guides are for users who have a single public IP address: The above guides are designed to get your first firewall up and running
- quickly in the three most common Shorewall configurations. The Shorewall Setup Guide outlines
- the steps necessary to set up a firewall where there are multiple public
-IP addresses involved or if you want to learn more about Shorewall than is
- explained in the single-address guides above. The following documentation covers a variety of topics and supplements
-the QuickStart Guides described
-above. The following documentation covers a variety of topics and supplements
+ the QuickStart Guides described
+ above. Please review the appropriate guide before trying to use this
+ documentation directly. If you use one of these guides and have a suggestion for improvement please let me know. Last modified 9/16/2002 - Last modified 11/3/2002 - Tom Eastep Copyright 2002 Thomas M. Eastep If you have a permanent internet connection such as DSL or Cable,
-I recommend that you start the firewall automatically at boot. Once you
- have installed "firewall" in your init.d directory, simply type
- "chkconfig --add firewall". This will start the firewall in run levels
-2-5 and stop it in run levels 1 and 6. If you want to configure your firewall
-differently from this default, you can use the "--level" option in
- chkconfig (see "man chkconfig") or using your favorite graphical run-level
-editor. Important Notes:
- You can manually start and stop Shoreline Firewall using the "shorewall"
+ If you have a permanent internet connection such as DSL or Cable,
+ I recommend that you start the firewall automatically at boot. Once
+you have installed "firewall" in your init.d directory, simply type
+ "chkconfig --add firewall". This will start the firewall in run levels
+ 2-5 and stop it in run levels 1 and 6. If you want to configure your
+firewall differently from this default, you can use the "--level" option
+in chkconfig (see "man chkconfig") or using your favorite graphical
+run-level editor. Important Notes:
+ You can manually start and stop Shoreline Firewall using the "shorewall"
shell program: The "shorewall" program may also be used to monitor the firewall. The shorewall start, shorewall restart, shorewall check and
+
+ The shorewall start, shorewall restart, shorewall check and
shorewall try commands allow you to specify which Shorewall configuration to use: shorewall [ -c configuration-directory ] {start|restart|check} If a configuration-directory is specified, each time that Shorewall
- is going to use a file in /etc/shorewall it will first look in the configuration-directory
- . If the file is present in the configuration-directory, that file
+
+ If a configuration-directory is specified, each time that Shorewall
+ is going to use a file in /etc/shorewall it will first look in the configuration-directory
+ . If the file is present in the configuration-directory, that file
will be used; otherwise, the file in /etc/shorewall will be used. When changing the configuration of a production firewall, I recommend
-the following: When changing the configuration of a production firewall, I recommend
+ the following: If the configuration starts but doesn't work, just "shorewall restart"
-to restore the old configuration. If the new configuration fails to start,
-the "try" command will automatically start the old one for you. If the configuration starts but doesn't work, just "shorewall restart"
+ to restore the old configuration. If the new configuration fails to start,
+ the "try" command will automatically start the old one for you. When the new configuration works then just Updated 9/26/2002 - Tom Eastep
+
+ Updated 10/23/2002 - Tom Eastep
Copyright
- © 2001, 2002 Thomas M. Eastep. Copyright
+ © 2001, 2002 Thomas M. Eastep. "Any sane computer will tell you how it works -- you just
- have to ask it the right questions" -- Tom Eastep "Any sane computer will tell you how it works -- you
+just have to ask it the right questions" -- Tom Eastep "It irks me when people believe that
- free software comes at no cost. The cost is incredibly high."
-- Wietse Venema "It irks me when people believe that
+ free software comes at no cost. The cost is incredibly high."
+ - Wietse Venema There are a number of sources for problem solution information. Otherwise, please post your question or problem to the Shorewall users mailing list;
- there are lots of folks there who are willing to help you. Your question/problem
- description and their responses will be placed in the mailing list archives
- to help people who have a similar question or problem in the future. I don't look at problems sent to me directly but I try to spend some amount
- of time each day responding to problems posted on the mailing list. I don't look at problems sent to me directly but I try to spend some amount
+ of time each day responding to problems posted on the mailing list. To Subscribe to the mailing list go to http://www.shorewall.net/mailman/listinfo/shorewall-users
+ href="http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users
. Last Updated 9/27/2002 - Tom Eastep Last Updated 10/13/2002 - Tom Eastep Copyright © 2001, 2002 Thomas M. Eastep. Setting up a Linux system as a firewall for a small network
- with DMZ is a fairly straight-forward task if you understand the basics
- and follow the documentation. This guide doesn't attempt to acquaint you with all of the features of
- Shorewall. It rather focuses on what is required to configure Shorewall
-in one of its more popular configurations: Here is a schematic of a typical installation. This guide assumes that you have the iproute/iproute2 package installed
- (on RedHat, the package is called iproute). You can tell if
- this package is installed by the presence of an ip program on your
- firewall system. As root, you can use the 'which' command to check for
-this program: I recommend that you first read through the guide to familiarize yourself
- with what's involved then go back through it again making your configuration
- changes. Points at which configuration changes are recommended are flagged
- with The configuration files for Shorewall are contained in the directory
/etc/shorewall -- for simple setups, you will only need to deal with a few
of these as described in this guide. After you have installed Shorewall, download the three-interface
- sample, un-tar it (tar -zxvf three-interfaces.tgz) and and copy the
-files to /etc/shorewall (the files will replace files with the same names
-that were placed in /etc/shorewall when Shorewall was installed). As each file is introduced, I suggest that you look through the actual
- file on your system -- each file contains detailed configuration instructions
- and default entries. Shorewall views the network where it is running as being composed of a
- set of zones. In the three-interface sample configuration, the following
- zone names are used: Zone names are defined in /etc/shorewall/zones. Shorewall also recognizes the firewall system as its own zone - by default,
- the firewall itself is known as fw. Rules about what traffic to allow and what traffic to deny are expressed
- in terms of zones. For each connection request entering the firewall, the request is first
- checked against the /etc/shorewall/rules file. If no rule in that file matches
- the connection request then the first policy in /etc/shorewall/policy that
- matches the request is applied. If that policy is REJECT or DROP the
-request is first checked against the rules in /etc/shorewall/common (the
+ checked against the /etc/shorewall/rules file. If no rule in that file
+matches the connection request then the first policy in /etc/shorewall/policy
+that matches the request is applied. If that policy is REJECT or DROP
+the request is first checked against the rules in /etc/shorewall/common (the
samples provide that file for you). The /etc/shorewall/policy file included with the three-interface sample
- has the following policies: In the three-interface sample, the line below is included but commented
- out. If you want your firewall system to have full access to servers on
-the internet, uncomment that line. The above policy will: The firewall has three network interfaces. Where Internet
- connectivity is through a cable or DSL "Modem", the External Interface
- will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)
- unless you connect via Point-to-Point Protocol
- over Ethernet (PPPoE) or Point-to-Point Tunneling
+ connectivity is through a cable or DSL "Modem", the External Interface
+ will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)
+ unless you connect via Point-to-Point Protocol
+ over Ethernet (PPPoE) or Point-to-Point Tunneling
Protocol (PPTP) in which case the External Interface will be
a ppp interface (e.g., ppp0). If you connect via a regular modem,
-your External Interface will also be ppp0. If you connect using ISDN,
- you external interface will be ippp0. Your Local Interface will be an ethernet adapter (eth0,
- eth1 or eth2) and will be connected to a hub or switch. Your local computers
- will be connected to the same switch (note: If you have only a single local
- system, you can connect the firewall directly to the computer using a cross-over
- cable). Your DMZ Interface will also be an ethernet adapter
- (eth0, eth1 or eth2) and will be connected to a hub or switch. Your DMZ
-computers will be connected to the same switch (note: If you have only a
-single DMZ system, you can connect the firewall directly to the computer
-using a cross-over cable). If your external interface is ppp0 or ippp0,
- you can replace the "detect" in the second column with "-". If your external interface is ppp0 or ippp0
- or if you have a static IP address, you can remove "dhcp" from the option
- list. Before going further, we should say a few words about Internet
- Protocol (IP) addresses. Normally, your ISP will assign you a single
- Public IP address. This address may be assigned via the Dynamic
- Host Configuration Protocol (DHCP) or as part of establishing your connection
- when you dial in (standard modem) or establish your PPP connection. In
-rare cases, your ISP may assign you a static IP address; that means
-that you configure your firewall's external interface to use that address
-permanently. Regardless of how the address is assigned, it will be
-shared by all of your systems when you access the Internet. You will have
-to assign your own addresses for your internal network (the local and DMZ
-Interfaces on your firewall plus your other computers). RFC 1918 reserves
+ Protocol (IP) addresses. Normally, your ISP will assign you a single
+ Public IP address. This address may be assigned via the Dynamic
+ Host Configuration Protocol (DHCP) or as part of establishing your
+connection when you dial in (standard modem) or establish your PPP connection.
+In rare cases, your ISP may assign you a static IP address; that
+means that you configure your firewall's external interface to use that
+address permanently. Regardless of how the address is assigned, it
+will be shared by all of your systems when you access the Internet. You will
+have to assign your own addresses for your internal network (the local and
+DMZ Interfaces on your firewall plus your other computers). RFC 1918 reserves
several Private IP address ranges for this purpose: You will want to assign your local addresses from one
- sub-network or subnet and your DMZ addresses from another
+ sub-network or subnet and your DMZ addresses from another
subnet. For our purposes, we can consider a subnet to consists of a range
of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a Subnet
Mask of 255.255.255.0. The address x.y.z.0 is reserved as the Subnet
-Address and x.y.z.255 is reserved as the Subnet Broadcast Address.
-In Shorewall, a subnet is described using Classless
-InterDomain Routing (CIDR) notation with consists of the subnet address
-followed by "/24". The "24" refers to the number of consecutive "1"
-bits from the left of the subnet mask. Example sub-network: It is conventional to assign the internal interface either
- the first usable address in the subnet (10.10.10.1 in the above example)
- or the last usable address (10.10.10.254). One of the purposes of subnetting is to allow all computers
- in the subnet to understand which other computers can be communicated
-with directly. To communicate with systems outside of the subnetwork, systems
-send packets through a gateway (router). The foregoing short discussion barely scratches the surface
- regarding subnetting and routing. If you are interested in learning more
- about IP addressing and routing, I highly recommend "IP Fundamentals:
- What Everyone Needs to Know about Addressing & Routing", Thomas
-A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0. The remainder of this quide will assume that you have configured
- your network as shown here: The default gateway for the DMZ computers would be 10.10.10.254
- and the default gateway for the Local computers would be 10.10.10.254. The default gateway for the DMZ computers would be 10.10.11.254
+ and the default gateway for the Local computers would be 10.10.10.254. 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. When one of your local
- systems (let's assume local computer 1) sends a connection request to an
- internet host, the firewall must perform Network Address Translation
-(NAT). The firewall rewrites the source address in the packet to be the
-address of the firewall's external interface; in other words, the firewall
-makes it look as if the firewall itself is initiating the connection. This
-is necessary so that the destination host will be able to route return packets
- back to the firewall (remember that packets whose destination address is
- reserved by RFC 1918 can't be routed accross the internet). When the firewall
- receives a return packet, it rewrites the destination address back to 10.10.10.1
- and forwards the packet on to local computer 1. On Linux systems, the above process is often referred to as
IP Masquerading and you will also see the term Source Network Address
Translation (SNAT) used. Shorewall follows the convention used with
Netfilter: Masquerade describes the case where you let your
- firewall system automatically detect the external interface address.
- SNAT refers to the case when you explicitly specify
- the source address that you want outbound packets from your local network
- to use. In Shorewall, both Masquerading and SNAT are configured with
- entries in the /etc/shorewall/masq file. One of your goals will be to run one or more servers on your
- DMZ computers. Because these computers have RFC-1918 addresses, it is not
- possible for clients on the internet to connect directly to them. It is
-rather necessary for those clients to address their connection requests to
-your firewall who rewrites the destination address to the address of your
+ DMZ computers. Because these computers have RFC-1918 addresses, it is not
+ possible for clients on the internet to connect directly to them. It is
+ rather necessary for those clients to address their connection requests
+to your firewall who rewrites the destination address to the address of your
server and forwards the packet to that server. When your server responds,
-the firewall automatically performs SNAT to rewrite the source address in
-the response. The above process is called Port Forwarding or
- Destination Network Address Translation (DNAT). You configure port
+ Destination Network Address Translation (DNAT). You configure port
forwarding using DNAT rules in the /etc/shorewall/rules file. The general form of a simple port forwarding rule in /etc/shorewall/rules
- is: If you don't specify the <server port>, it is assumed to be
-the same as <port>. Example - you run a Web Server on DMZ 2 and you want to forward incoming
- TCP port 80 to that system: A couple of important points to keep in mind: If you want to be able to access your server from the local network using
- your external address, then if you have a static external IP you can replace
- the loc->dmz rule above with: If you have a dynamic ip then you must ensure that your external interface
- is up before starting Shorewall and you must take steps as follows (assume
- that your external interface is eth0): If you want to access your server from the DMZ using your external IP
-address, see FAQ 2a. Normally, when you connect to your ISP, as part of getting
- an IP address your firewall's Domain Name Service (DNS) resolver
-will be automatically configured (e.g., the /etc/resolv.conf file will be
-written). Alternatively, your ISP may have given you the IP address of a
-pair of DNS name servers for you to manually configure as your primary
-and secondary name servers. It is your responsibility to configure
-the resolver in your internal systems. You can take one of two approaches: You can configure your internal systems to use your ISP's
- name servers. If you ISP gave you the addresses of their servers or if
- those addresses are available on their web site, you can configure your
- internal systems to use those addresses. If that information isn't available,
- look in /etc/resolv.conf on your firewall system -- the name servers are
- given in "nameserver" records in that file. If you run the name server on the firewall:
- Run name server on DMZ computer 1 The three-interface sample includes the following rules: Those rules allow DNS access from your firewall and may be
- removed if you commented out the line in /etc/shorewall/policy allowing
- all connections from the firewall to the internet. The sample also includes: That rule allows you to run an SSH server on your firewall
- and in each of your DMZ systems and to connect to those servers from
- your local systems. If you wish to enable other connections between your systems,
- the general format is: Example - You want to run a publicly-available DNS server
- on your firewall system: If you don't specify the <server port>, it is assumed to be
+the same as <port>. Example - you run a Web Server on DMZ 2 and you want to forward incoming
+ TCP port 80 to that system: A couple of important points to keep in mind: If you want to be able to access your server from the local network using
+ your external address, then if you have a static external IP you can replace
+ the loc->dmz rule above with: If you have a dynamic ip then you must ensure that your external interface
+ is up before starting Shorewall and you must take steps as follows (assume
+ that your external interface is eth0): If you want to access your server from the DMZ using your external IP
+address, see FAQ 2a. Normally, when you connect to your ISP, as part of getting
+ an IP address your firewall's Domain Name Service (DNS) resolver
+ will be automatically configured (e.g., the /etc/resolv.conf file will be
+ written). Alternatively, your ISP may have given you the IP address of
+a pair of DNS name servers for you to manually configure as your
+primary and secondary name servers. It is your responsibility to
+configure the resolver in your internal systems. You can take one of two
+approaches: You can configure your internal systems to use your ISP's
+ name servers. If you ISP gave you the addresses of their servers or if
+ those addresses are available on their web site, you can configure your
+ internal systems to use those addresses. If that information isn't available,
+ look in /etc/resolv.conf on your firewall system -- the name servers
+are given in "nameserver" records in that file. If you run the name server on the firewall:
+
+ Run name server on DMZ computer 1 The three-interface sample includes the following rules: Those rules allow DNS access from your firewall and may be
+ removed if you commented out the line in /etc/shorewall/policy allowing
+ all connections from the firewall to the internet. The sample also includes: That rule allows you to run an SSH server on your firewall
+ and in each of your DMZ systems and to connect to those servers from
+ your local systems. If you wish to enable other connections between your systems,
+ the general format is: Example - You want to run a publicly-available DNS server
+ on your firewall system: Those two rules would of course be in addition to the rules
- listed above under "If you run the name server on your firewall". If you don't know what port and protocol a particular application
uses, look here. Important: I don't recommend enabling telnet to/from
- the internet because it uses clear text (even for login!). If you want
- shell access to your firewall from the internet, use SSH: IMPORTANT: Users of the .deb package must edit /etc/default/shorewall
-and set 'startup=1'. 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". 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 9/26/2002 - alternate configuration
+ and test it using the "shorewall
+ try" command. Last updated 10/22/2002 - Tom Eastep Copyright 2002 Thomas
- M. Eastep Beginning with version 1.2.0, Shorewall has limited support for traffic
-shaping/control. In order to use traffic shaping under Shorewall, it is
-essential that you get a copy of the Linux Advanced Routing
-and Shaping HOWTO, version 0.3.0 or later. You must also install
-the iproute (iproute2) package to provide the "ip" and "tc"
-utilities. Beginning with version 1.2.0, Shorewall has limited support
+for traffic shaping/control. In order to use traffic shaping under Shorewall,
+it is essential that you get a copy of the Linux Advanced Routing and Shaping HOWTO,
+version 0.3.0 or later. You must also install the iproute (iproute2) package
+to provide the "ip" and "tc" utilities. Shorewall traffic shaping support consists of the following: This screen shot show how I've configured QoS in my Kernel: The fwmark classifier provides a convenient way to classify
-packets for traffic shaping. The /etc/shorewall/tcrules file provides a means
-for specifying these marks in a tabular fashion. Columns in the file are as follows: Example 1 - All packets arriving on eth1 should be marked with
-1. All packets arriving on eth2 should be marked with 2. All packets originating
-on the firewall itself should be marked with 3. Example 1 - All packets arriving on eth1 should be marked
+with 1. All packets arriving on eth2 should be marked with 2. All packets
+originating on the firewall itself should be marked with 3. Example 2 - All GRE (protocol 47) packets not originating on the
-firewall and destined for 155.186.235.151 should be marked with 12. Example 2 - All GRE (protocol 47) packets not originating
+on the firewall and destined for 155.186.235.151 should be marked with 12. Example 3 - All SSH packets originating in 192.168.1.0/24 and
-destined for 155.186.235.151 should be marked with 22. Example 3 - All SSH packets originating in 192.168.1.0/24
+and destined for 155.186.235.151 should be marked with 22. I personally use HTB. I have found a couple of things that may be of
-use to others. I personally use HTB. I have found a couple of things that may be of use
+to others. run_tc qdisc add dev eth0 root handle 1: htb default 30 My tcrules file is shown in Example 1 above. You can look at my network
- configuration to get an idea of why I want these particular rules. Last Updated 8/24/2002 - Tom
-Eastep My tcrules file is shown in Example 1 above. You can look at my network configuration to get an idea of why I want
+these particular rules. Last Updated 10/25/2002 - Tom Eastep Copyright
-© 2001, 2002 Thomas M. Eastep. Check the Shorewall Errata to be
+sure that there isn't an update that you are missing for your version of
+the firewall. Check the FAQs for solutions to common
+problems. Check the Shorewall Errata
- to be sure that there isn't an update that you are missing for your version
-of the firewall. Check the FAQs for solutions to common problems. Many times when people have problems with Shorewall, the problem is
- actually an ill-conceived test setup. Here are several popular snafus: If the appropriate policy for the connection that you
-are trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING
-TO MAKE IT WORK. Such additional rules will NEVER make it work, they add
-clutter to your rule set and they represent a big security hole in the event
-that you forget to remove them later. I also recommend against setting all of your policies to
- ACCEPT in an effort to make something work. That robs you of one of your
- best diagnostic tools - the "Shorewall" messages that Netfilter will
- generate when you try to connect in a way that isn't permitted by your
- rule set. Check your log. If you don't see Shorewall messages,
-then your problem is probably NOT a Shorewall problem. If you DO see packet
-messages, it is an indication that you are missing one or more rules. While you are troubleshooting, it is a good idea to clear
+ Many times when people have problems with Shorewall, the problem is
+ actually an ill-conceived test setup. Here are several popular snafus: If the appropriate policy for the connection that you are
+trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING
+TO MAKE IT WORK. Such additional rules will NEVER make it work, they add clutter
+to your rule set and they represent a big security hole in the event that
+you forget to remove them later. I also recommend against setting all of your policies to
+ ACCEPT in an effort to make something work. That robs you of one of
+your best diagnostic tools - the "Shorewall" messages that Netfilter
+will generate when you try to connect in a way that isn't permitted
+by your rule set. Check your log. If you don't see Shorewall messages, then
+your problem is probably NOT a Shorewall problem. If you DO see packet messages,
+it may be an indication that you are missing one or more rules -- see FAQ 17. While you are troubleshooting, it is a good idea to clear
two variables in /etc/shorewall/shorewall.conf: LOGRATE="" This way, you will see all of the log messages being
- generated (be sure to restart shorewall after clearing these variables). Example: Jun 27 15:37:56 gateway kernel:
- Shorewall:all2all:REJECT:IN=eth2
-OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63
-ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47 Let's look at the important parts of this message: LOGRATE="" This way, you will see all of the log messages being
+ generated (be sure to restart shorewall after clearing these variables). Example: Jun 27 15:37:56 gateway kernel:
+ Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3
+LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47 Let's look at the important parts of this message: In this case, 192.168.2.2 was in the "dmz" zone and
-192.168.1.3 is in the "loc" zone. I was missing the rule: ACCEPT dmz loc udp 53 In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3
+is in the "loc" zone. I was missing the rule: ACCEPT dmz loc udp 53 See the support page. See the support page. Last updated 10/17/2002 - Tom Eastep Last updated 9/13/2002 -
-Tom Eastep
- Copyright
- © 2001, 2002 Thomas M. Eastep. Copyright
+ © 2001, 2002 Thomas M. Eastep. Setting up a Linux system as a firewall for a small network
- is a fairly straight-forward task if you understand the basics and follow
- the documentation. This guide doesn't attempt to acquaint you with all of the features of
- Shorewall. It rather focuses on what is required to configure Shorewall
-in its most common configuration: Setting up a Linux system as a firewall for a small network
+ is a fairly straight-forward task if you understand the basics and follow
+ the documentation. This guide doesn't attempt to acquaint you with all of the features of
+ Shorewall. It rather focuses on what is required to configure Shorewall
+ in its most common configuration: Here is a schematic of a typical installation. This guide assumes that you have the iproute/iproute2 package installed
- (on RedHat, the package is called iproute). You can tell if
- this package is installed by the presence of an ip program on your
- firewall system. As root, you can use the 'which' command to check for
-this program: This guide assumes that you have the iproute/iproute2 package installed
+ (on RedHat, the package is called iproute). You can tell
+if this package is installed by the presence of an ip program on
+your firewall system. As root, you can use the 'which' command to check
+for this program: I recommend that you first read through the guide to familiarize yourself
- with what's involved then go back through it again making your configuration
- changes. Points at which configuration changes are recommended are flagged
- with I recommend that you first read through the guide to familiarize yourself
+ with what's involved then go back through it again making your configuration
+ changes. Points at which configuration changes are recommended are flagged
+ with The configuration files for Shorewall are contained in the directory
-/etc/shorewall -- for simple setups, you will only need to deal with a few
-of these as described in this guide. After you have installed Shorewall, download the two-interface sample,
- un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall
- (these files will replace files with the same name). As each file is introduced, I suggest that you look through the actual
- file on your system -- each file contains detailed configuration instructions
- and default entries. Shorewall views the network where it is running as being composed of a
- set of zones. In the two-interface sample configuration, the following
- zone names are used: The configuration files for Shorewall are contained in the directory /etc/shorewall
+-- for simple setups, you will only need to deal with a few of these as
+described in this guide. After you have installed
+Shorewall, download the two-interface sample,
+ un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall
+ (these files will replace files with the same name). As each file is introduced, I suggest that you look through the actual
+ file on your system -- each file contains detailed configuration instructions
+ and default entries. Shorewall views the network where it is running as being composed of a
+ set of zones. In the two-interface sample configuration, the following
+ zone names are used: Zones are defined in the /etc/shorewall/zones
- file. Shorewall also recognizes the firewall system as its own zone - by default,
- the firewall itself is known as fw. Rules about what traffic to allow and what traffic to deny are expressed
- in terms of zones. Zones are defined in the /etc/shorewall/zones
+ file. Shorewall also recognizes the firewall system as its own zone - by default,
+ the firewall itself is known as fw. Rules about what traffic to allow and what traffic to deny are expressed
+ in terms of zones. For each connection request entering the firewall, the request is first
- checked against the /etc/shorewall/rules file. If no rule in that file matches
- the connection request then the first policy in /etc/shorewall/policy that
- matches the request is applied. If that policy is REJECT or DROP the
-request is first checked against the rules in /etc/shorewall/common (the
-samples provide that file for you). The /etc/shorewall/policy file included with the two-interface sample has
-the following policies: For each connection request entering the firewall, the request is first
+ checked against the /etc/shorewall/rules file. If no rule in that file
+matches the connection request then the first policy in /etc/shorewall/policy
+that matches the request is applied. If that policy is REJECT or DROP
+the request is first checked against the rules in /etc/shorewall/common
+(the samples provide that file for you). The /etc/shorewall/policy file included with the two-interface sample
+has the following policies: In the two-interface sample, the line below is included but commented
- out. If you want your firewall system to have full access to servers on
-the internet, uncomment that line. In the two-interface sample, the line below is included but commented
+ out. If you want your firewall system to have full access to servers on
+ the internet, uncomment that line. The above policy will: The firewall has two network interfaces. Where Internet
-connectivity is through a cable or DSL "Modem", the External Interface
- will be the ethernet adapter that is connected to that "Modem" (e.g., eth0)
- unless you connect via Point-to-Point Protocol
- over Ethernet (PPPoE) or Point-to-Point Tunneling
- Protocol (PPTP) in which case the External Interface will be
-a ppp interface (e.g., ppp0). If you connect via a regular modem,
-your External Interface will also be ppp0. If you connect via ISDN,
+ The firewall has two network interfaces. Where Internet connectivity
+is through a cable or DSL "Modem", the External Interface will be
+the ethernet adapter that is connected to that "Modem" (e.g., eth0)
+ unless you connect via Point-to-Point Protocol
+ over Ethernet (PPPoE) or Point-to-Point Tunneling
+ Protocol (PPTP) in which case the External Interface will be
+a ppp interface (e.g., ppp0). If you connect via a regular modem,
+your External Interface will also be ppp0. If you connect via ISDN,
your external interface will be ippp0. Your Internal Interface will be an ethernet adapter
- (eth1 or eth0) and will be connected to a hub or switch. Your other computers
- will be connected to the same hub/switch (note: If you have only a single
- internal system, you can connect the firewall directly to the computer using
- a cross-over cable). Your Internal Interface will be an ethernet adapter
+ (eth1 or eth0) and will be connected to a hub or switch. Your other computers
+ will be connected to the same hub/switch (note: If you have only a single
+ internal system, you can connect the firewall directly to the computer
+using a cross-over cable). If your external interface is ppp0 or ippp0,
- you can replace the "detect" in the second column with "-". If your external interface is ppp0 or ippp0
- or if you have a static IP address, you can remove "dhcp" from the option
- list. If your external interface is ppp0 or ippp0,
+ you can replace the "detect" in the second column with "-". If your external interface is ppp0 or ippp0
+ or if you have a static IP address, you can remove "dhcp" from the option
+ list. Before going further, we should say a few words about Internet
- Protocol (IP) addresses. Normally, your ISP will assign you a single
- Public IP address. This address may be assigned via the Dynamic
- Host Configuration Protocol (DHCP) or as part of establishing your connection
- when you dial in (standard modem) or establish your PPP connection. In
-rare cases, your ISP may assign you a static IP address; that means
-that you configure your firewall's external interface to use that address
-permanently. However your external address is assigned, it will be
-shared by all of your systems when you access the Internet. You will have
-to assign your own addresses in your internal network (the Internal Interface
-on your firewall plus your other computers). RFC 1918 reserves several
-Private IP address ranges for this purpose: Before going further, we should say a few words about Internet
+ Protocol (IP) addresses. Normally, your ISP will assign you a single
+ Public IP address. This address may be assigned via the Dynamic
+ Host Configuration Protocol (DHCP) or as part of establishing your
+connection when you dial in (standard modem) or establish your PPP connection.
+In rare cases, your ISP may assign you a static IP address; that
+means that you configure your firewall's external interface to use that
+address permanently. However your external address is assigned, it
+will be shared by all of your systems when you access the Internet. You
+will have to assign your own addresses in your internal network (the Internal
+Interface on your firewall plus your other computers). RFC 1918 reserves
+several Private IP address ranges for this purpose: You will want to assign your addresses from the same
- sub-network (subnet). For our purposes, we can consider a subnet
- to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet
- will have a Subnet Mask of 255.255.255.0. The address x.y.z.0 is
- reserved as the Subnet Address and x.y.z.255 is reserved as the
- Subnet Broadcast Address. In Shorewall, a subnet is described
- using Classless InterDomain Routing (CIDR)
- notation with consists of the subnet address followed by "/24". The
- "24" refers to the number of consecutive leading "1" bits from the left
- of the subnet mask. You will want to assign your addresses from the same
+ sub-network (subnet). For our purposes, we can consider a subnet
+ to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet
+ will have a Subnet Mask of 255.255.255.0. The address x.y.z.0
+is reserved as the Subnet Address and x.y.z.255 is reserved as
+the Subnet Broadcast Address. In Shorewall, a subnet is
+described using Classless InterDomain Routing
+(CIDR) notation with consists of the subnet address followed
+by "/24". The "24" refers to the number of consecutive leading "1" bits
+from the left of the subnet mask. Example sub-network: It is conventional to assign the internal interface either
+ the first usable address in the subnet (10.10.10.1 in the above example)
+ or the last usable address (10.10.10.254). It is conventional to assign the internal interface either
- the first usable address in the subnet (10.10.10.1 in the above example)
- or the last usable address (10.10.10.254). One of the purposes of subnetting is to allow all computers
- in the subnet to understand which other computers can be communicated
-with directly. To communicate with systems outside of the subnetwork, systems
-send packets through a gateway (router). One of the purposes of subnetting is to allow all computers
+ in the subnet to understand which other computers can be communicated
+ with directly. To communicate with systems outside of the subnetwork,
+systems send packets through a gateway (router). The foregoing short discussion barely scratches the surface
- regarding subnetting and routing. If you are interested in learning more
- about IP addressing and routing, I highly recommend "IP Fundamentals:
- What Everyone Needs to Know about Addressing & Routing", Thomas
-A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0. The remainder of this quide will assume that you have configured
- your network as shown here: The foregoing short discussion barely scratches the surface
+ regarding subnetting and routing. If you are interested in learning more
+ about IP addressing and routing, I highly recommend "IP Fundamentals:
+ What Everyone Needs to Know about Addressing & Routing", Thomas
+ A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0. The remainder of this quide will assume that you have configured
+ your network as shown here: The default gateway for computer's 1 & 2 would be 10.10.10.254. 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. When one of your local
- systems (let's assume computer 1) sends a connection request to an internet
- host, the firewall must perform Network Address Translation (NAT).
- The firewall rewrites the source address in the packet to be the address
- of the firewall's external interface; in other words, the firewall makes
- it look as if the firewall itself is initiating the connection. This is
- necessary so that the destination host will be able to route return packets
- back to the firewall (remember that packets whose destination address is
- reserved by RFC 1918 can't be routed across the internet so the remote host
- can't address its response to computer 1). When the firewall receives a
-return packet, it rewrites the destination address back to 10.10.10.1 and
- forwards the packet on to computer 1. On Linux systems, the above process is often referred to as
- IP Masquerading but you will also see the term Source Network Address
- Translation (SNAT) used. Shorewall follows the convention used with
- Netfilter: 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. When one of your local
+ systems (let's assume computer 1) sends a connection request to an internet
+ host, the firewall must perform Network Address Translation (NAT).
+ The firewall rewrites the source address in the packet to be the address
+ of the firewall's external interface; in other words, the firewall makes
+ it look as if the firewall itself is initiating the connection. This
+is necessary so that the destination host will be able to route return
+packets back to the firewall (remember that packets whose destination
+address is reserved by RFC 1918 can't be routed across the internet so
+the remote host can't address its response to computer 1). When the firewall
+receives a return packet, it rewrites the destination address back to 10.10.10.1
+and forwards the packet on to computer 1. On Linux systems, the above process is often referred to
+as IP Masquerading but you will also see the term Source Network
+Address Translation (SNAT) used. Shorewall follows the convention used
+with Netfilter: Masquerade describes the case where you let your
- firewall system automatically detect the external interface address.
- SNAT refers to the case when you explicitly specify
- the source address that you want outbound packets from your local network
- to use. Masquerade describes the case where you let your
+ firewall system automatically detect the external interface address.
+ SNAT refers to the case when you explicitly specify
+ the source address that you want outbound packets from your local network
+ to use. In Shorewall, both Masquerading and SNAT are configured with
- entries in the /etc/shorewall/masq file. You will normally use Masquerading
- if your external IP is dynamic and SNAT if the IP is static. In Shorewall, both Masquerading and SNAT are configured with
+ entries in the /etc/shorewall/masq file. You will normally use Masquerading
+ if your external IP is dynamic and SNAT if the IP is static. One of your goals may be to run one or more servers on your
- local computers. Because these computers have RFC-1918 addresses, it is
-not possible for clients on the internet to connect directly to them. It
-is rather necessary for those clients to address their connection requests
-to the firewall who rewrites the destination address to the address of your
- server and forwards the packet to that server. When your server responds,
- the firewall automatically performs SNAT to rewrite the source address in
- the response. The above process is called Port Forwarding or
- Destination Network Address Translation (DNAT). You configure port
- forwarding using DNAT rules in the /etc/shorewall/rules file. The general form of a simple port forwarding rule in /etc/shorewall/rules
- is: One of your goals may be to run one or more servers on your
+ local computers. Because these computers have RFC-1918 addresses, it is
+ not possible for clients on the internet to connect directly to them. It
+ is rather necessary for those clients to address their connection requests
+ to the firewall who rewrites the destination address to the address of
+your server and forwards the packet to that server. When your server responds,
+ the firewall automatically performs SNAT to rewrite the source address
+in the response. The above process is called Port Forwarding or
+ Destination Network Address Translation (DNAT). You configure port
+forwarding using DNAT rules in the /etc/shorewall/rules file. The general form of a simple port forwarding rule in /etc/shorewall/rules
+ is: Example - you run a Web Server on computer 2 and you want to forward incoming
- TCP port 80 to that system: Example - you run a Web Server on computer 2 and you want to forward incoming
+ TCP port 80 to that system: A couple of important points to keep in mind: Normally, when you connect to your ISP, as part of getting
- an IP address your firewall's Domain Name Service (DNS) resolver
-will be automatically configured (e.g., the /etc/resolv.conf file will be
-written). Alternatively, your ISP may have given you the IP address of a
-pair of DNS name servers for you to manually configure as your primary
-and secondary name servers. Regardless of how DNS gets configured on your
-firewall, it is your responsibility to configure the resolver in your
- internal systems. You can take one of two approaches: Normally, when you connect to your ISP, as part of getting
+ an IP address your firewall's Domain Name Service (DNS) resolver
+ will be automatically configured (e.g., the /etc/resolv.conf file will
+be written). Alternatively, your ISP may have given you the IP address
+of a pair of DNS name servers for you to manually configure as your
+primary and secondary name servers. Regardless of how DNS gets configured
+on your firewall, it is your responsibility to configure the resolver
+in your internal systems. You can take one of two approaches: You can configure your internal systems to use your ISP's
- name servers. If you ISP gave you the addresses of their servers or if
- those addresses are available on their web site, you can configure your
- internal systems to use those addresses. If that information isn't available,
- look in /etc/resolv.conf on your firewall system -- the name servers are
- given in "nameserver" records in that file. You can configure your internal systems to use your ISP's
+ name servers. If you ISP gave you the addresses of their servers or
+if those addresses are available on their web site, you can configure
+your internal systems to use those addresses. If that information isn't
+available, look in /etc/resolv.conf on your firewall system -- the name
+servers are given in "nameserver" records in that file. The two-interface sample includes the following rules: Those rules allow DNS access from your firewall and may be
+ removed if you uncommented the line in /etc/shorewall/policy allowing
+ all connections from the firewall to the internet. Those rules allow DNS access from your firewall and may be
- removed if you commented out the line in /etc/shorewall/policy allowing
- all connections from the firewall to the internet. The sample also includes: That rule allows you to run an SSH server on your firewall
+ and connect to that server from your local systems. That rule allows you to run an SSH server on your firewall
- and connect to that server from your local systems. If you wish to enable other connections between your firewall
- and other systems, the general format is: If you wish to enable other connections between your firewall
+ and other systems, the general format is: Example - You want to run a Web Server on your firewall
+ system: Example - You want to run a Web Server on your firewall
- system: Those two rules would of course be in addition to the rules
+ listed above under "You can configure a Caching Name Server on your
+firewall" Those two rules would of course be in addition to the rules
- listed above under "You can configure a Caching Name Server on your firewall" If you don't know what port and protocol a particular application
-uses, look here. Important: I don't recommend enabling telnet to/from
- the internet because it uses clear text (even for login!). If you want
- shell access to your firewall from the internet, use SSH: If you don't know what port and protocol a particular
+application uses, look here. Important: I don't recommend enabling telnet to/from
+ the internet because it uses clear text (even for login!). If you want
+ shell access to your firewall from the internet, use SSH: IMPORTANT: Users of the .deb package must edit /etc/default/shorewall
+ color="#ff0000">Users of the .deb package must edit /etc/default/shorewall
and set 'startup=1'. 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". 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". 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 9/26/2002 -
+
+ 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 10/9/2002 - Tom Eastep Copyright 2002 Thomas
- M. Eastep Copyright 2002 Thomas
+ M. Eastep For upgrade instructions see the Install/Upgrade page. If you have a pair of firewall systems configured for failover
-or if you have asymmetric routing, you will need to modify
- your firewall setup slightly under Shorewall
- versions >= 1.3.8. Beginning with version 1.3.7,
- you must set NEWNOTSYN=Yes in your
- /etc/shorewall/shorewall.conf file. If you have a pair of firewall systems configured for failover
+ or if you have asymmetric routing, you will need to modify
+ your firewall setup slightly under Shorewall
+ versions >= 1.3.8. Beginning with version 1.3.8,
+ you must set NEWNOTSYN=Yes in your
+ /etc/shorewall/shorewall.conf file. Users specifying ALLOWRELATED=No in /etc/shorewall.conf
-will need to include the following rules in
-their /etc/shorewall/icmpdef file (creating
-this file if necessary): Users specifying ALLOWRELATED=No in /etc/shorewall.conf
+ will need to include the following rules
+in their /etc/shorewall/icmpdef file (creating
+ this file if necessary): Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
-command from that file since the icmp.def file is now empty. To properly upgrade with Shorewall version
- 1.3.3 and later: Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
+ command from that file since the icmp.def file is now empty. To properly upgrade with Shorewall version
+ 1.3.3 and later: The .lrp that I release isn't set up for a two-interface firewall like
+ Jacques's. You need to follow the instructions
+ for setting up a two-interface firewall plus you also need to add
+the following two Bering-specific rules to /etc/shorewall/rules: If you have a pair of firewall systems configured for
+ failover or if you have asymmetric routing, you will need to modify
+ your firewall setup slightly under Shorewall versions 1.3.6
+and 1.3.7 Create the file /etc/shorewall/newnotsyn and in it add
+ the following rule Create /etc/shorewall/common (if you don't already
+ have that file) and include the following: The .lrp that I release isn't set up for a two-interface firewall like
- Jacques's. You need to follow the instructions
-for setting up a two-interface firewall plus you also need to add the
-following two Bering-specific rules to /etc/shorewall/rules: If you have a pair of firewall systems configured for
- failover or if you have asymmetric routing, you will need to modify
- your firewall setup slightly under Shorewall versions 1.3.6 and
-1.3.7 Create the file /etc/shorewall/newnotsyn and in it add
- the following rule Create /etc/shorewall/common (if you don't already
- have that file) and include the following: Some forms of pre-1.3.0 rules file syntax are no
- longer supported. Some forms of pre-1.3.0 rules file syntax are no
+ longer supported. Example 1: Must be replaced with: Example 2: Must be replaced with: The functions and versions files together with the
- 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
- If you have applications that access these files, those applications
- should be modified accordingly. Last updated 9/28/2002 -
- Tom Eastep Copyright
- © 2001, 2002 Thomas M. Eastep. The functions and versions files together with the
+ 'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
+ If you have applications that access these files, those applications
+ should be modified accordingly. Last updated 11/09/2002 -
+ Tom Eastep Copyright
+ © 2001, 2002 Thomas M. Eastep.
+
+ Example 1:
+
+ /etc/shorewall/rules
+ # Accept AUTH but only on address 192.0.2.125
+ Example 2 (NAT):
ACCEPT net fw:192.0.2.125 tcp auth
+
+ /etc/shorewall/nat
+
+ 192.0.2.126 eth0 10.1.1.126
+ /etc/shorewall/rules
+ # Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)
+
+
ACCEPT net loc:10.1.1.126 tcp www
+
+
+
+
+
+
diff --git a/Shorewall-docs/IPSEC.htm b/Shorewall-docs/IPSEC.htm
index fee400531..e3518fd2e 100644
--- a/Shorewall-docs/IPSEC.htm
+++ b/Shorewall-docs/IPSEC.htm
@@ -1,284 +1,367 @@
-
-
+
+
-
-
-
-
-
- IPSEC Tunnels
- Configuring FreeS/Wan
-There is an excellent guide to configuring IPSEC tunnels at
- http://jixen.tripod.com
-. I highly recommend that you consult that site for information about confuring
-FreeS/Wan.
-
-IPSec Gateway
-on the Firewall System
-
-
- 
-
-
-
-
-
-
-
-
- TYPE
-
- ZONE
-
- GATEWAY
-
- GATEWAY ZONE
-
-
-
-
- ipsec
- net
- 134.28.54.2
-
-
-
-
-
-
-
-
-
- TYPE
-
- ZONE
-
- GATEWAY
-
- GATEWAY ZONE
-
-
-
-
- ipsec
- net
- 206.161.148.9
-
-
-
-
-
-
-
-
- ZONE
- DISPLAY
- COMMENTS
-
-
-
- vpn
- VPN
- Remote Subnet
-
-
-
-
-
-
-
-
- ZONE
-
- INTERFACE
-
- BROADCAST
-
- OPTIONS
-
-
-
-
- vpn
- ipsec0
-
-
-
-
-
-
-
-
-
- SOURCE
- DEST
- POLICY
- LOG LEVEL
-
-
-
- loc
- vpn
- ACCEPT
-
-
-
-
- vpn
- loc
- ACCEPT
-
-
- Mobile System (Road Warrior)
-
- 
-
-
-
-
-
-
-
- ZONE
- DISPLAY
- COMMENTS
-
-
-
- vpn
- VPN
- Remote Subnet
-
-
+
+
+
+
+
+
+
-
-
-
-
- TYPE
-
- ZONE
-
- GATEWAY
-
- GATEWAY ZONE
-
-
-
- ipsec
- net
- 0.0.0.0/0
- vpn
-
+
+
+
+
+
+
+
+
+
+ IPSEC Tunnels
+ Configuring FreeS/Wan
+ There is an excellent guide to configuring IPSEC tunnels at http://jixen.tripod.com . I highly recommend
+that you consult that site for information about confuring FreeS/Wan.
+ IPSec Gateway on the Firewall System
+
+
+
+
-
+
+
+
+
+ TYPE
+ ZONE
+ GATEWAY
+ GATEWAY ZONE
+
+
+
+
+ ipsec
+ net
+ 134.28.54.2
+
+
+
+
+
+
+
+
+
+ TYPE
+ ZONE
+ GATEWAY
+ GATEWAY ZONE
+
+
+
+
+ ipsec
+ net
+ 206.161.148.9
+
+
+
+
+
+
+
+
+
+
+ ZONE
+ DISPLAY
+ COMMENTS
+
+
+
+
+ vpn
+ VPN
+ Remote Subnet
+
+
+
+
+
+
+
+
+ ZONE
+ INTERFACE
+ BROADCAST
+ OPTIONS
+
+
+
+
+ vpn
+ ipsec0
+
+
+
+
+
+
+
+
+
+
+ SOURCE
+ DEST
+ POLICY
+ LOG LEVEL
+
+
+ loc
+ vpn
+ ACCEPT
+
+
+
+
+
+ vpn
+ loc
+ ACCEPT
+
+ Mobile System (Road
+Warrior)
+
+
+
+
+
+
+
+
+
+
+ ZONE
+ DISPLAY
+ COMMENTS
+
+
+
+
+ vpn
+ VPN
+ Remote Subnet
+
+
+
+
+
+
+
+
+ TYPE
+ ZONE
+ GATEWAY
+ GATEWAY ZONE
+
+
+
+
+ ipsec
+ net
+ 0.0.0.0/0
+ vpn
+
Dynamic RoadWarrior Zones
+ Beginning with Shorewall release 1.3.10, you can define multiple VPN zones
+and add and delete remote endpoints dynamically using /sbin/shorewall. In
+/etc/shorewall/zones:
+
+
+
+
+ In /etc/shorewall/tunnels:
+
+
+
+
+ ZONE
+
+ DISPLAY
+
+ COMMENTS
+
+
+
+ vpn1
+
+ VPN-1
+
+ First VPN Zone
+
+
+
+ vpn2
+
+ VPN-2
+
+ Second VPN Zone
+
+
+
+
+
+ vpn3
+
+ VPN-3
+
+ Third VPN Zone
+
+
+
+
+
+
+ When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall
+will issue warnings to that effect. These warnings may be safely ignored.
+FreeS/Wan may now be configured to have three different Road Warrior connections
+with the choice of connection being based on X-509 certificates or some other
+means. Each of these connectioins will utilize a different updown script that
+adds the remote station to the appropriate zone when the connection comes
+up and that deletes the remote station when the connection comes down. For
+example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of the
+script will issue the command":
+
+
+
+
+ TYPE
+
+ ZONE
+
+ GATEWAY
+
+ GATEWAY ZONE
+
+
+
+
+
+ ipsec
+
+ net
+
+ 0.0.0.0/0
+
+ vpn1,vpn2,vpn3
+
+
+
+
+
+/sbin/shorewall add ipsec0:134.28.54.2 vpn2
+ and the 'down' part will:
+
+
+/sbin/shorewall delete ipsec0:134.28.54.2 vpn
+
+
+
-
\ No newline at end of file
+
diff --git a/Shorewall-docs/Install.htm b/Shorewall-docs/Install.htm
index 4e68cef62..1b7565f5a 100644
--- a/Shorewall-docs/Install.htm
+++ b/Shorewall-docs/Install.htm
@@ -1,174 +1,207 @@
+
-
-
-
-
-
+
+
+
-
- Shorewall Installation and Upgrade
-
+
+
-
-
+
+
+
+
+ Shorewall Installation and
+Upgrade
+
-Install
-using tarball
-Upgrade using RPM
-Upgrade
-using tarball
-Configuring Shorewall
-Uninstall/Fallback
+ Upgrade using RPM
+ Upgrade using tarball
+ Configuring Shorewall
+ Uninstall/Fallback
+
-
-
-
- Note: Some SuSE users have encountered a problem whereby rpm reports a
- conflict with kernel <= 2.2 even though a 2.4 kernel is installed. If this
- happens, simply use the --nodeps option to rpm (rpm -ivh --nodeps <shorewall
- rpm>).
+
+ Note: Some SuSE users have encountered a problem whereby rpm reports
+a conflict with kernel <= 2.2 even though a 2.4 kernel is installed.
+If this happens, simply use the --nodeps option to rpm (rpm -ivh --nodeps
+<shorewall rpm>).
-
-
-
-
-
+
-
- Configuring Shorewall
-Configuring Shorewall
+
+
-
-
+
+
+
+
diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm
index 9ed1b7b06..6016710da 100644
--- a/Shorewall-docs/News.htm
+++ b/Shorewall-docs/News.htm
@@ -1,1337 +1,1458 @@
-
+
-
-
-
-
-
+
-
+
+
-
-
+
+
+
+
+
- Shorewall News Archive
-
-
-
-
-
-
- 
- A couple of recent configuration changes at www.shorewall.net broke
- the Search facility:
-
-
-
- Hopefully these problems are now corrected.
-
-
-
-
+
+
-
-
- Hopefully these problems are now corrected.
-
-
-
+
+
+
+ You may download the Beta from:
+
+
+
+
+
+
+
+
+ The firewall and server here at shorewall.net are now running RedHat
+release 8.0.
+
+ 9/30/2002 - Shorewall 1.3.9a
+
+
-
-
-
+
+
+
+
+ A couple of recent configuration changes at www.shorewall.net
+ broke the Search facility:
+
+
+
+ Hopefully these problems are now corrected.
+
+
+
+
+
+
+
+ Hopefully these problems are now corrected.
+
+
+
+
+
+
+
-
-
+
+
+
-
+
-
-
-
-
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
-
-
-
-
+
-
-
+
-
-
+
+ to use the "--oldpackage" option when upgrading to 1.2.0:
+
+
+
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
- 1. Create a New Directory
- 2. Copy to that directory any of your configuration files that
- you want to change.
- 3. Modify the copied files as needed.
- 4. Restart Shorewall specifying the new directory.
+ 1. Create a New Directory
+ 2. Copy to that directory any of your configuration files
+ that you want to change.
+ 3. Modify the copied files as needed.
+ 4. Restart Shorewall specifying the new directory.
-
-
+
-
- Example:
- sea eth0:130.252.100.0/24,206.191.149.0/24
+
+ Example:
+ sea eth0:130.252.100.0/24,206.191.149.0/24
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
+
-
-
-
+
-
-
+
-
-
+
-
-
+
+
+
+
+
+
diff --git a/Shorewall-docs/PPTP.htm b/Shorewall-docs/PPTP.htm
index b8a61e6c4..21aa4560b 100644
--- a/Shorewall-docs/PPTP.htm
+++ b/Shorewall-docs/PPTP.htm
@@ -1,575 +1,411 @@
+
-
-
-
-
-
-
-
-
+
+
+
-
- PPTP
-
+
+
-
+
+
+
+
+
+ PPTP
+
-
+
1. PPTP Server Running on your Firewall
-
-
+
Patching and Building pppd
+
-
-
-
+
-
-Patching and Building your Kernel
+
-
+
-
+
-
+
+
+
+
+ Configuring Samba
-
-
+
+[global]
- workgroup = TDM-NSTOP
- netbios name = WOOKIE
- server string = GNU/Linux Box
- encrypt passwords = Yes
- log file = /var/log/samba/%m.log
- max log size = 0
- socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
- os level = 65
- domain master = True
- preferred master = True
- dns proxy = No
- wins support = Yes
- printing = lprng
-
-[homes]
- comment = Home Directories
- valid users = %S
- read only = No
- create mask = 0664
- directory mask = 0775
-
-[printers]
- comment = All Printers
- path = /var/spool/samba
- printable = Yes
-
+
+
[global]
+
workgroup = TDM-NSTOP
netbios name = WOOKIE
server string = GNU/Linux Box
encrypt passwords = Yes
log file = /var/log/samba/%m.log
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
os level = 65
domain master = True
preferred master = True
dns proxy = No
wins support = Yes
printing = lprng
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0664
directory mask = 0775
[printers]
comment = All Printers
path = /var/spool/samba
printable = YesConfiguring pppd
+
+
+
+
+ lock
- lock
- mtu 1490
- mru 1490
- ms-wins 192.168.1.3
- ms-dns 206.124.146.177
- multilink
- proxyarp
- auth
- +chap
- +chapms
- +chapms-v2
- ipcp-accept-local
- ipcp-accept-remote
- lcp-echo-failure 30
- lcp-echo-interval 5
- deflate 0
- mppe-128
- mppe-stateless
- require-mppe
- require-mppe-stateless
+ mtu 1490
+ mru 1490
+ ms-wins 192.168.1.3
+ ms-dns 206.124.146.177
+ multilink
+ proxyarp
+ auth
+ +chap
+ +chapms
+ +chapms-v2
+ ipcp-accept-local
+ ipcp-accept-remote
+ lcp-echo-failure 30
+ lcp-echo-interval 5
+ deflate 0
+ mppe-128
+ mppe-stateless
+ require-mppe
+ require-mppe-stateless
+
-
+
+
+
+
+
-
- # client server secret
- IP addresses
- CPQTDM\\TEastep * <shhhhhh>
- 192.168.1.7
- TEastep *
- <shhhhhh> 192.168.1.7
+ CPQTDM\\TEastep * <shhhhhh> 192.168.1.7
+ TEastep * <shhhhhh> 192.168.1.7
+ alias ppp-compress-18 ppp_mppe
- alias ppp-compress-21 bsd_comp
- alias ppp-compress-24 ppp_deflate
- alias ppp-compress-26 ppp_deflate
+
+ alias ppp-compress-18 ppp_mppe
+
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflateConfiguring pptpd
+
+
+
+
+ speed 115200
- speed 115200
- localip 192.168.1.254
- remoteip 192.168.1.33-38
+ localip 192.168.1.254
+ remoteip 192.168.1.33-38
+
-
+
+
+
+
+ #
- #
- # /etc/rc.d/init.d/pptpd
- #
- # chkconfig: 5 12 85
- # description: control pptp server
- #
-
- case "$1" in
- start)
- echo 1 > /proc/sys/net/ipv4/ip_forward
- modprobe ppp_async
- modprobe ppp_generic
- modprobe ppp_mppe
- modprobe slhc
- if /usr/local/sbin/pptpd; then
- touch /var/lock/subsys/pptpd
- fi
- ;;
- stop)
- killall pptpd
- rm -f /var/lock/subsys/pptpd
- ;;
- restart)
- killall pptpd
- if /usr/local/sbin/pptpd; then
- touch /var/lock/subsys/pptpd
- fi
- ;;
- status)
- ifconfig
- ;;
- *)
- echo "Usage: $0 {start|stop|restart|status}"
- ;;
- esac
+ # /etc/rc.d/init.d/pptpd
+ #
+ # chkconfig: 5 12 85
+ # description: control pptp server
+ #
+
+ case "$1" in
+ start)
+ echo 1 > /proc/sys/net/ipv4/ip_forward
+ modprobe ppp_async
+ modprobe ppp_generic
+ modprobe ppp_mppe
+ modprobe slhc
+ if /usr/local/sbin/pptpd; then
+ touch /var/lock/subsys/pptpd
+ fi
+ ;;
+ stop)
+ killall pptpd
+ rm -f /var/lock/subsys/pptpd
+ ;;
+ restart)
+ killall pptpd
+ if /usr/local/sbin/pptpd; then
+ touch /var/lock/subsys/pptpd
+ fi
+ ;;
+ status)
+ ifconfig
+ ;;
+ *)
+ echo "Usage: $0 {start|stop|restart|status}"
+ ;;
+ esac
+ Configuring Shorewall
+
/etc/shorewall/zones:
-
-
-
-
- ZONE
- DISPLAY
- COMMENTS
-
-
- net
- Internet
- The Internet
-
-
+
+loc
- Local
- My Local Network including remote PPTP clients
-
+
+
+
+
+
-
+
+ ZONE
+ DISPLAY
+ COMMENTS
+
+
+ net
+ Internet
+ The Internet
+
+
+
+
loc
+ Local
+ My Local Network including remote PPTP clients
+ /etc/shorewall/interfaces:
-
-
-
-
- ZONE
- INTERFACE
- BROADCAST
- OPTIONS
-
-
- net
- eth0
- 206.124.146.255
- noping,norfc1918
-
-
- loc
- eth2
- 192.168.1.255
-
-
-
+
+-
- ppp+
-
-
-
+
+
+
+
+
-
+
+ ZONE
+ INTERFACE
+ BROADCAST
+ OPTIONS
+
+
+ net
+ eth0
+ 206.124.146.255
+ noping,norfc1918
+
+
+ loc
+ eth2
+ 192.168.1.255
+
+
+
+
+
-
+ ppp+
+
+
+ /etc/shorewall/hosts:
-
-
-
-
- ZONE
- HOST(S)
- OPTIONS
-
-
- loc
- eth2:192.168.1.0/24
- routestopped
-
-
+
+loc
- ppp+:192.168.1.0/24
-
-
+
+
+
+
+
-
+
+ ZONE
+ HOST(S)
+ OPTIONS
+
+
+ loc
+ eth2:192.168.1.0/24
+ routestopped
+
+
+
+
loc
+ ppp+:192.168.1.0/24
+
+ /etc/shorewall/policy:
-
-
-
-
- SOURCE
- DEST
- POLICY
- LOG LEVEL
-
-
+
+loc
- loc
- ACCEPT
-
-
+
-
+
+
-
+
+ SOURCE
+ DEST
+ POLICY
+ LOG LEVEL
+
+
+
+
loc
+ loc
+ ACCEPT
+
+ /etc/shorewall/rules:
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DEST
-
- PROTO
- DEST
-
- PORT(S)SOURCE
-
- PORT(S)ORIGINAL
-
-
- DEST
-
- ACCEPT
- net
- fw
- tcp
- 1723
-
-
-
-
- ACCEPT
- net
- fw
- 47
- -
-
-
-
-
-ACCEPT
- fw
- net
- 47
- -
-
-
- /etc/shorewall/interfaces:
-
-
-
-
+
+
+ZONE
- INTERFACE
- BROADCAST
- OPTIONS
- /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b):
+
+
+
+
-
+
+
-
+
ACTION
+ SOURCE
+ DEST
+ PROTO
+ DEST
+
+ PORT(S)SOURCE
+
+ PORT(S)ORIGINAL
+
+ DEST
+
- ACCEPT
net
- eth0
- 206.124.146.255
- noping,norfc1918
-
-
- loc
- eth2
- 192.168.1.255
-
-
-
- loc
- ppp0
-
-
- 2. PPTP Server Running Behind your Firewall
-
-
-
-
-
- ACTION
- SOURCE
- DEST
-
- PROTO
- DEST
-
- PORT(S)SOURCE
-
- PORT(S)ORIGINAL
-
-
- DEST
-
- DNAT
- net
- loc:<server address>
- tcp
- 1723
-
-
-
-
-DNAT
- net
- loc:<server address>
- 47
- -
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DEST
-
- PROTO
- DEST
-
- PORT(S)SOURCE
-
- PORT(S)ORIGINAL
-
-
- DEST
-
- DNAT
- net
- loc:<server address>
- tcp
- 1723
- -
- <external address>
-
-
-DNAT
- net
- loc:<server address>
- 47
- -
- -
- <external address>
- 3. PPTP Clients Running Behind your Firewall
-
-
-
- loadmodule ip_nat_pptp
-4. PPTP Client Running on your Firewall.
-
-
-/etc/shorewall/zones
-
-
-
-
-
-
- ZONE
- DISPLAY
- COMMENTS
-
-
- cpq
- Compaq
- Compaq Intranet
- /etc/shorewall/interfaces
-
-
-
-
-
-
- ZONE
- INTERFACE
- BROADCAST
- OPTIONS
-
-
- -
- ppp+
-
-
- /etc/shorewall/hosts
-
-
-
-
-
-
- ZONE
- HOST(S)
- OPTIONS
-
-
- -
- ppp+:!192.168.1.0/24
-
- /etc/shorewall/rules
-
-
+
+
-
+
-
-
- ACTION
- SOURCE
- DEST
-
- PROTO
- DEST
-
- PORT(S)SOURCE
-
- PORT(S)ORIGINAL
-
-
- DEST
-
+ ACCEPT
fw
- net
tcp
1723
-
-
+
+
+
+
ACCEPT
+ net
+ fw
+ 47
+ -
+
+
+
+
+ ACCEPT
@@ -577,160 +413,487 @@ below).
net
47
-
-
-
+
+
+
+
-
+
+
+
+ TYPE
+
+ ZONE
+
+ GATEWAY
+
+ GATEWAY ZONE
+
+
+
+
pptpserver
+
+ net
+
+ 0.0.0.0/0
+
+
+
+Note: I have multiple ppp interfaces on my firewall. If you have a single
+ppp interface, you probably want:/etc/shorewall/interfaces:
+
+
+
+
+
+
+
+
+
+ ZONE
+ INTERFACE
+ BROADCAST
+ OPTIONS
+
+
+ net
+ eth0
+ 206.124.146.255
+ noping,norfc1918
+
+
+ loc
+ eth2
+ 192.168.1.255
+
+
+
+
+
+ loc
+ ppp0
+
+
+ 2. PPTP Server Running Behind
+your Firewall
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DEST
+ PROTO
+ DEST
+
+ PORT(S)SOURCE
+
+ PORT(S)ORIGINAL
+
+ DEST
+
+ DNAT
+ net
+ loc:<server address>
+ tcp
+ 1723
+
+
+
+
+
+
+DNAT
+ net
+ loc:<server address>
+ 47
+ -
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DEST
+ PROTO
+ DEST
+
+ PORT(S)SOURCE
+
+ PORT(S)ORIGINAL
+
+ DEST
+
+ DNAT
+ net
+ loc:<server address>
+ tcp
+ 1723
+ -
+ <external address>
+
+
+
+
+DNAT
+ net
+ loc:<server address>
+ 47
+ -
+ -
+ <external address>
+ 3. PPTP Clients Running Behind
+your Firewall
+
+
+
+
+
+ loadmodule ip_nat_pptp 4. PPTP Client Running on your Firewall.
+
+
+
+
+/etc/shorewall/zones
+
+
+
+
+
+
+
+
+
+ ZONE
+ DISPLAY
+ COMMENTS
+
+
+
+
+ cpq
+ Compaq
+ Compaq Intranet
+ /etc/shorewall/interfaces
+
+
+
+
+
+
+
+
+
+ ZONE
+ INTERFACE
+ BROADCAST
+ OPTIONS
+
+
+
+
+ -
+ ppp+
+
+
+ /etc/shorewall/hosts
+
+
+
+
+
+
+
+
+
+ ZONE
+ HOST(S)
+ OPTIONS
+
+
+
+
+ -
+ ppp+:!192.168.1.0/24
+
+ /etc/shorewall/rules (For Shorewall versions up to and including 1.3.9b)
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DEST
+ PROTO
+ DEST
+
+ PORT(S)SOURCE
+
+ PORT(S)ORIGINAL
+
+ DEST
+
+ ACCEPT
+ fw
+ net
+ tcp
+ 1723
+
+
+
+
+
+
+ ACCEPT
+ fw
+ net
+ 47
+ -
+
+
+
+
-
-
-#
-# /etc/rc.d/init.d/pptp
-#
-# chkconfig: 5 60 85
-# description: PPTP Link Control
-#
-NAME="Tandem"
-ADDRESS=tunnel-tandem.compaq.com
-USER='Tandem\tommy'
-ECN=0
-DEBUG=
-
-start_pptp() {
- echo $ECN > /proc/sys/net/ipv4/tcp_ecn
- if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then
- touch /var/lock/subsys/pptp
- echo "PPTP Connection to $NAME Started"
- fi
-}
-
-stop_pptp() {
- if killall /usr/sbin/pptp 2> /dev/null; then
- echo "Stopped pptp"
- else
- rm -f /var/run/pptp/*
- fi
-
- # if killall pppd; then
- # echo "Stopped pppd"
- # fi
-
- rm -f /var/lock/subsys/pptp
-
- echo 1 > /proc/sys/net/ipv4/tcp_ecn
-}
-
-
-case "$1" in
- start)
- echo "Starting PPTP Connection to ${NAME}..."
- start_pptp
- ;;
- stop)
- echo "Stopping $NAME PPTP Connection..."
- stop_pptp
- ;;
- restart)
- echo "Restarting $NAME PPTP Connection..."
- stop_pptp
- start_pptp
- ;;
- status)
- ifconfig
- ;;
- *)
- echo "Usage: $0 {start|stop|restart|status}"
- ;;
-esac
-
-
-
-
-# Identify this connection
-#
-ipparam Compaq
-#
-# Lock the port
-#
-lock
-#
-# We don't need the tunnel server to authenticate itself
-#
-noauth
-
-+chap
-+chapms
-+chapms-v2
-
-multilink
-mrru 1614
-#
-# Turn off transmission protocols we know won't be used
-#
-nobsdcomp
-nodeflate
-
-#
-# We want MPPE
-#
-mppe-128
-mppe-stateless
-
-#
-# We want a sane mtu/mru
-#
-mtu 1000
-mru 1000
-
-#
-# Time this thing out of it goes poof
-#
-lcp-echo-failure 10
-lcp-echo-interval 10
-
-
-
+
+
+
+
+ TYPE
+
+ ZONE
+
+ GATEWAY
+
+ GATEWAY ZONE
+
+
+
+
+ pptpclient
+
+ net
+
+ 0.0.0.0/0
+
+
+
- case $6 in
- Compaq)
- route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1
- route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1
- route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1
- ...
- ;;
- esac #!/bin/sh
- restart_pptp() {
- /sbin/service pptp stop
- sleep 10
- if /sbin/service pptp start; then
- /usr/bin/logger "PPTP Restarted"
- fi
- }
-
- if [ -n "`ps ax | grep /usr/sbin/pptp | grep -v grep`" ]; then
- exit 0
- fi
-
- echo "Attempting to restart PPTP"
-
- restart_pptp > /dev/null 2>&1 &
-
-
+
+
+
+ #
+ # /etc/rc.d/init.d/pptp
+ #
+ # chkconfig: 5 60 85
+ # description: PPTP Link Control
+ #
+ NAME="Tandem"
+ ADDRESS=tunnel-tandem.compaq.com
+ USER='Tandem\tommy'
+ ECN=0
+ DEBUG=
+
+ start_pptp() {
+ echo $ECN > /proc/sys/net/ipv4/tcp_ecn
+ if /usr/sbin/pptp $ADDRESS user $USER noauth $DEBUG; then
+ touch /var/lock/subsys/pptp
+ echo "PPTP Connection to $NAME Started"
+ fi
+ }
+
+ stop_pptp() {
+ if killall /usr/sbin/pptp 2> /dev/null; then
+ echo "Stopped pptp"
+ else
+ rm -f /var/run/pptp/*
+ fi
+
+ # if killall pppd; then
+ # echo "Stopped pppd"
+ # fi
+
+ rm -f /var/lock/subsys/pptp
+
+ echo 1 > /proc/sys/net/ipv4/tcp_ecn
+ }
+
+
+ case "$1" in
+ start)
+ echo "Starting PPTP Connection to ${NAME}..."
+ start_pptp
+ ;;
+ stop)
+ echo "Stopping $NAME PPTP Connection..."
+ stop_pptp
+ ;;
+ restart)
+ echo "Restarting $NAME PPTP Connection..."
+ stop_pptp
+ start_pptp
+ ;;
+ status)
+ ifconfig
+ ;;
+ *)
+ echo "Usage: $0 {start|stop|restart|status}"
+ ;;
+ esac
+
+
+
+
+ # Identify this connection
+ #
+ ipparam Compaq
+ #
+ # Lock the port
+ #
+ lock
+ #
+ # We don't need the tunnel server to authenticate itself
+ #
+ noauth
+
+ +chap
+ +chapms
+ +chapms-v2
+
+ multilink
+ mrru 1614
+ #
+ # Turn off transmission protocols we know won't be used
+ #
+ nobsdcomp
+ nodeflate
+
+ #
+ # We want MPPE
+ #
+ mppe-128
+ mppe-stateless
+
+ #
+ # We want a sane mtu/mru
+ #
+ mtu 1000
+ mru 1000
+
+ #
+ # Time this thing out of it goes poof
+ #
+ lcp-echo-failure 10
+ lcp-echo-interval 10
+
+
+
+
+ case $6 in
+ Compaq)
+ route add -net 16.0.0.0 netmask 255.0.0.0 gw $5 $1
+ route add -net 130.252.0.0 netmask 255.255.0.0 gw $5 $1
+ route add -net 131.124.0.0 netmask 255.255.0.0 gw $5 $1
+ ...
+ ;;
+ esac #!/bin/sh
+
+
restart_pptp() {
/sbin/service pptp stop
sleep 10
if /sbin/service pptp start; then
/usr/bin/logger "PPTP Restarted"
fi
}
if [ -n "`ps ax | grep /usr/sbin/pptp | grep -v grep`" ]; then
exit 0
fi
echo "Attempting to restart PPTP"
restart_pptp > /dev/null 2>&1 &
+
+
+
diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm
index cf94ecb99..42a295f8d 100644
--- a/Shorewall-docs/Shorewall_index_frame.htm
+++ b/Shorewall-docs/Shorewall_index_frame.htm
@@ -1,106 +1,121 @@
-
+
-
+
-
+
-
+
-
-
-
-
-
+
+
+
-
+
-
+
+
+
-
+
- Shorewall
-
-
+
-
+
+
+
+
+
+
-
-
-
-
- Configuration
+
+ Configuration
+
+
+
-
-
-
-
+
+
+
+
+
-
-
-
-
+
+
-
\ No newline at end of file
+
diff --git a/Shorewall-docs/blacklisting_support.htm b/Shorewall-docs/blacklisting_support.htm
index 678186546..8999e2eb9 100644
--- a/Shorewall-docs/blacklisting_support.htm
+++ b/Shorewall-docs/blacklisting_support.htm
@@ -1,95 +1,95 @@
-
+
-
+
-
+
-
+
-
-
-
+
-
+
+
+
-
-
+
+
+
+
- Blacklisting Support
- Static Blacklisting
-
-
-
-
+
- Dynamic Blacklisting
-
-
-
-
+
shorewall deny 192.0.2.124 192.0.2.125
-
+
+ shorewall drop 192.0.2.124 192.0.2.125
+
shorewall allow 192.0.2.125
-
+
+
+
diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm
index b7b76e842..c8657434e 100644
--- a/Shorewall-docs/configuration_file_basics.htm
+++ b/Shorewall-docs/configuration_file_basics.htm
@@ -1,300 +1,319 @@
-
+
-
+
-
+
-
+
-
-
-
-
-
+
+
+
-
-
+
+
+
+
- Configuration Files
- Files
-
-
-
-
-Comments
-
-# This is a comment
-
-ACCEPT net fw tcp www #This is an end-of-line comment
-
-Line Continuation
-
-ACCEPT net fw tcp \
-
-
smtp,www,pop3,imap #Services running on the firewallUsing DNS Names
-
-
-
-
-
- DNS names in iptables rules aren't nearly as useful as they first appear.
-When a DNS name appears in a rule, the iptables utility resolves the name
-to one or more IP addresses and inserts those addresses into the rule. So
-change in the DNS->IP address relationship that occur after the firewall
-has started have absolutely no effect on the firewall's ruleset.
-
-
-
-
-
-
- Examples of valid DNS names:
-
-
- Examples of invalid DNS names:
-
-
-
- DNS names may not be used as:
-
-
-
- These are iptables restrictions and are not simply imposed for your inconvenience
-by Shorewall.
-
-
-Complementing an Address or Subnet
-
-Comma-separated Lists
-
-
-
-
-
- Valid: routestopped,dhcp,norfc1918
- Invalid: routestopped, dhcp, norfc1818Port Numbers/Service Names
-
-Port Ranges
-
-Using Shell Variables
-
-
-
-
-NET_IF=eth0
-
NET_BCAST=130.252.100.255
NET_OPTIONS=noping,norfc1918
- Example (/etc/shorewall/interfaces record):
-
-
+
+net $NET_IF $NET_BCAST $NET_OPTIONS
-
-
-
-
-net eth0 130.252.100.255 noping,norfc1918
- Files
+
+
+
+
+Comments
+
+# This is a comment
+
+ACCEPT net fw tcp www #This is an end-of-line comment
+
+Line Continuation
+
+ACCEPT net fw tcp \
+
+
smtp,www,pop3,imap #Services running on the firewallUsing DNS Names
+
+
+
+
+
+ DNS names in iptables rules aren't nearly as useful as they first appear.
+ When a DNS name appears in a rule, the iptables utility resolves the name
+ to one or more IP addresses and inserts those addresses into the rule.
+So change in the DNS->IP address relationship that occur after the firewall
+ has started have absolutely no effect on the firewall's ruleset.
+
+
+
+
+
+
+ Examples of valid DNS names:
+
+
+ Examples of invalid DNS names:
+
+
+
+ DNS names may not be used as:
+
+
+
+ These are iptables restrictions and are not simply imposed for your
+inconvenience by Shorewall.
+
+
+Complementing an Address or Subnet
+
+Comma-separated Lists
+
+
+
+
+
+ Valid: routestopped,dhcp,norfc1918
+ Invalid: routestopped, dhcp, norfc1818Port Numbers/Service Names
+
+Port Ranges
+
+
+ DNAT net loc:192.168.1.3 tcp 4000:4100
+
+Using Shell Variables
+
+
+
+NET_IF=eth0
+
NET_BCAST=130.252.100.255
NET_OPTIONS=noping,norfc1918
+ Example (/etc/shorewall/interfaces record):
+
+
+
+net $NET_IF $NET_BCAST $NET_OPTIONS
+
+
+
+
+net eth0 130.252.100.255 noping,norfc1918
+ Using MAC Addresses
-
-
-
- In GNU/Linux, MAC addresses are usually written as a series of 6
-hex numbers separated by colons. Example:
-
- [root@gateway root]# ifconfig eth0
- eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
- inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
- UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
- RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
- TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
- collisions:30394 txqueuelen:100
- RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8 Mb)
- Interrupt:11 Base address:0x1800
-
- Because Shorewall uses colons as a separator for address fields,
-Shorewall requires MAC addresses to be written in another way. In
-Shorewall, MAC addresses begin with a tilde ("~") and consist of 6
-hex numbers separated by hyphens. In Shorewall, the MAC address in
-the example above would be written "~02-00-08-E3-FA-55".
+
+ In GNU/Linux, MAC addresses are usually written as a series of
+6 hex numbers separated by colons. Example:
+
+ [root@gateway root]# ifconfig eth0
+ eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
+ inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
+ UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
+ RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
+ TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
+ collisions:30394 txqueuelen:100
+ RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8
+ Mb)
+ Interrupt:11 Base address:0x1800
+
+ Because Shorewall uses colons as a separator for address fields,
+ Shorewall requires MAC addresses to be written in another way. In
+Shorewall, MAC addresses begin with a tilde ("~") and consist of 6
+hex numbers separated by hyphens. In Shorewall, the MAC address in
+the example above would be written "~02-00-08-E3-FA-55".
+
+Shorewall Configurations
-
-
-
-
-
+
+
+
+
diff --git a/Shorewall-docs/dhcp.htm b/Shorewall-docs/dhcp.htm
index c66b6fe65..d736f42eb 100644
--- a/Shorewall-docs/dhcp.htm
+++ b/Shorewall-docs/dhcp.htm
@@ -1,60 +1,82 @@
+
-
-
-
-
-
-
-
-
+
+
+
-
- DHCP
-
+
+
-
+
+
+
+
+ DHCP
+ DHCP Server on your firewall
+
+If you want to Run a DHCP Server on your firewall
+
-
-A Firewall Interface gets its IP Address via DHCP
+
+If a Firewall Interface gets its IP Address via DHCP
+
-
-
-
-
\ No newline at end of file
+
diff --git a/Shorewall-docs/download.htm b/Shorewall-docs/download.htm
index fef0d6fd6..e9405790c 100644
--- a/Shorewall-docs/download.htm
+++ b/Shorewall-docs/download.htm
@@ -1,304 +1,311 @@
-
+
-
+
-
+
-
+
-
-
-
+
-
+
+
+
-
-
+
+
+
+
- Shorewall Download
-
-
-
-
-
-
+
+
+
+
+
-
+
-
-
-
-
- SERVER LOCATION
- DOMAIN
- HTTP
- FTP
-
-
- Washington State, USA
- Shorewall.net
- Browse
- Browse
-
-
- Slovak Republic
- Shorewall.net
- Browse
- Browse
-
-
- Texas, USA
- Infohiiway.com
- Browse
- Browse
-
-
- Hamburg, Germany
- Shorewall.net
- Browse
- Browse
-
-
- Martinez (Zona Norte - GBA), Argentina
- Correofuego.com.ar
- Browse
- Browse
-
-
- France
- Shorewall.net
- Browse
- Browse
-
-
-
+California, USA (Incomplete)
- Sourceforge.net
- Browse
- N/A
-
+
-
+
+
+
+
-
+
+ SERVER LOCATION
+ DOMAIN
+ HTTP
+ FTP
+
+
+ Washington State, USA
+ Shorewall.net
+ Browse
+ Browse
+
+
+ Slovak Republic
+ Shorewall.net
+ Browse
+ Browse
+
+
+ Texas, USA
+ Infohiiway.com
+ Browse
+ Browse
+
+
+ Hamburg, Germany
+ Shorewall.net
+ Browse
+ Browse
+
+
+ Martinez (Zona Norte - GBA), Argentina
+ Correofuego.com.ar
+ Browse
+ Browse
+
+
+ France
+ Shorewall.net
+ Browse
+ Browse
+
+
+
+
California, USA (Incomplete)
+ Sourceforge.net
+ Browse
+ N/A
+
+
+
+
+
-
-
+
+
diff --git a/Shorewall-docs/errata.htm b/Shorewall-docs/errata.htm
index 2f20a4a90..5331d3557 100644
--- a/Shorewall-docs/errata.htm
+++ b/Shorewall-docs/errata.htm
@@ -1,109 +1,152 @@
-
+
-
-
-
+
-
+
+
+
-
-
+
+
+
+
+
- Shorewall Errata/Upgrade Issues
-
-
-
+
+
-
-
-
+
+
+
Problems in Version 1.3
-
-Version 1.3.8
-
+
+Version 1.3.9a
-
- Installing recalculate_interfacess: command not found
-
+ The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
+corrects this problem.Copy the script to /usr/lib/shorewall/firewall as described
+above.
+
+ Alternatively, edit /usr/lob/shorewall/firewall and change the
+single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess'
+to 'recalculate_interface'.
+
+
+
+
+
+ Version 1.3.9
+ TUNNELS Broken in 1.3.9!!! There is an updated firewall script
+at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
+-- copy that file to /usr/lib/shorewall/firewall as described above.
+
+ Version 1.3.8
+
+
+ Installing
this corrected firewall script in /var/lib/shorewall/firewall
- as described above corrects these problems.
-
+ as described above corrects these problems.
+
+ Version 1.3.7b
-
+
Version 1.3.7a
-
+
Version <= 1.3.7a
-
+
-
-
+
Version 1.3.7
-
+
d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
-
+
6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrpVersion 1.3.6
-
+
-
-
+
Two-interface Samples 1.3.6 (file two-interfaces.tgz)
-
+
Version 1.3.5-1.3.5b
-
+
Versions 1.3.4-1.3.5a
-
+
+
+
+
-
- adm eth0:1.2.4.5,eth0:5.6.7.8
-
+
+
+
-
-
+ modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall
+ as instructed above.
+
+
+
-
+ Version 1.3.5
-
+
Version 1.3.n, n < 4
-
+
Version 1.3.n, n < 3
-
+
Version 1.3.2
-
+
-
-
+
-
-
+
Version 1.3.1
-
+
-
-
+
-
- net eth0 dhcp
- loc eth1 dhcp
-
- Shorewall will ignore the 'dhcp' on eth1.
-
- Users who downloaded the corrected script prior to 1850 GMT
- today should download and install the corrected script again
- to ensure that this second problem is corrected.
+
+ net eth0 dhcp
+ loc eth1 dhcp
+
+ Shorewall will ignore the 'dhcp' on eth1.
+
+ Users who downloaded the corrected script prior to 1850
+ GMT today should download and install the corrected script
+ again to ensure that this second problem is corrected.Version 1.3.0
-
+
-
-
-
+
+
Upgrade Issues
-
+
+
+
Problem with
- iptables version 1.2.3
-
-
+ iptables version 1.2.3
+
+
+
+ corrects a problem in handling the TOS target.
+
-
-
+
+ Problems with kernels >= 2.4.18
and RedHat iptables
-
-
+
+
+
+
-
+ this iptables RPM. If you are already running a 1.2.5 version of
+ iptables, you will need to specify the --oldpackage option to rpm (e.g.,
+ "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").
+
+ may experience the following:
+
+
+
-
+ # shorewall start
-
Processing /etc/shorewall/shorewall.conf ...
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
Aborted (core dumped)Problems installing/upgrading
- RPM on SuSE
-
+ RPM on SuSE
+
Problems with
iptables version 1.2.7 and MULTIPORT=Yes
-
+
-
-
-Problems with RH Kernel 2.4.18-10 and NAT
+ /etc/shorewall/nat entries of the following form will result in Shorewall
+ being unable to start:
+
+
+
+#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
+ Error message is:
192.0.2.22 eth0 192.168.9.22 yes yes
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+Setting up NAT...
+ The solution is to put "no" in the LOCAL column. Kernel support for LOCAL=yes
+ has never worked properly and 2.4.18-10 has disabled it. The 2.4.19 kernel
+ contains corrected support under a new kernel configuraiton option; see
+http://www.shorewall.net/Documentation.htm#NAT
iptables: Invalid argument
Terminated
+
+
+
+
+
diff --git a/Shorewall-docs/images/DMZ.jpg b/Shorewall-docs/images/DMZ.jpg
deleted file mode 100644
index 30704b5b7..000000000
Binary files a/Shorewall-docs/images/DMZ.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/DMZ2.jpg b/Shorewall-docs/images/DMZ2.jpg
deleted file mode 100644
index be96e6565..000000000
Binary files a/Shorewall-docs/images/DMZ2.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/DMZ3.jpg b/Shorewall-docs/images/DMZ3.jpg
deleted file mode 100644
index 06a9fc3dc..000000000
Binary files a/Shorewall-docs/images/DMZ3.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/Thumbs.db b/Shorewall-docs/images/Thumbs.db
index 128d0b393..b97a45e40 100644
Binary files a/Shorewall-docs/images/Thumbs.db and b/Shorewall-docs/images/Thumbs.db differ
diff --git a/Shorewall-docs/images/basics.jpg b/Shorewall-docs/images/basics.jpg
deleted file mode 100644
index 4b457f92f..000000000
Binary files a/Shorewall-docs/images/basics.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/basics1.jpg b/Shorewall-docs/images/basics1.jpg
deleted file mode 100644
index 3af2a7c83..000000000
Binary files a/Shorewall-docs/images/basics1.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/network.jpg b/Shorewall-docs/images/network.jpg
deleted file mode 100644
index f928049ac..000000000
Binary files a/Shorewall-docs/images/network.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/proxyarp.jpg b/Shorewall-docs/images/proxyarp.jpg
deleted file mode 100644
index 6c638fca8..000000000
Binary files a/Shorewall-docs/images/proxyarp.jpg and /dev/null differ
diff --git a/Shorewall-docs/images/proxyarp.png b/Shorewall-docs/images/proxyarp.png
index 88b0f1b42..495b7fd79 100644
Binary files a/Shorewall-docs/images/proxyarp.png and b/Shorewall-docs/images/proxyarp.png differ
diff --git a/Shorewall-docs/images/proxyarp.vsd b/Shorewall-docs/images/proxyarp.vsd
index b2fbfbe93..ae0ec4bc0 100644
Binary files a/Shorewall-docs/images/proxyarp.vsd and b/Shorewall-docs/images/proxyarp.vsd differ
diff --git a/Shorewall-docs/images/staticnat.jpg b/Shorewall-docs/images/staticnat.jpg
deleted file mode 100644
index aa50608ed..000000000
Binary files a/Shorewall-docs/images/staticnat.jpg and /dev/null differ
diff --git a/Shorewall-docs/mailing_list_problems.htm b/Shorewall-docs/mailing_list_problems.htm
index 7c7f80ba7..612ae8c83 100644
--- a/Shorewall-docs/mailing_list_problems.htm
+++ b/Shorewall-docs/mailing_list_problems.htm
@@ -1,59 +1,53 @@
+
-
-
-
-
-
-
-
+
+
-
+
+
+
-
- Mailing List Problems
-
+
+
-
+
+
+
+
+
+ Mailing List Problems
+ Shorewall.net is currently experiencing mail delivery problems
-to at least one address in each of the following domains:
-
-
-
-
-
-
-2020ca - delivery to this domain has been disabled (cause unknown)
-excite.com - delivery to this domain has been disabled (cause unknown)
-epacificglobal.com - delivery to this domain has been disabled (no MX record for domain)
-familie-fleischhacker.de - (connection timed out)
-gmx.net - delivery to this domain has been disabled (cause unknown)
-hotmail.com - delivery to this domain has been disabled (Mailbox over quota)
-intercom.net - delivery to this domain has been disabled (cause unknown)
-initialcs.com - delivery to this domain has been disabled (cause unknown)
-intelligents.2y.net - delivery to this domain has been disabled (Name Service Problem -- Host not Found).
-khp-inc.com - delivery to this domain has been disabled (anti-virus problems)
-kieninger.de - delivery to this domain has been disabled (relaying to <xxxxx@kieninger.de> prohibited by administrator)
-littleblue.de - (connection timed out)
-opermail.net - delivery to this domain has been disabled (cause unknown)
-penquindevelopment.com - delivery to this domain has been disabled (connection timed out)
-scip-online.de - delivery to this domain has been disabled (cause unknown)
-spctnet.com - connection timed out - delivery to this domain has been disabled
-telusplanet.net - delivery to this domain has been disabled (cause unknown)
-yahoo.com - delivery to this domain has been disabled (Mailbox over quota)
-
+
+
+
+
+ 2020ca - delivery to this domain has been disabled (cause unknown)
+
arundel.homelinux.org - delivery to this domain has been disabled (connection timed out, connection refused)
asurfer.com - (Mailbox full)
cuscominc.com - delivery to this domain has been disable (bouncing mail from all sources with "Mail rejected because the server you are sending to is misconfigured").
excite.com - delivery to this domain has been disabled (cause unknown)
epacificglobal.com - delivery to this domain has been disabled (no MX record for domain)
freefish.dyndns.org - delivery to this domain has been disabled (Name Server Problem -- Host not found)
gmx.net - delivery to this domain has been disabled (cause unknown)
hotmail.com - delivery to this domain has been disabled (Mailbox over quota)
intercom.net - delivery to this domain has been disabled (cause unknown)
ionsphere.org - (connection timed out)
initialcs.com - delivery to this domain has been disabled (cause unknown)
intelligents.2y.net - delivery to this domain has been disabled (Name Service Problem -- Host not Found).
khp-inc.com - delivery to this domain has been disabled (anti-virus problems)
kieninger.de - delivery to this domain has been disabled (relaying to <xxxxx@kieninger.de> prohibited by administrator)
littleblue.de - (connection timed out)
navair.navy.mil - delivery to this domain has been disabled (A restriction in the system prevented delivery of the message)
opermail.net - delivery to this domain has been disabled (cause unknown)
opus.homeip.net - (SpamAssassin is missing the HiRes Time module)
penquindevelopment.com - delivery to this domain has been disabled (connection timed out)
scip-online.de - delivery to this domain has been disabled (cause unknown)
spctnet.com - connection timed out - delivery to this domain has been disabled
telusplanet.net - delivery to this domain has been disabled (cause unknown)
yahoo.com - delivery to this domain has been disabled (Mailbox over quota)
+
+
+
+
+
-
-
\ No newline at end of file
+
diff --git a/Shorewall-docs/myfiles.htm b/Shorewall-docs/myfiles.htm
index 4a57eaecd..cef30a5e6 100644
--- a/Shorewall-docs/myfiles.htm
+++ b/Shorewall-docs/myfiles.htm
@@ -1,133 +1,134 @@
-
+
-
-
-
+
-
+
+
+
-
-
+
+
+
+
- About My Network
-
-
+
My Current Network
-
-
-
+
-
-
-
-
-
+
- Shorewall.conf
-
- SUBSYSLOCK=/var/lock/subsys/shorewall
-
-
STATEDIR=/var/state/shorewall
LOGRATE=
LOGBURST=
ADD_IP_ALIASES="Yes"
CLAMPMSS=Yes
MULTIPORT=YesZones File:
-
- #ZONE DISPLAY COMMENTS
-
-
net Internet Internet
me Eastep My Workstation
loc Local Local networks
dmz DMZ Demilitarized zone
tx Texas Peer Network in Dallas Texas
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVEInterfaces File:
-
-
-
-
- #ZONE INTERFACE BROADCAST OPTIONS
-
+
+
net eth0 206.124.146.255 routefilter,norfc1918,blacklist,filterping
loc eth2 192.168.1.255 dhcp
dmz eth1 206.124.146.255 -
net eth3 206.124.146.255 norfc1918
- texas -
loc ppp+
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVEShorewall.conf
+
+ SUBSYSLOCK=/var/lock/subsys/shorewall
+
+
STATEDIR=/var/state/shorewall
LOGRATE=
LOGBURST=
ADD_IP_ALIASES="Yes"
CLAMPMSS=Yes
MULTIPORT=YesZones File:
+
+ #ZONE DISPLAY COMMENTS
+
+
net Internet Internet
me Eastep My Workstation
loc Local Local networks
dmz DMZ Demilitarized zone
tx Texas Peer Network in Dallas Texas
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVEInterfaces File:
+
+
+
+
+ #ZONE INTERFACE BROADCAST OPTIONS
+
net eth0 206.124.146.255 routefilter,norfc1918,blacklist,filterping
loc eth2 192.168.1.255 dhcp,filterping,maclist
dmz eth1 206.124.146.255 filterping
net eth3 206.124.146.255 filterping,blacklist
- texas - filterping
loc ppp+ - filterping
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVEHosts File:
-
+
#ZONE HOST(S) OPTIONS
-
+
me eth2:192.168.1.3,eth2:206.124.146.179
tx texas:192.168.9.0/24
#LAST LINE -- ADD YOUR ENTRIES ABOVE -- DO NOT REMOVERoutestopped File:
-
+
#INTERFACE HOST(S)
-
+
eth1 206.124.146.177
eth2 -
eth3 206.124.146.180Common File:
-
+
. /etc/shorewall/common.def
-
+
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
run_iptables -A common -p tcp --dport 113 -j REJECTPolicy File:
-
+
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
me all ACCEPT
@@ -135,34 +136,40 @@ Ethernet interfaces.
all me CONTINUE #WARNING: You must be running Shorewall 1.3.1 or later for
-
+
# this policy to work as expected!!!
loc loc ACCEPT
loc net ACCEPT
$FW loc ACCEPT
$FW tx ACCEPT
loc tx ACCEPT
loc fw REJECT
net net ACCEPT
net all DROP info 10/sec:40
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOTEMasq File:
-
-
-
-
- #INTERFACE SUBNET ADDRESS
-
+
+
eth0 192.168.1.0/24 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+
+ #INTERFACE SUBNET ADDRESS
+
eth0 192.168.1.0/24 206.124.146.176
texas 206.124.146.179 192.168.1.254
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVENAT File:
-
+
#EXTERNAL INTERFACE INTERNAL ALL LOCAL
-
+
206.124.146.178 eth0 192.168.1.5 No No
206.124.146.179 eth0 192.168.1.3 No No
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVEProxy ARP File:
-
- #ADDRESS INTERFACE EXTERNAL HAVEROUTE
-
-
206.124.146.177 eth1 eth0 No
206.124.146.180 eth3 eth0 No
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVERules File (The shell variables
- are set in /etc/shorewall/params):
-
+
+ #ADDRESS INTERFACE EXTERNAL HAVEROUTE
+
+
206.124.146.177 eth1 eth0 No
206.124.146.180 eth3 eth0 No
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVERules File (The shell variables
+ are set in /etc/shorewall/params):
+
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
-
-
# PORT(S) PORT(S) PORT(S) DEST
#
# Local Network to Internet - Reject attempts by Trojans to call home
#
REJECT:info loc net tcp 6667
#
# Local Network to Firewall
#
ACCEPT loc fw tcp ssh
ACCEPT loc fw tcp time
#
# Local Network to DMZ
#
ACCEPT loc dmz udp domain
ACCEPT loc dmz tcp smtp
ACCEPT loc dmz tcp domain
ACCEPT loc dmz tcp ssh
ACCEPT loc dmz tcp auth
ACCEPT loc dmz tcp imap
ACCEPT loc dmz tcp https
ACCEPT loc dmz tcp imaps
ACCEPT loc dmz tcp cvspserver
ACCEPT loc dmz tcp www
ACCEPT loc dmz tcp ftp
ACCEPT loc dmz tcp pop3
ACCEPT loc dmz icmp echo-request
#
# Internet to DMZ
#
ACCEPT net dmz tcp www
ACCEPT net dmz tcp smtp
ACCEPT net dmz tcp ftp
ACCEPT net dmz tcp auth
ACCEPT net dmz tcp https
ACCEPT net dmz tcp imaps
ACCEPT net dmz tcp domain
ACCEPT net dmz tcp cvspserver
ACCEPT net dmz udp domain
ACCEPT net dmz icmp echo-request
ACCEPT net:$MIRRORS dmz tcp rsync
#
# Net to Me (ICQ chat and file transfers)
#
ACCEPT net me tcp 4000:4100
#
# Net to Local
#
ACCEPT net loc tcp auth
REJECT net loc tcp www
#
# DMZ to Internet
#
ACCEPT dmz net icmp echo-request
ACCEPT dmz net tcp smtp
ACCEPT dmz net tcp auth
ACCEPT dmz net tcp domain
ACCEPT dmz net tcp www
ACCEPT dmz net tcp https
ACCEPT dmz net tcp whois
ACCEPT dmz net tcp echo
ACCEPT dmz net udp domain
ACCEPT dmz net:$NTPSERVERS udp ntp
ACCEPT dmz net:$POPSERVERS tcp pop3
#
# The following compensates for a bug, either in some FTP clients or in the
# Netfilter connection tracking code that occasionally denies active mode
# FTP clients
#
ACCEPT:info dmz net tcp 1024: 20
#
# DMZ to Firewall -- snmp
#
ACCEPT dmz fw tcp snmp
ACCEPT dmz fw udp snmp
#
# DMZ to Local Network
#
ACCEPT dmz loc tcp smtp
ACCEPT dmz loc tcp auth
ACCEPT dmz loc icmp echo-request
# Internet to Firewall
#
ACCEPT net fw tcp 1723
ACCEPT net fw gre
REJECT net fw tcp www
#
# Firewall to Internet
#
ACCEPT fw net:$NTPSERVERS udp ntp
ACCEPT fw net udp domain
ACCEPT fw net tcp domain
ACCEPT fw net tcp www
ACCEPT fw net tcp https
ACCEPT fw net tcp ssh
ACCEPT fw net tcp whois
ACCEPT fw net icmp echo-request
#
# Firewall to DMZ
#
ACCEPT fw dmz tcp www
ACCEPT fw dmz tcp ftp
ACCEPT fw dmz tcp ssh
ACCEPT fw dmz tcp smtp
ACCEPT fw dmz udp domain
#
# Let Texas Ping
#
ACCEPT tx fw icmp echo-request
ACCEPT tx loc icmp echo-request
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+
+
+
+
diff --git a/Shorewall-docs/ports.htm b/Shorewall-docs/ports.htm
index f205236fe..2ab74c0a0 100644
--- a/Shorewall-docs/ports.htm
+++ b/Shorewall-docs/ports.htm
@@ -1,122 +1,192 @@
+
-
-
-
-
+
+
+
-
+
+
+
-
- Ports required for Various Services/Applications
-
+
+
-
-
+
+
+
+
+ Ports required for Various
+Services/Applications
+
+
+
+
-
+
+
+
-
+
+
+
+
-
-
- If you are configuring a server, only open TCP Port 53 if you will return long
- replies to queries or if you need to enable ZONE transfers. In the latter
- case, be sure that your server is properly configured.
-
+
+
+
+
+
+ If you are configuring a server, only open TCP Port 53 if you will return
+long replies to queries or if you need to enable ZONE transfers. In the
+latter case, be sure that your server is properly configured.
+
+
-
+
+
+
+
-
+
+
+
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
+
+
+
-
-
+
+
+
-
-
+ kernel is compiled to support FTP connection tracking. If you build this
+ support as a module, Shorewall will automatically load the module from
+ /var/lib/<kernel version>/kernel/net/ipv4/netfilter.
+
+
+
+
+
+
+
+
+
+ loadmodule ip_nat_ftp ports=21,49
+
+
+
+
+ options ip_nat_ftp ports=21,49
+
+
+
-
-
- UDP Ports 137-139.
-
- Also, see this page.
+ UDP Ports 137-139.
+
+
+
+ Also, see this page.
+
-
-
-
+
+
+
+
+
+
diff --git a/Shorewall-docs/quotes.htm b/Shorewall-docs/quotes.htm
index 9144c69cd..452dd5537 100644
--- a/Shorewall-docs/quotes.htm
+++ b/Shorewall-docs/quotes.htm
@@ -1,101 +1,104 @@
-
+
-
+
-
+
-
+
-
-
-
-
-
+
+
+
-
-
+
+
+
+
- Quotes from Shorewall Users
-
-
+
-
-Minutes instead of months! Congratulations and thanks for such a simple and
-well documented thing for something as huge as iptables." -- JV, Spain.
-
-
-
- While I had previously taken the time (maybe 40 hours) to really understand
- ipchains, then spent at least an hour per server customizing and carefully
- scrutinizing firewall rules, I've got shorewall running on my home firewall,
- with rulesets and policies that I know make sense, in under 20 minutes."
+ While I had previously taken the time (maybe 40 hours) to really understand
+ ipchains, then spent at least an hour per server customizing and carefully
+ scrutinizing firewall rules, I've got shorewall running on my home firewall,
+ with rulesets and policies that I know make sense, in under 20 minutes."
-- RP, Guatamala
-
-
+
+
+
+
diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm
index cf85d36d3..d373b1aeb 100644
--- a/Shorewall-docs/seattlefirewall_index.htm
+++ b/Shorewall-docs/seattlefirewall_index.htm
@@ -2,294 +2,396 @@
-
+
+
-
-
-
-
-
-
+
+
+
-
-
-
-
-
+
+
+
-
-
-
-
- 
- Shorewall 1.3
-- "iptables made easy"
-
-
+
+
-
-
+
+
+
-
+
+
+
+
+
-
-
-
+ What is it?
+ Shorewall 1.3 - "iptables
+ made easy"
-
-
-
- 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
- Jacques Nilo and Eric Wolzak have a LEAF
- distribution called Bering that features Shorewall-1.3.3
- and Kernel-2.4.18. You can find their work at: http://leaf.sourceforge.net/devel/jniloNews
-
-
-
-
-
-
-
-
- 
-
-
- A couple of recent configuration changes at www.shorewall.net broke
- the Search facility:
-
-
-
- Hopefully these problems are now corrected.
-
-
-
-
-
-
-
-
-
-
+
+
-
+
+
+
-
+
-
-
+
+
+
+
+
+
-
-
+
- What is it?
-
-
-
+
+
+
+
+
+
+ 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
+ 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.9b and Kernel-2.4.18. You can find
+their work at: http://leaf.sourceforge.net/devel/jniloThinking of Downloading this Site for Offline Browsing?
+ You might want to reconsider -- this site is 213 MB!!!
+and you will almost certainly be blacklisted before you download the whole
+thing (my SDSL is only 384kbs so I'll have lots of time to catch you). Besides,
+if you simply download the product and install it, you get the essential
+parts of the site in a fraction of the time. And do you really want to download:
+
-
+ You get all that and more if you do a blind recurive copy of this site.
+ Happy downloading!
-
+
+
+
+ News
-
+
+
+
+
+
+
+
+
+
+ 
+
+
+If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to version
+1.3.10, you will need to use the '--force' option:
+
+
+
+
+ rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
+
+
+
+
+
+
+
+
+ You may download the Beta from:
+
+
+
+
+
+
+
+
+ 10/6/2002 - Shorewall.net now running on RH8.0
+
+
+ The firewall and server here at shorewall.net are now
+running RedHat release 8.0.
+
+
+
+
+
+
+
+
+ There is an updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall
+ -- copy that file to /usr/lib/shorewall/firewall.
+
+
+
+
+
+
+ 9/28/2002 - Shorewall 1.3.9
+
+
+
-
-
+ Donations
- M
- Donations
+
+
+ M
+
+
+
+
+
-
-
-
-
-
+
+
+
-
-
-
-
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
-
-
-
-
-
-
-
-
-
- Tom Eastep
- 
-
- Photo by Ken Mazawa
-
-
-
+
+
+
+
+
+ Tom Eastep
+ 
+
+
+
-
-
+
+
+
+
+ Copyright
+ © 2001, 2002 Thomas M. Eastep.
+
+
+
+
+
diff --git a/Shorewall-docs/shorewall_ca_certificate.htm b/Shorewall-docs/shorewall_ca_certificate.htm
deleted file mode 100644
index 3768f568c..000000000
--- a/Shorewall-docs/shorewall_ca_certificate.htm
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
-
-
-
-
-
-Shorewall CA Certificate
-
-
-
+
+
+
-
- Shorewall Features
-
+
+
+
+
+
+
+
+ Shorewall Features
+
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
+
-
+
+
+
-
-
+ Version 3.1
+
+
+
+
- Shorewall QuickStart Guides
-
- Version 3.1The Guides
-
+
-
-
+
-
-
-
-
-
+
+
-
-
-
-
+
-
-
- Additional Documentation
-
-
-
-
+
-
-
-
-
-
+
-
-
-
-
-
-
+
+
+
diff --git a/Shorewall-docs/starting_and_stopping_shorewall.htm b/Shorewall-docs/starting_and_stopping_shorewall.htm
index f216e4f9e..cad46fc6e 100644
--- a/Shorewall-docs/starting_and_stopping_shorewall.htm
+++ b/Shorewall-docs/starting_and_stopping_shorewall.htm
@@ -1,13 +1,13 @@
-
+
-
+
-
+
-
+
-
-
-
-
+
+
-
+
-
-
+
+
-
- Starting/Stopping and Monitoring
-the Firewall
+
+
+
+
- Starting/Stopping and Monitoring
+ the Firewall
-
-
-
-
-
-
+
+
+
+
+
-
-
+
-
+Finally, the "shorewall" program may be used to dynamically alter the contents
+of a zone.
+
+
+Examples:
-
-
+ shorewall add ipsec0:192.0.2.24 vpn1 -- adds the address 192.0.2.24
+from interface ipsec0 to the zone vpn1
+
+shorewall delete ipsec0:192.0.2.24 vpn1 -- deletes the address 192.0.2.24
+from interface ipsec0 from zone vpn1
+
-
+
+
-
-
+
+ shorewall try configuration-directory
+
- shorewall try configuration-directory
-
-
-
-
-
-
+
+
diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm
index f22c2bd51..cf59cad7c 100644
--- a/Shorewall-docs/support.htm
+++ b/Shorewall-docs/support.htm
@@ -1,77 +1,78 @@
-
+
-
+
-
+
-
+
-
-
-
-
-
+
+
+
-
-
+
+
+
+
- Shorewall Support
- "It is
-easier to post a problem than to use your own brain" -- "It
+is easier to post a problem than to use your own brain" -- Wietse Venema (creator of Postfix)
-
-
-
-Before Reporting a Problem
-
+
-
-
+
Mailing List Archive Search
+
+
-
+
+
Problem Reporting Guidelines
-
+
-
-
+
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
+
If you run Shorewall under Bering -- please
+ post your question or problem to the LEAF Users mailing list.
-
+
+
+
diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm
index f6c767173..a87918901 100644
--- a/Shorewall-docs/three-interface.htm
+++ b/Shorewall-docs/three-interface.htm
@@ -1,764 +1,484 @@
-
+
-
+
-
+
-
+
-
-
-
+
-
+
+
+
-
-
+
+
+
+
- Three-Interface Firewall
- Version 2.0.1
-
+
-
-
+
- [root@gateway root]# which ip
-
+
/sbin/ip
[root@gateway root]#
-
+
+
- If you edit your configuration files on a Windows system, you must
- save them as Unix files if your editor supports that option or you must
-run them through dos2unix before trying to use them. Similarly, if you copy
-a configuration file from your Windows hard drive to a floppy disk, you
-must run dos2unix against the copy before using it with Shorewall.
-
-
+
Shorewall Concepts
-
+
-
-
-
+
-
- Name
- Description
-
-
- net
- The Internet
-
-
- loc
- Your Local Network
-
-
-
-
+
+ dmz
- Demilitarized Zone
-
+
+ Name
+ Description
+
+
+ net
+ The Internet
+
+
+ loc
+ Your Local Network
+
+
+
+
dmz
+ Demilitarized Zone
+
-
-
+
+ has the following policies:
+
+
+
-
-
-
-
-
-
- Source Zone
- Destination Zone
- Policy
- Log Level
- Limit:Burst
-
-
- loc
- net
- ACCEPT
-
-
-
-
- net
- all
- DROP
- info
-
-
-
-
-
+
+ all
- all
- REJECT
- info
-
-
+
+ Source Zone
+ Destination Zone
+ Policy
+ Log Level
+ Limit:Burst
+
+
+ loc
+ net
+ ACCEPT
+
+
+
+
+ net
+ all
+ DROP
+ info
+
+
+
+
+
all
+ all
+ REJECT
+ info
+
+
+
+
+
-
+
-
-
-
-
- Source Zone
- Destination Zone
- Policy
- Log Level
- Limit:Burst
-
-
-
-
+
+ fw
- net
- ACCEPT
-
-
-
+
+ Source Zone
+ Destination Zone
+ Policy
+ Log Level
+ Limit:Burst
+
+
+
+
fw
+ net
+ ACCEPT
+
+
+
-
-
+
- At this point, edit your /etc/shorewall/policy file and make any
-changes that you wish.Network Interfaces
-
+
-
- If your external interface is ppp0 or ippp0 then you
- will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
- Do not connect more than one interface to the same hub or switch
- (even for testing). It won't work the way that you expect it to and you
-will end up confused and believing that Shorewall doesn't work at all.
- The Shorewall three-interface sample configuration assumes that the
- external interface is eth0, the local interface is eth1 and
- the DMZ interface is eth2. If your configuration is different,
-you will have to modify the sample /etc/shorewall/interfaces file accordingly.
- While you are there, you may wish to review the list of options that are
- specified for the interfaces. Some hints:
-
-
+
IP Addresses
-
+
+
+
+
-
- 10.0.0.0 - 10.255.255.255
-
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
+
+
+
-
-
- Before starting Shorewall, you should look at the IP address of
-your external interface and if it is one of the above ranges, you should
-remove the 'norfc1918' option from the external interface's entry in
- /etc/shorewall/interfaces.
+ Before starting Shorewall, you should look at the IP address
+of your external interface and if it is one of the above ranges, you
+should remove the 'norfc1918' option from the external interface's entry
+in /etc/shorewall/interfaces.
+
+
+
-
-
+ Address and x.y.z.255 is reserved as the Subnet Broadcast Address.
+ In Shorewall, a subnet is described using Classless
+ InterDomain Routing (CIDR) notation with consists of the subnet
+address followed by "/24". The "24" refers to the number of consecutive
+"1" bits from the left of the subnet mask.
+
+
+
-
-
-
+
+
+
+
-
-
-
-
-
-
-
- Range:
- 10.10.10.0 - 10.10.10.255
-
-
- Subnet Address:
- 10.10.10.0
-
-
- Broadcast Address:
- 10.10.10.255
-
-
-
-
+
+ CIDR Notation:
- 10.10.10.0/24
-
+
+ Range:
+ 10.10.10.0 - 10.10.10.255
+
+
+ Subnet Address:
+ 10.10.10.0
+
+
+ Broadcast Address:
+ 10.10.10.255
+
+
+
+
CIDR Notation:
+ 10.10.10.0/24
+
+
+
+
+
-
-
+ the first usable address in the subnet (10.10.10.1 in the above example)
+ or the last usable address (10.10.10.254).
+
+
+
-
-
+ in the subnet to understand which other computers can be communicated
+ with directly. To communicate with systems outside of the subnetwork,
+systems send packets through a gateway (router).
+
+
+
-
+ Your local computers (Local Computers 1 & 2) should be configured
+ with their default gateway set to the IP address of the firewall's
+ internal interface and your DMZ computers ( DMZ Computers 1 & 2)
+should be configured with their default gateway set to the IP address
+of the firewall's DMZ interface.
+
- Your local computers (Local Computers 1 & 2) should be configured
- with their default gateway set to the IP address of the firewall's
- internal interface and your DMZ computers ( DMZ Computers 1 & 2) should
- be configured with their default gateway set to the IP address of the
-firewall's DMZ interface. 
- IP Masquerading (SNAT)
-
+
-
-
+
- If your external firewall interface is eth0, your local interface
- eth1 and your DMZ interface is eth2 then you do not need to
- modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq
- and change it to match your configuration.
- If your external IP is static, you can enter it in the third column
- in the /etc/shorewall/masq entry if you like although your firewall will
- work fine if you leave that column empty. Entering your static IP in column
- 3 makes processing outgoing packets a little more efficient. Port Forwarding (DNAT)
-
+
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
- DNAT
- net
- dmz:<server local ip address> [:<server
-port>]
- <protocol>
- <port>
-
-
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- DNAT
- net
- dmz:10.10.11.2
- tcp
- 80
- # Forward port 80
- from the internet
-
-
-
-
- ACCEPT
- loc
- dmz:10.10.11.2
- tcp
- 80
- #Allow connections
- from the local network
-
-
-
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
- DNAT
- net
- dmz:10.10.11.2:80
- tcp
- 5000
-
-
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
- DNAT
- net
- dmz:10.10.11.2:80
- tcp
- 80
- -
- <external IP>
-
-
-
-
-
- ETH0_IP=`find_interface_address eth0`
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
- DNAT
- net
- dmz:10.10.11.2:80
- tcp
- 80
- -
- $ETH0_IP
-
- At this point, add the DNAT and ACCEPT rules for your servers. Domain Name Server (DNS)
-
-
-
-
-
- You can configure a Caching Name Server on your firewall
-or in your DMZ. Red Hat has an RPM for a caching name server (which
-also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp.
-If you take this approach, you configure your internal systems to use the
-caching name server as their primary (and only) name server. You use the
-internal IP address of the firewall (10.10.10.254 in the example above)
- for the name server address if you choose to run the name server on your
- firewall. To allow your local systems to talk to your caching name server,
- you must open port 53 (both UDP and TCP) from the local network to the
- server; you do that by adding the rules in /etc/shorewall/rules.
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- ACCEPT
- loc
- fw
- tcp
- 53
-
-
-
-
- ACCEPT
- loc
- fw
- udp
- 53
-
-
-
-
- ACCEPT
- dmz
- fw
- tcp
- 53
-
-
-
-
-
-
- ACCEPT
- dmz
- fw
- udp
- 53
-
-
-
-
-
-
-
-
-
-
+
ACTION
SOURCE
DESTINATION
@@ -768,192 +488,225 @@ internal IP address of the firewall (10.10.10.254 in the example above)
ORIGINAL ADDRESS
-
- ACCEPT
- loc
- dmz:10.10.11.1
- tcp
- 53
-
-
-
-
- ACCEPT
- loc
- dmz:10.10.11.1
- udp
- 53
-
-
-
-
- ACCEPT
- fw
- dmz:10.10.10.1
- tcp
- 53
-
-
-
-
-
-
- ACCEPT
- fw
- dmz:10.10.10.1
- udp
- 53
-
-
-
-
-
-Other Connections
-
-
-
-
-
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- ACCEPT
- fw
+ DNAT
net
- udp
- 53
-
-
-
-
-
-
- ACCEPT
- fw
- net
- tcp
- 53
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- ACCEPT
- loc
- fw
- tcp
- 22
-
-
-
-
-
-
- ACCEPT
- loc
- dmz
- tcp
- 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+
+
ACCEPT
- <source zone>
- <destination zone>
+ dmz:<server local ip address> [:<server
+ port>]
<protocol>
<port>
-
-
-
-
-
-
+
+
+
+
-
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+ DNAT
+ net
+ dmz:10.10.11.2
+ tcp
+ 80
+ # Forward port 80
+ from the internet
+
+
+
+
+ ACCEPT
+ loc
+ dmz:10.10.11.2
+ tcp
+ 80
+ #Allow connections
+ from the local network
+
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+ DNAT
+ net
+ dmz:10.10.11.2:80
+ tcp
+ 5000
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+ DNAT
+ net
+ dmz:10.10.11.2:80
+ tcp
+ 80
+ -
+ <external IP>
+
+
+
+
+
+ ETH0_IP=`find_interface_address eth0`
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+ DNAT
+ loc
+
+ dmz:10.10.11.2:80
+ tcp
+ 80
+ -
+ $ETH0_IP
+
+ At this point, add the DNAT and ACCEPT rules for your servers.
+Domain Name Server (DNS)
+
+
+
+
+
+ You can configure a Caching Name Server on your firewall
+ or in your DMZ. Red Hat has an RPM for a caching name server (which
+ also requires the 'bind' RPM) and for Bering users, there is dnscache.lrp.
+ If you take this approach, you configure your internal systems to use
+the caching name server as their primary (and only) name server. You use
+the internal IP address of the firewall (10.10.10.254 in the example above)
+ for the name server address if you choose to run the name server on your
+ firewall. To allow your local systems to talk to your caching name server,
+ you must open port 53 (both UDP and TCP) from the local network to the
+ server; you do that by adding the rules in /etc/shorewall/rules.
+
-
+
+
-
ACTION
SOURCE
DESTINATION
@@ -964,137 +717,392 @@ internal IP address of the firewall (10.10.10.254 in the example above)
ACCEPT
- net
+ loc
fw
tcp
53
- #Allow DNS access
- from the internet
+
+
+ ACCEPT
- net
+ loc
+ fw
+ udp
+ 53
+
+
+
+
-
-
+ ACCEPT
+ dmz
fw
tcp
53
- #Allow DNS access
- from the internet
+
+
+
+
+
ACCEPT
+ dmz
+ fw
+ udp
+ 53
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+ ACCEPT
+ loc
+ dmz:10.10.11.1
+ tcp
+ 53
+
+
+
+
+ ACCEPT
+ loc
+ dmz:10.10.11.1
+ udp
+ 53
+
+
+
+
+ ACCEPT
+ fw
+ dmz:10.10.10.1
+ tcp
+ 53
+
+
+
+
+
+
+ ACCEPT
+ fw
+ dmz:10.10.10.1
+ udp
+ 53
+
+
+
+
+
+Other Connections
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+ ACCEPT
+ fw
+ net
+ udp
+ 53
+
+
+
+
+
+
+ ACCEPT
+ fw
+ net
+ tcp
+ 53
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+ ACCEPT
+ loc
+ fw
+ tcp
+ 22
+
+
+
+
+
+
+ ACCEPT
+ loc
+ dmz
+ tcp
+ 22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+ ACCEPT
+ <source zone>
+ <destination zone>
+ <protocol>
+ <port>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+ ACCEPT
+ net
+ fw
+ tcp
+ 53
+ #Allow DNS access
+ from the internet
+
+
+
+
+ ACCEPT
+ net
+ fw
+ tcp
+ 53
+ #Allow DNS access
+ from the internet
+
-
-
+ listed above under "If you run the name server on your firewall".
+
+
+
-
-
+
+
+
-
-
-
+
+
+ the internet because it uses clear text (even for login!). If you want
+ shell access to your firewall from the internet, use SSH:
+
+
-
-
-
-
-
-
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+
+ ACCEPT
- net
- fw
- tcp
- 22
-
-
-
+
+ ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
ACCEPT
+ net
+ fw
+ tcp
+ 22
+
+
+
+
+
+
+
-
-
- Now modify /etc/shorewall/rules to add or remove other connections
- as required.
+ Now modify /etc/shorewall/rules to add or remove other connections
+ as required.
+
+
+
-
-Starting and Stopping Your Firewall
-
+
+
+
-
-
- The installation procedure configures
-your system to start Shorewall at system boot but beginning with Shorewall
-version 1.3.9 startup is disabled so that your system won't try to start
+ The installation procedure configures
+ your system to start Shorewall at system boot but beginning with Shorewall
+ version 1.3.9 startup is disabled so that your system won't try to start
Shorewall before configuration is complete. Once you have completed configuration
of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
-
-
+ and set 'startup=1'.
+
+
+
+
-
-
+ 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".
+
+
+
-
-
- The three-interface sample assumes that you want to enable routing
- to/from eth1 (your local network) and eth2 (DMZ) when Shorewall
- is stopped. If these two interfaces don't connect to your local network
- and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped
- accordingly.
+ The three-interface sample assumes that you want to enable routing
+ to/from eth1 (your local network) and eth2 (DMZ) when Shorewall
+ is stopped. If these two interfaces don't connect to your local network
+ and DMZ or if you want to enable a different set of hosts, modify /etc/shorewall/routestopped
+ accordingly.
+
+
+
-
-
+
diff --git a/Shorewall-docs/traffic_shaping.htm b/Shorewall-docs/traffic_shaping.htm
index 4593e1f70..ddff1c3b7 100644
--- a/Shorewall-docs/traffic_shaping.htm
+++ b/Shorewall-docs/traffic_shaping.htm
@@ -1,214 +1,257 @@
+
-
-
-
-
-
-
-
-
+
+
+
-
- Traffic Shaping/Control
-
+
+
-
+
+
+
+
+ Traffic Shaping/Control
+
-
+
-
-
-
- In tcstart, when you want to run the 'tc' utility, use the run_tc function
- supplied by shorewall.
-
+
+
+
+ In tcstart, when you want to run the 'tc' utility, use the run_tc function
+ supplied by shorewall.
+ Kernel Configuration
+
+ /etc/shorewall/tcrules
+
-
-
-
- Example - 5
-
-
- Examples
- eth0
- 192.168.2.4,192.168.1.0/24
-
-
-
-
+
+ Example - 5
+
+
+ Examples
+ eth0
+ 192.168.2.4,192.168.1.0/24
+
+
+
+
-
-
- MARK
- SOURCE
- DEST
- PROTO
- PORT(S)
- CLIENT PORT(S)
-
-
- 1
- eth1
- 0.0.0.0/0
- all
-
-
-
-
- 2
- eth2
- 0.0.0.0/0
- all
-
-
-
-
+
+3
- fw
- 0.0.0.0/0
- all
-
-
-
+
+
-
+
+ MARK
+ SOURCE
+ DEST
+ PROTO
+ PORT(S)
+ CLIENT PORT(S)
+
+
+ 1
+ eth1
+ 0.0.0.0/0
+ all
+
+
+
+
+ 2
+ eth2
+ 0.0.0.0/0
+ all
+
+
+
+
+
+
3
+ fw
+ 0.0.0.0/0
+ all
+
+
+
-
-
- MARK
- SOURCE
- DEST
- PROTO
- PORT(S)
- CLIENT PORT(S)
-
-
+
+12
- 0.0.0.0/0
- 155.186.235.151
- 47
-
-
-
+
+
-
+
+ MARK
+ SOURCE
+ DEST
+ PROTO
+ PORT(S)
+ CLIENT PORT(S)
+
+
+
+
12
+ 0.0.0.0/0
+ 155.186.235.151
+ 47
+
+
+
-
-
- MARK
- SOURCE
- DEST
- PROTO
- PORT(S)
- CLIENT PORT(S)
-
-
+
+22
- 192.168.1.0/24
- 155.186.235.151
- tcp
- 22
-
-
+
+
+
+
+ MARK
+ SOURCE
+ DEST
+ PROTO
+ PORT(S)
+ CLIENT PORT(S)
+
+
+
+
22
+ 192.168.1.0/24
+ 155.186.235.151
+ tcp
+ 22
+
+ Hierarchical Token Bucket
-
-
-
+
+
-
-
-
- run_tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k
-
- run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 150kbit ceil 10mbit burst 15k
- run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 234kbit ceil 10mbit burst 15k
- run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil
- 10mbit burst 15k
-
- run_tc qdisc add dev eth0 parent 1:10 sfq perturb 10
- run_tc qdisc add dev eth0 parent 1:20 sfq perturb 10
- run_tc qdisc add dev eth0 parent 1:30 sfq perturb 10
-
- run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
- run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:20
- run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
-
-
+
+
+run_tc qdisc add dev eth0 root handle 1: htb default 30
+
+
run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k
echo " Added Top Level Class -- rate 384kbit"run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k
+
+
run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k
run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit ceil 384kbit burst 15k quantum 1500echo " Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
+
+ run_tc qdisc add dev eth0 parent 1:10 sfq perturb 10
+
+
run_tc qdisc add dev eth0 parent 1:20 sfq perturb 10
run_tc qdisc add dev eth0 parent 1:30 sfq perturb 10echo " Enabled SFQ on Second Level Classes"
+
+ run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
+
+
run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 2 fw classid 1:20
run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30echo " Defined fwmark filters"
+
+
+
+
-
-
\ No newline at end of file
+
diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm
index 964d3df21..1e69a028e 100644
--- a/Shorewall-docs/troubleshoot.htm
+++ b/Shorewall-docs/troubleshoot.htm
@@ -1,205 +1,199 @@
-
-
+
+
-
+
+
-
-
-
- Shorewall Troubleshooting
-
+
+
+
+
+
+
+
+
+
+ Shorewall Troubleshooting
+ Check the Errata
+
+Check the FAQs
+
+If the firewall fails to start
+ If you receive an error message when starting or restarting the firewall
+and you can't determine the cause, then do the following:
+
+
+
+Check the Errata
-
- Check the FAQs
-
- If the firewall fails to start
-
- If you
-receive an error message when starting or restarting the firewall and you
-can't determine the cause, then do the following:
-
-
- Your test environment
-
-
-
- If you are having
-connection problems:
-
- Your test environment
+
+
+
+
+If you are having connection problems:
+
+
- LOGBURST=""
+ LOGBURST=""
+
+
+
-
-
- Other Gotchas
-
-
-
+
+
-
Other Gotchas
+
+
+
-
+
-
-
- ACCEPT <source zone> <destination zone>
+
+
+ ACCEPT <source zone> <destination zone>
icmp echo-request
-
- The ramifications of this can be subtle. For example, if you have the
- following in /etc/shorewall/nat:
-
- 10.1.1.2 eth0 130.252.100.18
-
- and you ping 130.252.100.18, unless you have allowed icmp type 8 between
-the zone containing the system you are pinging from and the zone containing
- 10.1.1.2, the ping requests will be dropped. This is true even if you
+
+ The ramifications of this can be subtle. For example, if you have the
+ following in /etc/shorewall/nat:
+
+ 10.1.1.2 eth0 130.252.100.18
+
+ and you ping 130.252.100.18, unless you have allowed icmp type 8 between
+the zone containing the system you are pinging from and the zone containing
+ 10.1.1.2, the ping requests will be dropped. This is true even if you
have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces.Still Having Problems?
- Still Having Problems?
+
+
+
+
-
-
-
-
-
\ No newline at end of file
+
diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm
index c3ede11b8..d5b723f73 100644
--- a/Shorewall-docs/two-interface.htm
+++ b/Shorewall-docs/two-interface.htm
@@ -1,917 +1,920 @@
-
+
-
+
-
+
-
+
-
-
-
-
-
+
+
+
-
-
+
+
+
+
- Basic Two-Interface Firewall
-
-
-
+
- [root@gateway root]# which ip
-
-
/sbin/ip
[root@gateway root]#
- .
+ .
- If you edit your configuration files on a Windows system, you must
- save them as Unix files if your editor supports that option or you must
-run them through dos2unix before trying to use them. Similarly, if you copy
-a configuration file from your Windows hard drive to a floppy disk, you
-must run dos2unix against the copy before using it with Shorewall.
-
-
+
Shorewall Concepts
-
-
-
+
+
-
-
+
Name
+ Description
+
-
- Name
- Description
-
-
- net
- The Internet
-
-
-
-
+ loc
- Your Local Network
- net
+ The Internet
+
+
+
+
+
loc
+ Your Local Network
+
-
-
-
+
+
+
-
-
-
+
+
-
+
Source Zone
+ Destination Zone
+ Policy
+ Log Level
+ Limit:Burst
+
-
- Source Zone
- Destination Zone
- Policy
- Log Level
- Limit:Burst
-
-
- loc
- net
- ACCEPT
-
-
-
-
- net
- all
- DROP
- info
-
-
-
-
-
+ all
- all
- REJECT
- info
-
- loc
+ net
+ ACCEPT
+
+
+
+
+
+ net
+ all
+ DROP
+ info
+
+
+
+
+
all
+ all
+ REJECT
+ info
+
+
-
+
+
+
-
+
-
+
+
-
+
Source Zone
+ Destination Zone
+ Policy
+ Log Level
+ Limit:Burst
+
-
- Source Zone
- Destination Zone
- Policy
- Log Level
- Limit:Burst
-
-
-
-
+ fw
- net
- ACCEPT
-
-
- fw
+ net
+ ACCEPT
+
+
+
+
+
-
-
+
- At this point, edit your /etc/shorewall/policy and make any changes
+ At this point, edit your /etc/shorewall/policy and make any changes
that you wish.Network Interfaces
-
+
-
- If your external interface is ppp0 or ippp0 then you
- will want to set CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
- Do not connect the internal and external interface to the same
- hub or switch (even for testing). It won't work the way that you think that
- it will and you will end up confused and believing that Shorewall doesn't
+ Do not connect the internal and external interface to the same
+ hub or switch (even for testing). It won't work the way that you think that
+ it will and you will end up confused and believing that Shorewall doesn't
work at all.
- The Shorewall two-interface sample configuration assumes that the
-external interface is eth0 and the internal interface is eth1.
- If your configuration is different, you will have to modify the sample
-/etc/shorewall/interfaces file
-accordingly. While you are there, you may wish to review the list of options
-that are specified for the interfaces. Some hints:
-
-
+
IP Addresses
-
-
+
+
-
- 10.0.0.0 - 10.255.255.255
-
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
+
+
+
-
-
- Before starting Shorewall, you should look at the IP address of
-your external interface and if it is one of the above ranges, you should
-remove the 'norfc1918' option from the external interface's entry in
- /etc/shorewall/interfaces.
-
-
-
+ Before starting Shorewall, you should look at the IP address of
+ your external interface and if it is one of the above ranges, you should
+ remove the 'norfc1918' option from the external interface's entry in
+ /etc/shorewall/interfaces.
+
+
+
+
+
+
-
-
-
+
+
+
+
+
+
+
+
-
-
-
-
+
Range:
- 10.10.10.0 - 10.10.10.255
-
-
- Subnet Address:
- 10.10.10.0
-
-
- Broadcast Address:
- 10.10.10.255
-
-
-
-
+ CIDR Notation:
- 10.10.10.0/24
- Range:
+ 10.10.10.0 - 10.10.10.255
+
+
+
+ Subnet Address:
+ 10.10.10.0
+
+
+ Broadcast Address:
+ 10.10.10.255
+
+
+
+
CIDR Notation:
+ 10.10.10.0/24
+
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
-
-
- Your local computers (computer 1 and computer 2 in the above diagram)
- should be configured with their default gateway to be the IP address
- of the firewall's internal interface. 
- IP Masquerading (SNAT)
-
-
-
-
-
- If your external firewall interface is eth0, you do not need
- to modify the file provided with the sample. Otherwise, edit /etc/shorewall/masq
- and change the first column to the name of your external interface and the
- second column to the name of your internal interface.
- If your external IP is static, you can enter it in the third column
- in the /etc/shorewall/masq entry if you like although your firewall will
- work fine if you leave that column empty. Entering your static IP in column
- 3 makes processing outgoing packets a little more efficient. Port Forwarding (DNAT)
-
-
+
+
+
-
-
-
+
+
-
+
ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+ DNAT
- net
- loc:<server local ip address> [:<server
+ DNAT
+ net
+ loc:<server local ip address> [:<server
port>]
- <protocol>
- <port>
-
-
- <protocol>
+ <port>
+
+
+
+
+
+
+
+
-
+
-
+
+
-
+
ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+ DNAT
- net
- loc:10.10.10.2
- tcp
- 80
-
-
- DNAT
+ net
+ loc:10.10.10.2
+ tcp
+ 80
+
+
+
+
+
-
-
-
+
+
+
-
+
-
+
+
-
+
ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+ DNAT
- net
- loc:10.10.10.2:80
- tcp
- 5000
-
-
- DNAT
+ net
+ loc:10.10.10.2:80
+ tcp
+ 5000
+
+
+
+
+
- At this point, modify /etc/shorewall/rules to add any DNAT rules
+ At this point, modify /etc/shorewall/rules to add any DNAT rules
that you require.Domain Name Server (DNS)
-
-
-
-
-
- You can configure a Caching Name Server on your firewall.
- Red Hat has an RPM for a caching name server (the RPM also requires
- the 'bind' RPM) and for Bering users, there is dnscache.lrp. If you take
- this approach, you configure your internal systems to use the firewall
- itself as their primary (and only) name server. You use the internal IP
- address of the firewall (10.10.10.254 in the example above) for the name
- server address. To allow your local systems to talk to your caching name
- server, you must open port 53 (both UDP and TCP) from the local network
- to the firewall; you do that by adding the following rules in /etc/shorewall/rules.
-
+
+
-
-
-
+
+
-
+
ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
-
- ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- ACCEPT
- loc
- fw
- tcp
- 53
-
-
-
-
-
-
+ ACCEPT
- loc
- fw
- udp
- 53
-
-
- ACCEPT
+ loc
+ fw
+ tcp
+ 53
+
+
+
+
+
+
+
ACCEPT
+ loc
+ fw
+ udp
+ 53
+
+
+
+
+
+
-
-Other Connections
-
+
+
+
-
-
-
+
+
+
+
+
+
+
+
-
-
-
-
+
ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- ACCEPT
- fw
- net
- tcp
- 53
-
-
-
-
-
-
+ ACCEPT
- fw
- net
- udp
- 53
-
-
- ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+ ACCEPT
+ fw
+ net
+ tcp
+ 53
+
+
+
+
+
+
ACCEPT
+ fw
+ net
+ udp
+ 53
+
+
+
+
-
-
-
-
-
+
+
-
-
-
+
+
+
+
+
+
+
+
-
-
-
-
+
ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+ ACCEPT
- loc
- fw
- tcp
- 22
-
-
- ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+
ACCEPT
+ loc
+ fw
+ tcp
+ 22
+
+
+
+
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
-
-
-
-
+
ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+ ACCEPT
- <source zone>
- <destination zone>
- <protocol>
- <port>
-
-
- ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+
ACCEPT
+ <source zone>
+ <destination zone>
+ <protocol>
+ <port>
+
+
+
+
-
-
-
-
-
-
+
+
+
+
+
+
+
-
-
-
-
+
ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
- ACCEPT
- net
- fw
- tcp
- 80
- #Allow web access
- from the internet
-
-
-
-
+ ACCEPT
- loc
- fw
- tcp
- 80
- #Allow web access
- from the local network
- ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+ ACCEPT
+ net
+ fw
+ tcp
+ 80
+ #Allow web access
+ from the internet
+
+
+
+
ACCEPT
+ loc
+ fw
+ tcp
+ 80
+ #Allow web access
+ from the local network
+
+
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
+
ACTION
- SOURCE
- DESTINATION
- PROTOCOL
- PORT
- SOURCE PORT
- ORIGINAL ADDRESS
-
-
-
-
+ ACCEPT
- net
- fw
- tcp
- 22
-
-
- ACTION
+ SOURCE
+ DESTINATION
+ PROTOCOL
+ PORT
+ SOURCE PORT
+ ORIGINAL ADDRESS
+
+
+
+
+
ACCEPT
+ net
+ fw
+ tcp
+ 22
+
+
+
+
+
+
+
-
-
- Now edit your /etc/shorewall/rules file to add or delete other
+ Now edit your /etc/shorewall/rules file to add or delete other
connections as required.
-
-
-Starting and Stopping Your Firewall
+
+
+
+
+Starting and Stopping Your Firewall
+
+
+
- The installation procedure configures
- your system to start Shorewall at system boot but beginning with Shorewall
-version 1.3.9 startup is disabled so that your system won't try to start
-Shorewall before configuration is complete. Once you have completed configuration
-of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.
-
+
+
-
+
-
-
-
-
-
+
+
-
-
- The two-interface sample assumes that you want to enable routing
- to/from eth1 (the local network) when Shorewall is stopped. If
- your local network isn't connected to eth1 or if you wish to enable
+ The two-interface sample assumes that you want to enable routing
+ to/from eth1 (the local network) when Shorewall is stopped. If
+your local network isn't connected to eth1 or if you wish to enable
access to/from other hosts, change /etc/shorewall/routestopped accordingly.
-
-
-
+
+
+
+
+
+
diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm
index 7f5c39572..9e63663a9 100755
--- a/Shorewall-docs/upgrade_issues.htm
+++ b/Shorewall-docs/upgrade_issues.htm
@@ -1,165 +1,176 @@
-
+
-
-
-
+
-
+
+
+
-
-
+
+
+
+
- Upgrade Issues
- Version 1.3.10
+If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to version
+1.3.10, you will need to use the '--force' option:
+
+
+
+rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
+Version >= 1.3.9
+ The 'functions' file has moved to /usr/lib/shorewall/functions. If you
+have an application that uses functions from that file, your application
+will need to be changed to reflect this change of location.
+
Version >= 1.3.8
-
-Version >= 1.3.7
-
- run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
-
-
run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPTUpgrading Bering to
- Shorewall >= 1.3.3
-
-Upgrading Bering to
+ Shorewall >= 1.3.3
+
+
-
+
+
+
+
+# Bering specific rules:
+
# allow loc to fw udp/53 for dnscache to work
# allow loc to fw tcp/80 for weblet to work
#
ACCEPT loc fw udp 53
ACCEPT loc fw tcp 80Version 1.3.6 and 1.3.7
+
+
+
-
-
+
+ run_iptables -A newnotsyn -j RETURN #
+So that the connection tracking table can be rebuilt
+ # from non-SYN packets
+ after takeover.
+
+
+ run_iptables -A common -p tcp --tcp-flags
+ ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
+
+ #tracking table.
+ . /etc/shorewall/common.def
-
-
-# Bering specific rules:
-
# allow loc to fw udp/53 for dnscache to work
# allow loc to fw tcp/80 for weblet to work
#
ACCEPT loc fw udp 53
ACCEPT loc fw tcp 80Version 1.3.6 and 1.3.7
-
-
-
-
+
-
- run_iptables -A newnotsyn -j RETURN # So
-that the connection tracking table can be rebuilt
- # from non-SYN packets after
-takeover.
-
-
- run_iptables -A common -p tcp --tcp-flags
- ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection
-
- #tracking table.
- . /etc/shorewall/common.def Versions >= 1.3.5
-
-
+
+
+
-
+ ACCEPT net loc:192.168.1.12:22 tcp 11111 - all
-
+
+
+
-
- DNAT net loc:192.168.1.12:22 tcp 11111
-
+
+
+
-
-
+
+
+
-
- ACCEPT loc fw::3128 tcp 80 - all
-
+
+
+
-
-
+
+
+
-
+ REDIRECT loc 3128 tcp 80
- Version >= 1.3.2
-
-
-
+
+
+
- 
- 
-
-
-
-