From 5c4c7d8f41e93b170eb2acd3bb846b0dc9fd613d Mon Sep 17 00:00:00 2001 From: teastep Date: Tue, 18 Feb 2003 01:51:36 +0000 Subject: [PATCH] Allow comma-separated list in routestopped file entries; update documentation git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@452 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- .../documentation/Shorewall_Squid_Usage.html | 788 +++---- STABLE/documentation/errata.htm | 1077 ++++----- STABLE/documentation/three-interface_fr.html | 2027 +++++++++-------- STABLE/firewall | 6 +- 4 files changed, 2026 insertions(+), 1872 deletions(-) diff --git a/STABLE/documentation/Shorewall_Squid_Usage.html b/STABLE/documentation/Shorewall_Squid_Usage.html index a310704f3..814a48dcd 100644 --- a/STABLE/documentation/Shorewall_Squid_Usage.html +++ b/STABLE/documentation/Shorewall_Squid_Usage.html @@ -2,368 +2,332 @@ Shorewall Squid Usage - + - + - + - - - + - + - - - - +
+ + + +
+
-
-
+ 		Using Shorewall with Squid
- 		+ -
-
-
- This page covers Shorewall configuration to use with Squid running as a Transparent - Proxy. 
-
- + This page covers Shorewall configuration to use with Squid running as a Transparent + Proxy. 
+
+ Caution -     Please observe the following general requirements:
-
- -     In all cases, Squid should be configured to run -as a transparent proxy as described at +
+ +     In all cases, Squid should be configured to run + as a transparent proxy as described at http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html.
-
- -     The following instructions mention the files /etc/shorewall/start - and /etc/shorewall/init -- if you don't have those files, siimply create -them.
-
- -     When the Squid server is in the DMZ zone or in -the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts - file entries. That is because the packets being routed to the Squid server - still have their original destination IP addresses.
-
- -     You must have iproute2 (ip utility) installed - on your firewall.
-
- -     You must have iptables installed on your Squid -server.
-
- -     You must have NAT and MANGLE enabled in your /etc/shorewall/conf - file
-
-         NAT_ENABLED=Yes
-         MANGLE_ENABLED=Yes
-
- Three different configurations are covered:
- +
+ +     The following instructions mention the files /etc/shorewall/start + and /etc/shorewall/init -- if you don't have those files, siimply create + them.
+
+ +     When the Squid server is in the DMZ zone or in + the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts + file entries. That is because the packets being routed to the Squid server + still have their original destination IP addresses.
+
+ +     You must have iproute2 (ip utility) installed + on your firewall.
+
+ +     You must have iptables installed on your Squid + server.
+
+ +     You must have NAT and MANGLE enabled in your +/etc/shorewall/conf file
+
+         NAT_ENABLED=Yes
+         MANGLE_ENABLED=Yes
+
+ Three different configurations are covered:
+
    -
  1. Squid running on the - Firewall.
    2. -
  2. Squid running in the +
  3. Squid running on +the Firewall.
    4. +
  4. Squid running in the local network
    5. -
  5. Squid running in the DMZ
    6. - +
  6. Squid running in the DMZ
    7. +
- +

Squid Running on the Firewall

- 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 + 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.
-
- In /etc/shorewall/rules:
-
+
+ In /etc/shorewall/rules:
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ACTIONSOURCEDEST PROTODEST
+ PORT(S)		SOURCE
+ PORT(S)		ORIGINAL
+ DEST
REDIRECTloc3128tcpwww -
+ 		!206.124.146.177
ACCEPTfwnettcpwww
+
+
+
+
+ +

Squid Running in the local network

+ You want to redirect all local www connection requests to a Squid + transparent proxy +running in your local zone at 192.168.1.3 and listening on port 3128. + Your local interface is eth1. There may also be a web server running on +192.168.1.3. It is assumed that web access is already enabled from the local +zone to the internet.
+ +

WARNING: This setup may conflict with + other aspects of your gateway including but not limited to traffic shaping + and route redirection. For that reason, I don't recommend it.
+

+ + + +
+ 
echo 202 www.out >> /etc/iproute2/rt_tables
+
+ + + +
+ 
if [ -z "`ip rule list | grep www.out`" ] ; then
	ip rule add fwmark 202 table www.out
	ip route add default via 192.168.1.3 dev eth1 table www.out
	ip route flush cache
	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
fi
+
+ +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
-
+ 
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
-

Squid Running in the local network

- You want to redirect all local www connection requests to a Squid - transparent proxy - running in your local zone at 192.168.1.3 and listening on port 3128. -Your local interface is eth1. There may also be a web server running on 192.168.1.3. -It is assumed that web access is already enabled from the local zone to the -internet.
- -

WARNING: This setup may conflict with - other aspects of your gateway including but not limited to traffic shaping - and route redirection. For that reason, I don't recommend it.
-

- - -
- 
echo 202 www.out >> /etc/iproute2/rt_tables
-
- - - -
- 
if [ -z "`ip rule list | grep www.out`" ] ; then
	ip rule add fwmark 202 table www.out
	ip route add default via 192.168.1.3 dev eth1 table www.out
	ip route flush cache
	echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects
fi
-
- - - -
- 
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202
-
- - - -
If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
-
-
+
If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
+
+ +
- + 
iptables-save > /etc/sysconfig/iptables
chkconfig --level 35 iptables start
-
- +
+
- +

Squid Running in the DMZ (This is what I do)

- You have a single Linux system in your DMZ with IP address 192.0.2.177. - You want to run both a web server and Squid on that system. Your DMZ interface + You have a single Linux system in your DMZ with IP address 192.0.2.177. + You want to run both a web server and Squid on that system. Your DMZ interface is eth1 and your local interface is eth2.
- + - -
+ +
echo 202 www.out >> /etc/iproute2/rt_tables
-
- +
+ + +
+ 
if [ -z "`ip rule list | grep www.out`" ] ; then
	ip rule add fwmark 202 table www.out
	ip route add default via 192.0.2.177 dev eth1 table www.out
	ip route flush cache
fi
+
+ + - -
- 
if [ -z "`ip rule list | grep www.out`" ] ; then
	ip rule add fwmark 202 table www.out
	ip route add default via 192.0.2.177 dev eth1 table www.out
	ip route flush cache
fi
-
- - - -
+ +
	iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202
-
- -
B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf +
+ +
B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf and add the following entry in /etc/shorewall/tcrules:
-
-
-
- - - - - - - - - - - - - - - - - - - -
MARK
- 		SOURCE
- 		DESTINATION
- 		PROTOCOL
- 		PORT
- 		CLIENT PORT
-
202
- 		eth2
- 		0.0.0.0/0
- 		tcp
- 		80
- 		-
-
-
-C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
-
+
+
@@ -383,7 +347,7 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t - @@ -400,90 +364,130 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t
202:P
+ 		202
 eth2
-
-
+ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:
+ + +
+
+ + + + + + + + + + + + + + + + + + + + +
MARK
+ 		SOURCE
+ 		DESTINATION
+ 		PROTOCOL
+ 		PORT
+ 		CLIENT PORT
+
202:P
+ 		eth2
+ 		0.0.0.0/0
+ 		tcp
+ 		80
+ 		-
+
+
+
+
+ - -
- - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		CLIENT
- PORT(2)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		dmz
- 		net
- 		tcp
- 		80
-
-
-
-
-
- - - -
If you are running RedHat on the server, you can simply execute - the following commands after you have typed the iptables command above:
-
- +
+ + + + + + + + + + + + + + + + + + + + + + +
ACTION
+ 		SOURCE
+ 		DEST
+ 		PROTO
+ 		DEST
+ PORT(S)
+ 		CLIENT
+ PORT(2)
+ 		ORIGINAL
+ DEST
+
ACCEPT
+ 		dmz
+ 		net
+ 		tcp
+ 		80
+
+
+
+
+
+ + + +
If you are running RedHat on the server, you can simply execute + the following commands after you have typed the iptables command above:
+
+ +
- + 
iptables-save > /etc/sysconfig/iptables
chkconfig --level 35 iptables start
-
- + +
- -

Updated 1/23/2003 - Tom Eastep -

+ +

Updated 1/23/2003 - Tom Eastep +

- Copyright © 2003 Thomas M. Eastep.
-
-
-
+
+
+
+


diff --git a/STABLE/documentation/errata.htm b/STABLE/documentation/errata.htm index 5a2a445dd..604c1a5a4 100644 --- a/STABLE/documentation/errata.htm +++ b/STABLE/documentation/errata.htm @@ -2,649 +2,662 @@ - + Shorewall 1.3 Errata - + + - + - + - + - - - + + - + + - - -
+
- +

Shorewall Errata/Upgrade Issues

-
- -

IMPORTANT

