diff --git a/Shorewall-docs2/Documentation.xml b/Shorewall-docs2/Documentation.xml index 9260af172..85a7b7434 100644 --- a/Shorewall-docs2/Documentation.xml +++ b/Shorewall-docs2/Documentation.xml @@ -411,8 +411,7 @@ NET_OPTIONS=blacklist,norfc1918 short name for the zone. The name should be 5 characters or - less in length (4 characters or less if you are running Shorewall - 1.4.4 or later) and consist of lower-case letters or numbers. Short + less in length and consist of lower-case letters or numbers. Short names must begin with a letter and the name assigned to the firewall is reserved for use by Shorewall itself. Note that the output produced by iptables is much easier to read if you select short @@ -596,21 +595,21 @@ NET_OPTIONS=blacklist,norfc1918 respond to arp requests based on the value of <number>. - 1 - reply only if the target IP address is local - address configured on the incoming interface + 1 - reply only if the target IP address is local address + configured on the incoming interface - 2 - reply only if the target IP address is local - address configured on the incoming interface and both with the + 2 - reply only if the target IP address is local address + configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface - 3 - do not reply for local addresses configured with + 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied - 4-7 - reserved + 4-7 - reserved - 8 - do not reply for all local addresses + 8 - do not reply for all local addresses If no <number> is given then the value 1 is assumed @@ -1056,13 +1055,6 @@ net eth0 detect dhcp,norfc1918 Your /etc/shorewall/hosts file might look like: - #ZONE HOST(S) OPTIONS -loc eth1:192.168.1.0/24 -loc eth1:192.168.12.0/24 - - If you are running Shorewall 1.4.6 or later, your hosts file may - look like: - #ZONE HOST(S) OPTIONS loc eth1:192.168.1.0/24,192.168.12.0/24 @@ -1494,18 +1486,18 @@ DNAT net loc:192.168.1.3 tcp ssh - Rules in the ESTABLISHED and RELATED sections are limited to the + Rules in the ESTABLISHED and RELATED sections are limited to the following ACTIONs:
- ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions. + ACCEPT, DROP, REJECT, QUEUE, LOG and User-defined actions.
Macros may be used in these sections provided that they expand to only these ACTIONs. At the end of the ESTABLISHED and RELATED sections, there is an implicit ACCEPT rule. - RESTRICTION: If you specify FASTACCEPT=Yes in + RESTRICTION: If you specify FASTACCEPT=Yes in /etc/shorewall.shorewall.conf then the ESTABLISHED and RELATED sections must be empty. @@ -2005,7 +1997,7 @@ ACCEPT:info - - tc You wish to forward all ssh connection requests from the internet to local system 192.168.1.3. You wish to limit the number of connections - to 4/minute with a burst of 8 (Shorewall 1.4.7 and later only): + to 4/minute with a burst of 8: #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT<4/min:8> net loc:192.168.1.3 tcp ssh @@ -2109,11 +2101,10 @@ ACCEPT net fw:206.124.146.176 tcp 22 - (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. + (For advanced users). From the internet, you with to forward tcp + port 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in + your DMZ. You also want to allow access from the internet directly to + tcp port 25 on 192.0.2.177. #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST @@ -2126,20 +2117,18 @@ ACCEPT net dmz:192.0.2.177 tcp 25 - (Shorewall version 1.4.6 or later). You have 9 http servers - behind a Shorewall firewall and you want connection requests to be - distributed among your servers. The servers are - 192.168.1.101-192.168.1.109. + You have 9 http servers behind a Shorewall firewall and you want + connection requests to be distributed among your servers. The servers + are 192.168.1.101-192.168.1.109. #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net loc:192.168.1.101-192.168.1.109 tcp 80 - (Shorewall 2.0.2 Beta 2 and Later). You want to redirect all - local www connection requests EXCEPT those from 192.168.1.4 and - 192.168.1.199 to a Squid transparent proxy running on the firewall and - listening on port 3128. + You want to redirect all local www connection requests EXCEPT + those from 192.168.1.4 and 192.168.1.199 to a Squid transparent proxy + running on the firewall and listening on port 3128. #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL # PORT(S) DEST @@ -2434,7 +2423,7 @@ eth0 192.168.10.0/24!192.168.10.44,192.168.10.45 206.124.146.176 - You have a second IP address (206.124.146.177) assigned to you + <title>You have a second IP address (206.124.146.177) assigned to you and wish to use it for SNAT of the subnet 192.168.12.0/24. You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in <xref linkend="Conf" />. @@ -2444,16 +2433,16 @@ eth0:0 192.168.12.0/24 206.124.146.177 - You want to use both 206.124.146.177 and 206.124.146.179 for - SNAT of the subnet 192.168.12.0/24. Each address will be used on - alternate outbound connections. + You want to use both 206.124.146.177 and 206.124.146.179 for SNAT + of the subnet 192.168.12.0/24. Each address will be used on alternate + outbound connections. #INTERFACE SUBNET ADDRESS eth0 192.168.12.0/24 206.124.146.177,206.124.146.179 - You want all outgoing SMTP traffic entering the firewall on eth1 + <title>You want all outgoing SMTP traffic entering the firewall on eth1 to be sent from eth0 with source IP address 206.124.146.177. You want all other outgoing traffic from eth1 to be sent from eth0 with source IP address 206.124.146.176. @@ -3074,8 +3063,7 @@ eth0 eth1 206.124.146.176 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. + given, then info is assumed. @@ -3633,8 +3621,7 @@ LOGBURST=5 - /etc/shorewall/tos file that is included with - Shorewall + Here's a sample /etc/shorewall/tos file: #SOURCE DEST PROTOCOL SOURCE PORTS(S) DEST PORTS(S) TOS all all tcp - ssh 16 diff --git a/Shorewall-docs2/FAQ.xml b/Shorewall-docs2/FAQ.xml index ea1fc427b..c918d6339 100644 --- a/Shorewall-docs2/FAQ.xml +++ b/Shorewall-docs2/FAQ.xml @@ -17,7 +17,7 @@ - 2005-08-24 + 2005-08-30 2001-2005 @@ -36,6 +36,13 @@ + + This article applies to Shorewall 3.0 and + later. If you are running a version of Shorewall earlier than Shorewall + 3.0.0 then please see the documentation for that + release. + +
Installing Shorewall @@ -90,9 +97,9 @@ message "warning: user teastep does not exist - using root" Answer: You may safely ignore - this warning message. It was caused by a minor packaging error - that has since been corrected. It makes no difference to - Shorewall's operation. + this warning message. It was caused by a minor packaging error that has + since been corrected. It makes no difference to Shorewall's + operation.
@@ -373,15 +380,9 @@ DNAT net fw:192.168.1.1:22 tcp 4104 - If you insist on a stupid IP solution to the accessibility problem - rather than a more efficient DNS solution, then if you are running - Shorewall 2.0.0 or 2.0.1 then please see the Shorewall 1.4 - FAQ. - - Otherwise, 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, 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, then: All traffic redirected through use of this hack will look to the server as if it came from the firewall (192.168.1.254) rather than from the original client! @@ -410,14 +411,9 @@ eth1:192.168.1.5 eth1 192.168.1.254 tcp www 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 through Shorewall 2.0.* then include this in + IP address. If you have a dynamic IP address then include this in /etc/shorewall/init: - ETH0_IP=`find_interface_address eth0` - - For users of Shorewall 2.1.0 and later: - ETH0_IP=`find_first_interface_address eth0` and make your DNAT rule: @@ -530,10 +526,6 @@ DNAT loc dmz:192.168.2.4 tcp 80 - 206 In /etc/shorewall/init: - ETH0_IP=`find_interface_address eth0` - - For users of Shorewall 2.1.0 and later: - ETH0_IP=`find_first_interface_address eth0` and make your DNAT rule: @@ -587,40 +579,10 @@ to debug/develop the newnat interface. and it shows some ports as closed rather than blocked. Why? - Answer: (Shorewall versions prior - to 2.0.0 only). 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, 139 and 445 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. - - - You can change the default behavior of Shorewall through use of - an /etc/shorewall/common file. See the Extension Script - Section. - - - - Beginning with Shorewall 1.4.9, Shorewall no longer rejects the - Windows SMB ports (135-139 and 445) by default and silently drops them - instead. - - - Answer: (Shorewall versions 2.0.0 - and later). The default Shorewall setup invokes the Drop action prior to enforcing a DROP policy and - the default policy to all zone from the internet is DROP. The Drop - action is defined in + Answer: The default Shorewall + setup invokes the Drop action prior to + enforcing a DROP policy and the default policy to all zone from the + internet is DROP. The Drop action is defined in /usr/share/shorewall/action.Drop which in turn invokes the RejectAuth action (defined in /usr/share/shorewall/action.RejectAuth). This is @@ -744,63 +706,6 @@ to debug/develop the newnat interface. url="SimpleBridge.html">Shorewall Simple Bridge documentation. - -
- (FAQ 40) Shorewall is Blocking my OpenVPN Tunnel - - I have this entry in /etc/shorewall/tunnels: - - # TYPE ZONE GATEWAY GATEWAY -# ZONE -openvpn:5000 net 69.145.71.133 - - Yet I am seeing this log message: - - Oct 12 13:41:03 localhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT= -MAC=00:04:5a:7f:92:9f:00:b0:c2:89:68:e4:08:00 SRC=69.145.71.133 -DST=216.187.138.18 LEN=42 TOS=0x00 PREC=0x00 TTL=46 ID=11 DF PROTO=UDP -SPT=33120 DPT=5000 LEN=22 - - Answer: Shorewall's openvpn tunnel type assumes that OpenVPN will be - using the same port (default 5000) for both the source and destination - port. From the above message, it is clear that the remote client is - using source port 33120. The solution is to replace your /etc/shorewall/tunnels entry - with this one: - - # TYPE ZONE GATEWAY GATEWAY -# ZONE -generic:udp:5000 net 69.145.71.133 -
- -
- (FAQ 47) This Rule Doesn't Work as Documented - - I want to allow access from the local zone to the net except for - two systems (192.168.100.101 and 192.168.100.115). I use the following - rule but find that 192.168.100.115 can still access the net. Is this a - bug? - - #ACTION SOURCE DEST PROTO -ACCEPT loc:!192.168.100.101,192.168.100.115 net - - Answer: Shorewall is currently - inconsistent as to where it correctly supports the "!" before a list of - addresses. In some places, it works as you would expect and in other - cases such as this one it does not. You will need to take a different - approach to accomplish what you want. I recommend that you change your - loc->net policy to ACCEPT and then use this rule: - - #ACTION SOURCE DEST PROTO -REJECT loc:192.168.100.101,192.168.100.115 net - - Author's Note: I have looked - several times at correcting this problem but it really isn't feasible - until I muster the energy to rewrite the Shorewall rules parser. - Sorry. -
@@ -831,9 +736,8 @@ REJECT loc:192.168.100.101,192.168.100.115 net LOGLIMIT="" LOGBURST="" - Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages - to a separate file. + It is also possible to set up + Shorewall to log all of its messages to a separate file.
(FAQ 6a) Are there any log parsers that work with @@ -912,9 +816,7 @@ LOGBURST=""</programlisting> <title>(FAQ 16) Shorewall is writing log messages all over my console making it unusable! - Answer: If you are running - Shorewall version 1.4.4 or 1.4.4a then check the errata. Otherwise: + Answer: @@ -1279,240 +1181,8 @@ LOGBURST="" (FAQ 32) My firewall has two connections to the internet from two different ISPs. How do I set this up in Shorewall? - - Anyone with two Internet connections MUST read and understand - this article on Shorewall and - Routing. If you don't, you will be completely lost trying to - make this work. And that article should be all - that you need if you are running Shorewall 2.3.2 or - later. - - - Setting this up in Shorewall is easy; setting up the routing is a - bit harder. - - Assuming that eth0 and - eth1 are the interfaces to the - two ISPs then: - - /etc/shorewall/interfaces: - - #ZONE INTERFACE BROADCAST OPTIONS -net eth0 detect -net eth1 detect - - /etc/shorewall/policy: - - #SOURCE DESTINATION POLICY LIMIT:BURST -net net DROP - - If you have masqueraded hosts, be sure to update - /etc/shorewall/masq to masquerade to both ISPs. For - example, if you masquerade all hosts connected to eth2 then: - - #INTERFACE SUBNET ADDRESS -eth0 eth2 -eth1 eth2 - - Again, if you are running Shorewall 2.3.2 or later, please see - this article for - instructions for setting up the routing. Otherwise, follow the - instructions that follow. - - There was an article in SysAdmin covering the topic of setting up - routing for this configuration. It may be found at http://www.samag.com/documents/s=1824/sam0201h/. - - Stephen Carville has put together a Shorewall-specific writeup - that covers this subject at http://www.heronforge.net/redhat/node17.html. - - The following information regarding setting up routing - for this configuration is reproduced from the LARTC HOWTO and has not been verified - by the author. If you have questions or problems with the instructions - given below, please post to the LARTC mailing - list. - - - A common configuration is the following, in which there are two - providers that connect a local network (or even a single machine) to - the big Internet. - - ________ - +------------+ / - | | | - +-------------+ Provider 1 +------- - __ | | | / - ___/ \_ +------+-------+ +------------+ | - _/ \__ | if1 | / - / \ | | | -| Local network -----+ Linux router | | Internet - \_ __/ | | | - \__ __/ | if2 | \ - \___/ +------+-------+ +------------+ | - | | | \ - +-------------+ Provider 2 +------- - | | | - +------------+ \________ - - - There are usually two questions given this setup. - - Split access - - The first is how to route answers to packets coming in over a - particular provider, say Provider 1, back out again over that same - provider. - - Let us first set some symbolical names. Let $IF1 be the name of the first interface (if1 in - the picture above) and $IF2 the name - of the second interface. Then let $IP1 be the IP address associated with - $IF1 and $IP2 the IP address associated with $IF2. Next, let $P1 be the IP address of the gateway at - Provider 1, and $P2 the IP address of - the gateway at provider 2. Finally, let $P1_NET be the IP network $P1 is in, and $P2_NET the IP network $P2 is in. - - One creates two additional routing tables, say T1 and T2. - These are added in /etc/iproute2/rt_tables. Then you set up routing in - these tables as follows: - - ip route add $P1_NET dev $IF1 src $IP1 table T1 -ip route add default via $P1 table T1 -ip route add $P2_NET dev $IF2 src $IP2 table T2 -ip route add default via $P2 table T2 - - Nothing spectacular, just build a route to the gateway and build - a default route via that gateway, as you would do in the case of a - single upstream provider, but put the routes in a separate table per - provider. Note that the network route suffices, as it tells you how to - find any host in that network, which includes the gateway, as - specified above. - - Next you set up the main routing table. It is a good idea to - route things to the direct neighbour through the interface connected - to that neighbour. Note the `src' arguments, they make sure the right - outgoing IP address is chosen. - - ip route add $P1_NET dev $IF1 src $IP1 -ip route add $P2_NET dev $IF2 src $IP2 - - Then, your preference for default route: - - ip route add default via $P1 - - Next, you set up the routing rules. These actually choose what - routing table to route with. You want to make sure that you route out - a given interface if you already have the corresponding source - address: - - ip rule add from $IP1 table T1 -ip rule add from $IP2 table T2 - - This set of commands makes sure all answers to traffic coming in - on a particular interface get answered from that interface. - - - 'If $P0_NET is the local network and $IF0 is its interface, - the following additional entries are desirable: - - ip route add $P0_NET dev $IF0 table T1 -ip route add $P2_NET dev $IF2 table T1 -ip route add 127.0.0.0/8 dev lo table T1 -ip route add $P0_NET dev $IF0 table T2 -ip route add $P1_NET dev $IF1 table T2 -ip route add 127.0.0.0/8 dev lo table T2 - - - Now, this is just the very basic setup. It will work for all - processes running on the router itself, and for the local network, if - it is masqueraded. If it is not, then you either have IP space from - both providers or you are going to want to masquerade to one of the - two providers. In both cases you will want to add rules selecting - which provider to route out from based on the IP address of the - machine in the local network. - - Load balancing - - The second question is how to balance traffic going out over the - two providers. This is actually not hard if you already have set up - split access as above. - - Instead of choosing one of the two providers as your default - route, you now set up the default route to be a multipath route. In - the default kernel this will balance routes over the two providers. It - is done as follows (once more building on the example in the section - on split-access): - - ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \ - nexthop via $P2 dev $IF2 weight 1 - - This will balance the routes over both providers. The weight parameters can be tweaked to favor one - provider over the other. - - - balancing will not be perfect, as it is route based, and - routes are cached. This means that routes to often-used sites will - always be over the same provider. - - - Furthermore, if you really want to do this, you probably also - want to look at Julian Anastasov's patches at http://www.ssi.bg/~ja/#routes - , Julian's route patch page. They will make things nicer to work - with. - - - The following was contributed by Martin Brown and is an excerpt - from http://www.docum.org/stef.coene/qos/faq/cache/44.html - . - - - There are two issues requiring different handling when dealing - with multiple Internet providers on a given network. The below assumes - that the host which has multiple Internet connections is a - masquerading (or NATting) host and is at the chokepoint between the - internal and external networks. For the use of multiple inbound - connections to the same internal server (public IP A from ISP A and - public IP B from ISP B both get redirected to the same internal - server), the ideal solution involves using two private IP addresses on - the internal server. This leads to an end-to-end uniqueness of public - IP to private IP and can be easily accomplished by following the - directions here: - - - http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-inbound - - - For the use of multiple outbound links to the Internet, there - are a number of different techniques. The simplest is identified - here: - - http://linux-ip.net/html/adv-multi-internet.html#adv-multi-internet-outbound - - - Better (and more robust) techniques are available after a kernel - routing patch by Julian Anastasov. See the famous nano-howto. - - http://www.ssi.bg/~ja/ - - + Answer: See this article + on Shorewall and Routing.
@@ -1664,8 +1334,8 @@ Creating input Chains... output to a file as in shorewall restart > /dev/null). - Beginning with Shorewall version 2.0.2 Beta 1, Shorewall supports - a fast start capability. To use this capability: + Shorewall also supports a fast start capability. To use this + capability: @@ -1712,66 +1382,6 @@ Creating input Chains... shorewall save. Otherwise at the next reboot, you will revert to the old configuration stored in /var/lib/shorewall/restore. - -
- (FAQ 34a) I get errors about a host or network not found when I - run<filename>/var/lib/shorewall/restore</filename>. The - <command>shorewall restore</command> and <command>shorewall -f - start</command> commands gives the same result. - - Answer: iptables 1.2.9 is broken with respect to iptables-save - and the connection tracking match extension. You must patch your - iptables using the patch available from the Shorewall errata page. -
-
- -
- (FAQ 41) Why do I get modprobe failure messages when I start - Shorewall? - - When I start shorewall I got the following errors. - - Oct 30 11:13:12 fwr modprobe: modprobe: Can't locate module ipt_conntrack -Oct 30 11:13:17 fwr modprobe: modprobe: Can't locate module ipt_pkttype -Oct 30 11:13:18 fwr modprobe: modprobe: Can't locate module ipt_pkttype -Oct 30 11:13:57 fwr last message repeated 2 times -Oct 30 11:14:06 fwr root: Shorewall Restarted - - The "shorewall status" output seems complying with my rules set. - Should I worry ? and is there any way to get rid of these errors - ? - - Answer: You are seeing two - different things: - - - - The normal checking that Shorewall does when it starts. - Shorewall tries to determine the the capabilities of your 'iptables' - and kernel and then taylors the ruleset accordingly. - - - - A problem in Shorewall 2.0.3a through 2.0.5 whereby Shorewall - tried to use the pkttype match feature each - time that it wanted to generate a rule involving broadcast or - multicast packets. - - - - You can suppress the messages by aliasing the modules mentioned in - the error messages to off in /etc/modules.conf. Just be sure to review - these aliases each time that you do a kernel upgrade to be sure that you - are not disabling a feature in your new kernel that you want to - use. - - alias ipt_conntrack off -alias ipt_pkttype off - - For users who don't have the pkttype match feature in their - kernel, I also recommend upgrading to Shorewall 2.0.6 or later and then - setting PKTTYPE=No in shorewall.conf.
@@ -1940,18 +1550,6 @@ iptables: Invalid argument
-
- (FAQ 46) Given that the Debian Stable Release includes Shorewall - 1.2.12, how can you not support that version? - - The first release of Shorewall was in March of 2001. Shorewall - 1.2.12 was released in May of 2002. It is now the year 2005 and - Shorewall 2.2 is available. Shorewall 1.2.12 is poorly documented and is - missing many of the features that Shorewall users find essential today - and it is silly to continue to run it simply because it is bundled with - an ancient Debian release. -
-
(FAQ 36) Does Shorewall Work with the 2.6 Linux Kernel? @@ -2153,21 +1751,6 @@ eth0 eth1 # eth1 = interface to local netwo Edit /etc/shorewall/shorewall.conf and change NEWNOTSYN=No to NEWNOTSYN=Yes then restart Shorewall. - -
- (FAQ 26a) When I try to use the <quote>-O</quote> option of - nmap from the firewall system, I get <quote>operation not - permitted</quote>. How do I allow this option? - - If you are running Shorewall 2.2.0 or later, set DROPINVALID=No - in /etc/shorewall/shorewall.conf. - - Otherwise, add this command to your /etc/shorewall/start - file: - - run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP -
@@ -2278,36 +1861,33 @@ REJECT fw net:216.239.39.99 allGiven that (FAQ 42) How can I tell which features my kernel and iptables support? - Answer: Users running Shorewall 2.2.4 or later can simply use the - shorewall show capabilities command at a root - prompt. + Answer: Use the shorewall show capabilities + command at a root prompt. - For those running older versions, at a root prompt, enter the - command shorewall check. There is a section near the - top of the resulting output that gives you a synopsis of your - kernel/iptables capabilities. - - gateway:/etc/shorewall # shorewall check + gateway:~# shorewall show capabilities Loading /usr/share/shorewall/functions... Processing /etc/shorewall/params ... Processing /etc/shorewall/shorewall.conf... Loading Modules... - -Notice: The 'check' command is unsupported and problem - reports complaining about errors that it didn't catch - will not be accepted - Shorewall has detected the following iptables/netfilter capabilities: NAT: Available Packet Mangling: Available Multi-port Match: Available + Extended Multi-port Match: Available Connection Tracking Match: Available - Packet Type Match: Not available + Packet Type Match: Available Policy Match: Available Physdev Match: Available IP range Match: Available -Verifying Configuration... -... + Recent Match: Available + Owner Match: Available + Ipset Match: Available + ROUTE Target: Available + Extended MARK Target: Available + CONNMARK Target: Available + Connmark Match: Available + Raw Table: Available +gateway:~#
- + \ No newline at end of file diff --git a/Shorewall-docs2/IPSEC-2.6.xml b/Shorewall-docs2/IPSEC-2.6.xml index 014346e65..c4fccf599 100644 --- a/Shorewall-docs2/IPSEC-2.6.xml +++ b/Shorewall-docs2/IPSEC-2.6.xml @@ -15,7 +15,7 @@ - 2005-08-20 + 2005-08-30 2004 @@ -36,6 +36,13 @@ + + This article applies to Shorewall 3.0 and + later. If you are running a version of Shorewall earlier than Shorewall + 3.0.0 then please see the documentation for that + release. + + The information in this article is only applicable if you plan to have IPSEC end-points on the same system where Shorewall is used. @@ -43,12 +50,10 @@ To use the features described in this article, your kernel and - iptables must include the Netfilter+ipsec patches and policy match support - and you must be running Shorewall 2.1.5 or later (with Shorewall 2.2.0 - Beta 1 or later recommended). The Netfilter patches are available from - Netfilter Patch-O-Matic-NG and are also included in some commercial - distributions (most notably SuSE 9.1 and - 9.2). + iptables must include the Netfilter+ipsec patches and policy match + support. The Netfilter patches are available from Netfilter + Patch-O-Matic-NG and are also included in some commercial distributions + (most notably SuSE 9.1 through 9.3). @@ -106,7 +111,7 @@
- Shorewall 2.2 and Kernel 2.6 IPSEC + Shorewall 3.0 and Kernel 2.6 IPSEC This is not a HOWTO for Kernel 2.6 IPSEC -- for that, please see - A new /etc/shorewall/ipsec + The /etc/shorewall/zones file allows you to associate zones with traffic that will be encrypted or that has been decrypted. @@ -195,9 +200,8 @@ - In summary, Shorewall 2.1.5 and later versions provide the - facilities to replace the use of ipsec pseudo-interfaces in zone and - MASQUERADE/SNAT definition. + In summary, Shorewall provides the facilities to replace the use of + ipsec pseudo-interfaces in zone and MASQUERADE/SNAT definition. There are two cases to consider: @@ -250,7 +254,9 @@ For more information on IPSEC, Kernel 2.6 and Shorewall see my presentation on the subject given at LinuxFest NW - 2005. + 2005. Be warned though that the presentation is based on Shorewall + 2.2 and there are some differences in the details of how IPSEC is + configured.
@@ -313,18 +319,13 @@ ipsec net 206.162.148.9 /etc/shorewall/zones — Systems A and B: - #ZONE DISPLAY COMMENTS + #ZONE IPSEC OPTIONS IN OUT +# ONLY OPTIONS OPTIONS#ZONE DISPLAY COMMENTS vpn VPN Virtual Private Network net Internet The big bad internet #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - - Note that the vpn zone is defined before the - net zone. This is necessary if you are using a Shorewall - version earlier than 2.1.11. - - Remember the assumption that both systems A and B have eth0 as their internet interface. @@ -466,7 +467,7 @@ sainfo address 192.168.1.0/24 any address 134.28.54.2/32 any If you have hosts that access the internet through an IPSEC tunnel, then it is a good idea to set the MSS value for traffic from those hosts explicitly in the - /etc/shorewall/ipsec file. For example, if hosts + /etc/shorewall/zones file. For example, if hosts in the sec zone access the internet through an ESP tunnel then the following entry would be appropriate: @@ -507,12 +508,6 @@ vpn VPN Road Warriors net Internet The big bad internet loc local Local Network (192.168.1.0/24) #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - - - Note that the vpn zone is defined before the - net zone. This is necessary if you are using a - Shorewall version earlier than 2.1.11. - In this instance, the mobile system (B) has IP address 134.28.54.2 @@ -748,19 +743,6 @@ spdadd 192.168.20.40/32 192.168.20.10/32 any -P in ipsec esp/transport/192.168. Shorewall configuration goes as follows:
- /etc/shorewall/zones: - - #ZONE DISPLAY COMMENTS -net Net Internet -loc Local Local Network -#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE - - - Note that the vpn zone is defined before the - net zone. This is advised if you are using a Shorewall - version earlier than 2.1.11. - - /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS @@ -773,11 +755,12 @@ net eth0 detect routefilter,dhcp,tcpflags # ZONE ipsec:noah net 192.168.20.0/24 loc - /etc/shorewall/ipsec: + /etc/shorewall/zones: #ZONE IPSEC OPTIONS IN OUT # ONLY OPTIONS OPTIONS -loc Yes mode=transport +loc Yes mode=transport +net /etc/shorewall/hosts: diff --git a/Shorewall-docs2/Install.xml b/Shorewall-docs2/Install.xml index 355692436..e87383f51 100644 --- a/Shorewall-docs2/Install.xml +++ b/Shorewall-docs2/Install.xml @@ -36,6 +36,13 @@ + + This article applies to Shorewall 3.0 and + later. If you are installing or upgradeing to a version of Shorewall + earlier than Shorewall 3.0.0 then please see the documentation for that + release. + + Before attempting installation, I strongly urge you to read and print a copy of the Shorewall @@ -158,39 +165,11 @@ cd to the shorewall directory (the version is encoded in the - directory name as in shorewall-1.1.10). + directory name as in shorewall-3.0.0). - If you are running Slackware, you need Shorewall - 2.0.2 RC1 or later. If you are installing a Shorewall version earlier - than 2.0.3 Beta 1 then you must also edit the install.sh file and - change the lines - - DEST="/etc/init.d" -INIT="shorewall" - - to - - DEST="/etc/rc.d" -INIT="rc.firewall" - - - - If you are running Slackware and are installing Shorewall 2.0.3 - Beta 1 to Shorewall 2.2.3, then type: - - DEST=/etc/rc.d INIT=rc.firewall ./install.sh - - If you are running Slackware and are installing Shorewall 2.2.4 - or later, then type: - - ./install.sh - - - - Otherwise, type: + Type: ./install.sh @@ -201,26 +180,9 @@ INIT="rc.firewall" - Enable Startup: - - - - Users running Shorewall 2.1.3 or later, edit - /etc/shorewall/shorewall.conf and set - STARTUP_ENABLED=Yes. - - - - Users running Shorewall 2.1.2 or earlier and using the .deb - should edit /etc/default/shorewall and set - startup=1. - - - - All other users, remove the file - /etc/shorewall/startup_disabled - - + Enable Startup by editing + /etc/shorewall/shorewall.conf and set + STARTUP_ENABLED=Yes. @@ -273,9 +235,9 @@ INIT="rc.firewall" described here. - Once you have completed configuring Shorewall, you can enable - startup at boot time by setting startup=1 in - /etc/default/shorewall. + Once you have completed configuring Shorewall, + you can enable startup at boot time by setting startup=1 in + /etc/default/shorewall.
@@ -395,35 +357,7 @@ INIT="rc.firewall" - If you are running Slackware, you should use - Shorewall 2.0.2 RC1 or later. If you are installing a Shorewall - version earlier than 2.0.3 Beta 1 then you must also edit the - install.sh file and change the lines - - DEST="/etc/init.d" -INIT="shorewall" - - to - - DEST="/etc/rc.d" -INIT="rc.firewall" - - - - If you are running Slackware and are installing Shorewall 2.0.3 - Beta 1 through Shorewall 2.2.3, then type: - - DEST=/etc/rc.d INIT=rc.firewall ./install.sh - - If you are running Slackware and are installing Shorewall 2.2.4 - or later, then type: - - ./install.sh - - - - Otherwise, type: + Type: ./install.sh diff --git a/Shorewall-docs2/Introduction.xml b/Shorewall-docs2/Introduction.xml index a291f46f4..3c3e31ae4 100644 --- a/Shorewall-docs2/Introduction.xml +++ b/Shorewall-docs2/Introduction.xml @@ -13,7 +13,7 @@ Eastep - 2005-08-11 + 2005-08-30 2003-2005 @@ -35,7 +35,7 @@
Introduction - The information in this document applies only to 2.x releases of + The information in this document applies only to 3.x releases of Shorewall.
@@ -119,7 +119,7 @@ Shorewall views the network where it is running as being composed of a set of zones. In the three-interface sample configuration for - example, the following zone names are used: + example, the following zone names are used: #NAME DESCRIPTION net The Internet @@ -133,7 +133,9 @@ dmz Demilitarized Zone Shorewall also recognizes the firewall system as its own zone - by default, the firewall itself is known as fw. + role="bold">fw but that may be changed by + setting the FW option in /etc/shorewall/shorewall.conf. Rules about what traffic to allow and what traffic to deny are expressed in terms of zones. diff --git a/Shorewall-docs2/images/Troubleshoot.odg b/Shorewall-docs2/images/Troubleshoot.odg index 273676efd..9bffce214 100644 Binary files a/Shorewall-docs2/images/Troubleshoot.odg and b/Shorewall-docs2/images/Troubleshoot.odg differ diff --git a/Shorewall-docs2/images/Troubleshoot.png b/Shorewall-docs2/images/Troubleshoot.png index 6c60a72a7..7eb72772f 100644 Binary files a/Shorewall-docs2/images/Troubleshoot.png and b/Shorewall-docs2/images/Troubleshoot.png differ diff --git a/Shorewall-docs2/starting_and_stopping_shorewall.xml b/Shorewall-docs2/starting_and_stopping_shorewall.xml index 406e6dc2a..4c0087591 100644 --- a/Shorewall-docs2/starting_and_stopping_shorewall.xml +++ b/Shorewall-docs2/starting_and_stopping_shorewall.xml @@ -15,7 +15,7 @@ - 2005-05-23 + 2005-08-30 2004 @@ -36,6 +36,12 @@ + + This article applies to Shorewall 3.0 and later. If you are running + a version of Shorewall earlier than Shorewall 3.0.0 then please see the + documentation for that release. + +
Operational Components @@ -213,14 +219,11 @@ Shorewall startup is disabled by default. Once you have - configured your firewall, you can enable startup by removing the - file /etc/shorewall/startup_disabled. Note: - Users of the .deb package must edit - /etc/default/shorewall and set - startup=1 while users who are running Shorewall - 2.1.3 or later must edit - /etc/shorewall/shorewall.conf and set - STARTUP_ENABLED=Yes. + configured your firewall, you can enable startup by editing + /etc/shorewall/shorewall.conf and setting + STARTUP_ENABLED=Yes.. Note: Users of the .deb package must also + edit /etc/default/shorewall and set + startup=1. @@ -357,14 +360,6 @@ Shorewall to check before looking in the directories listed in CONFIG_PATH. - Shorewall versions before Shorewall 2.2.0: - - shorewall [ -c <configuration-directory> ] {start|restart|check} - shorewall try <configuration-directory> [ <timeout> ] - - Shorewall versions 2.2.0 and later the -c option is - deprecated: - shorewall {start|restart|check} <configuration-directory> shorewall try <configuration-directory> [ <timeout> ] @@ -468,12 +463,6 @@ Adds an interface (and list of hosts if included) to a dynamic zone usually used with VPN's. - Note that there was no provision in the syntax for specifying - a bridge port prior to Shorewall - versions 2.0.12 and 2.2.0 Beta 7 and that the "shorewall add" - command was not supported for hosts connected to the firewall - through a bridge port prior to those releases. - Example: shorewall add ipsec0:192.0.2.24 vpn1 @@ -497,32 +486,17 @@ - check (Shorewall versions prior to 2.2.0) - - - shorewall [ -c <configuration-directory> ] - check - - Performs a cursory validation of the zones, interfaces, hosts, - rules and policy files. Use this if you are unsure of any edits you - have made to the shorewall configuration. See above for a recommended way to make - changes. - - - - - check (Shorewall 2.2.0 and later) + check shorewall [-q] check [ <configuration-directory> ] Performs a cursory validation of the zones, interfaces, hosts, - rules and policy files. Use this if you are unsure of any edits you - have made to the shorewall configuration. See above for a recommended way to make - changes. + rules, policy, masq, blacklist, proxyarp, nat and provider files. + Use this if you are unsure of any edits you have made to the + shorewall configuration. See above + for a recommended way to make changes. @@ -568,12 +542,6 @@ Deletes the specified interface (and host list if included) from the specified zone. - Note that there was no provision in the syntax for specifying - a bridge port prior to Shorewall - versions 2.0.12 and 2.2.0 Beta 7 and that the "shorewall delete" - command was not supported for hosts connected to the firewall - through a bridge port prior to those releases. - Example: shorewall delete ipsec0:192.0.2.24 @@ -595,6 +563,19 @@ + + dump + + + shorewall [ -x ] dump + + Produce a verbose report about the firewall. + + When -x is given, that option is also passed to iptables to + display actual packet and byte counts. + + + forget @@ -679,22 +660,6 @@ - - monitor - - - shorewall [-x] monitor - [<refresh_interval>] - - Continuously display the firewall status, last 20 log entries - and nat. When the log entry display changes, an audible alarm is - sounded. - - When -x is given, that option is also passed to iptables to - display actual packet and byte counts. - - - refresh @@ -733,21 +698,7 @@ - restart (Prior to Shorewall version 2.2.0) - - - shorewall [ -q ] [ -c <configuration-directory> - ] restart - - Restart is similar to shorewall stop - followed by shorewall start. Existing connections - are maintained. If -q is specified, less detail is displayed making - it easier to spot warnings - - - - - restart (Shorewall version 2.2.0 and later) + restart shorewall [ -q ] restart @@ -781,7 +732,7 @@ - safe-restart (Shorewall version 2.4.0 and later) + safe-restart shorewall [ -q ] safe-restart [ <filename> @@ -800,7 +751,7 @@ - safe-start (Shorewall version 2.4.0 and later) + safe-start shorewall [ -q ] safe-start [ <filename> @@ -853,9 +804,8 @@ shorewall show log - display the last 20 packet log entries. - shorewall show capabilities - Added in - Shorewall version 2.2.4 and displays your kernel/iptables - capabilities + shorewall show capabilities - Displays your + kernel/iptables capabilities shorewall show connections - displays the IP connections currently being tracked by the firewall. @@ -866,11 +816,8 @@ shorewall show tc - displays information about the traffic control/shaping configuration. - shorewall show zones — Added in Shorewall - version 2.2.0 Beta 7. Enabled when Shorewall is [re]started with - DYNAMIC_ZONES=Yes in /etc/shorewall/shorewall.conf. - Displays the composition of each zone. + shorewall show zones — Displays the + composition of each zone. When -x is given, that option is also passed to iptables to display actual packet and byte counts. @@ -878,25 +825,7 @@ - start (Shorewall versions prior to 2.2.0) - - - shorewall [ -q ] [ -f ] [ -c - <configuration-directory> ] start - - Start shorewall. Existing connections through shorewall - managed interfaces are untouched. New connections will be allowed - only if they are allowed by the firewall rules or policies. If -q is - specified, less detail is displayed making it easier to spot - warnings If -f is specified, the saved configuration specified by - the RESTOREFILE option in /etc/shorewall/shorewall.conf - will be restored if that saved configuration exists - - - - - start (Shorewall 2.2.0 and later) + start shorewall [ -q ] [ -f ] start [ @@ -935,12 +864,10 @@ status - shorewall [ -x ] status + shorewall status - Produce a verbose report about the firewall. - - When -x is given, that option is also passed to iptables to - display actual packet and byte counts. + Produce a short report about the firewall's status and state + relative to the diagram below. @@ -1020,9 +947,8 @@ firewall stop Only traffic to/from hosts listed in /etc/shorewall/hosts - is passed to/from/through the firewall. For Shorewall versions - beginning with 1.4.7, if ADMINISABSENTMINDED=Yes in - /etc/shorewall/shorewall.conf then in addition, all existing + is passed to/from/through the firewall. If ADMINISABSENTMINDED=Yes + in /etc/shorewall/shorewall.conf then in addition, all existing connections are retained and all connection requests from the firewall are accepted. diff --git a/Shorewall-docs2/support.xml b/Shorewall-docs2/support.xml index d46e17b34..77ca3f3ab 100644 --- a/Shorewall-docs2/support.xml +++ b/Shorewall-docs2/support.xml @@ -15,7 +15,7 @@ - 2005-07-19 + 2005-08-30 2001-2005 @@ -41,6 +41,13 @@ + + This article applies to Shorewall 3.0 and + later. If you are running a version of Shorewall earlier than Shorewall + 3.0.0 then please see the documentation for that + release. + +
Before Reporting a Problem or Asking a Question @@ -49,14 +56,14 @@ - The two currently-supported Shorewall major releases are 2.4 and 2.2. + The three currently-supported Shorewall major releases are 3.0, 2.4 and 2.2. Because of the short time between the releases of 2.2.0 and 2.4.0, - Shorewall 2.0 will be supported until 1 December 2005 or until the - release of 2.6.0, whichever comes first. + Shorewall 2.2 will be supported until 1 December 2006 or until the + release of 3.1.0, whichever comes first. - Shorewall versions earlier than 2.0.0 are no longer supported; + Shorewall versions earlier than 2.2.0 are no longer supported; we will only answer your question if it deals with upgrading from these old releases to a current one. @@ -134,32 +141,32 @@ gateway:~# the following command:
- /sbin/shorewall show shorewall + /sbin/shorewall status shorewall
If Shorewall has started successfully, you will see output similar to this:
- Shorewall-2.2.3 Chain shorewall at gateway - Wed Apr 20 14:41:53 PDT 2005 + Shorewall-2.5.4 Status at gateway - Tue Aug 30 14:07:29 PDT 2005 -Counters reset Sat Apr 16 17:35:06 PDT 2005 - -Chain shorewall (0 references) - pkts bytes target prot opt in out source destination +Shorewall is running +State:Started (Tue Aug 30 07:18:07 PDT 2005)
If Shorewall has not started properly, you will see output similar to this:
- Shorewall-2.2.3 Chain shorewall at gateway - Wed Apr 20 14:43:13 PDT 2005 + Shorewall-2.5.4 Status at gateway - Tue Aug 30 14:08:11 PDT 2005 -Counters reset Sat Apr 16 17:35:06 PDT 2005 - -iptables: No chain/target/match by that name - +Shorewall is stopped +State:Stopped (Tue Aug 30 14:08:11 PDT 2005)
+ + The "State:" refers to the Shorewall State + Diagram. @@ -182,7 +189,7 @@ Counters reset Sat Apr 16 17:35:06 PDT 2005 - /sbin/shorewall status > + /sbin/shorewall dump > /tmp/status.txt