- .| - + |
+
+
Shorewall 1.3 Reference- |
-
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: + tcpflags (added in version 1.3.11) - This option causes
Shorewall to make sanity checks on the header flags in TCP packets arriving
on this interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH;
@@ -257,948 +278,1062 @@ these flag combinations are typically used for "silent" port scans. Packets
failing these checks are logged according to the TCP_FLAGS_LOG_LEVEL option
in /etc/shorewall/shorewall.conf and are disposed of
according to the TCP_FLAGS_DISPOSITION option.
-
- 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 - FAQ 14.
+ 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 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, 0000080A...) 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.
-
- maclist (Added in version 1.3.10) - If this option is specified,
- all connection requests from this interface are subject to MAC Verification. May only be specified for
- ethernet interfaces.
My recommendations concerning options:
-
- +
Example 1: You have a conventional firewall setup in which eth0 connects - to a Cable or DSL modem and eth1 connects to your local network and - eth0 gets its IP address via DHCP. You want to 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 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:
+ would be as follows: + +-- + ++- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- + +net -ppp0 -- - + +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +net +eth0 +detect +dhcp,noping,norfc1918,blacklist ++ - + - +loc +eth1 +detect ++
+
Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces + file would be:
+ + ++ ++ ++ +
++ +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 -- + +ZONE +INTERFACE +BROADCAST +OPTIONS ++ - + +loc +eth1 + +192.168.1.255,192.168.12.255 ++
+
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:
- +- + +- + +-
- -- An IP address (example - eth1:192.168.1.3)
+- An IP address (example - eth1:192.168.1.3)
-- A subnet in CIDR notation - (example - eth2:192.168.2.0/24)
+- A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
- + +The interface name much match an entry in /etc/shorewall/interfaces.
-
The interface name much match an entry in /etc/shorewall/interfaces.
+ + +- + ++ 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 variable carefully.
+ 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.
- - -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.
- - -This file is used to describe the firewall policy regarding establishment - of connections. Connection establishment is described in terms of -clients who initiate connections and servers who receive - those connection requests. Policies defined in /etc/shorewall/policy -describe which zones are allowed to establish connections with other -zones.
- - -Policies established in /etc/shorewall/policy can be viewed as default - policies. If no rule in /etc/shorewall/rules applies to a particular - connection request then the policy from /etc/shorewall/policy is applied.
- - -Four policies are defined:
- - -For each policy specified in /etc/shorewall/policy, you can indicate - that you want a message sent to your system log each time that the - policy is applied.
- - -Entries in /etc/shorewall/policy have four columns as follows:
- - -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 --
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.
- -- -- -- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- -loc -all -ACCEPT -- - - -net -all -DROP -info -- - - - - - - - -loc -loc -REJECT -info --
Where zones are nested or overlapping , the - CONTINUE policy allows hosts that are within multiple zones to be managed - under the rules of all of these zones. Let's look at an example:
- -/etc/shorewall/zones:
- -- -- -- +
-- -ZONE -DISPLAY -COMMENTS -- -sam -Sam -Sam's system at home -- -net -Internet -The Internet -- +loc -Loc -Local Network -ZONE +INTERFACE +BROADCAST +OPTIONS + ++ +net +eth0 +detect +dhcp,noping,norfc1918 ++ - +- +eth1 +detect ++
+
/etc/shorewall/interfaces:
- -- ++ + +
The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.
+ + +Your /etc/shorewall/hosts file might look like:
+ + ++ +- -- +
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -- -eth0 -detect -dhcp,noping,norfc1918 -- +loc -eth1 -detect -routestopped -ZONE +HOST(S) +OPTIONS + ++ +loc1 +eth1:192.168.1.0/25 ++
++ + -loc2 +eth1:192.168.1.128/25 +routestopped +
/etc/shorewall/hosts:
- -- ++ + +
Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.
+ + +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.
+ + +This file is used to describe the firewall policy regarding establishment + of connections. Connection establishment is described in terms + of clients who initiate connections and servers who + receive those connection requests. Policies defined in /etc/shorewall/policy + describe which zones are allowed to establish connections with other + zones.
+ + +Policies established in /etc/shorewall/policy can be viewed as default + policies. If no rule in /etc/shorewall/rules applies to a particular + connection request then the policy from /etc/shorewall/policy is + applied.
+ + +Four policies are defined:
+ + +For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time that + the policy is applied.
+ + +Entries in /etc/shorewall/policy have four columns as follows:
+ + +In the SOURCE and DEST columns, you can enter "all" to indicate all + zones.
+ + +The policy file installed by default is as follows:
+ + ++ +- -- +
-- -ZONE -HOST(S) -OPTIONS -- -net -eth0:0.0.0.0/0 -- - +sam -eth0:206.191.149.197 -routestopped -SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST + ++ +loc +net +ACCEPT ++ +
++
++ +net +all +DROP +info ++
++ - + +all +all +REJECT +info ++
+
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:
- -+ + ++ + +This table may be interpreted as follows:
+ + ++
+ +- All connection requests from the local network +to hosts on the internet are accepted.
+- All connection requests originating from the internet + are ignored and logged at level KERNEL.INFO.
+- All other connection requests are rejected and +logged.
+ +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.
+ +- +- -- +
-- -SOURCE -DEST -POLICY -LOG LEVEL -- +loc -net -ACCEPT -- SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST + ++ loc +all +ACCEPT ++
++
+- -sam -all -CONTINUE -- - -net -all -DROP -info -- +all -all -REJECT -info -net +all +DROP +info ++ +
++ - + +loc +loc +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:
- -- ++ ++ 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:
+ ++- -- +
-- -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 +DISPLAY +COMMENTS + ++ +sam +Sam +Sam's system at home ++ +net +Internet +The Internet ++ - + +loc +Loc +Local Network +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:
- +
/etc/shorewall/interfaces:
+ +- -+ + +- + +
+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +- +eth0 +detect +dhcp,noping,norfc1918 ++ + + + + + + + + +loc +eth1 +detect +routestopped +
/etc/shorewall/hosts:
+ + ++ ++ + ++ +
++ +ZONE +HOST(S) +OPTIONS ++ + +net +eth0:0.0.0.0/0 ++
++ + + + + + + + +sam +eth0:206.191.149.197 +routestopped +
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:
+ + +- +- + + + +- -
-- -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 @@ -1207,428 +1342,460 @@ is sam and if there is no match then the connection request should 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.
-
Shorewall automatically enables firewall->firewall traffic over the
- loopback interface (lo) -- that traffic cannot be regulated using rules
-and any rule that tries to regulate such traffic will generate a warning
-and will be ignored.
-
Entries in the file have the following columns:
- +The ACTION may optionally be followed by ":" and a syslog
-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 NAT enabled.
-
The ACTION may optionally be followed by ":" and a syslog 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
+ 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. + - +- ++ - +- -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- + + +DNAT -net -loc:192.168.1.3 -tcp -ssh -- - + +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.
+ 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- -REDIRECT -loc -3128 -tcp -www -- !206.124.146.177 -- +ACCEPT -fw -net -tcp -www -- - + +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:
- - - -- -+ + + + +passive ports 0.0.0.0/0 65500 65534
-
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:
+ + + ++ + + ++ + +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 @@ -1636,101 +1803,190 @@ appropriate:
02:00:08:E3:FA:55. - +- ++ - Example 6. You wish - to allow access to the SMTP server in your DMZ from all zones.- -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- + + +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 ++
++
++
+
-+ + +- -
+- -ACTION -
-SOURCE -
-DEST -
-PROTO -
-DEST -
- PORTS(S)
-SOURCE -
- PORT(S)
-ORIGINAL -
- DEST
-- + Example 6. + You wish to allow access to the SMTP server in your DMZ from all zones.ACCEPT -
-all -
-dmz -
-tcp -
-25 -
--
--
-
- ++- ++ +
-+ +ACTION +
+SOURCE +
+DEST +
+PROTO +
+DEST +
+ PORT(S)
+SOURCE +
+ PORT(S)
+ORIGINAL +
+ DEST
++ + +ACCEPT +
+all +
+dmz +
+tcp +
+25 +
++
++
+
- Note: When 'all' is used as a source or destination, intra-zone traffic - is not affected. In this example, if there were two DMZ interfaces then the - above rule would NOT enable SMTP traffic between hosts on these interfaces.
+ Note: When 'all' is used as a source or destination, intra-zone + traffic is not affected. In this example, if there were two DMZ interfaces + then the above rule would NOT enable SMTP traffic between hosts on these + interfaces.
+ + Example 7 (For advanced users running Shorewall version 1.3.13 +or later). From the internet, you with to forward tcp port 25 directed + to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You also + want to allow access from the internet directly to tcp port 25 on 192.0.2.177. +
+ +++ Using "DNAT-" rather than "DNAT" avoids two extra copies of the third + rule from being generated.+ +
++ +ACTION +
+SOURCE +
+DEST +
+PROTO +
+DEST +
+ PORT(S)
+SOURCE +
+ PORT(S)
+ORIGINAL +
+ DEST
++ +DNAT- +
+net +
+dmz:192.0.2.177 +
+tcp +
+25 +
+0 +
+192.0.2.178 +
++ +DNAT- +
+net +
+dmz:192.0.2.177 +
+tcp +
+25 +
+0 +
+192.0.2.179 +
++ + + +ACCEPT +
+net +
+dmz:192.0.2.177 +
+tcp +
+25 +
++
++
+
+Look here for information on other services.
- +/etc/shorewall/common
- +Shorewall allows definition of rules that apply between all zones. @@ -1740,167 +1996,177 @@ appropriate:
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. - +/etc/shorewall/masq
- +The /etc/shorewall/masq file is used to define classical IP Masquerading - and Source Network Address Translation (SNAT). There is one entry in - the file for each subnet that you want to masquerade. In order to make - use of this feature, you must have NAT enabled - .
+ 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:
- +-
- -- INTERFACE - The interface that will masquerade - the subnet; this is normally your internet interface. This interface - name can be optionally qualified by adding ":" and a subnet or host - IP. When this qualification is added, only packets addressed to -that host or subnet will be masqueraded.
-- SUBNET - The subnet that you want to have masqueraded - through the INTERFACE. This may be expressed as a single IP address, - a subnet or an interface name. In the latter instance, the interface - must be configured and started before Shorewall is started as Shorewall - will determine the subnet based on information obtained from the 'ip' - utility.
-
-
- The subnet may be optionally followed by "!' and a comma-separated - list of addresses and/or subnets that are to be excluded from masquerading.- ADDRESS - The source address to be used for -outgoing packets. This column is optional and if left blank, the current - primary IP address of the interface in the first column is used. If -you have a static IP on that interface, listing it here makes processing -of output packets a little less expensive for the firewall.
- +- INTERFACE - The interface that will +masquerade the subnet; this is normally your internet interface. +This interface name can be optionally qualified by adding ":" +and a subnet or host IP. When this qualification is added, only +packets addressed to that host or subnet will be masqueraded.
+- SUBNET - The subnet that you want to +have masqueraded through the INTERFACE. This may be expressed +as a single IP address, a subnet or an interface name. In the latter + instance, the interface must be configured and started before Shorewall + is started as Shorewall will determine the subnet based on information + obtained from the 'ip' utility.
+
+
+ The subnet may be optionally followed by "!' and + a comma-separated list of addresses and/or subnets that are to be + excluded from masquerading.- ADDRESS - The source address to be used + for outgoing packets. This column is optional and if left blank, + the current primary IP address of the interface in the first column + is used. If you have a static IP on that interface, listing it here + makes processing of output packets a little less expensive for +the firewall. If you specify an address in this column, it must be an IP +address configured on the INTERFACE or you must have ADD_SNAT_ALIASES enabled +in /etc/shorewall/shorewall.conf.
+Example 1: You have eth0 connected to a cable modem and eth1 - connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq - file would look like:
- - -- -- - -- - -
-- -INTERFACE -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 1: You have eth0 connected to a cable modem and eth1 + connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq + file would look like:
+ + ++ +- -+ + +
++ +INTERFACE +SUBNET +ADDRESS ++ + + + + + + + + + +eth0 +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 eth1. You - want all local->net - connections to use - source address - 206.124.146.176.
-+- +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 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 @@ -1910,36 +2176,39 @@ to eth1. You 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 +/etc/shorewall/proxyarp
- + +If you want to use proxy ARP on an entire sub-network, @@ -1948,30 +2217,31 @@ to eth1. You http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - If you decide - to use -the technique - described in that - HOWTO, you can set - the proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by including - the proxyarp - option in - the interface's - record in - - /etc/shorewall/interfaces. - When using Proxy ARP - sub-netting, you do - NOT include - any entries in - /etc/shorewall/proxyarp. -
+ If you + decide to use + the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by including + the +proxyarp option + in the interface's + record in + + /etc/shorewall/interfaces. + When using Proxy ARP + sub-netting, +you do NOT +include any entries +in /etc/shorewall/proxyarp. + - + +The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for @@ -1979,48 +2249,51 @@ the technique on a small set of systems since you need one entry - in this -file for each - system using proxy - ARP. Columns are:
- + in this + file for each + system using proxy + ARP. Columns are: +-
- +- ADDRESS - address of the system.
-- INTERFACE - the interface that connects to the - system. If the interface is obvious from the subnetting, you may - enter "-" in this column.
-- EXTERNAL - the external interface that you want - to honor ARP requests for the ADDRESS specified in the first column.
-- HAVEROUTE - If - you already have - a route through - INTERFACE to - ADDRESS, this - column should - contain - "Yes" - or - "yes". - If you want - Shorewall to add - the route, the - column should - contain - "No" +
- ADDRESS - address of the system.
+- INTERFACE - the interface that connects + to the system. If the interface is obvious from the subnetting, + you may enter "-" in this column.
+- EXTERNAL - the external interface that + you want to honor ARP requests for the ADDRESS specified in +the first column.
+- HAVEROUTE - If + you already have + a route through + INTERFACE to + ADDRESS, this + column should + contain + "Yes" or - "no".
- + "yes". + If you want + Shorewall to add + the route, + the +column should + contain + "No" + or + "no". +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 @@ -2029,95 +2302,104 @@ 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: +-
- + +- eth0 - 155.186.235.1 (internet connection)
-- eth1 - 192.168.9.0/24 (masqueraded local systems)
-- eth2 - 192.168.10.1 (interface to your DMZ)
- +- eth0 - 155.186.235.1 (internet connection)
+- eth1 - 192.168.9.0/24 (masqueraded local systems)
+- eth2 - 192.168.10.1 (interface to your DMZ)
+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
- + +qt service ipsec stop
+In /etc/shorewall/start, include:
- -qt service ipsec start
+ +qt service ipsec start
- +/etc/shorewall/nat
- + +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 @@ -2129,642 +2411,681 @@ files.
static NAT. Port forwarding can be accomplished - with simple - entries in - the - rules file. - Also, in most - cases - - Proxy ARP - provides a - superior solution - to static NAT - because the - internal systems - are accessed using - the same IP - address internally - and externally. + with + simple entries in + the + + rules file. + Also, in most + cases + + Proxy ARP + provides a + superior solution + to static NAT + because the + internal systems + are accessed using + the same +IP address +internally + and externally. - + +Columns in an entry are:
- +-
- +- EXTERNAL - External IP address - This should - NOT be the primary IP address of the interface named in the next -column.
-- INTERFACE - Interface that you want the EXTERNAL - IP address to appear on.
-- INTERNAL - Internal IP address.
-- ALL - INTERFACES - - If Yes - or yes (or - left - empty), - NAT will - be - effective - from -all - hosts. If - No or no - then NAT - will be - effective - only - through - the - interface - named in - the - INTERFACE - column. - Note: If two or more NATed systems are connected to the -same firewall interface and you want them to be able to communicate -using their EXTERNAL IP addresses, then you will want to specify the - multi option in the /etc/shorewall/interface -entry for that interface.
-- LOCAL - If Yes or yes and the ALL INTERFACES column - contains Yes or yes, NAT will be effective from the firewall system. - Note: For this to work, you must be running kernel -2.4.19 or later and iptables 1.2.6a or later and you must have enabled - CONFIG_IP_NF_NAT_LOCAL in your kernel.
- +- EXTERNAL - External IP address - This + should NOT be the primary IP address of the interface named in + the next column.
+- INTERFACE - Interface that you want +the EXTERNAL IP address to appear on.
+- INTERNAL - Internal IP address.
+- ALL + INTERFACES + - If Yes + or yes (or + left + empty), + NAT will + be + effective + from + all + hosts. If + No or no + then NAT + will be + effective + only + through + the + interface + named in + the + INTERFACE + column. + Note: If two or more NATed systems are connected to + the same firewall interface and you want them to be able to communicate + using their EXTERNAL IP addresses, then you will want to specify +the multi option in the /etc/shorewall/interface + entry for that interface.
+- LOCAL - If Yes or yes and the ALL INTERFACES + column contains Yes or yes, NAT will be effective from the firewall + system. Note: For this to work, you must be running + kernel 2.4.19 or later and iptables 1.2.6a or later and you must + have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel.
+Look here for additional information and an example. -
- + + +/etc/shorewall/tunnels
- +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.
+ 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, instructions for IPIP -and GRE tunnels are here and instructions - for PPTP tunnels are here.
- + be found here, instructions for IPIP + and GRE tunnels are here and instructions + for PPTP tunnels are here. +/etc/shorewall/shorewall.conf
- +This file is used to set the following firewall parameters:
- +-
- + +- MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
-If your kernel has a FORWARD chain in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes -to cause the marking specified in the tcrules file to occur in that chain -rather than in the PREROUTING chain. This permits you to mark inbound traffic -based on its destination address when SNAT or Masquerading are in use. To -determine if your kernel has a FORWARD chain in the mangle table, use the -"/sbin/shorewall show mangle" command; if a FORWARD chain is displayed then -your kernel will support this option. If this option is not specified or -if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No -is assumed.
+- CLEAR_TC - Added at version 1.3.13
-
+ If this option is set to 'No' then Shorewall won't clear the current traffic +control rules during [re]start. This setting is intended for use by people +that prefer to configure traffic shaping when the network interfaces come +up rather than when the firewall is started. If that is what you want to +do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart +file. That way, your traffic shaping rules can still use the 'fwmark' classifier +based on packet marking defined in /etc/shorewall/tcrules. If not specified, +CLEAR_TC=Yes is assumed.
- RFC1918_LOG_LEVEL - Added at version 1.3.12
-
- This parameter determines the level at which packets logged under the 'norfc1918' -mechanism are logged. The value must be a valid syslog -level and if no level is given, then info is assumed. Prior to Shorewall -version 1.3.12, these packets are always logged at the info level.- TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
-
-Determines the disposition of TCP packets that fail the checks enabled by - the tcpflags interface option and must have - a value of ACCEPT (accept the packet), REJECT (send an RST response) or -DROP (ignore the packet). If not set or if set to the empty value (e.g., -TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is assumed.- TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
+
- Determines the syslog -level for logging packets that fail the checks enabled by the MARK_IN_FORWARD_CHAIN - Added at version 1.3.12
+ If your kernel has a FORWARD chain in the mangle table, you may set + MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the tcrules file to occur in that chain + rather than in the PREROUTING chain. This permits you to mark inbound +traffic based on its destination address when SNAT or Masquerading are +in use. To determine if your kernel has a FORWARD chain in the mangle table, +use the "/sbin/shorewall show mangle" command; if a FORWARD chain is displayed + then your kernel will support this option. If this option is not specified + or if it is given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then +MARK_IN_FORWARD_CHAIN=No is assumed.
+- RFC1918_LOG_LEVEL - Added at version 1.3.12
+
+ This parameter determines the level at which packets logged under + the 'norfc1918' mechanism + are logged. The value must be a valid syslog + level and if no level is given, then info is assumed. Prior to Shorewall + version 1.3.12, these packets are always logged at the info level.- TCP_FLAGS_DISPOSITION - Added in Version 1.3.11
+
+ Determines the disposition of TCP packets that fail the checks enabled + by the tcpflags interface option and must + have a value of ACCEPT (accept the packet), REJECT (send an RST response) + or DROP (ignore the packet). If not set or if set to the empty value +(e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP is +assumed.- TCP_FLAGS_LOG_LEVEL - Added in Version 1.3.11
-
+ Determines the syslog level + for logging packets that fail the checks enabled by the tcpflags interface option.The value must be a valid -syslogd log level. If you don't want to log these packets, set to the empty -value (e.g., TCP_FLAGS_LOG_LEVEL="").
-- MACLIST_DISPOSITION - Added in Version 1.3.10
-
- Determines the disposition of connections requests that fail MAC Verification and must have the value ACCEPT -(accept the connection request anyway), REJECT (reject the connection request) -or DROP (ignore the connection request). If not set or if set to the empty -value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT is assumed.- MACLIST_LOG_LEVEL - Added in Version 1.3.10
+
- Determines the syslog -level for logging connection requests that fail +- MACLIST_DISPOSITION - Added in Version 1.3.10
+
+ Determines the disposition of connections requests that fail + MAC Verification and must have the +value ACCEPT (accept the connection request anyway), REJECT (reject the connection + request) or DROP (ignore the connection request). If not set or if set to + the empty value (e.g., MACLIST_DISPOSITION="") then MACLIST_DISPOSITION=REJECT + is assumed.- MACLIST_LOG_LEVEL - Added in Version 1.3.10
-
+ Determines the syslog level + for logging connection requests that fail MAC Verification. The value must be a valid -syslogd log level. If you don't want to log these connection requests, set -to the empty value (e.g., MACLIST_LOG_LEVEL="").
-- NEWNOTSYN - Added in Version 1.3.8
-
- When set to "Yes" or "yes", Shorewall will filter TCP packets that - are not part of an established connention and that are not SYN packets - (SYN flag on - ACK flag off). If set to "No", Shorewall will silently -drop such packets. If not set or set to the empty value (e.g., "NEWNOTSYN="), - NEWNOTSYN=No is assumed.
-
- If you have a HA setup with failover to another firewall, you should - have NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes - if you have asymmetric routing.
-- FORWARDPING - Added in Version 1.3.7
-
- When set to "Yes" or "yes", ICMP echo-request (ping) packets - from interfaces that specify "filterping" are ACCEPTed by the firewall. - When set to "No" or "no", such ping requests are silently dropped -unless they are handled by an explicit entry in the rules file. If not specified, "No" is assumed.- LOGNEWNOTSYN - Added in Version 1.3.6
-
- Beginning with version 1.3.6, Shorewall drops non-SYN TCP -packets that are not part of an existing connection. If you would -like to log these packets, set LOGNEWNOTSYN to the syslog -level at which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|
-
- Note: Packets logged under this option are usually -the result of broken remote IP stacks rather than the result of -any sort of attempt to breach your firewall.
-- MERGE_HOSTS - Added in Version 1.3.5
+
- Prior to 1.3.5, when the /etc/shorewall/hosts - file included an entry for a zone then the entire zone had to be -defined in the /etc/shorewall/hosts file and any associations between -the zone and interfaces in the /etc/shorewall/interfaces - file were ignored. This behavior is preserved if MERGE_HOSTS=No or - if MERGE_HOSTS is not set or is set to the empty value.
-
- Beginning with version 1.3.5, if MERGE_HOSTS=Yes, then zone - assignments in the /etc/shorewall/hosts file are ADDED to those -in the /etc/shorewall/interfaces file.
-
- Example:
-
- Interfaces File:
- + syslogd log level. If you don't want to log these connection requests, + set to the empty value (e.g., MACLIST_LOG_LEVEL="").
+- NEWNOTSYN - Added in Version 1.3.8
+
+ When set to "Yes" or "yes", Shorewall will filter TCP packets + that are not part of an established connention and that are not SYN + packets (SYN flag on - ACK flag off). If set to "No", Shorewall will +silently drop such packets. If not set or set to the empty value (e.g., +"NEWNOTSYN="), NEWNOTSYN=No is assumed.
+
+ If you have a HA setup with failover to another firewall, + you should have NEWNOTSYN=Yes on both firewalls. You should also select + NEWNOTSYN=Yes if you have asymmetric routing.
+- FORWARDPING - Added in Version 1.3.7
+
+ When set to "Yes" or "yes", ICMP echo-request (ping) + packets from interfaces that specify "filterping" are ACCEPTed + by the firewall. When set to "No" or "no", such ping requests are + silently dropped unless they are handled by an explicit entry in + the rules file. If not specified, "No" is assumed.- LOGNEWNOTSYN - Added in Version 1.3.6
+
+ Beginning with version 1.3.6, Shorewall drops non-SYN + TCP packets that are not part of an existing connection. If +you would like to log these packets, set LOGNEWNOTSYN to the + syslog level at which you want + the packets logged. Example: LOGNEWNOTSYN=ULOG|
+
+ Note: Packets logged under this option are +usually the result of broken remote IP stacks rather than the +result of any sort of attempt to breach your firewall.
+- MERGE_HOSTS - Added in Version 1.3.5
-
+ Prior to 1.3.5, when the /etc/shorewall/hosts + file included an entry for a zone then the entire zone had to + be defined in the /etc/shorewall/hosts file and any associations + between the zone and interfaces in the /etc/shorewall/interfaces + file were ignored. This behavior is preserved if MERGE_HOSTS=No + or if MERGE_HOSTS is not set or is set to the empty value.
+
+ Beginning with version 1.3.5, if MERGE_HOSTS=Yes, +then zone assignments in the /etc/shorewall/hosts file are ADDED +to those in the /etc/shorewall/interfaces file.
+
+ Example:
+
+ Interfaces File:
+ +- -
- + +- -ZONE -HOSTS -BROADCAST -OPTIONS -- -loc -eth1 -- -dhcp -- + +- -ppp+ -- - + +ZONE +HOSTS +BROADCAST +OPTIONS ++ +loc +eth1 +- +dhcp ++ - - + + + +- +ppp+ ++
++
+- + Hosts File:
- Hosts File:
-
+ + +- -
- + +- -ZONE -HOSTS -- + +loc -ppp+:192.168.12.0/24 -+ +ZONE +HOSTS ++ - - + + + +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.
-- DETECT_DNAT_ADDRS - Added in Version 1.3.4
-
- If set to "Yes" or "yes", Shorewall will detect the IP address(es) - of the interface(es) to the source zone and will include this (these) -address(es) in DNAT rules as the original destination IP address. If set -to "No" or "no", Shorewall will not detect this (these) address(es) and -any destination IP address will match the DNAT rule. If not specified or -empty, "DETECT_DNAT_ADDRS=Yes" is assumed.
-- MULTIPORT - Added in Version 1.3.2
+
- If set to "Yes" or "yes", Shorewall will use the Netfilter -multiport facility. In order to use this facility, your kernel must -have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). When this -support is used, Shorewall will generate a single rule from each record -in the /etc/shorewall/rules file that meets these criteria:
- + 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.
+ +- DETECT_DNAT_ADDRS - Added in Version 1.3.4
+
+ If set to "Yes" or "yes", Shorewall will detect the IP +address(es) of the interface(es) to the source zone and will include +this (these) address(es) in DNAT rules as the original destination +IP address. If set to "No" or "no", Shorewall will not detect this (these) +address(es) and any destination IP address will match the DNAT rule. +If not specified or empty, "DETECT_DNAT_ADDRS=Yes" is assumed.
+- MULTIPORT - Added in Version 1.3.2
-
+ If set to "Yes" or "yes", Shorewall will use the Netfilter + multiport facility. In order to use this facility, your kernel + must have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). When + this support is used, Shorewall will generate a single rule from + each record in the /etc/shorewall/rules file that meets these criteria:
+ +-
- + +- No port range(s) specified
-- Specifies 15 or fewer ports
- +- No port range(s) specified
+- Specifies 15 or fewer ports
+ +Rules not meeting those criteria will continue to generate an individual - rule for each listed port or port range.
-- NAT_BEFORE_RULES
-
- If set to "No" or "no", port forwarding rules can override -the contents of the /etc/shorewall/nat file. If -set to "Yes" or "yes", port forwarding rules cannot override static -NAT. If not set or set to an empty value, "Yes" is assumed.- FW
+
+ rule for each listed port or port range. +- NAT_BEFORE_RULES
+
+ If set to "No" or "no", port forwarding rules can +override the contents of the /etc/shorewall/nat +file. If set to "Yes" or "yes", port forwarding rules cannot override + static NAT. If not set or set to an empty value, "Yes" is assumed.- FW
-
- This - parameter - specifies the - name of the - firewall zone. - If not set or - if set to an - empty string, - the value - "fw" - is assumed.- SUBSYSLOCK
-
- This parameter should be set to the name of a file that - the firewall should create if it starts successfully and remove - when it stops. Creating and removing this file allows Shorewall - to work with your distribution's initscripts. For RedHat, this - should be set to /var/lock/subsys/shorewall. For Debian, the value - is /var/state/shorewall and in LEAF it is - /var/run/shorwall. - Example: SUBSYSLOCK=/var/lock/subsys/shorewall.- STATEDIR
-
- This parameter specifies the name of a directory where - Shorewall stores state information. If the directory doesn't -exist when Shorewall starts, it will create the directory. Example: -STATEDIR=/tmp/shorewall.
-
- NOTE: If you change the STATEDIR variable while the -firewall is running, create the new directory if necessary then copy -the contents of the old directory to the new directory.- ALLOWRELATED
-
- This parameter must be assigned the value "Yes" - ("yes") or "No" ("no") and specifies whether Shorewall allows - connection requests that are related to an already allowed connection. - If you say "No" ("no"), you can still override this setting by -including "related" rules in /etc/shorewall/rules ("related" given -as the protocol). If you specify ALLOWRELATED=No, you will need to -include rules in /etc/shorewall/icmpdef -to handle common ICMP packet types.- MODULESDIR
-
- This parameter specifies the directory where your kernel - netfilter modules may be found. If you leave the variable empty, - Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.- LOGRATE and LOGBURST
-
- These parameters set the match rate and initial burst - size for logged packets. Please see the iptables man page for a -description of the behavior of these parameters (the iptables option ---limit is set by LOGRATE and --limit-burst is set by LOGBURST). If -both parameters are set empty, no rate-limiting will occur.
-
- Example:
- LOGRATE=10/minute
- LOGBURST=5
-- LOGFILE
+
+ This + parameter + specifies the + name of the + firewall zone. + If not set or + if set to an + empty string, + the +value + "fw" + is assumed.- SUBSYSLOCK
+
+ This parameter should be set to the name of +a file that the firewall should create if it starts successfully + and remove when it stops. Creating and removing this file allows + Shorewall to work with your distribution's initscripts. For +RedHat, this should be set to /var/lock/subsys/shorewall. For +Debian, the value is /var/state/shorewall and in LEAF it is + /var/run/shorwall. + Example: + SUBSYSLOCK=/var/lock/subsys/shorewall.- STATEDIR
+
+ This parameter specifies the name of a directory + where Shorewall stores state information. If the directory + doesn't exist when Shorewall starts, it will create the directory. + Example: STATEDIR=/tmp/shorewall.
+
+ NOTE: If you change the STATEDIR variable while + the firewall is running, create the new directory if necessary + then copy the contents of the old directory to the new directory. +- ALLOWRELATED
+
+ This parameter must be assigned the value "Yes" + ("yes") or "No" ("no") and specifies whether Shorewall +allows connection requests that are related to an already allowed +connection. If you say "No" ("no"), you can still override this +setting by including "related" rules in /etc/shorewall/rules ("related" + given as the protocol). If you specify ALLOWRELATED=No, you will +need to include rules in /etc/shorewall/icmpdef to + handle common ICMP packet types.- MODULESDIR
+
+ This parameter specifies the directory where +your kernel netfilter modules may be found. If you leave the +variable empty, Shorewall will supply the value "/lib/modules/`uname + -r`/kernel/net/ipv4/netfilter.- LOGRATE and LOGBURST
+
+ These parameters set the match rate and initial + burst size for logged packets. Please see the iptables man page + for a description of the behavior of these parameters (the iptables + option --limit is set by LOGRATE and --limit-burst is set by LOGBURST). + If both parameters are set empty, no rate-limiting will occur.
+
+ Example:
+ LOGRATE=10/minute
+ LOGBURST=5
+- LOGFILE
-
- This parameter - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when - processing the - "show - log", - "monitor", - "status" - and - "hits" - commands. If - not assigned - or if -assigned - an empty - value, - /var/log/messages - is assumed.- NAT_ENABLED
-
- This parameter determines whether Shorewall supports -NAT operations. NAT operations include:
-
- Static NAT
- Port Forwarding
- Port Redirection
- Masquerading
-
- If the parameter has no value or has a value of "Yes" - or "yes" then NAT is enabled. If the parameter has a value of - "no" or "No" then NAT is disabled.
-- MANGLE_ENABLED
-
- This parameter determines if packet mangling is enabled. - If the parameter has no value or has a value of "Yes" or "yes" - than packet mangling is enabled. If the parameter has a value of -"no" or "No" then packet mangling is disabled. If packet mangling is - disabled, the /etc/shorewall/tos file is ignored.
-- IP_FORWARDING
-
- This parameter determines whether Shorewall enables -or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). - Possible values are:
-
- On or on - packet forwarding will be enabled.
- Off or off - packet forwarding will be disabled.
- Keep or keep - Shorewall will neither enable nor - disable packet forwarding.
-
- If this variable is not set or is given an empty value - (IP_FORWARD="") then IP_FORWARD=On is assumed.
-- ADD_IP_ALIASES
-
- This parameter determines whether Shorewall automatically - adds the - external address(es) in /etc/shorewall/nat - . If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these aliases. If it is set to "No" or "no", you must - add these aliases yourself using your distribution's network configuration - tools.
-
- If this variable is not set or is given an empty value - (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.- ADD_SNAT_ALIASES
-
- This parameter determines whether Shorewall automatically -adds the SNAT ADDRESS in /etc/shorewall/masq. - If the variable is set to "Yes" or "yes" then Shorewall automatically - adds these addresses. If it is set to "No" or "no", you must add these - addresses yourself using your distribution's network configuration - tools.
-
- If this variable is not set or is given an empty value - (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.
-- LOGUNCLEAN
-
- - This parameter - determines the - logging level - of - mangled/invalid - packets - controlled by - the 'dropunclean + This parameter + tells the + /sbin/shorewall + program where + to look for + Shorewall + messages when + processing the + "show + log", + "monitor", + "status" and -logunclean' - interface - options. If - LOGUNCLEAN is - empty - (LOGUNCLEAN=) - then packets - selected - by 'dropclean' - are dropped - silently - ('logunclean' - packets - are logged - under - the 'info' log - level). - Otherwise, - these packets - are logged at - the specified - level - (Example: - LOGUNCLEAN=debug).- BLACKLIST_DISPOSITION
+
+ "hits" + commands. + If not + assigned + or if assigned + an empty + value, + /var/log/messages + is assumed.- NAT_ENABLED
+
+ This parameter determines whether Shorewall +supports NAT operations. NAT operations include:
+
+ Static NAT
+ Port Forwarding
+ Port Redirection
+ Masquerading
+
+ If the parameter has no value or has a value +of "Yes" or "yes" then NAT is enabled. If the parameter has a +value of "no" or "No" then NAT is disabled.
+- MANGLE_ENABLED
+
+ This parameter determines if packet mangling +is enabled. If the parameter has no value or has a value of +"Yes" or "yes" than packet mangling is enabled. If the parameter +has a value of "no" or "No" then packet mangling is disabled. If +packet mangling is disabled, the /etc/shorewall/tos file is ignored.
+- IP_FORWARDING
+
+ This parameter determines whether Shorewall +enables or disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward). + Possible values are:
+
+ On or on - packet forwarding will be enabled.
+ Off or off - packet forwarding will be disabled.
+ Keep or keep - Shorewall will neither enable + nor disable packet forwarding.
+
+ If this variable is not set or is given an empty + value (IP_FORWARD="") then IP_FORWARD=On is assumed.
+- ADD_IP_ALIASES
+
+ This parameter determines whether Shorewall automatically + adds the + external address(es) in /etc/shorewall/nat + . If the variable is set to "Yes" or "yes" then Shorewall +automatically adds these aliases. If it is set to "No" or +"no", you must add these aliases yourself using your distribution's +network configuration tools.
+
+ If this variable is not set or is given an empty + value (ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.- ADD_SNAT_ALIASES
+
+ This parameter determines whether Shorewall automatically + adds the SNAT ADDRESS in /etc/shorewall/masq. + If the variable is set to "Yes" or "yes" then Shorewall automatically + adds these addresses. If it is set to "No" or "no", you must add + these addresses yourself using your distribution's network configuration + tools.
+
+ If this variable is not set or is given an empty + value (ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is +assumed.
+- LOGUNCLEAN
-
- This parameter - determines the - disposition of - packets from - blacklisted - hosts. It may - have the value - DROP if the - packets are - to be -dropped or - REJECT if the - packets are to - be replied - with an ICMP - port - unreachable - reply or a TCP - RST (tcp - only). If you - do not assign - a value or if - you assign -an empty -value then -DROP is -assumed.- BLACKLIST_LOGLEVEL
+
+ This parameter + determines the + logging level + of + mangled/invalid + packets + controlled by + the 'dropunclean + and logunclean' + interface + options. If + LOGUNCLEAN + is empty + (LOGUNCLEAN=) + then + packets + selected by + 'dropclean' are + dropped + silently + ('logunclean' + packets are + logged under + the 'info' log + level). + Otherwise, + these +packets + are logged at + the specified + level + (Example: + LOGUNCLEAN=debug).- BLACKLIST_DISPOSITION
-
- This paremter - determines if - packets from - blacklisted - hosts are - logged and it - determines the - syslog level - that they are - to be logged - at. Its - value - is a syslog -level - (Example: - BLACKLIST_LOGLEVEL=debug). - If you do not - assign a value - or if you - assign an - empty value - then packets - from - blacklisted - hosts -are not - logged.- CLAMPMSS
+
+ This parameter + determines the + disposition of + packets from + blacklisted + hosts. It may + have the value + DROP if + the +packets are to + be dropped or + REJECT if the + packets are to + be replied + with an ICMP + port + unreachable + reply or a TCP + RST (tcp + only). If +you do +not assign + a value or if + you assign an + empty value + then DROP is + assumed.- BLACKLIST_LOGLEVEL
+
- This parameter - enables the - TCP Clamp MSS - to PMTU - feature of - Netfilter and - is usually - required when - your internet - connection is - through -PPPoE - or PPTP. If - set to - "Yes" - or - "yes", - the feature is - enabled. If - left blank or - set to - "No" - or - "no", - the feature is - not enabled. - Note: This - option - requires - CONFIG_IP_NF_TARGET_TCPMSS - syslog level + (Example: + BLACKLIST_LOGLEVEL=debug). + If +you do not + assign a value + or if you + assign an + empty value + then packets + from + blacklisted + hosts are not + logged.- CLAMPMSS
-
+ + This parameter + enables the + TCP Clamp MSS + to PMTU + feature of + Netfilter and + is usually + required when + your internet + connection + is through + PPPoE + or PPTP. If + set to + "Yes" + or + "yes", + the feature is + enabled. If + left blank or + set to + "No" + or + "no", + the feature is + not enabled. + Note: This + option + requires + CONFIG_IP_NF_TARGET_TCPMSS + in your kernel.- ROUTE_FILTER
- +
- If this parameter is given the value "Yes" or "yes" then route - filtering (anti-spoofing) is enabled on all network interfaces. - The default value is "no".- ROUTE_FILTER
+
+ If this parameter is given the value "Yes" or "yes" + then route filtering (anti-spoofing) is enabled on all network + interfaces. The default value is "no"./etc/shorewall/modules Configuration
- + +The file /etc/shorewall/modules contains commands for loading the kernel - modules required by Shorewall-defined firewall rules. Shorewall will - source this file during start/restart provided that it exists and that - the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).
+ 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:
- - - - +++ + + + +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:
+ + + + ++ + + ++ 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 @@ -2772,401 +3093,410 @@ it does, the function assumes that the running configuration supports compress - +
- + ++ parameters> + - +insmod moduledirectory/<modulename>.o.gz <module - parameters>
-/etc/shorewall/tos Configuration
- +The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet destination, protocol, - source port and destination port. In order for this file to be processed - by Shorewall, you must have mangle support - enabled .
+ 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:
- +-
- +- SOURCE -- The source zone. May be qualified -by following the zone name with a colon (":") and either an IP -address, an IP subnet, a MAC address in Shorewall -Format or the name of an interface. This column may also contain -the name of - the firewall - zone to indicate packets originating -on the firewall itself or "all" to indicate any source.
-- DEST -- The destination zone. May be qualified - by following the zone name with a colon (":") and either an IP address - or an IP subnet. Because packets are marked prior to routing, you - may not specify the name of an interface. This column may also -contain "all" to indicate any destination.
-- PROTOCOL -- The name of a protocol in /etc/protocols - or the protocol's number.
-- SOURCE PORT(S) -- The source port or a port -range. For all ports, place a hyphen ("-") in this column.
-- DEST PORT(S) -- The destination port or a port - range. To indicate all ports, place a hyphen ("-") in this column.
-- TOS -- The type of service. Must be one of the - following:
- +- SOURCE -- The source zone. May be qualified + by following the zone name with a colon (":") and either an + IP address, an IP subnet, a MAC address in Shorewall + Format or the name of an interface. This column may also +contain the name of + the firewall + zone to indicate packets +originating on the firewall itself or "all" to indicate any source.
+- DEST -- The destination zone. May be +qualified by following the zone name with a colon (":") and +either an IP address or an IP subnet. Because packets are marked +prior to routing, you may not specify the name of an interface. +This column may also contain "all" to indicate any destination.
+- PROTOCOL -- The name of a protocol in + /etc/protocols or the protocol's number.
+- SOURCE PORT(S) -- The source port or +a port range. For all ports, place a hyphen ("-") in this column.
+- DEST PORT(S) -- The destination port + or a port range. To indicate all ports, place a hyphen ("-") + in this column.
+- TOS -- The type of service. Must be +one of the following:
+- ++ Maximize-Throughput (8)- + +-Minimize-Delay (16)
-
- Maximize-Throughput (8)
- Maximize-Reliability (4)
- Minimize-Cost (2)
- Normal-Service (0)
+ 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. + - +/etc/shorewall/blacklist
- +Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall Format or subnet address. - Example:
+ Example: - +130.252.100.69- +
206.124.146.0/24Packets from hosts listed in - the - blacklist - file - will - be + the + blacklist + file + will + be - disposed - of - according - to - the - value + disposed + of + according + to + the - assigned - to - the BLACKLIST_DISPOSITION + value + assigned + to + the BLACKLIST_DISPOSITION - and BLACKLIST_LOGLEVEL variables - in + and BLACKLIST_LOGLEVEL variables - /etc/shorewall/shorewall.conf. - Only - packets + in + /etc/shorewall/shorewall.conf. + Only + packets - arriving - on - interfaces - that - have - the + arriving + on + interfaces + that + have - 'blacklist' - option - in + the + 'blacklist' + option - /etc/shorewall/interfaces - are - checked - against + in + /etc/shorewall/interfaces + are + checked - the - blacklist. The black list is designed to prevent listed - hosts/subnets from accessing services on your network.
- + 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:
- + +
--
- +- ADDRESS/SUBNET - As described above.
-- PROTOCOL - Optional. If specified, only packets specifying - this protocol will be blocked.
-- PORTS - Optional; may only be given if PROTOCOL is -tcp, udp or icmp. Expressed as a comma-separated list of port numbers -or service names (from /etc/services). If present, only packets destined -for the specified protocol and one of the listed ports are blocked. When -the PROTOCOL is icmp, the PORTS column contains a comma-separated list -of ICMP type numbers or names (see "iptables -h icmp").
- +
-- ADDRESS/SUBNET - As described above.
+- PROTOCOL - Optional. If specified, only packets + specifying this protocol will be blocked.
+- PORTS - Optional; may only be given if PROTOCOL + is tcp, udp or icmp. Expressed as a comma-separated list of port +numbers or service names (from /etc/services). If present, only packets +destined for the specified protocol and one of the listed ports are +blocked. When the PROTOCOL is icmp, the PORTS column contains a comma-separated + list of ICMP type numbers or names (see "iptables -h icmp").
+
+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).
- +/etc/shorewall/rfc1918 (Added in Version 1.3.1)
- +This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:
+ interface option. Columns in the file are: - +-
- +- SUBNET - The subnet using VLSM notation (e.g., - 192.168.0.0/16).
+- SUBNET - The subnet using VLSM notation + (e.g., 192.168.0.0/16).
-- TARGET - What to do with packets to/from - the SUBNET: +
- TARGET - What to do with packets + to/from the SUBNET: +
- + +-
-- RETURN - Process the packet normally thru - the rules and policies.
+- RETURN - Process the packet normally + thru the rules and policies.
-- DROP - Silently drop the packet.
+- DROP - Silently drop the packet.
-- logdrop - Log then drop the packet -- see -the RFC1918_LOG_LEVEL parameter above.
+- logdrop - Log then drop the packet + -- see the RFC1918_LOG_LEVEL parameter above.
- +/etc/shorewall/routestopped (Added in Version - 1.3.4)
+ 1.3.4) - +This file defines the hosts that are accessible from the firewall when - the firewall is stopped. Columns in the file are:
+ the firewall is stopped. Columns in the file are: - +-
- +- INTERFACE - The firewall interface through - which the host(s) comminicate with the firewall.
+- INTERFACE - The firewall interface + through which the host(s) comminicate with the firewall.
-- HOST(S) - (Optional) - A comma-separated -list of IP/Subnet addresses. If not supplied or supplied as "-" then -0.0.0.0/0 is assumed.
- +- HOST(S) - (Optional) - A comma-separated + list of IP/Subnet addresses. If not supplied or supplied as "-" then + 0.0.0.0/0 is assumed.
+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 -- +- -/etc/shorewall/maclist (Added in Version 1.3.10)
- This file is described in the MAC Validation - Documentation.
+ This file is described in the MAC Validation Documentation.
+
+ +Updated 1/13/2003 - Tom Eastep +
+ + + +Copyright © 2001, 2002, 2003 Thomas M. Eastep.
- -Updated 12/20/2002 - Tom Eastep -
- - - -Copyright - © 2001, 2002 Thomas M. Eastep.
- - - - -
-
+ +
+
+
+
diff --git a/STABLE/documentation/Documentation_Index.htm b/STABLE/documentation/Documentation_Index.htm index 60fcdafc8..f78703030 100644 --- a/STABLE/documentation/Documentation_Index.htm +++ b/STABLE/documentation/Documentation_Index.htm @@ -1,28 +1,31 @@ + - - - - - -The Documentation Index + + + + + + + + +The Documentation Index + - - - + +The Shorewall Documentation Index
-has Moved -Here
- --Last updated 8/9/2002 - - - Tom Eastep -
-- Copyright - © 2001, 2002 Thomas M. Eastep.
- + +has Moved Here
+ +Last updated 8/9/2002 - + Tom Eastep
+ +Copyright © 2001, 2002 Thomas M. Eastep.
+
+ - diff --git a/STABLE/documentation/FAQ.htm b/STABLE/documentation/FAQ.htm index 10242d846..376151c69 100644 --- a/STABLE/documentation/FAQ.htm +++ b/STABLE/documentation/FAQ.htm @@ -2,1017 +2,1088 @@ - + - + - + - +Shorewall FAQ - + - +- -
- - - -- ++ + + + - - + ++ -Shorewall FAQs
-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 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 +or MSN Instant 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?
+6b. DROP messages on port 10619 are flooding the logs with their connect +requests. Can i exclude these error messages for this port temporarily from +logging in Shorewall?
+ + + +
+8. When I try to start Shorewall + on RedHat 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!
- 17. How do I find - out why this traffic is getting logged?
-
-
- 18. Is there any way to use aliased - ip addresses with Shorewall, and maintain separate rulesets for - different IPs?
-
- 19. I have added entries to /etc/shorewall/tcrules - but they don't seem to do anything. Why?
-
- 20. I have just set up a server. Do -I have to change Shorewall to allow access to my server from the internet?
-
- 21. I see these strange log entries -occasionally; what are they?
-
- 22. I have some iptables commands that I -want to run when Shorewall starts. Which file do I put them in?
- -
-1. I want to forward UDP port 7777 to - my my personal PC with IP address 192.168.1.5. I've looked everywhere - and can't find how to do it.
- + + + + + +15. My local systems can't see + out to the net
+ +16. Shorewall is writing log messages + all over my console making it unusable!
+ 17. How do + I find out why this traffic is getting logged?
+
+
+ 18. Is there any way to use + aliased ip addresses with Shorewall, and maintain separate + rulesets for different IPs?
+
+ 19. I have added entries to +/etc/shorewall/tcrules but they don't seem to do anything. +Why?
+
+ 20. I have just set up a server. + Do I have to change Shorewall to allow access to my server from +the internet?
+
+ 21. I see these strange log entries + occasionally; what are they?
+
+ 22. I have some iptables commands that + I want to run when Shorewall starts. Which file do I put them in?
+
+ 23. Why do you use such ugly fonts on + your web site?
+
+ 24: How can I allow conections to let's +say the ssh port only from specific IP Addresses on the internet?
+ +
+1. I want to forward UDP port 7777 to + my my personal PC with IP address 192.168.1.5. I've looked +everywhere and can't find how to do it.
+Answer: The first example in the 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:
- -- + 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 ++
++
+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
- +1a. Ok -- I followed those instructions + but it doesn't work
+Answer: That is usually the result of one of two things:
- +-
- -- You are trying to test from inside your firewall - (no, that won't work -- see FAQ #2).
-- You have a more basic problem with your local - system such as an incorrect default gateway configured (it should - be set to the IP address of your firewall's internal interface).
- +- You are trying to test from inside +your firewall (no, that won't work -- see FAQ +#2).
+- You have a more basic problem with +your local system such as an incorrect default gateway configured +(it should be set to the IP address of your firewall's internal +interface).
+1b. I'm still having problems with port - forwarding
- Answer: To further diagnose this problem:
- + +1b. I'm still having problems with port + forwarding
+ Answer: To further diagnose this problem:
+-
- -- As root, type "iptables -t nat -Z". This clears the -NetFilter counters in the nat table.
-- Try to connect to the redirected port from an external - host.
-- As root type "shorewall show nat"
-- Locate the appropriate DNAT rule. It will be in a chain - called zone_dnat where zone is the zone that includes - the ('net' in the above examples).
-- Is the packet count in the first column non-zero? If -so, the connection request is reaching the firewall and is being redirected - to the server. In this case, the problem is usually a missing or incorrect - default gateway setting on the server (the server's default gateway -should be the IP address of the firewall's interface to the server).
-- If the packet count is zero:
- +- As root, type "iptables -t nat -Z". This clears + the NetFilter counters in the nat table.
+- Try to connect to the redirected port from an +external host.
+- As root type "shorewall show nat"
+- Locate the appropriate DNAT rule. It will be +in a chain called zone_dnat where zone is the +zone that includes the ('net' in the above examples).
+- Is the packet count in the first column non-zero? + If so, the connection request is reaching the firewall and is being + redirected to the server. In this case, the problem is usually +a missing or incorrect default gateway setting on the server (the +server's default gateway should be the IP address of the firewall's +interface to the server).
+- If the packet count is zero:
+ +-
- +- the connection request is not reaching your server -(possibly it is being blocked by your ISP); or
-- you are trying to connect to a secondary IP address - on your firewall and your rule is only redirecting the primary IP address - (You need to specify the secondary IP address in the "ORIG. DEST." column - in your DNAT rule); or
-- your DNAT rule doesn't match the connection request - in some other way. In that case, you may have to use a packet sniffer - such as tcpdump or ethereal to further diagnose the problem.
- +
-- the connection request is not reaching your +server (possibly it is being blocked by your ISP); or
+- you are trying to connect to a secondary IP +address on your firewall and your rule is only redirecting the primary +IP address (You need to specify the secondary IP address in the "ORIG. + DEST." column in your DNAT rule); or
+- your DNAT rule doesn't match the connection +request in some other way. In that case, you may have to use a packet +sniffer such as tcpdump or ethereal to further diagnose the problem.
+ +
+2. I port forward www requests to www.mydomain.com - (IP 130.151.100.69) to system 192.168.1.5 in my local network. - External clients can browse http://www.mydomain.com but internal - clients can't.
- + +2. I port forward www requests to www.mydomain.com + (IP 130.151.100.69) to system 192.168.1.5 in my local network. + External clients can browse http://www.mydomain.com but internal + clients can't.
+Answer: I have two objections to this setup.
- +-
- -- Having an internet-accessible server in your - local network is like raising foxes in the corner of your hen - house. If the server is compromised, there's nothing between that - server and your other internal systems. For the cost of another - NIC and a cross-over cable, you can put your server in a DMZ -such that it is isolated from your local systems - assuming that -the Server can be located near the Firewall, of course :-)
-- The accessibility problem is best solved using - Bind Version 9 "views" - (or using a separate DNS server for local clients) such that www.mydomain.com - resolves to 130.141.100.69 externally and 192.168.1.5 internally. -That's what I do here at shorewall.net for my local systems that use -static NAT.
- +- Having an internet-accessible server + in your local network is like raising foxes in the corner +of your hen house. If the server is compromised, there's nothing + between that server and your other internal systems. For the + cost of another NIC and a cross-over cable, you can put your +server in a DMZ such that it is isolated from your local systems - + assuming that the Server can be located near the Firewall, of course + :-)
+- The accessibility problem is best solved + using Bind Version + 9 "views" (or using a separate DNS server for local clients) such + that www.mydomain.com resolves to 130.141.100.69 externally and +192.168.1.5 internally. That's what I do here at shorewall.net for +my local systems that use static NAT.
+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).
- -+ +- -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 +-- -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:
-+ ++ +++ +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.
-2a. I have a zone "Z" with an RFC1918 - subnet and I use static NAT to assign non-RFC1918 addresses to - hosts in Z. Hosts in Z cannot communicate with each other using -their external (non-RFC1918 addresses) so they can't access each -other using their DNS names.
- -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:++ +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.
+2a. I have a zone "Z" with an RFC1918 + subnet and I use static NAT to assign non-RFC1918 addresses + to hosts in Z. Hosts in Z cannot communicate with each other using + their external (non-RFC1918 addresses) so they can't access each + other using their DNS names.
+ +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
- Interface: eth2
- Subnet: 192.168.2.0/24
+ 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:
- -- + ++ I personnaly use Logwatch. It emails me a report each day from + my various systems with each report summarizing the logged activity on + the corresponding system. + ++- -- -
-- -SOURCE -DESTINATION -POLICY -LIMIT:BURST -- + +dmz -dmz -ACCEPT --
-+ +SOURCE +DESTINATION +POLICY +LIMIT:BURST ++ - - - + + +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?
- +3. I want to use Netmeeting or MSN Instant +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. -
- -4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' rather - than 'blocked'. Why?
- -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.
- -4a. I just ran an nmap UDP scan of my - firewall and it showed 100s of ports as open!!!!
- -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.
- -5. I've installed Shorewall and now I - can't ping through the firewall
- -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: -- -- For a complete description of Shorewall 'ping' management, see this page. - -run_iptables -A icmpdef -p ICMP --icmp-type echo-request - -j ACCEPT
-
+ href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help with Netmeeting. Look +here for a solution for MSN +IM but be aware that there are significant security risks involved with this +solution. Also check the Netfilter mailing list archives at http://www.netfilter.org.6. Where are the log messages written - and how do I change the destination?
- -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:
- -+ ++ +4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' + rather than 'blocked'. Why?
+ +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.
+ +4a. I just ran an nmap UDP scan of my + firewall and it showed 100s of ports as open!!!!
+ +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.
+ +5. I've installed Shorewall and now I + can't ping through the firewall
+ +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: ++ ++ For a complete description of Shorewall 'ping' management, see this page. + +run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
+
+6. Where are the log messages written + and how do I change the destination?
+ +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=""
Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages to a separate file.6a. Are there any log parsers that work - with Shorewall?
- -Answer: Here are several links that may be helpful: -
- -- + href="shorewall_logging.html">set up Shorewall to log all of its messages to a separate file.
+6a. Are there any log parsers that work + with Shorewall?
+ +Answer: Here are several links that may be helpful: +
+ ++- I personnaly use Logwatch. It emails me a report each day from my various - systems with each report summarizing the logged activity on the corresponding - system. -http://www.shorewall.net/pub/shorewall/parsefw/
-
- http://www.fireparse.com
- http://www.fireparse.com
+ http://cert.uni-stuttgart.de/projects/fwlogwatch
- http://www.logwatch.org
-7. When I stop Shorewall using 'shorewall - stop', I can't connect to anything. Why doesn't that command work?
- -The 'stop' command is intended to place your firewall into - a safe state whereby only those hosts listed in /etc/shorewall/routestopped' -are activated. If you want to totally open up your firewall, you -must use the 'shorewall clear' command.
- -8. When I try to start Shorewall on RedHat, -I get messages about insmod failing -- what's wrong?
- -Answer: The output you will see looks something like - this:
- + http://www.logwatch.org
+ +6b. DROP messages on port 10619 +are flooding the logs with their connect requests. Can i exclude these +error messages for this port temporarily from logging in Shorewall?
+Temporarily add the following rule:
+DROP net fw udp 10619+6c. All day long I get a steady flow +of these DROP messages from port 53 to some high numbered port. They get +dropped, but what the heck are they?
+Jan 8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00+Answer: There are two possibilities:
SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00
TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33
++
+You can distinguish the difference by setting the logunclean option +(/etc/shorewall/interfaces) on +your external interface (eth0 in the above example). If they get logged twice, +they are corrupted. I solve this problem by using an /etc/shorewall/common +file like this:- They are late-arriving replies to DNS queries.
+- They are corrupted reply packets.
+
+++The above file is also include in all of my sample configurations available +in the Quick Start Guides.#+
# Include the standard common.def file
#
. /etc/shorewall/common.def
#
# The following rule is non-standard and compensates for tardy
# DNS replies
#
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP
+7. When I stop Shorewall using 'shorewall + stop', I can't connect to anything. Why doesn't that command + work?
+ +The 'stop' command is intended to place your firewall into + a safe state whereby only those hosts listed in /etc/shorewall/routestopped' + are activated. If you want to totally open up your firewall, + you must use the 'shorewall clear' command.
+ +8. When I try to start Shorewall on RedHat, + I get messages about insmod failing -- what's wrong?
+ +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.
-++Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) shipped + with RH7.2.
+- -
9. Why can't Shorewall detect my interfaces - properly?
- -I just installed Shorewall and when I issue the start command, - I see the following:
- -+ ++ +9. Why can't Shorewall detect my interfaces + properly?
+ +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
-10. What Distributions does it work - with?
- -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
+10. What Distributions does it work + with?
+ +Shorewall works with any GNU/Linux distribution that includes + the proper prerequisites.
+11. What Features does it have?
- -Answer: See the Shorewall - Feature List.
- + +Answer: See the Shorewall + Feature List.
+12. Why isn't there a GUI?
- -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.
+13. Why do you call it "Shorewall"?
- -Answer: Shorewall is a concatenation of "Shoreline" - (the city where -I live) and "Firewall". The full name of the product -is actually "Shoreline Firewall" but "Shorewall" is must more commonly used.
- -14. I'm connected via a cable modem - and it has an internal web server that allows me to configure/monitor - it but as expected if I enable rfc1918 blocking for my eth0 interface - (the internet one), it also blocks the cable modems web server.
- -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". The full name of the product + is actually "Shoreline Firewall" but "Shorewall" is must more commonly +used.
+ +14. I'm connected via a cable modem + and it has an internal web server that allows me to configure/monitor + it but as expected if I enable rfc1918 blocking for my eth0 + interface (the internet one), it also blocks the cable modems +web server.
+ +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.
- -
-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 -
--- -14a. Even though it assigns public -IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable -RFC 1918 filtering on my external interface, my DHCP client cannot renew -its lease.
--- -The solution is the same as FAQ 14 above. Simply substitute - the IP address of your ISPs DHCP server.
-15. My local systems can't see out to - the net
- -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.
-16. Shorewall is writing log messages - all over my console making it unusable!
- -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.
- -
-17. How do I find out why this traffic is getting -logged?
- Answer: Logging occurs out of a number of chains - (as indicated in the log message) in Shorewall:
- --
+ + -- man1918 - The destination address is listed - in /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
-- rfc1918 - The source address is listed in - /etc/shorewall/rfc1918 with a logdrop target -- see /etc/shorewall/rfc1918.
-- all2<zone>, <zone>2all -or all2all - You have a policy that specifies a log level - and this packet is being logged under that policy. If you intend to - ACCEPT this traffic then you need a rule - to that effect.
-
-- <zone1>2<zone2> - Either you -have a policy for <zone1> - to <zone2> that specifies a log level and this -packet is being logged under that policy or this packet matches a - rule that includes a log level.
-- <interface>_mac - The packet is being logged - under the maclist interface option.
-
-- logpkt - The packet is being logged under - the logunclean interface option.
-- badpkt - The packet is being logged under - the dropunclean interface option as specified - in the LOGUNCLEAN setting in /etc/shorewall/shorewall.conf.
-- blacklst - The packet is being logged because - the source IP is blacklisted in the /etc/shorewall/blacklist file.
-- newnotsyn - The packet is being logged because - it is a TCP packet that is not part of any current connection yet -it is not a syn packet. Options affecting the logging of such packets -include NEWNOTSYN and LOGNEWNOTSYN in - /etc/shorewall/shorewall.conf.
-- INPUT or FORWARD - The packet has -a source IP address that isn't in any of your defined zones ("shorewall - check" and look at the printed zone definitions) or the chain is FORWARD - and the destination IP isn't in any of your defined zones.
-- logflags - The packet is being logged because it failed - the checks implemented by the tcpflags interface option.
- -
-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.
-
- Example 1:
-
- /etc/shorewall/rules +
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.
+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.
+
# Accept AUTH but only on address 192.0.2.125- Example 2 (NAT):
ACCEPT net fw:192.0.2.125 tcp auth
192.0.2.126 eth0 10.1.1.126- /etc/shorewall/rules + /etc/shorewall/rules
# Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)- Example 3 (DNAT):
ACCEPT net loc:10.1.1.126 tcp www
# Forward SMTP on external address 192.0.2.127 to local system 10.1.1.127- -
DNAT net loc:10.1.1.127 tcp smtp - 192.0.2.127
+ ++ 192.0.2.3 is external on my firewall... 172.16.0.0/24 is +my internal LAN19. I have added entries to /etc/shorewall/tcrules + but they don't seem to do anything. Why?
+ You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf + so the contents of the tcrules file are simply being ignored.
+ +20. I have just set up a server. Do I have + to change Shorewall to allow access to my server from the internet?
+ Yes. Consult the QuickStart guide that +you used during your initial setup for information about how to set + up rules for your server.
+
+ +21. I see these strange log entries occasionally; + what are they?
+ +
+- 192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal - LANNov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00-
SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3
[SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]
-
- Answer: While most people associate the Internet Control -Message Protocol (ICMP) with 'ping', ICMP is a key piece of the internet. -ICMP is used to report problems back to the sender of a packet; this is -what is happening here. Unfortunately, where NAT is involved (including -SNAT, DNAT and Masquerade), there are a lot of broken implementations. -That is what you are seeing with these messages.
-
- Here is my interpretation of what is happening -- to confirm this -analysis, one would have to have packet sniffers placed a both ends of -the connection.
-
- Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS - query to 192.0.2.3 and your DNS server tried to send a response (the -response information is in the brackets -- note source port 53 which marks -this as a DNS reply). When the response was returned to to 206.124.146.179, -it rewrote the destination IP TO 172.16.1.10 and forwarded the packet to -172.16.1.10 who no longer had a connection on UDP port 2857. This causes -a port unreachable (type 3, code 3) to be generated back to 192.0.2.3. -As this packet is sent back through 206.124.146.179, that box correctly -changes the source address in the packet to 206.124.146.179 but doesn't -reset the DST IP in the original DNS response similarly. When the ICMP -reaches your firewall (192.0.2.3), your firewall has no record of having -sent a DNS reply to 172.16.1.10 so this ICMP doesn't appear to be related -to anything that was sent. The final result is that the packet gets logged -and dropped in the all2all chain. I have also seen cases where the source -IP in the ICMP itself isn't set back to the external IP of the remote NAT -gateway; that causes your firewall to log and drop the packet out of the -rfc1918 chain because the source IP is reserved by RFC 1918.
- -22. I have some iptables commands that -I want to run when Shorewall starts. Which file do I put them in?
- You can place these commands in one of the Shorewall Extension Scripts. Be -sure that you look at the contents of the chain(s) that you will be modifying -with your commands to be sure that the commands will do what they are intended. -Many iptables commands published in HOWTOs and other instructional material -use the -A command which adds the rules to the end of the chain. Most chains -that Shorewall constructs end with an unconditional DROP, ACCEPT or REJECT -rule and any rules that you add after that will be ignored. Check "man iptables" -and look at the -I (--insert) command.
-
- +
net:<ip1>,<ip2>,...+ Example:
ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22+
Copyright
- © 2001, 2002 Thomas M. Eastep.
-
Copyright
+© 2001, 2002, 2003 Thomas M. Eastep.
+
Updated 8/22/2002 - Tom Eastep
-Copyright -© 2001, 2002 Thomas M. Eastep.
+Copyright +© 2001, 2002 Thomas M. Eastep.
- \ No newline at end of file + diff --git a/STABLE/documentation/IPSEC.htm b/STABLE/documentation/IPSEC.htm index e3518fd2e..98e7d4852 100644 --- a/STABLE/documentation/IPSEC.htm +++ b/STABLE/documentation/IPSEC.htm @@ -359,8 +359,8 @@ script will issue the command":Last updated 10/23/2002 - Tom Eastep
-- Copyright © 2001, 2002 Thomas M. Eastep.
++ Copyright © 2001, 2002 Thomas M. Eastep.
Updated 10/28/2002 - Tom Eastep
-Copyright - © 2001, 2002 Thomas M. Eastep.
+Copyright + © 2001, 2002 Thomas M. Eastep.
| - + |
+
MAC Verification
- |
-
MACLIST_DISPOSITION=REJECT- /etc/shorewall/interfaces:
MACLIST_LOG_LEVEL=info
#ZONE INTERFACE BROADCAST OPTIONS- /etc/shorewall/maclist:
net eth0 206.124.146.255 norfc1918,filterping,dhcp,blacklist
loc eth2 192.168.1.255 dhcp,filterping,maclist
dmz eth1 192.168.2.255 filterping
net eth3 206.124.146.255 filterping,blacklist
- texas 192.168.9.255 filterping
loc ppp+ - filterping
#INTERFACE MAC IP ADDRESSES (Optional)- As shown above, I use MAC Verification on my local - zone.
eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie
eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry
eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa
eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)
eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap
#INTERFACE MAC IP ADDRESSES (Optional)+ As shown above, I use MAC Verification on my +local zone.
eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie
eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry
eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa
eth2 00:A0:CC:DB:31:C4 192.168.1.128/26 #PPTP Clients to server on Ursa
eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)
eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap
eth2 00:06:43:45:C6:15 192.168.1.253,192.168.2.0/24- This entry accomodates traffic from the router itself (192.168.1.253) -and from the second LAN segment (192.168.2.0/24). Remember that all traffic - being sent to my firewall from the 192.168.2.0/24 segment will be forwarded - by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15) - and not that of the host sending the traffic. -
Updated 12/22/2002 - Tom Eastep -
+ This entry accomodates traffic from the router itself (192.168.1.253) + and from the second LAN segment (192.168.2.0/24). Remember that all traffic + being sent to my firewall from the 192.168.2.0/24 segment will be forwarded + by the router so that traffic's MAC address will be that of the router +(00:06:43:45:C6:15) and not that of the host sending the traffic. + +Updated 1/7/2002 - Tom Eastep +
- -Copyright - © 2001, 2002 Thomas M. Eastep.
-