- -
    -
  1. - -

    If you use a Windows system to download - a corrected script, be sure to run the script through - dos2unix after you have moved - it to your Linux system.

    -
    2. -
  2. - -

    If you are installing Shorewall for the -first time and plan to use the .tgz and install.sh script, you can -untar the archive, replace the 'firewall' script in the untarred directory - with the one you downloaded below, and then run install.sh.

    -
    3. -
  3. - -

    If you are running a Shorewall version earlier - than 1.3.11, when the instructions say to install a corrected firewall - script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall - or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to -overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD -/etc/shorewall/firewall or /var/lib/shorewall/firewall before -you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall - are symbolic links that point to the 'shorewall' file used by -your system initialization scripts to start Shorewall during -boot. It is that file that must be overwritten with the corrected -script. Beginning with Shorewall 1.3.11, you may rename the existing file -before copying in the new file.

    -
    4. -
  4. -

    DO NOT INSTALL CORRECTED COMPONENTS - ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. -For example, do NOT install the 1.3.9a firewall script if you are running + + + +

    IMPORTANT

    + +
      +
    1. + +

      If you use a Windows system to download + a corrected script, be sure to run the script through + dos2unix after you have moved + it to your Linux system.

      +
      2. +
    2. + +

      If you are installing Shorewall for the first +time and plan to use the .tgz and install.sh script, you can untar +the archive, replace the 'firewall' script in the untarred directory + with the one you downloaded below, and then run install.sh.

      +
      3. +
    3. + +

      If you are running a Shorewall version earlier + than 1.3.11, when the instructions say to install a corrected firewall + script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall + or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to overwrite + the existing file. DO NOT REMOVE OR RENAME THE OLD /etc/shorewall/firewall + or /var/lib/shorewall/firewall before you do that. /etc/shorewall/firewall + and /var/lib/shorewall/firewall are symbolic links that point + to the 'shorewall' file used by your system initialization scripts + to start Shorewall during boot. It is that file that must be +overwritten with the corrected script. Beginning with Shorewall +1.3.11, you may rename the existing file before copying in the new file.

      +
      4. +
    4. + +

      DO NOT INSTALL CORRECTED COMPONENTS + ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. +For example, do NOT install the 1.3.9a firewall script if you are running 1.3.7c.
      -

      -
      5. - +

      + +
    - + - -
    + +

    Problems in Version 1.3

    - -

    Version 1.3.13

    - + +

    Version 1.3.14

      -
    • The 'shorewall add' command produces an error message referring -to 'find_interfaces_by_maclist'.
      • -
    • The 'shorewall delete' command can leave behind undeleted rules.
      • -
    • The 'shorewall add' command can fail with "iptables: Index of insertion -too big".
      +
    • There is an updated +rfc1918 file that reflects the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.
      • +
    • The documentation for the routestopped file claimed that a comma-separated +list could appear in the second column while the code only supported a single +host or network address. This has been corrected in this +firewall script which may be installed in /usr/lib/shorewall as described +above.
      • -
    - All three problems are corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
    - -
      -
    • VLAN interface names of the form "ethn.m" (e.g., eth0.1) -are not supported in this version or in 1.3.12. If you need such support, -post on the users list and I can provide you with a patched version.
      -
      • - -
    - -

    Version 1.3.12

    +

    Version 1.3.13

      -
    • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect is - the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem -is corrected by this - firewall script which may be installed in /usr/lib/shorewall as described - above.
      • -
    • VLAN interface names of the form "ethn.m" (e.g., eth0.1) - are not supported in this version or in 1.3.13. If you need such support, +
    • The 'shorewall add' command produces an error message referring +to 'find_interfaces_by_maclist'.
      • +
    • The 'shorewall delete' command can leave behind undeleted rules.
      • +
    • The 'shorewall add' command can fail with "iptables: Index of insertion +too big".
      +
      • + +
    + All three problems are corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
    + +
      +
    • VLAN interface names of the form "ethn.m" (e.g., eth0.1) + are not supported in this version or in 1.3.12. If you need such support, post on the users list and I can provide you with a patched version.
      • - +
    - -

    Version 1.3.12 LRP

    + +

    Version 1.3.12

      -
    • The .lrp was missing the /etc/shorewall/routestopped file -- a -new lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.
      -
      • +
    • If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect +is the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem +is corrected by this + firewall script which may be installed in /usr/lib/shorewall as described + above.
      • +
    • VLAN interface names of the form "ethn.m" (e.g., eth0.1) + are not supported in this version or in 1.3.13. If you need such support, + post on the users list and I can provide you with a patched version.
      +
    -

    Version 1.3.11a

    +

    Version 1.3.12 LRP

      -
    • This - copy of /etc/shorewall/rfc1918 reflects the recent allocation of 82.0.0.0/8.
      +
    • The .lrp was missing the /etc/shorewall/routestopped file -- +a new lrp (shorwall-1.3.12a.lrp) has been released which corrects this +problem.
    +

    Version 1.3.11a

    + + +

    Version 1.3.11

    - +
      -
    • When installing/upgrading using the .rpm, you may receive +
    • When installing/upgrading using the .rpm, you may receive the following warnings:
      -
      -      user teastep does not exist - using root
      -      group teastep does not exist - using root
      -
      - These warnings are harmless and may be ignored. Users downloading - the .rpm from shorewall.net or mirrors should no longer see these warnings +
      +      user teastep does not exist - using root
      +      group teastep does not exist - using root
      +
      + These warnings are harmless and may be ignored. Users downloading + the .rpm from shorewall.net or mirrors should no longer see these warnings as the .rpm you will get from there has been corrected.
      • -
    • DNAT rules that exclude a source subzone (SOURCE column contains - ! followed by a sub-zone list) result in an error message and Shorewall +
    • DNAT rules that exclude a source subzone (SOURCE column contains + ! followed by a sub-zone list) result in an error message and Shorewall fails to start.
      +
      + Install this + corrected script in /usr/lib/shorewall/firewall to correct this problem. + Thanks go to Roger Aich who analyzed this problem and provided a fix.

      - Install this - corrected script in /usr/lib/shorewall/firewall to correct this problem. - Thanks go to Roger Aich who analyzed this problem and provided a fix.
      -
      - This problem is corrected in version 1.3.11a.
      -
      • - + This problem is corrected in version 1.3.11a.
      + +
    - +

    Version 1.3.10

    - +
      -
    • If you experience problems connecting to a PPTP server running - on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, +
    • If you experience problems connecting to a PPTP server +running on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels, this - version of the firewall script may help. Please report any cases -where installing this script in /usr/lib/shorewall/firewall solved your -connection problems. Beginning with version 1.3.10, it is safe to save -the old version of /usr/lib/shorewall/firewall before copying in the -new one since /usr/lib/shorewall/firewall is the real script now and -not just a symbolic link to the real script.
      -
      • - + href="http://www.shorewall.net/pub/shorewall/errata/1.3.10/firewall">this + version of the firewall script may help. Please report any cases +where installing this script in /usr/lib/shorewall/firewall solved your +connection problems. Beginning with version 1.3.10, it is safe to save +the old version of /usr/lib/shorewall/firewall before copying in the new +one since /usr/lib/shorewall/firewall is the real script now and not +just a symbolic link to the real script.
      + +
    - +

    Version 1.3.9a

    - -
      -
    • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No - then the following message appears during "shorewall [re]start":
      • - -
    +
      +
    • If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No + then the following message appears during "shorewall [re]start":
      • + +
    + 
              recalculate_interfacess: command not found
    - +
    The updated firewall script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - corrects this problem.Copy the script to /usr/lib/shorewall/firewall - as described above.
    -
    - -
    Alternatively, edit /usr/lob/shorewall/firewall and change the - single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' - to 'recalculate_interface'.
    -
    - -
      -
    • The installer (install.sh) issues a misleading message -"Common functions installed in /var/lib/shorewall/functions" whereas -the file is installed in /usr/lib/shorewall/functions. The installer -also performs incorrectly when updating old configurations that had the -file /etc/shorewall/functions. Here - is an updated version that corrects these problems.
      -
      • - -
    + target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + corrects this problem.Copy the script to /usr/lib/shorewall/firewall + as described above.
    + + +
    Alternatively, edit /usr/lob/shorewall/firewall and change the + single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess' + to 'recalculate_interface'.
    +
    -

    Version 1.3.9

    - TUNNELS Broken in 1.3.9!!! There is an updated firewall - script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall as described above.
    -
    - Version 1.3.8
      -
    • Use of shell variables in the LOG LEVEL or SYNPARMS - columns of the policy file doesn't work.
      • -
    • A DNAT rule with the same original and new IP addresses - but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 - tcp 25 - 10.1.1.1")
      -
      • - +
    • The installer (install.sh) issues a misleading message +"Common functions installed in /var/lib/shorewall/functions" whereas +the file is installed in /usr/lib/shorewall/functions. The installer also +performs incorrectly when updating old configurations that had the file +/etc/shorewall/functions. Here + is an updated version that corrects these problems.
      +
      • +
    - Installing - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects these -problems. -

    Version 1.3.7b

    - -

    DNAT rules where the source zone is 'fw' ($FW) - result in an error message. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this -problem.

    - -

    Version 1.3.7a

    - -

    "shorewall refresh" is not creating the proper - rule for FORWARDPING=Yes. Consequently, after - "shorewall refresh", the firewall will not forward - icmp echo-request (ping) packets. Installing - - this corrected firewall script in /var/lib/shorewall/firewall - as described above corrects this -problem.

    - -

    Version <= 1.3.7a

    - -

    If "norfc1918" and "dhcp" are both specified as - options on a given interface then RFC 1918 - checking is occurring before DHCP checking. This - means that if a DHCP client broadcasts using an - RFC 1918 source address, then the firewall will - reject the broadcast (usually logging it). This - has two problems:

    - -
      -
    1. If the firewall is -running a DHCP server, the client -won't be able to obtain an IP address - lease from that server.
      2. -
    2. With this order of -checking, the "dhcp" option cannot -be used as a noise-reduction measure -where there are both dynamic and static - clients on a LAN segment.
      3. - -
    - - -

    - This version of the 1.3.7a firewall script - corrects the problem. It must be installed - in /var/lib/shorewall as described - above.

    - -

    Version 1.3.7

    - -

    Version 1.3.7 dead on arrival -- please use - version 1.3.7a and check your version against - these md5sums -- if there's a difference, please - download again.

    - -
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    - -

    In other words, type "md5sum <whatever package you downloaded> - and compare the result with what you see above.

    - -

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the - .7 version in each sequence from now on.

    - -

    Version 1.3.6

    - + +

    Version 1.3.9

    + TUNNELS Broken in 1.3.9!!! There is an updated firewall + script at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall as described above.
    +
    + Version 1.3.8
      -
    • - - -

      If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, - an error occurs when the firewall script attempts to -add an SNAT alias.

      -
      • -
    • - -

      The logunclean and dropunclean options - cause errors during startup when Shorewall is run with iptables - 1.2.7.

      +
    • Use of shell variables in the LOG LEVEL or SYNPARMS + columns of the policy file doesn't work.
      • +
    • A DNAT rule with the same original and new IP addresses + but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24 + tcp 25 - 10.1.1.1")
    - -

    These problems are fixed in - this correct firewall script which must be installed in - /var/lib/shorewall/ as described above. These problems are also - corrected in version 1.3.7.

    - -

    Two-interface Samples 1.3.6 (file two-interfaces.tgz)

    - -

    A line was inadvertently deleted from the "interfaces - file" -- this line should be added back in if the version that you - downloaded is missing it:

    - -

    net    eth0    detect    routefilter,dhcp,norfc1918

    - -

    If you downloaded two-interfaces-a.tgz then the above - line should already be in the file.

    - -

    Version 1.3.5-1.3.5b

    - -

    The new 'proxyarp' interface option doesn't work :-( - This is fixed in - this corrected firewall script which must be installed in - /var/lib/shorewall/ as described above.

    - -

    Versions 1.3.4-1.3.5a

    - -

    Prior to version 1.3.4, host file entries such as the - following were allowed:

    - -
    -
    	adm	eth0:1.2.4.5,eth0:5.6.7.8
    -
    - -
    -

    That capability was lost in version 1.3.4 so that it is only - possible to  include a single host specification on each line. - This problem is corrected by this - modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall - as instructed above.

    -
    - -
    -

    This problem is corrected in version 1.3.5b.

    -
    - -

    Version 1.3.5

    - -

    REDIRECT rules are broken in this version. Install - - this corrected firewall script in /var/lib/pub/shorewall/firewall - as instructed above. This problem is corrected in version - 1.3.5a.

    - -

    Version 1.3.n, n < 4

    - -

    The "shorewall start" and "shorewall restart" commands - to not verify that the zones named in the /etc/shorewall/policy -file have been previously defined in the /etc/shorewall/zones -file. The "shorewall check" command does perform this verification -so it's a good idea to run that command after you have made configuration - changes.

    - -

    Version 1.3.n, n < 3

    - -

    If you have upgraded from Shorewall 1.2 and after - "Activating rules..." you see the message: "iptables: No chains/target/match - by that name" then you probably have an entry in /etc/shorewall/hosts - that specifies an interface that you didn't include in - /etc/shorewall/interfaces. To correct this problem, you - must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 -and later versions produce a clearer error message in this -case.

    - -

    Version 1.3.2

    - -

    Until approximately 2130 GMT on 17 June 2002, the - download sites contained an incorrect version of the .lrp file. That - file can be identified by its size (56284 bytes). The correct -version has a size of 38126 bytes.

    - -
      -
    • The code to detect a duplicate interface - entry in /etc/shorewall/interfaces contained a typo that prevented - it from working correctly.
      • -
    • "NAT_BEFORE_RULES=No" was broken; it behaved - just like "NAT_BEFORE_RULES=Yes".
      • - -
    - -

    Both problems are corrected in - this script which should be installed in /var/lib/shorewall - as described above.

    - -
      -
    • + Installing + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects these +problems. +

      Version 1.3.7b

      + +

      DNAT rules where the source zone is 'fw' ($FW) + result in an error message. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this problem.

      + +

      Version 1.3.7a

      + +

      "shorewall refresh" is not creating the proper + rule for FORWARDPING=Yes. Consequently, after + "shorewall refresh", the firewall will not forward + icmp echo-request (ping) packets. Installing + + this corrected firewall script in /var/lib/shorewall/firewall + as described above corrects this problem.

      + +

      Version <= 1.3.7a

      + +

      If "norfc1918" and "dhcp" are both specified as + options on a given interface then RFC 1918 + checking is occurring before DHCP checking. This + means that if a DHCP client broadcasts using an + RFC 1918 source address, then the firewall will + reject the broadcast (usually logging it). This + has two problems:

      + +
        +
      1. If the firewall is + running a DHCP server, the client + won't be able to obtain an IP address + lease from that server.
        2. +
      2. With this order of + checking, the "dhcp" option cannot + be used as a noise-reduction measure + where there are both dynamic and static + clients on a LAN segment.
        3. + +
      - -

      The IANA have just announced the allocation of subnet - 221.0.0.0/8. This - updated rfc1918 file reflects that allocation.

      -
      • - -
    - -

    Version 1.3.1

    - + +

    + This version of the 1.3.7a firewall script + corrects the problem. It must be +installed in /var/lib/shorewall as +described above.

    + +

    Version 1.3.7

    + +

    Version 1.3.7 dead on arrival -- please use + version 1.3.7a and check your version against + these md5sums -- if there's a difference, please + download again.

    + +
    	d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz
    	6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm
    	3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp
    + +

    In other words, type "md5sum <whatever package you downloaded> + and compare the result with what you see above.

    + +

    I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the + .7 version in each sequence from now on.

    + +

    Version 1.3.6

    +
      -
    • TCP SYN packets may be double counted -when LIMIT:BURST is included in a CONTINUE or ACCEPT policy -(i.e., each packet is sent through the limit chain twice).
      • -
    • An unnecessary jump to the policy chain - is sometimes generated for a CONTINUE policy.
      • -
    • When an option is given for more than -one interface in /etc/shorewall/interfaces then depending - on the option, Shorewall may ignore all but the first -appearence of the option. For example:
      -
      - net    eth0    dhcp
      - loc    eth1    dhcp
      -
      - Shorewall will ignore the 'dhcp' on eth1.
      • -
    • Update 17 June 2002 - The bug described - in the prior bullet affects the following options: dhcp, - dropunclean, logunclean, norfc1918, routefilter, multi, - filterping and noping. An additional bug has been found - that affects only the 'routestopped' option.
      -
      - Users who downloaded the corrected script -prior to 1850 GMT today should download and install -the corrected script again to ensure that this second -problem is corrected.
      • - +
    • + + +

      If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf, + an error occurs when the firewall script attempts to add + an SNAT alias.

      +
      • +
    • + + +

      The logunclean and dropunclean options + cause errors during startup when Shorewall is run with iptables + 1.2.7.

      +
      • +
    - -

    These problems are corrected in - this firewall script which should be installed in /etc/shorewall/firewall + +

    These problems are fixed in + this correct firewall script which must be installed in + /var/lib/shorewall/ as described above. These problems are also + corrected in version 1.3.7.

    + +

    Two-interface Samples 1.3.6 (file two-interfaces.tgz)

    + +

    A line was inadvertently deleted from the "interfaces + file" -- this line should be added back in if the version that you + downloaded is missing it:

    + +

    net    eth0    detect    routefilter,dhcp,norfc1918

    + +

    If you downloaded two-interfaces-a.tgz then the above + line should already be in the file.

    + +

    Version 1.3.5-1.3.5b

    + +

    The new 'proxyarp' interface option doesn't work :-( + This is fixed in + this corrected firewall script which must be installed in + /var/lib/shorewall/ as described above.

    + +

    Versions 1.3.4-1.3.5a

    + +

    Prior to version 1.3.4, host file entries such as the + following were allowed:

    + +
    +
    	adm	eth0:1.2.4.5,eth0:5.6.7.8
    +
    + +
    +

    That capability was lost in version 1.3.4 so that it is only + possible to  include a single host specification on each line. + This problem is corrected by this + modified 1.3.5a firewall script. Install the script in /var/lib/pub/shorewall/firewall + as instructed above.

    +
    + +
    +

    This problem is corrected in version 1.3.5b.

    +
    + +

    Version 1.3.5

    + +

    REDIRECT rules are broken in this version. Install + + this corrected firewall script in /var/lib/pub/shorewall/firewall + as instructed above. This problem is corrected in version + 1.3.5a.

    + +

    Version 1.3.n, n < 4

    + +

    The "shorewall start" and "shorewall restart" commands + to not verify that the zones named in the /etc/shorewall/policy file + have been previously defined in the /etc/shorewall/zones file. +The "shorewall check" command does perform this verification so +it's a good idea to run that command after you have made configuration + changes.

    + +

    Version 1.3.n, n < 3

    + +

    If you have upgraded from Shorewall 1.2 and after + "Activating rules..." you see the message: "iptables: No chains/target/match + by that name" then you probably have an entry in /etc/shorewall/hosts + that specifies an interface that you didn't include in + /etc/shorewall/interfaces. To correct this problem, you + must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3 and + later versions produce a clearer error message in this case.

    + +

    Version 1.3.2

    + +

    Until approximately 2130 GMT on 17 June 2002, the + download sites contained an incorrect version of the .lrp file. That + file can be identified by its size (56284 bytes). The correct version + has a size of 38126 bytes.

    + +
      +
    • The code to detect a duplicate interface + entry in /etc/shorewall/interfaces contained a typo that +prevented it from working correctly.
      • +
    • "NAT_BEFORE_RULES=No" was broken; it +behaved just like "NAT_BEFORE_RULES=Yes".
      • + +
    + +

    Both problems are corrected in + this script which should be installed in /var/lib/shorewall as described above.

    - -

    Version 1.3.0

    - +
      -
    • Folks who downloaded 1.3.0 from the links - on the download page before 23:40 GMT, 29 May 2002 may - have downloaded 1.2.13 rather than 1.3.0. The "shorewall - version" command will tell you which version that you - have installed.
      • -
    • The documentation NAT.htm file uses non-existent - wallpaper and bullet graphic files. The - corrected version is here.
      • - +
    • + + +

      The IANA have just announced the allocation of subnet + 221.0.0.0/8. This + updated rfc1918 file reflects that allocation.

      +
      • +
    - -
    + +

    Version 1.3.1

    + +
      +
    • TCP SYN packets may be double counted +when LIMIT:BURST is included in a CONTINUE or ACCEPT policy +(i.e., each packet is sent through the limit chain twice).
      • +
    • An unnecessary jump to the policy chain + is sometimes generated for a CONTINUE policy.
      • +
    • When an option is given for more than +one interface in /etc/shorewall/interfaces then depending + on the option, Shorewall may ignore all but the first +appearence of the option. For example:
      +
      + net    eth0    dhcp
      + loc    eth1    dhcp
      +
      + Shorewall will ignore the 'dhcp' on eth1.
      • +
    • Update 17 June 2002 - The bug described + in the prior bullet affects the following options: dhcp, + dropunclean, logunclean, norfc1918, routefilter, multi, + filterping and noping. An additional bug has been found + that affects only the 'routestopped' option.
      +
      + Users who downloaded the corrected script +prior to 1850 GMT today should download and install the +corrected script again to ensure that this second problem +is corrected.
      • + +
    + +

    These problems are corrected in + this firewall script which should be installed in /etc/shorewall/firewall + as described above.

    + +

    Version 1.3.0

    + +
      +
    • Folks who downloaded 1.3.0 from the links + on the download page before 23:40 GMT, 29 May 2002 may + have downloaded 1.2.13 rather than 1.3.0. The "shorewall + version" command will tell you which version that you + have installed.
      • +
    • The documentation NAT.htm file uses non-existent + wallpaper and bullet graphic files. The + corrected version is here.
      • + +
    + +

    Upgrade Issues

    - +

    The upgrade issues have moved to a separate page.

    - -
    -

    Problem with + +
    +

    Problem with iptables version 1.2.3

    - -
    - -

    There are a couple of serious bugs in iptables 1.2.3 that - prevent it from working with Shorewall. Regrettably, RedHat - released this buggy iptables in RedHat 7.2. 

    + +
    + +

    There are a couple of serious bugs in iptables 1.2.3 that + prevent it from working with Shorewall. Regrettably, RedHat + released this buggy iptables in RedHat 7.2. 

    - +

    I have built a - corrected 1.2.3 rpm which you can download here  and I have -also built an -iptables-1.2.4 rpm which you can download here. If you are currently - running RedHat 7.1, you can install either of these RPMs - before you upgrade to RedHat 7.2.

    + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm"> + corrected 1.2.3 rpm which you can download here  and I have + also built an + iptables-1.2.4 rpm which you can download here. If you are currently + running RedHat 7.1, you can install either of these RPMs + before you upgrade to RedHat 7.2.

    - -

    Update 11/9/2001: RedHat - has released an iptables-1.2.4 RPM of their own which you can -download from http://www.redhat.com/support/errata/RHSA-2001-144.html. - I have installed this RPM on my firewall and it works -fine.

    + +

    Update 11/9/2001: RedHat + has released an iptables-1.2.4 RPM of their own which you can download + from http://www.redhat.com/support/errata/RHSA-2001-144.html. + I have installed this RPM on my firewall and it works + fine.

    - -

    If you would like to patch iptables 1.2.3 yourself, + +

    If you would like to patch iptables 1.2.3 yourself, the patches are available for download. This patch - which corrects a problem with parsing of the --log-level specification + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch + which corrects a problem with parsing of the --log-level specification while this patch - corrects a problem in handling the  TOS target.

    + href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch + corrects a problem in handling the  TOS target.

    - +

    To install one of the above patches:

    - +
      -
    • cd iptables-1.2.3/extensions
      • -
    • patch -p0 < the-patch-file
      • +
    • cd iptables-1.2.3/extensions
      • +
    • patch -p0 < the-patch-file
      • - +
    -
    +
    - -

    Problems with kernels >= 2.4.18 - and RedHat iptables

    - -
    -

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 + +

    Problems with kernels >= 2.4.18 + and RedHat iptables

    + +
    +

    Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19 may experience the following:

    - -
    - + +
    + 
    # shorewall start
    Processing /etc/shorewall/shorewall.conf ...
    Processing /etc/shorewall/params ...
    Starting Shorewall...
    Loading Modules...
    Initializing...
    Determining Zones...
    Zones: net
    Validating interfaces file...
    Validating hosts file...
    Determining Hosts in Zones...
    Net Zone: eth0:0.0.0.0/0
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    iptables: libiptc/libip4tc.c:380: do_check: Assertion
    `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
    Aborted (core dumped)
    -
    +
    - -

    The RedHat iptables RPM is compiled with debugging enabled but the - user-space debugging code was not updated to reflect recent changes in - the Netfilter 'mangle' table. You can correct the problem by + +

    The RedHat iptables RPM is compiled with debugging enabled but the + user-space debugging code was not updated to reflect recent changes in + the Netfilter 'mangle' table. You can correct the problem by installing - this iptables RPM. If you are already running a 1.2.5 version - of iptables, you will need to specify the --oldpackage option to - rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    -
    + href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm"> + this iptables RPM. If you are already running a 1.2.5 version + of iptables, you will need to specify the --oldpackage option +to rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").

    +
    - -

    Problems installing/upgrading + +

    Problems installing/upgrading RPM on SuSE

    - -

    If you find that rpm complains about a conflict - with kernel <= 2.2 yet you have a 2.4 kernel - installed, simply use the "--nodeps" option to - rpm.

    - + +

    If you find that rpm complains about a conflict + with kernel <= 2.2 yet you have a 2.4 kernel + installed, simply use the "--nodeps" option to + rpm.

    +

    Installing: rpm -ivh --nodeps <shorewall rpm>

    - +

    Upgrading: rpm -Uvh --nodeps <shorewall rpm>

    - -

    Problems with - iptables version 1.2.7 and MULTIPORT=Yes

    - -

    The iptables 1.2.7 release of iptables has made - an incompatible change to the syntax used to - specify multiport match rules; as a consequence, - if you install iptables 1.2.7 you must be running - Shorewall 1.3.7a or later or:

    - + +

    Problems with + iptables version 1.2.7 and MULTIPORT=Yes

    + +

    The iptables 1.2.7 release of iptables has made + an incompatible change to the syntax used to + specify multiport match rules; as a consequence, + if you install iptables 1.2.7 you must be running + Shorewall 1.3.7a or later or:

    +
      -
    • set MULTIPORT=No in - /etc/shorewall/shorewall.conf; or
      • -
    • if you are running -Shorewall 1.3.6 you may install - - this firewall script in /var/lib/shorewall/firewall +
    • set MULTIPORT=No +in /etc/shorewall/shorewall.conf; or
      • +
    • if you are running + Shorewall 1.3.6 you may install + + this firewall script in /var/lib/shorewall/firewall as described above.
      • - +
    - +

    Problems with RH Kernel 2.4.18-10 and NAT
    -

    - /etc/shorewall/nat entries of the following form will result +

    + /etc/shorewall/nat entries of the following form will result in Shorewall being unable to start:
    -
    - +
    + 
    #EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL
    192.0.2.22      eth0            192.168.9.22    yes                     yes
    #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
    - Error message is:
    - + Error message is:
    + 
    Setting up NAT...
    iptables: Invalid argument
    Terminated

    - The solution is to put "no" in the LOCAL column. Kernel support - for LOCAL=yes has never worked properly and 2.4.18-10 has disabled it. - The 2.4.19 kernel contains corrected support under a new kernel configuraiton - option; see http://www.shorewall.net/Documentation.htm#NAT
    - -

    Last updated 2/8/2003 - - Tom Eastep

    - + The solution is to put "no" in the LOCAL column. Kernel support + for LOCAL=yes has never worked properly and 2.4.18-10 has disabled +it. The 2.4.19 kernel contains corrected support under a new kernel +configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
    + +

    Last updated 2/17/2003 - + Tom Eastep

    +

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

    +

    +



    diff --git a/STABLE/documentation/three-interface_fr.html b/STABLE/documentation/three-interface_fr.html index 1b35fce45..7fed307fa 100755 --- a/STABLE/documentation/three-interface_fr.html +++ b/STABLE/documentation/three-interface_fr.html @@ -1,1073 +1,1208 @@ + + + + Three-Interface Firewall - + + - - - + + - - + + + +
    +

    Three-Interface Firewall

    -
    +

    Version 2.0.1 Française

    +

    Notes du traducteur :
    -Je ne prétends pas être un vrai traducteur dans le sens ou mon travail -n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à -une traduction exacte du texte, mais plutôt à en faire une version -française intelligible par tous (et par moi). Les termes techniques sont -la plupart du temps conservés sous leur forme originale et mis entre -parenthèses car vous pouvez les retrouver dans le reste des -documentations ainsi que dans les fichiers de configuration. N?hésitez -pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM -pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP -pour son formidable outil et sa disponibilité).

    + Je ne prétends pas être un vrai traducteur dans le sens ou mon travail n?est +pas des plus précis (loin de là...). Je ne me suis pas attaché à une traduction +exacte du texte, mais plutôt à en faire une version française intelligible +par tous (et par moi). Les termes techniques sont la plupart du temps conservés +sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver +dans le reste des documentations ainsi que dans les fichiers de configuration. +N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM pour +sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour son +formidable outil et sa disponibilité).

    +


    -Mettre en place un système linux en tant que firewall pour un petit -réseau contenant une DMZ est une chose assez simple à réaliser si vous -comprenez les bases et suivez cette documentation.

    -

    Ce guide ne prétend pas vous mettre au courant de toutes les -possibilités de Shorewall. Il se focalise sur les besoins pour -configurer Shorewall dans une de ses utilisations les plus populaire :

    + Mettre en place un système linux en tant que firewall pour un petit réseau +contenant une DMZ est une chose assez simple à réaliser si vous comprenez +les bases et suivez cette documentation.

    + +

    Ce guide ne prétend pas vous mettre au courant de toutes les possibilités +de Shorewall. Il se focalise sur les besoins pour configurer Shorewall dans +une de ses utilisations les plus populaire :

    +
      -
    • Un système Linux utilisé en tant que firewall/routeur pour un -petit réseau local.
      • -
    • Une seule adresse IP publique.
      • -
    • Une DMZ connectée sur une interface Ethernet séparée.
      • -
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame -Relay, RTC, ...
      • +
    • Un système Linux utilisé en tant que firewall/routeur pour un petit +réseau local.
      • +
    • Une seule adresse IP publique.
      • +
    • Une DMZ connectée sur une interface Ethernet séparée.
      • +
    • Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame Relay, +RTC, ...
      • +
    +

    Voici le schéma d'une installation typique.

    +

    -

    Ce guide suppose que vous avez le paquet iproute/iproute2 -d'installé. Vous pouvez voir si le paquet est installé en vérifiant la -présence du programme ip sur votre système de firewall. Sous root, -utilisez la commande 'which' pour rechercher le programme :

    + height="635"> +

    + +

    Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé. +Vous pouvez voir si le paquet est installé en vérifiant la présence du programme +ip sur votre système de firewall. Sous root, utilisez la commande 'which' +pour rechercher le programme :

    + 
         [root@gateway root]# which ip
         /sbin/ip
         [root@gateway root]#
    -

    Je vous recommande dans un premier temps de parcourir tout le guide -pour vous familiariser avec ce qu'il va se passer, et de revenir au -début en effectuant le changements dans votre configuration. Les points -où, les changements dans la configuration sont recommandées, sont -signalés par une

    -

    Si -vous éditez vos fichiers de configuration sur un système Windows, vous -devez les sauver comme des fichiers Unix si votre éditeur offre cette -option sinon vous devez les faire passer par dos2unix avant d'essayer de -les utiliser. De la même manière, si vous copiez un fichier de -configuration depuis votre disque dur Windows vers une disquette, vous -devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall.

    + +

    Je vous recommande dans un premier temps de parcourir tout le guide pour +vous familiariser avec ce qu'il va se passer, et de revenir au début en effectuant +le changements dans votre configuration. Les points où, les changements dans +la configuration sont recommandées, sont signalés par une +

    + +

    + Si vous éditez vos fichiers de configuration sur un système Windows, vous +devez les sauver comme des fichiers Unix si votre éditeur offre cette option +sinon vous devez les faire passer par dos2unix avant d'essayer de les utiliser. +De la même manière, si vous copiez un fichier de configuration depuis votre +disque dur Windows vers une disquette, vous devez lancer dos2unix sur la +copie avant de l'utiliser avec Shorewall.

    + +

    Les Concepts de Shorewall

    +

    Les fichiers de configuration pour Shorewall sont situés dans -le répertoire /etc/shorewall -- pour de simples paramétrages, vous -n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce -guide. Après avoir installé Shorewall, téléchargez -la configuration d'exemple three-interface -sample, un-tarez la (tar -zxvf three-interfaces.tgz) et -copiez les fichiers vers /etc/shorewall (Ils remplaceront les fichiers -de même nom déjà existant dans /etc/shorewall installés lors de -l'installation de Shorewall).

    -

    En même temps que chacun des fichiers est présenté, je vous suggère -de jeter un oeil à ceux qui se trouvent réellement sur votre système -- -chacun des fichiers contient des instructions de configuration -détaillées et des entrées par défaut.

    -

    Shorewall voit le réseau où il tourne comme composé par un ensemble -de zones. Dans les fichiers de configuration fournis pour trois -interfaces, trois zones sont définies :

    + alt=""> + Les fichiers de configuration pour Shorewall sont situés dans le répertoire + /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec +quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration +d'exemple three-interface +sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez +les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même +nom déjà existant dans /etc/shorewall installés lors de l'installation de +Shorewall).

    + +

    En même temps que chacun des fichiers est présenté, je vous suggère de +jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun +des fichiers contient des instructions de configuration détaillées et des +entrées par défaut.

    + +

    Shorewall voit le réseau où il tourne comme composé par un ensemble de +zones. Dans les fichiers de configuration fournis pour trois interfaces, +trois zones sont définies :

    + - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    NameDescription
    netThe Internet
    locVotre réseau local
    dmzZone Demilitarisée
    +

    Les noms de zone sont définis dans /etc/shorewall/zones.

    -

    Shorewall reconnaît aussi le système de firewall comme sa propre -zone - par défaut, le firewall lui même est connu en tant que fw.

    -

    Les règles concernant le trafic à autoriser ou à interdire sont -exprimées en utilisant les termes de zones.

    + +

    Shorewall reconnaît aussi le système de firewall comme sa propre zone +- par défaut, le firewall lui même est connu en tant que fw.

    + +

    Les règles concernant le trafic à autoriser ou à interdire sont exprimées +en utilisant les termes de zones.

    +
      -
    • Vous exprimez les politiques par défaut pour les connexions d'une -zone à une autre dans le fichier -/etc/shorewall/policy .
      • -
    • Vous définissez les exceptions à ces règles de politiques par -défaut dans le fichier /etc/shorewall/rules.
      • +
    • Vous exprimez les politiques par défaut pour les connexions d'une zone +à une autre dans le fichier /etc/shorewall/policy + .
      • +
    • Vous définissez les exceptions à ces règles de politiques par défaut +dans le fichier /etc/shorewall/rules.
      • +
    -

    Pour chacune des demandes de connexion entrantes dans le firewall, -les demandes sont en premier lieu comparées par rapport au fichier -/etc/shorewall/rules. Si aucune des règles dans ce fichier ne -correspondent, alors la première politique dans /etc/shorewall/policy -qui y correspond est appliquée. Si cette politique est REJECT ou DROP la -requête est alors comparée par rapport aux règles contenues dans -/etc/shorewall/common (l'archive d'exemple vous fournit ce fichier).

    -

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive -three-interface sample a les politiques suivantes :

    -
    + +

    Pour chacune des demandes de connexion entrantes dans le firewall, les +demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules. +Si aucune des règles dans ce fichier ne correspondent, alors la première +politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette +politique est REJECT ou DROP la requête est alors comparée par rapport aux +règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit +ce fichier).

    + +

    Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface +sample a les politiques suivantes :

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT
    -
    -
    netallDROPinfo
    -
    allallREJECTinfo
    -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    locnetACCEPT
    +
    +
    netallDROPinfo
    +
    allallREJECTinfo
    +
    -
    -
    -

    Dans l'archive three-interface, la ligne suivante est existante -mais elle est commentée. Si vous souhaitez que votre système de firewall -puisse avoir un accès complet aux serveurs sur Internet, décommentez la.

    +
    + +
    +

    Dans l'archive three-interface, la ligne suivante est existante mais +elle est commentée. Si vous souhaitez que votre système de firewall puisse +avoir un accès complet aux serveurs sur Internet, décommentez la.

    + - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + +
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    -
    -
    Source ZoneDestination ZonePolicyLog LevelLimit:Burst
    fwnetACCEPT
    +
    +
    -
    +
    +

    Les politiques précédentes vont :

    +
      -
    1. permettre toutes demandes de connexion depuis le firewall vers -l'Internet
      2. -
    2. drop (ignorer) toutes les demandes de connexion depuis l'Internet -vers votre firewall ou vers votre réseau local
      3. -
    3. Facultativement accepter toutes les demandes de connexion depuis -votre firewall et vers Internet (si vous decommentez la politique -précédente)
      4. -
    4. reject (rejeter) toutes les autres demandes de connexion.
      5. +
    5. permettre toutes demandes de connexion depuis le firewall vers l'Internet
      6. +
    6. drop (ignorer) toutes les demandes de connexion depuis l'Internet vers +votre firewall ou vers votre réseau local
      7. +
    7. Facultativement accepter toutes les demandes de connexion depuis votre +firewall et vers Internet (si vous decommentez la politique précédente)
      8. +
    8. reject (rejeter) toutes les autres demandes de connexion.
      9. +
    -

    A -ce point, éditez votre /etc/shorewall/policy et faites y les changements + +

    +A ce point, éditez votre /etc/shorewall/policy et faites y les changements que vous désire

    +

    Les Interfaces Réseau

    +

    -

    Le firewall a trois interfaces de réseau. Lorsque la -connexion Internet passe par le câble ou par un ROUTEUR (pas un simple -modem) ADSL (non USB), l'interface vers l'extérieur (External Interface) -sera l'adaptateur sur lequel est connecté le routeur (e.g., eth0) à -moins que vous ne vous connectiez par Point-to-PointProtocol -overEthernet (PPPoE) ou par Point-to-PointTunneling Protocol (PPTP), -dans ce cas l'interface extérieure sera une interface de type ppp (e.g., -ppp0). Si vous vous connectez par un simple modem (RTC), votre interface -extérieure sera aussi ppp0. Si votre connexion passe par Numéris -(ISDN), votre interface extérieure sera ippp0.

    + height="635"> +

    + +

    Le firewall a trois interfaces de réseau. Lorsque la connexion +Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL +(non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur +sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous +connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling +Protocol (PPTP), dans ce cas l'interface extérieure sera une interface de +type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), +votre interface extérieure sera aussi ppp0. Si votre connexion passe par +Numéris (ISDN), votre interface extérieure sera ippp0.

    +

    Si votre interface vers l'extérieur est ppp0 ou ippp0 -alors vous mettrez CLAMPMSS=yes dans -/etc/shorewall/shorewall.conf.

    -

    Votre Interface locale sera un adaptateur -Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un -switch. Vos ordinateurs locaux seront connectés à ce même switch (note : -si vous n'avez qu'un seul ordinateur en local, vous pouvez le connecter -directement au firewall par un câble croisé).

    -

    Votre interface DMZ sera aussi un adaptateur -Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. -Vos ordinateurs appartenant à la DMZ seront connectés à ce même switch -(note : si vous n'avez qu'un seul ordinateur dans la DMZ, vous pouvez -le connecter directement au firewall par un câble croisé).

    + height="13"> + Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez +CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.

    + +

    Votre Interface locale sera un adaptateur Ethernet +(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs +locaux seront connectés à ce même switch (note : si vous n'avez qu'un seul +ordinateur en local, vous pouvez le connecter directement au firewall par +un câble croisé).

    + +

    Votre interface DMZ sera aussi un adaptateur Ethernet +(eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs +appartenant à la DMZ seront connectés à ce même switch (note : si vous n'avez +qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement au +firewall par un câble croisé).

    +

    Ne connectez pas l'interface interne et -externe sur le même hub ou switch (même pour tester). Cela ne -fonctionnera pas et ne croyez pas que ce soit shorewall qui ne marche -pas.

    + width="60" height="60"> +     Ne connectez pas l'interface interne et externe sur le même hub +ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez pas que +ce soit shorewall qui ne marche pas.

    +

    L'exemple de configuration de Shorewall pour trois -interfaces suppose que l'interface externe est eth0, l'interface -locale est eth1 et que la DMZ est sur l'interface eth2. -Si votre configuration diffère, vous devrez modifier le fichier -d'exemple /etc/shorewall/interfaces en conséquence. Tant que vous y -êtes, vous pourriez parcourir la liste des options qui sont spécifiées -pour les interfaces. Quelques trucs :

    + height="13"> + L'exemple de configuration de Shorewall pour trois interfaces suppose que +l'interface externe est eth0, l'interface locale est eth1 +et que la DMZ est sur l'interface eth2. Si votre configuration diffère, +vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence. +Tant que vous y êtes, vous pourriez parcourir la liste des options qui sont +spécifiées pour les interfaces. Quelques trucs :

    +
      -
    • -

      Si votre interface externe est ppp0 ou ippp0, vous -pouvez remplacer le "detect" dans la seconde colonne par un "-".

      -
      • -
    • -

      Si votre interface externe est ppp0 ou ippp0 ou -bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" -de la liste d'option.

      -
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0, vous pouvez +remplacer le "detect" dans la seconde colonne par un "-".

      +
      • +
    • +

      Si votre interface externe est ppp0 ou ippp0 ou bien +si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la +liste d'option.

      +
      • +
    +

    Adresses IP

    -

    Avant d'aller plus loin, nous devons dire quelques mots -au sujet du Protocole d'adresse Internet (IP). Normalement, votre -fournisseur Internet (ISP) vous assignera une seule adresse IP (single -Public IP address). Cette adresse peut être assignée par le Dynamic Host -Configuration Protocol (DHCP) ou lors de l'établissement de votre -connexion lorsque vous vous connectez (modem standard) ou établissez -votre connexion PPP. Dans de rares cas , votre provider peu vous -assigner une adresse statique (staticIP address); cela signifie que vous -configurez votre interface externe sur votre firewall afin d'utiliser -cette adresse de manière permanente. Une fois votre adresse externe -assignée, elle va être partagée par tout vos systèmes lors de l'accès à -Internet. Vous devrez assigner vos propres adresses à votre réseau -local (votre interface interne sur le firewall ainsi que les autres -ordinateurs). La RFC 1918 réserve plusieurs plages d'IP (Private IP -address ranges) à cette fin :

    -
    + +

    Avant d'aller plus loin, nous devons dire quelques mots au +sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur +Internet (ISP) vous assignera une seule adresse IP (single Public IP address). +Cette adresse peut être assignée par le Dynamic Host Configuration Protocol +(DHCP) ou lors de l'établissement de votre connexion lorsque vous vous connectez +(modem standard) ou établissez votre connexion PPP. Dans de rares cas , votre +provider peu vous assigner une adresse statique (staticIP address); cela +signifie que vous configurez votre interface externe sur votre firewall afin +d'utiliser cette adresse de manière permanente. Une fois votre adresse externe +assignée, elle va être partagée par tout vos systèmes lors de l'accès à Internet. +Vous devrez assigner vos propres adresses à votre réseau local (votre interface +interne sur le firewall ainsi que les autres ordinateurs). La RFC 1918 réserve +plusieurs plages d'IP (Private IP address ranges) à cette fin :

    + +
         10.0.0.0    - 10.255.255.255
         172.16.0.0  - 172.31.255.255
         192.168.0.0 - 192.168.255.255
    -
    -
    +
    + +

    Avant de lancer Shorewall, vous devriez regarder l'adresse -de votre interface externe et si elle est comprise dans une des plages -précédentes, vous devriez enlever l'option 'norfc1918' dans le fichier -/etc/shorewall/interfaces.

    -
    -
    -

    Vous devrez assigner les adresses locales à un -sous-réseau (sub-network ou subnet) et les adresse pour -la DMZ à un autre sous-réseau. Pour ce faire, nous pouvons considérer -qu'un sous-réseau consiste en une plage d'adresse x.y.z.0 à x.y.z.255. -Chacun des sous-réseaux possèdera une masque (Subnet Mask) de -255.255.255.0. L'adresse x.y.z.0 est réservée comme l'adresse du -sous-réseau (Subnet Address) et x.y.z.255 est réservée en -tant qu'adresse de broadcast du sous-réseau (Subnet Broadcast Address). -Sous Shorewall, un sous-réseau est décrit/désigné en utilisant la -notation Classless -InterDomain Routing(CIDR) qui consiste en l'adresse du -sous-réseau suivie par "/24". Le "24" se réfère au nombre de bits "1" -consécutifs dans la partie gauche du masque de sous-réseau.

    -
    -
    + height="13"> + Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface +externe et si elle est comprise dans une des plages précédentes, vous devriez +enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.

    +
    + +
    +

    Vous devrez assigner les adresses locales à un sous-réseau +(sub-network ou subnet) et les adresse pour la DMZ à un autre +sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste +en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera +une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0 est +réservée comme l'adresse du sous-réseau (Subnet Address) et x.y.z.255 + est réservée en tant qu'adresse de broadcast du sous-réseau (Subnet Broadcast +Address). Sous Shorewall, un sous-réseau est décrit/désigné en utilisant +la notation Classless InterDomain +Routing(CIDR) qui consiste en l'adresse du sous-réseau suivie par +"/24". Le "24" se réfère au nombre de bits "1" consécutifs dans la partie +gauche du masque de sous-réseau.

    +
    + +

    Exemple de sous-réseau (subnet) :

    -
    -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + +
    Plage:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    Plage:10.10.10.0 - 10.10.10.255
    Subnet Address:10.10.10.0
    Broadcast Address:10.10.10.255
    CIDR Notation:10.10.10.0/24
    -
    -
    -
    -

    Il est de convention d'assigner à l'interface interne -la première adresse utilisable dans le sous-réseau (10.10.10.1 dans -l'exemple précédent) ou la dernière utilisable (10.10.10.254).

    -
    -
    -

    L'un des buts d'un sous-réseau est de permettre à tous -les ordinateurs dans le sous-réseau de savoir avec quels autres -ordinateurs ils peuvent communiquer directement. Pour communiquer avec -des systèmes en dehors du sous-réseau, les ordinateurs envoient des -paquets à travers le gateway (routeur).

    -
    -
    + +
    + +
    +

    Il est de convention d'assigner à l'interface interne la +première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple +précédent) ou la dernière utilisable (10.10.10.254).

    +
    + +
    +

    L'un des buts d'un sous-réseau est de permettre à tous les +ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs ils +peuvent communiquer directement. Pour communiquer avec des systèmes en dehors +du sous-réseau, les ordinateurs envoient des paquets à travers le gateway +(routeur).

    +
    + +

    Vos ordinateurs locaux (ordinateur local 1 et 2) devraient -être configurés avec leur passerelle par défaut (default gateway)pointant -sur l'adresse IP de l'interface interne du firewall, et les ordinateurs -de la DMZ devraient être configurés avec leur passerelle par défaut (default -gateway) pointant sur l'adresse IP de l'interface DMZ du firewall.

    -
    -

    Cette courte description ne fait que survoler les -concepts de routage et de sous-réseau. Si vous vous voulez en apprendre -plus sur l'adressage IP et le routage, je vous recommande chaudement "IP -Fundamentals: What Everyone Needs to Know about Addressing & -Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN -0-13-975483-0.

    -

    Pour rappel, ce guide supposera que vous avez configuré -votre réseau comme montrer ci-dessous :

    + height="13"> + Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés +avec leur passerelle par défaut (default gateway)pointant sur l'adresse +IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient +être configurés avec leur passerelle par défaut (default gateway) +pointant sur l'adresse IP de l'interface DMZ du firewall.

    +
    + +

    Cette courte description ne fait que survoler les concepts +de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur l'adressage +IP et le routage, je vous recommande chaudement "IP Fundamentals: What +Everyone Needs to Know about Addressing & Routing", Thomas A. +Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.

    + +

    Pour rappel, ce guide supposera que vous avez configuré votre +réseau comme montrer ci-dessous :

    +

    -

    La passerelle par défaut (default gateway) pour les -ordinateurs de la DMZ sera 10.10.11.254 et le passerelle par -défaut pour les ordinateurs en local sera 10.10.10.254.

    + height="635"> +

    + +

    La passerelle par défaut (default gateway) pour les ordinateurs +de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les ordinateurs +en local sera 10.10.10.254.

    +

    IP Masquerading (SNAT)

    -

    Les adresses réservées par la RFC 1918 sont parfois -désignées comme non-routables car les routeurs Internet (backbone) ne -font pas circuler les paquets qui ont une adresse de destination -appartenant à la RFC-1918. Lorsqu'un de vos systèmes en local (supposons -l'ordinateur1) demande une connexion à un serveur par Internet, le -firewall doit appliquer un NAT (Network Address Translation). Le -firewall ré écrit l'adresse source dans le paquet, et l'a remplace par -l'adresse de l'interface externe du firewall; en d'autres mots, le -firewall fait croire que c'est lui même qui initie la connexion. Ceci -est nécessaire afin que l'hôte de destination soit capable de renvoyer -les paquets au firewall (souvenez vous que les paquets qui ont pour -adresse de destination, une adresse réservée par la RFC 1918 ne pourront -pas être routés à travers Internet, donc l'hôte Internet ne pourra -adresser sa réponse à l'ordinateur 1). Lorsque le firewall reçoit le -paquet de réponse, il remet l'adresse de destination à 10.10.10.1 et -fait passer le paquet vers l'ordinateur 1.

    -

    Sur les systèmes Linux, ce procédé est souvent appelé -de l'IP Masquerading mais vous verrez aussi le terme de Source Network -Address Translation (SNAT) utilisé. Shorewall suit la convention -utilisée avec Netfilter :

    + +

    Les adresses réservées par la RFC 1918 sont parfois désignées +comme non-routables car les routeurs Internet (backbone) ne font pas circuler +les paquets qui ont une adresse de destination appartenant à la RFC-1918. +Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une +connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network +Address Translation). Le firewall ré écrit l'adresse source dans le paquet, +et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres +mots, le firewall fait croire que c'est lui même qui initie la connexion. +Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer +les paquets au firewall (souvenez vous que les paquets qui ont pour adresse +de destination, une adresse réservée par la RFC 1918 ne pourront pas être +routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse +à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet +l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur +1.

    + +

    Sur les systèmes Linux, ce procédé est souvent appelé de +l'IP Masquerading mais vous verrez aussi le terme de Source Network Address +Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter +:

    +
      -
    • -

      Masquerade désigne le cas ou vous laissez votre -firewall détecter automatiquement l'adresse de l'interface externe.

      -
      • -
    • -

      SNAT désigne le cas où vous spécifiez explicitement -l'adresse source des paquets sortant de votre réseau local.

      -
      • +
    • +

      Masquerade désigne le cas ou vous laissez votre firewall +détecter automatiquement l'adresse de l'interface externe.

      +
      • +
    • +

      SNAT désigne le cas où vous spécifiez explicitement l'adresse +source des paquets sortant de votre réseau local.

      +
      • +
    -

    Sous Shorewall, autant le Masquerading que le SNAT sont -configuré avec des entrés dans le fichier /etc/shorewall/masq.

    + +

    Sous Shorewall, autant le Masquerading que le SNAT sont configuré +avec des entrés dans le fichier /etc/shorewall/masq.

    +

    Si votre interface externe est eth0, votre -interface locale eth1 et votre interface pour la DMZ eth2 -vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. -Dans le cas contraire, éditez /etc/shorewall/masq et changez le en -conséquence.

    + height="13"> + Si votre interface externe est eth0, votre interface locale eth1 +et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier +le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq + et changez le en conséquence.

    +

    Si votre IP externe est statique, vous pouvez la mettre -dans la troisième colonne dans /etc/shorewall/masq si vous le désirez, -de toutes façons votre firewall fonctionnera bien si vous laissez cette -colonne vide. Le fait de mettre votre IP statique dans la troisième -colonne permet un traitement des paquets sortant un peu plus efficace.
    -

    + height="13"> + Si votre IP externe est statique, vous pouvez la mettre dans la troisième +colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre +firewall fonctionnera bien si vous laissez cette colonne vide. Le fait de +mettre votre IP statique dans la troisième colonne permet un traitement des +paquets sortant un peu plus efficace.
    +

    +

    Si vous utilisez les paquets Debian, vérifiez que -votre fichier de configuration shorewall.conf contient bien les valeurs -suivantes, si elles n'y sont pas faite les changements nécessaires :
    -

    + height="13" alt=""> + Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration +shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas +faite les changements nécessaires :
    +

    +
      -
    • NAT_ENABLED=Yes
      • -
    • IP_FORWARDING=On
      -
      • +
    • NAT_ENABLED=Yes
      • +
    • IP_FORWARDING=On
      +
      • +
    +

    Port Forwarding (DNAT)

    -

    Un de nos buts est de, peut être, faire tourner un ou -plusieurs serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs -on une adresse RFC-1918, il n'est pas possible pour les clients sur -Internet de se connecter directement à eux. Il est nécessaire à ces -clients d'adresser leurs demandes de connexion au firewall qui ré écrit -l'adresse de destination de votre serveur, et fait passer le paquet à -celui-ci. Lorsque votre serveur répond, le firewall applique -automatiquement un SNAT pour ré écrire l'adresse source dans la réponse.

    -

    Ce procédé est appelé Port Forwarding ou Destination -Network Address Translation(DNAT). Vous configurez le port forwarding en -utilisant les règles DNAT dans le fichier /etc/shorewall/rules.

    -

    La forme générale d'une simple règle de port forwarding dans -/etc/shorewall/rules est :

    -
    + +

    Un de nos buts est de, peut être, faire tourner un ou plusieurs +serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse +RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter +directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes +de connexion au firewall qui ré écrit l'adresse de destination de votre serveur, +et fait passer le paquet à celui-ci. Lorsque votre serveur répond, le firewall +applique automatiquement un SNAT pour ré écrire l'adresse source dans la +réponse.

    + +

    Ce procédé est appelé Port Forwarding ou Destination Network +Address Translation(DNAT). Vous configurez le port forwarding en utilisant +les règles DNAT dans le fichier /etc/shorewall/rules.

    + +

    La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules +est :

    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server - port>]<protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:<server local ip address> [:<server +port>]<protocol><port>
    +
    +
    -
    -

    Si vous ne spécifiez pas le <server port>, il est -supposé être le même que <port>.

    -

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et -vous voulez faire passer les paquets entrant en TCP sur le port 80 à ce -système :

    -
    +
    + +

    Si vous ne spécifiez pas le <server port>, il est supposé +être le même que <port>.

    + +

    Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous +voulez faire passer les paquets entrant en TCP sur le port 80 à ce système +:

    + +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2tcp80# Fait suivre le port 80depuis Internet
    ACCEPTlocdmz:10.10.11.2tcp80#Permet les connexions depuis le réseau local
    -
    +
    +

    Deux points importants à garder en mémoire :

    +
      -
    • Lorsque vous vous connectez à votre serveur à partir de votre -réseau local, vous devez utiliser l'adresse IP interne du serveur -(10.10.11.2).
      • -
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les -requêtes de connexion entrantes sur le port 80. Si vous avez des -problèmes pour vous connecter à votre serveur web, essayez la règle -suivante et connectez vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre -IP externe).
      • +
    • Lorsque vous vous connectez à votre serveur à partir de votre réseau +local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
      • +
    • Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes +de connexion entrantes sur le port 80. Si vous avez des problèmes pour vous +connecter à votre serveur web, essayez la règle suivante et connectez vous +sur le port 5000 (c.a.d., connectez vous à +http://w.x.y.z:5000 où w.x.y.z est votre IP externe).
      • +
    -
    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp5000
    +
    +
    -
    -

    Si vous voulez avoir la possibilité de vous connecter à votre -serveur depuis le réseau local en utilisant votre adresse externe, et si -vous avez une adresse IP externe statique (fixe), vous pouvez remplacer -la règle loc->dmz précédente par :

    -
    +
    + +

    Si vous voulez avoir la possibilité de vous connecter à votre serveur +depuis le réseau local en utilisant votre adresse externe, et si vous avez +une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz +précédente par :

    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATnetdmz:10.10.11.2:80tcp80-<external IP>
    -
    -

    Si vous avez une IP dynamique, alors vous devez vous assurer que -votre interface externe est en route avant de lancer Shorewall et vous -devez suivre les étapes suivantes (en supposant que votre interface -externe est eth0) :

    +
    + +

    Si vous avez une IP dynamique, alors vous devez vous assurer que votre +interface externe est en route avant de lancer Shorewall et vous devez suivre +les étapes suivantes (en supposant que votre interface externe est eth0) +:

    +
      -
    1. Insérez ce qui suit dans /etc/shorewall/params :
      -
      -ETH0_IP=`find_interface_address eth0`
      -
      2. -
    2. Faites votre règle loc->dmz :
      3. +
    3. Insérez ce qui suit dans /etc/shorewall/params :
      +
      + ETH0_IP=`find_interface_address eth0`
      +
      4. +
    4. Faites votre règle loc->dmz :
      5. +
    -
    + +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    -     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    DNATloc
    +     		dmz:10.10.11.2:80tcp80-$ETH0_IP
    -
    -

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant -votre adresse IP externe, regardez FAQ 2a.

    -

    A -ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    +
    + +

    Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre +adresse IP externe, regardez FAQ 2a.

    + +

    + A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..

    +

    Domain Name Server (DNS)

    -

    Normalement, quand vous vous connectez à votre -fournisseur (ISP), une partie consiste à obtenir votre adresse IP, votre -DNS pour le firewall (Domain Name Service) est configuré automatiquement -(c.a.d., le fichier /etc/resolv.conf a été écrit). Il arrive que votre -provider vous donne une paire d'adresse IP pour les DNS (name servers) -afin que vous configuriez manuellement votre serveur de nom primaire et -secondaire. La manière dont le DNS est configuré sur votre firewall est -de votre responsabilité. Vous pouvez procéder d'une de ses deux façons :

    + +

    Normalement, quand vous vous connectez à votre fournisseur +(ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le +firewall (Domain Name Service) est configuré automatiquement (c.a.d., le +fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous +donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez +manuellement votre serveur de nom primaire et secondaire. La manière dont +le DNS est configuré sur votre firewall est de votre responsabilité. Vous +pouvez procéder d'une de ses deux façons :

    +
      -
    • -

      Vous pouvez configurer votre système interne pour -utiliser les noms de serveurs de votre provider. Si votre fournisseur -vous donne les adresses de leurs serveurs ou si ces adresses sont -disponibles sur leur site web, vous pouvez configurer votre système -interne afin de les utiliser. Si cette information n'est pas disponible, -regardez dans /etc/resolv.conf sur votre firewall -- les noms des -serveurs sont donnés dans l'enregistrement "nameserver" dans ce fichier.

      -
      • -
    • +
    • +

      Vous pouvez configurer votre système interne pour utiliser +les noms de serveurs de votre provider. Si votre fournisseur vous donne les +adresses de leurs serveurs ou si ces adresses sont disponibles sur leur site +web, vous pouvez configurer votre système interne afin de les utiliser. Si +cette information n'est pas disponible, regardez dans /etc/resolv.conf sur +votre firewall -- les noms des serveurs sont donnés dans l'enregistrement +"nameserver" dans ce fichier.

      +
      • +

    • Vous pouvez installer/configurer un cache dns -(Caching Name Server) sur votre firewall ou dans la DMZ. Red Hat -a un RPM pour mettre en cache un serveur de nom (le RPM requis aussi le -RPM 'bind') et pour les utilisateurs de Bering, il y a dnscache.lrp. Si -vous adoptez cette approche, vous configurez votre système interne pour -utiliser le firewall lui même comme étant le seul serveur de nom -primaire. Vous pouvez utiliser l'adresse IP interne du firewall -(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous -décidez de faire tourner le serveur de nom sur votre firewall. Pour -permettre à vos systèmes locaux de discuter avec votre serveur cache de -nom, vous devez ouvrir le port 53 (UDP ET  TCP) sur le firewall vers le -réseau local; vous ferez ceci en ajoutant les règles suivantes dans -/etc/shorewall/rules.

      -
      • + width="13" height="13"> + Vous pouvez installer/configurer un cache dns (Caching Name Server) sur +votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre en cache +un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les utilisateurs +de Bering, il y a dnscache.lrp. Si vous adoptez cette approche, vous configurez +votre système interne pour utiliser le firewall lui même comme étant le seul +serveur de nom primaire. Vous pouvez utiliser l'adresse IP interne du firewall +(10.10.10.254 dans l'exemple) pour l'adresse de serveur de nom si vous décidez +de faire tourner le serveur de nom sur votre firewall. Pour permettre à vos +systèmes locaux de discuter avec votre serveur cache de nom, vous devez ouvrir +le port 53 (UDP ET  TCP) sur le firewall vers le réseau local; vous ferez +ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.

      + +
    -
    -

    Si vous faites tourner le serveur de nom sur le -firewall : + +

    +

    Si vous faites tourner le serveur de nom sur le firewall +: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    -
    -
    ACCEPTlocfwudp53
    -
    -
    ACCEPTdmzfwtcp53
    -
    -
    ACCEPTdmzfwudp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp53
    +
    +
    ACCEPTlocfwudp53
    +
    +
    ACCEPTdmzfwtcp53
    +
    +
    ACCEPTdmzfwudp53
    +
    +
    -

    -
    -
    -
    +

    +
    + +
    +

    Le serveur de nom tourne sur l'ordinateur 1 de la DMZ

    + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53
    -
    -
    ACCEPTlocdmz:10.10.11.1udp53
    -
    -
    ACCEPTfwdmz:10.10.10.1tcp53
    -
    -
    ACCEPTfwdmz:10.10.10.1udp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocdmz:10.10.11.1tcp53
    +
    +
    ACCEPTlocdmz:10.10.11.1udp53
    +
    +
    ACCEPTfwdmz:10.10.10.1tcp53
    +
    +
    ACCEPTfwdmz:10.10.10.1udp53
    +
    +
    -
    -
    -
    +
    + + +

    Autres Connexions

    -
    -
    -

    L'exemple pour trois interfaces contient les règles -suivantes :

    -
    -
    -
    +
    + +
    +

    L'exemple pour trois interfaces contient les règles suivantes +:

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    -
    -
    ACCEPTfwnettcp53
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTfwnetudp53
    +
    +
    ACCEPTfwnettcp53
    +
    +
    -
    -
    -
    -

    Ces règles permettent l'accès DNS depuis votre firewall -et peuvent être enlevées si vous avez décommenté la ligne dans -/etc/shorewall/policy autorisant toutes les connexions depuis votre -firewall et vers Internet.

    -
    -
    + +
    + +
    +

    Ces règles permettent l'accès DNS depuis votre firewall et +peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy +autorisant toutes les connexions depuis votre firewall et vers Internet.

    +
    + +

    L'exemple contient aussi :

    -
    -
    -
    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    -
    -
    ACCEPTlocdmztcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTlocfwtcp22
    +
    +
    ACCEPTlocdmztcp22
    +
    +
    -
    -
    -
    -

    Cette règle permet de faire fonctionner une serveur SSH -sur le firewall et sur tous les systèmes de la DMZ et d'y autoriser la -connexion à partir de votre réseau local.

    -
    -
    -

    Si vous désirez permettre d'autres connexions entre vos -systèmes, la forme générale est :

    -
    -
    -
    +
    +
    + +
    +

    Cette règle permet de faire fonctionner une serveur SSH sur +le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion +à partir de votre réseau local.

    +
    + +
    +

    Si vous désirez permettre d'autres connexions entre vos systèmes, +la forme générale est :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPT<source zone><destination zone><protocol><port>
    +
    +
    -
    -
    -
    -

    Exemple - Vous voulez faire tourner un serveur DNS -disponible pour le publique sur votre firewall :

    -
    -
    -
    +
    +
    + +
    +

    Exemple - Vous voulez faire tourner un serveur DNS disponible +pour le publique sur votre firewall :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    ACCEPTnetfwtcp53#permet les accès DNSdepuis Internet
    -
    -
    -
    -

    Ces deux règles seront, bien sur, ajoutées aux règles -décrites dans "Vous pouvez installer/configurer un cache dns (Caching -Name Server) sur votre firewall ou dans la DMZ".

    -
    -
    -

    Si vous ne savez pas quel port ou protocole une -application particulière utilise, regardez ici.

    -
    -
    -

    Important: Je ne vous recommande pas d'autoriser le -telnet depuis ou vers l'Internet car il utilise du texte en clair (même -pour le login et le mot de passe !). Si vous voulez avoir un accès au -shell de votre firewall depuis Internet, utilisez SSH :

    -
    -
    -
    +
    +
    + +
    +

    Ces deux règles seront, bien sur, ajoutées aux règles décrites +dans "Vous pouvez installer/configurer un cache dns (Caching Name Server) +sur votre firewall ou dans la DMZ".

    +
    + +
    +

    Si vous ne savez pas quel port ou protocole une application +particulière utilise, regardez ici.

    +
    + +
    +

    Important: Je ne vous recommande pas d'autoriser le telnet +depuis ou vers l'Internet car il utilise du texte en clair (même pour le +login et le mot de passe !). Si vous voulez avoir un accès au shell de votre +firewall depuis Internet, utilisez SSH :

    +
    + +
    +
    - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + +
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    -
    -
    ACTIONSOURCEDESTINATIONPROTOCOLPORTSOURCE PORTORIGINAL ADDRESS
    ACCEPTnetfwtcp22
    +
    +
    -
    -
    -
    + +
    + +

    Et maintenant, éditez /etc/shorewall/rules pour rajouter -les autres connexions désirées.

    -
    -
    + height="13"> + Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres connexions +désirées.

    +
    + +

    Lancer et Arrêter son Firewall

    -
    -
    +
    + +

    Arrow La procédure -d'installation configure votre système pour lancer Shorewall au boot -du système, mais au début avec la version 1.3.9 de Shorewall le -lancement est désactivé, n'essayer pas de lancer Shorewall avec que la -configuration soit finie. Une fois que vous en avez fini avec la -configuration du firewall, vous pouvez permettre le lancement de -Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
    -

    -

    IMPORTANT: Les utilisateurs des paquets .deb doivent -éditer /etc/default/shorewall et mettre 'startup=1'.
    -

    -
    -
    -

    Le firewall est activé en utilisant la commande -"shorewall start" et arrêté avec "shorewall stop". Lorsque le firewall -est stoppé, le routage est autorisé sur les hôtes qui possèdent une -entrée dans /etc/shorewall/routestopped. -Un firewall qui tourne peut être relancé en utilisant la commande -"shorewall restart". Si vous voulez enlever toutes traces de Shorewall -sur votre configuration de Netfilter, utilisez "shorewall clear".

    -
    -
    + height="13" alt="Arrow"> + La procédure d'installation configure votre système +pour lancer Shorewall au boot du système, mais au début avec la version 1.3.9 +de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall +avec que la configuration soit finie. Une fois que vous en avez fini avec +la configuration du firewall, vous pouvez permettre le lancement de Shorewall +en supprimant le fichier /etc/shorewall/startup_disabled.
    +

    + +

    IMPORTANT: Les utilisateurs des paquets .deb doivent éditer +/etc/default/shorewall et mettre 'startup=1'.
    +

    +
    + +
    +

    Le firewall est activé en utilisant la commande "shorewall +start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé, le +routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un +firewall qui tourne peut être relancé en utilisant la commande "shorewall +restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration +de Netfilter, utilisez "shorewall clear".

    +
    + +

    L'exemple pour trois interfaces suppose que vous voulez -permettre le routage depuis/vers eth1 (votre réseau local) et -eth2(DMZ) lorsque Shorewall est arrêté. Si ces deux -interfaces ne sont pas connectées à votre réseau local et votre DMZ, ou -si vous voulez permettre un ensemble d'hôtes différents, modifiez -/etc/shorewall/routestopped en conséquence.

    -
    -
    -

    ATTENTION: Si vous êtes connecté à votre firewall -depuis Internet, n'essayez pas une commande "shorewall stop" tant que -vous n'avez pas ajouté une entrée pour votre adresse IP (celle à partir -de laquelle vous êtes connectée) dans /etc/shorewall/routestopped. -De la même manière, je ne vous recommande pas d'utiliser "shorewall -restart"; il est plus intéressant de créer une + L'exemple pour trois interfaces suppose que vous voulez permettre le routage +depuis/vers eth1 (votre réseau local) et eth2(DMZ) lorsque +Shorewall est arrêté. Si ces deux interfaces ne sont pas connectées +à votre réseau local et votre DMZ, ou si vous voulez permettre un ensemble +d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.

    +
    + + + +

    Last updated 12/20/2002 - Tom Eastep

    -

    Copyright 2002 -Thomas M. Eastep

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

    Copyright 2002 Thomas +M. Eastep

    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    +
    diff --git a/STABLE/firewall b/STABLE/firewall index 80a4adac3..daa6d72df 100755 --- a/STABLE/firewall +++ b/STABLE/firewall @@ -1281,8 +1281,10 @@ stop_firewall() { while read interface host; do expandv interface host - [ "x$host" = "x-" ] && host= - hosts="$hosts $interface:${host:-0.0.0.0/0}" + [ "x$host" = "x-" ] && host=0.0.0.0/0 + for h in `separate_list $host`; do + hosts="$hosts $interface:$h" + done done < $TMP_DIR/routestopped for host in $hosts; do