diff --git a/Shorewall-docs2/FAQ.xml b/Shorewall-docs2/FAQ.xml index dbc86840a..738c94cde 100644 --- a/Shorewall-docs2/FAQ.xml +++ b/Shorewall-docs2/FAQ.xml @@ -17,7 +17,7 @@ - 2004-12-31 + 2005-03-01 2001-2004 @@ -296,19 +296,10 @@ DNAT net loc:192.168.1.3:22 tcp 1022 If you insist on an IP solution to the accessibility problem rather than a DNS solution, then assuming that your external interface is eth0 and your internal interface is eth1 and that eth1 has IP address - 192.168.1.254 with subnet 192.168.1.0/24. - - If you are running Shorewall 1.4.0 or earlier see the 1.3 FAQ for instructions suitable for - those releases. - - If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please - upgrade to Shorewall 1.4.2 or later. - - Otherwise: - In this configuration, all loc->loc traffic will look to - the server as if it came from the firewall rather than from the - original client! + 192.168.1.254 with subnet 192.168.1.0/24: + All traffic redirected through use of this hack will look to + the server as if it came from the firewall (192.168.1.254) rather + than from the original client! @@ -645,11 +636,6 @@ SPT=33120 DPT=5000 LEN=22 # TYPE ZONE GATEWAY GATEWAY # ZONE generic:udp:5000 net 69.145.71.133 - - - You must be running Shorewall 1.4.6 or later to apply this - solution. - @@ -715,53 +701,6 @@ LOGBURST="" DROP net fw udp 10619 -
- (FAQ 6c) All day long I get a steady flow of these DROP - messages from port 53 to some high numbered port. They get dropped, - but what the heck are they? - - Jan 8 15:50:48 norcomix kernel: - Shorewall:net2all:DROP:IN=eth0 OUT= - MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00 SRC=208.138.130.16 - DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00 TTL=251 ID=8288 DF - PROTO=UDP SPT=53 DPT=40275 LEN=33 - - Answer: There are two - possibilities: - - - - They are late-arriving replies to DNS queries. - - - - They are corrupted reply packets. - - - - You can distinguish the difference by setting the logunclean option (/etc/shorewall/interfaces) - on your external interface (eth0 in the above example). If they get - logged twice, they are corrupted. I solve this problem by using an - /etc/shorewall/common file like this: - - # -# Include the standard common.def file -# -. /etc/shorewall/common.def -# -# The following rule is non-standard and compensates for tardy -# DNS replies -# -run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP - - The above file is also include in all of my sample - configurations available in the Quick Start Guides and in - the common.def file in Shorewall 1.4.0 and later. -
-
(FAQ 6d) Why is the MAC address in Shorewall log messages so long? I thought MAC addresses were only 6 bytes in length. @@ -1817,6 +1756,49 @@ alias ipt_pkttype off The solution is the same as above. Simply substitute the IP address of your ISPs DHCP server.
+ +
+ (FAQ 14b) I connect to the internet with PPPoE. When I try to + access the built-in web server in my DSL Modem, I get connection + Refused. + + I see the following in my log: + + Mar 1 18:20:07 Mail kernel: Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=60 +TOS=0x00 PREC=0x00 TTL=64 ID=26774 DF PROTO=TCP SPT=32797 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 + + Answer: The fact that the message is being logged from the + OUTPUT chain means that the destination IP address is not in any + defined zone (see FAQ 17). You need + to: + + + + Add a zone for the modem in /etc/shorewall/zones: + + #ZONE DISPLAY COMMENTS +modem ADSLModem Zone for modem + + + + Define the zone to be associated with eth0 (or whatever interface connects + to your modem) in /etc/shorewall/interfaces: + + #ZONE INTERFACE BROADCAST OPTIONS +modem eth0 detect + + + + Allow web traffic to the modem in + /etc/shorewall/rules: + + #ACTION SOURCE DEST PROTO DEST PORT(S) +ACCEPT fw modem tcp 80 +ACCEPT loc modem tcp 80 + + +
@@ -2032,6 +2014,16 @@ Verifying Configuration... Revision History + + 1.43 + + 2005-03-01 + + TE + + Added FAQ 14b. + + 1.42 diff --git a/Shorewall-docs2/Install.xml b/Shorewall-docs2/Install.xml index 3997e6d40..1fcf956a7 100644 --- a/Shorewall-docs2/Install.xml +++ b/Shorewall-docs2/Install.xml @@ -15,7 +15,7 @@ - 2005-02-05 + 2005-02-26 2001 @@ -60,6 +60,28 @@ To install Shorewall using the RPM: + + Be sure that you have the correct RPM + package! + + The standard RPM package from shorewall.net and the mirrors is + known to work with Suse, Power PPC, Trustix and TurboLinux. There is + also an RPM package provided by Simon Matter that is taylored for + RedHat/Fedora + and another package from Jack Coates that is customized for Mandrake. All of these + are available from the download + page. + + If you try to install the wrong package, it probably won't + work. + + Install the RPM @@ -85,15 +107,15 @@ - Beginning with Shorewall 1.4.0, Shorewall is dependent on the - iproute package. Unfortunately, some distributions call this package - iproute2 which will cause the installation of Shorewall to fail with - the diagnostic: + Shorewall is dependent on the iproute package. Unfortunately, + some distributions call this package iproute2 which will cause the + installation of Shorewall to fail with the diagnostic: - error: failed dependencies:iproute is needed by shorewall-1.4.x-1 + error: failed dependencies:iproute is needed by shorewall-2.2.x-1 - This may be worked around by using the --nodeps option of - rpm. + This problem should not occur if you are using the correct RPM + package (see 1., above) but may be worked around by using the + --nodeps option of rpm. rpm -ivh --nodeps <shorewall rpm> @@ -261,17 +283,19 @@ INIT="rc.firewall" If you already have the Shorewall RPM installed and are upgrading to a new version: - - If you are upgrading from a 1.2 version of Shorewall to a 1.4 - version or and you have entries in the /etc/shorewall/hosts file then - please check your /etc/shorewall/interfaces file to be sure that it - contains an entry for each interface mentioned in the hosts file. Also, - there are certain 1.2 rule forms that are no longer supported under 1.4 - (you must use the new 1.4 syntax). See the upgrade issues for details. - - + + Be sure that you have the correct RPM + package! + + The standard RPM package from shorewall.net and the mirrors is + known to work with Suse, Power PPC, Trustix and TurboLinux. There is + also an RPM package provided by Simon Matter that is taylored for + RedHat/Fedora and another package from Jack Coates that is customized + for Mandrake. If you try to upgrade using the wrong package, it + probably won't work. + + Upgrade the RPM @@ -323,16 +347,6 @@ INIT="rc.firewall" If you already have Shorewall installed and are upgrading to a new version using the tarball: - - If you are upgrading from a 1.2 version of Shorewall to a 1.4 - version and you have entries in the /etc/shorewall/hosts file then - please check your /etc/shorewall/interfaces file to be sure that it - contains an entry for each interface mentioned in the hosts file. Also, - there are certain 1.2 rule forms that are no longer supported under 1.4 - (you must use the new 1.4 syntax). See the upgrade issues for details. - - unpack the tarball. diff --git a/Shorewall-docs2/Shorewall_Squid_Usage.xml b/Shorewall-docs2/Shorewall_Squid_Usage.xml index 9722b8ea6..22d22e2da 100644 --- a/Shorewall-docs2/Shorewall_Squid_Usage.xml +++ b/Shorewall-docs2/Shorewall_Squid_Usage.xml @@ -15,7 +15,7 @@ - 2005-02-28 + 2005-03-01 2003-2005 @@ -175,7 +175,7 @@ REDIRECT loc 3128 tcp www - !206.124.146. - * On your firewall system, issue the following command + On your firewall system, issue the following command echo 202 www.out >> /etc/iproute2/rt_tables @@ -184,7 +184,7 @@ REDIRECT loc 3128 tcp www - !206.124.146. In /etc/shorewall/init, put: if [ -z "`ip rule list | grep www.out`" ] ; then - ip rule add fwmark CA table www.out # Note 0xCA = 202 + ip rule add fwmark 0xCA table www.out # Note 0xCA = 202 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 @@ -257,7 +257,7 @@ chkconfig --level 35 iptables on In /etc/shorewall/init, put: if [ -z "`ip rule list | grep www.out`" ] ; then - ip rule add fwmark CA table www.out # Note 0xCA = 202 + ip rule add fwmark 0xCA table www.out # Note 0xCA = 202 ip route add default via 192.0.2.177 dev eth1 table www.out ip route flush cache fi diff --git a/Shorewall-docs2/bridge.xml b/Shorewall-docs2/bridge.xml index feda4c639..ec1ff22cd 100755 --- a/Shorewall-docs2/bridge.xml +++ b/Shorewall-docs2/bridge.xml @@ -15,7 +15,7 @@ - 2005-01-14 + 2005-02-22 2004 @@ -445,7 +445,7 @@ ln -s net.eth0 net.br0 # Remove net.eth*, add net.br0 and bridge. rc-update del net.eth0 rc-update del net.eth1 -rc-update add net,br0 default +rc-update add net.br0 default rc-update add bridge boot diff --git a/Shorewall-docs2/myfiles.xml b/Shorewall-docs2/myfiles.xml index b4f75dd06..e0a0028ce 100644 --- a/Shorewall-docs2/myfiles.xml +++ b/Shorewall-docs2/myfiles.xml @@ -15,7 +15,7 @@ - 2005-02-17 + 2005-02-25 2001-2005 @@ -53,10 +53,10 @@ I have DSL service and have 5 static IP addresses - (206.124.146.176-180). My DSL modem (Westell 2200 running - in Bridge mode) is connected to eth2 and has IP address 192.168.1.1 - (factory default). The modem is configured in bridge mode - so PPPoE is not involved. I have a local network connected to eth3 (subnet + (206.124.146.176-180). My DSL modem (Westell 2200) is + connected to eth2 and has IP address 192.168.1.1 (factory default). The + modem is configured in bridge mode so PPPoE is not + involved. I have a local network connected to eth3 (subnet 192.168.1.0/24), a wireless network (192.168.3.0/24) connected to eth0, and a DMZ connected to eth1 (206.124.146.176/32). Note that I configure the same IP address on both eth1 @@ -73,7 +73,7 @@ I use one-to-one NAT for Eastepnc6000 (My work system -- Windows - XP SP1). Internal address 192.168.1.7 and external address + XP SP1). Internal address 192.168.1.6 and external address 206.124.146.180. @@ -214,6 +214,7 @@ TCP_FLAGS_DISPOSITION=DROP
MIRRORS=<list of shorewall mirror ip addresses> NTPSERVERS=<list of the NTP servers I sync with> +POPSERVERS=<list of POP3 servers that I get mail from using 'fetchmail' on the DMZ server> LOG=ULOG WIFI_IF=eth0 EXT_IF=eth2 @@ -613,9 +614,10 @@ ACCEPT dmz net udp REJECT:$LOG dmz net udp 1025:1031 ACCEPT dmz net:$POPSERVERS tcp pop3 # -# Something is wrong with the FTP connection tracking code or there is some client out there -# that is sending a PORT command which that code doesn't understand. Either way, -# the following works around the problem. +# Some FTP clients insist on sending the PORT command in two separate packets. The FTP +# connection tracker in the kernel cannot parse the command and therefore cannot set +# up the proper expectations. We thus allow all outbound tcp traffic from local port 20 +# but log it so we can keep an eye on it. # ACCEPT:$LOG dmz net tcp 1024: 20 ##########################################################################################################################################################################