diff --git a/Shorewall-docs2/FAQ.xml b/Shorewall-docs2/FAQ.xml index a1e2d18c1..3f05ec721 100644 --- a/Shorewall-docs2/FAQ.xml +++ b/Shorewall-docs2/FAQ.xml @@ -17,7 +17,7 @@ - 2005-04-24 + 2005-05-08 2001-2005 @@ -99,22 +99,27 @@ shows how to do port forwarding under Shorewall. The format of a port-forwarding rule to a local system is as follows: - #ACTION SOURCE DEST PROTO DEST PORT -DNAT net loc:<local IP address>[:<local port>] <protocol> <port #> + #ACTION SOURCE DEST PROTO DEST PORT DNAT net + loc:<local IP address>[:<local + port>] <protocol> + <port #> So to forward UDP port 7777 to internal system 192.168.1.5, the rule is: - #ACTION SOURCE DEST PROTO DEST PORT -DNAT net loc:192.168.1.5 udp 7777 + #ACTION SOURCE DEST PROTO DEST PORT DNAT net + loc:192.168.1.5 udp 7777 If you want to forward requests directed to a particular address ( <external IP> ) on your firewall to an internal system: - #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL -# PORT DEST. -DNAT net loc:<local IP address>[:<local port>] <protocol> <port #> - <external IP> + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL # + PORT DEST. DNAT net loc:<local IP + address>[:<local port>] + <protocol> <port + #> - <external + IP> Finally, if you need to forward a range of ports, in the DEST PORT column specify the range as @@ -230,8 +235,8 @@ DNAT net loc:<local IP address>[:< In /etc/shorewall/rules: - #ACTION SOURCE DEST PROTO DEST PORT -DNAT net loc:192.168.1.3:22 tcp 1022 + #ACTION SOURCE DEST PROTO DEST PORT DNAT net + loc:192.168.1.3:22 tcp 1022
@@ -257,26 +262,27 @@ DNAT net loc:192.168.1.3:22 tcp 1022 You can enable access to the server from your local network using the firewall's external IP address by adding this rule: - #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL -# PORT DEST -DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176 + #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL + # PORT DEST DNAT loc dmz:192.168.2.4 tcp 80 - + 206.124.146.176 If your external IP address is dynamic, then you must do the following: In /etc/shorewall/init: - ETH0_IP=`find_interface_address eth0` + ETH0_IP=`find_interface_address + eth0` For users of Shorewall 2.1.0 and later: - ETH0_IP=`find_first_interface_address eth0` + ETH0_IP=`find_first_interface_address + eth0` and make your DNAT rule: - #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL -# PORT DEST. -DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL # + PORT DEST. DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP
@@ -292,8 +298,8 @@ DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0 If you add the following rule then from the net, you will have 4104 listening, from your LAN, port 22. - #ACTION SOURCE DEST PROTO DEST PORT(S) -DNAT net fw:192.168.1.1:22 tcp 4104 + #ACTION SOURCE DEST PROTO DEST PORT(S) DNAT net + fw:192.168.1.1:22 tcp 4104
@@ -373,40 +379,42 @@ DNAT net fw:192.168.1.1:22 tcp 4104 In /etc/shorewall/interfaces: - #ZONE INTERFACE BROADCAST OPTIONS -loc eth1 detect routeback + #ZONE INTERFACE BROADCAST OPTIONS loc eth1 detect + routeback In /etc/shorewall/masq: - #INTERFACE SUBNET ADDRESS PROTO PORT(S) -eth1:192.168.1.5 eth1 192.168.1.254 tcp www + #INTERFACE SUBNET ADDRESS PROTO PORT(S) + eth1:192.168.1.5 eth1 192.168.1.254 tcp www In /etc/shorewall/rules: - #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL -# PORT DEST. -DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69 + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL + # PORT DEST. DNAT loc loc:192.168.1.5 tcp www - + 130.151.100.69 That rule only works of course if you have a static external IP address. If you have a dynamic IP address and are running Shorewall 1.3.4 through Shorewall 2.0.* then include this in /etc/shorewall/init: - ETH0_IP=`find_interface_address eth0` + ETH0_IP=`find_interface_address + eth0` For users of Shorewall 2.1.0 and later: - ETH0_IP=`find_first_interface_address eth0` + ETH0_IP=`find_first_interface_address + eth0` and make your DNAT rule: - #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL -# PORT DEST. -DNAT loc loc:192.168.1.5 tcp www - $ETH0_IP + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL + # PORT DEST. DNAT loc loc:192.168.1.5 tcp www - + $ETH0_IP Using this technique, you will want to configure your DHCP/PPPoE client to automatically restart Shorewall each time that @@ -430,7 +438,8 @@ DNAT loc loc:192.168.1.5 tcp www - $ETH0 Oct 4 10:26:40 netgw kernel: Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200 DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF - PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0 + PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN + URGP=0 Answer: This is another problem @@ -460,12 +469,14 @@ DNAT loc loc:192.168.1.5 tcp www - $ETH0 Example: - Zone: dmz Interface: eth2 Subnet: 192.168.2.0/24 + Zone: dmz Interface: eth2 Subnet: + 192.168.2.0/24 In /etc/shorewall/interfaces: - #ZONE INTERFACE BROADCAST OPTIONS -dmz eth2 192.168.2.255 routeback + #ZONE INTERFACE BROADCAST OPTIONS dmz eth2 + 192.168.2.255 routeback In /etc/shorewall/nat, be sure that you have Yes in the ALL INTERFACES column. @@ -495,26 +506,27 @@ dmz eth2 192.168.2.255 routeback You can enable access to the server from your local network using the firewall's external IP address by adding this rule: - #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL -# PORT DEST -DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176 + #ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL + # PORT DEST DNAT loc dmz:192.168.2.4 tcp 80 - + 206.124.146.176 If your external IP address is dynamic, then you must do the following: In /etc/shorewall/init: - ETH0_IP=`find_interface_address eth0` + ETH0_IP=`find_interface_address + eth0` For users of Shorewall 2.1.0 and later: - ETH0_IP=`find_first_interface_address eth0` + ETH0_IP=`find_first_interface_address + eth0` and make your DNAT rule: - #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL -# PORT DEST. -DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP + #ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL # + PORT DEST. DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP @@ -533,17 +545,17 @@ DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0 following:
- > I know PoM -ng is going to address this issue, but till it is ready, and -> all the extras are ported to it, is there any way to use the h.323 -> contrack module kernel patch with a 2.6 kernel? -> Running 2.6.1 - no 2.4 kernel stuff on the system, so downgrade is not -> an option... The module is not ported yet to 2.6, sorry. -> Do I have any options besides a gatekeeper app (does not work in my -> network) or a proxy (would prefer to avoid them)? - -I suggest everyone to setup a proxy (gatekeeper) instead: the module is -really dumb and does not deserve to exist at all. It was an excellent tool -to debug/develop the newnat interface. + > I know PoM -ng is going to address this + issue, but till it is ready, and > all the extras are ported to it, + is there any way to use the h.323 > contrack module kernel patch + with a 2.6 kernel? > Running 2.6.1 - no 2.4 kernel stuff on the + system, so downgrade is not > an option... The module is not ported + yet to 2.6, sorry. > Do I have any options besides a gatekeeper app + (does not work in my > network) or a proxy (would prefer to avoid + them)? I suggest everyone to setup a proxy (gatekeeper) instead: the + module is really dumb and does not deserve to exist at all. It was an + excellent tool to debug/develop the newnat + interface.
Look here @@ -726,16 +738,16 @@ to debug/develop the newnat interface. I have this entry in /etc/shorewall/tunnels: - # TYPE ZONE GATEWAY GATEWAY -# ZONE -openvpn:5000 net 69.145.71.133 + # TYPE ZONE GATEWAY GATEWAY # ZONE openvpn:5000 net + 69.145.71.133 Yet I am seeing this log message: - Oct 12 13:41:03 localhost kernel: Shorewall:net2all:DROP:IN=eth0 OUT= -MAC=00:04:5a:7f:92:9f:00:b0:c2:89:68:e4:08:00 SRC=69.145.71.133 -DST=216.187.138.18 LEN=42 TOS=0x00 PREC=0x00 TTL=46 ID=11 DF PROTO=UDP -SPT=33120 DPT=5000 LEN=22 + Oct 12 13:41:03 localhost kernel: + Shorewall:net2all:DROP:IN=eth0 OUT= + MAC=00:04:5a:7f:92:9f:00:b0:c2:89:68:e4:08:00 SRC=69.145.71.133 + DST=216.187.138.18 LEN=42 TOS=0x00 PREC=0x00 TTL=46 ID=11 DF PROTO=UDP + SPT=33120 DPT=5000 LEN=22 Answer: Shorewall's openvpn tunnel type assumes that OpenVPN will be @@ -745,9 +757,8 @@ SPT=33120 DPT=5000 LEN=22 url="Documentation.htm#Tunnels">/etc/shorewall/tunnels entry with this one: - # TYPE ZONE GATEWAY GATEWAY -# ZONE -generic:udp:5000 net 69.145.71.133 + # TYPE ZONE GATEWAY GATEWAY # ZONE generic:udp:5000 net + 69.145.71.133 @@ -776,8 +787,7 @@ generic:udp:5000 net 69.145.71.133 /etc/shorewall/shorewall.conf -- If you want to log all messages, set: - LOGLIMIT="" -LOGBURST="" + LOGLIMIT="" LOGBURST="" Beginning with Shorewall version 1.3.12, you can set up Shorewall to log all of its messages @@ -791,12 +801,14 @@ LOGBURST="" that may be helpful: http://www.shorewall.net/pub/shorewall/parsefw/ -http://www.fireparse.com -http://cert.uni-stuttgart.de/projects/fwlogwatch -http://www.logwatch.org -http://gege.org/iptables -http://home.regit.org/ulogd-php.html + url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/pub/shorewall/parsefw/ + http://www.fireparse.com + http://cert.uni-stuttgart.de/projects/fwlogwatch + http://www.logwatch.org + http://gege.org/iptables + http://home.regit.org/ulogd-php.html I personally use Logwatch. It emails me a report each day from my various systems with each report summarizing the logged activity on @@ -804,7 +816,7 @@ LOGBURST=""
- (FAQ 2b) DROP messages on port 10619 are flooding the logs with + <title>(FAQ 6b) DROP messages on port 10619 are flooding the logs with their connect requests. Can i exclude these error messages for this port temporarily from logging in Shorewall? @@ -1074,13 +1086,14 @@ LOGBURST="" Here is an example: - Jun 27 15:37:56 gateway kernel: - Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 - DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP - SPT=1803 DPT=53 LEN=47 + Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 + TTL=63 ID=5805 DF PROTO=UDP SPT=1803 + DPT=53 LEN=47 Let's look at the important parts of this message: @@ -1233,23 +1246,21 @@ LOGBURST="" /etc/shorewall/interfaces: - #ZONE INTERFACE BROADCAST OPTIONS -net eth0 detect -net eth1 detect + #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect net + eth1 detect /etc/shorewall/policy: - #SOURCE DESTINATION POLICY LIMIT:BURST -net net DROP + #SOURCE DESTINATION POLICY LIMIT:BURST net net + DROP If you have masqueraded hosts, be sure to update /etc/shorewall/masq to masquerade to both ISPs. For example, if you masquerade all hosts connected to eth2 then: - #INTERFACE SUBNET ADDRESS -eth0 eth2 -eth1 eth2 + #INTERFACE SUBNET ADDRESS eth0 eth2 eth1 + eth2 There was an article in SysAdmin covering the topic of setting up routing for this configuration. It may be found at providers that connect a local network (or even a single machine) to the big Internet. - ________ - +------------+ / - | | | - +-------------+ Provider 1 +------- - __ | | | / - ___/ \_ +------+-------+ +------------+ | - _/ \__ | if1 | / - / \ | | | -| Local network -----+ Linux router | | Internet - \_ __/ | | | - \__ __/ | if2 | \ - \___/ +------+-------+ +------------+ | - | | | \ - +-------------+ Provider 2 +------- - | | | - +------------+ \________ - + ________ +------------+ / | | | +-------------+ + Provider 1 +------- __ | | | / ___/ \_ +------+-------+ +------------+ + | _/ \__ | if1 | / / \ | | | | Local network -----+ Linux router | | + Internet \_ __/ | | | \__ __/ | if2 | \ \___/ +------+-------+ + +------------+ | | | | \ +-------------+ Provider 2 +------- | | | + +------------+ \________ There are usually two questions given this setup. @@ -1319,10 +1319,9 @@ eth1 eth2 These are added in /etc/iproute2/rt_tables. Then you set up routing in these tables as follows: - ip route add $P1_NET dev $IF1 src $IP1 table T1 -ip route add default via $P1 table T1 -ip route add $P2_NET dev $IF2 src $IP2 table T2 -ip route add default via $P2 table T2 + ip route add $P1_NET dev $IF1 src $IP1 table T1 ip + route add default via $P1 table T1 ip route add $P2_NET dev $IF2 src + $IP2 table T2 ip route add default via $P2 table T2 Nothing spectacular, just build a route to the gateway and build a default route via that gateway, as you would do in the case of a @@ -1336,8 +1335,8 @@ ip route add default via $P2 table T2 to that neighbour. Note the `src' arguments, they make sure the right outgoing IP address is chosen. - ip route add $P1_NET dev $IF1 src $IP1 -ip route add $P2_NET dev $IF2 src $IP2 + ip route add $P1_NET dev $IF1 src $IP1 ip route add + $P2_NET dev $IF2 src $IP2 Then, your preference for default route: @@ -1348,8 +1347,8 @@ ip route add $P2_NET dev $IF2 src $IP2 a given interface if you already have the corresponding source address: - ip rule add from $IP1 table T1 -ip rule add from $IP2 table T2 + ip rule add from $IP1 table T1 ip rule add from $IP2 + table T2 This set of commands makes sure all answers to traffic coming in on a particular interface get answered from that interface. @@ -1358,12 +1357,11 @@ ip rule add from $IP2 table T2 'If $P0_NET is the local network and $IF0 is its interface, the following additional entries are desirable: - ip route add $P0_NET dev $IF0 table T1 -ip route add $P2_NET dev $IF2 table T1 -ip route add 127.0.0.0/8 dev lo table T1 -ip route add $P0_NET dev $IF0 table T2 -ip route add $P1_NET dev $IF1 table T2 -ip route add 127.0.0.0/8 dev lo table T2 + ip route add $P0_NET dev $IF0 + table T1 ip route add $P2_NET dev $IF2 table T1 ip route add + 127.0.0.0/8 dev lo table T1 ip route add $P0_NET dev $IF0 table T2 + ip route add $P1_NET dev $IF1 table T2 ip route add 127.0.0.0/8 dev + lo table T2 Now, this is just the very basic setup. It will work for all @@ -1386,8 +1384,8 @@ ip route add 127.0.0.0/8 dev lo table T2 is done as follows (once more building on the example in the section on split-access): - ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \ - nexthop via $P2 dev $IF2 weight 1 + ip route add default scope global nexthop via $P1 dev + $IF1 weight 1 \ nexthop via $P2 dev $IF2 weight 1 This will balance the routes over both providers. The weight parameters can be tweaked to favor one @@ -1464,20 +1462,21 @@ ip route add 127.0.0.0/8 dev lo table T2 Answer: The output you will see looks something like this: - /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy -Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters -/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod -/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed -/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed -iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?) -Perhaps iptables or your kernel needs to be upgraded. + /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: + init_module: Device or resource busy Hint: insmod errors can be caused + by incorrect module parameters, including invalid IO or IRQ parameters + /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod + /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed + /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod + ip_tables failed iptables v1.2.3: can't initialize iptables table `nat': + iptables who? (do you need to insmod?) Perhaps iptables or your kernel + needs to be upgraded. This problem is usually corrected through the following sequence of commands - service ipchains stop -chkconfig --delete ipchains -rmmod ipchains + service ipchains stop chkconfig --delete + ipchains rmmod ipchains Also, be sure to check the errata for problems concerning the version of iptables (v1.2.3) shipped with @@ -1500,21 +1499,13 @@ rmmod ipchains I just installed Shorewall and when I issue the start command, I see the following: - Processing /etc/shorewall/params ... -Processing /etc/shorewall/shorewall.conf ... -Starting Shorewall... -Loading Modules... -Initializing... -Determining Zones... - Zones: net loc -Validating interfaces file... -Validating hosts file... -Determining Hosts in Zones... - Net Zone: eth0:0.0.0.0/0 - Local Zone: eth1:0.0.0.0/0 -Deleting user chains... -Creating input Chains... -... + Processing /etc/shorewall/params ... Processing + /etc/shorewall/shorewall.conf ... Starting Shorewall... Loading + Modules... Initializing... Determining Zones... Zones: net loc + Validating interfaces file... Validating hosts file... Determining Hosts + in Zones... Net Zone: eth0:0.0.0.0/0 + Local Zone: eth1:0.0.0.0/0 + Deleting user chains... Creating input Chains... ... Why can't Shorewall detect my interfaces properly? @@ -1629,11 +1620,11 @@ Creating input Chains... When I start shorewall I got the following errors. - Oct 30 11:13:12 fwr modprobe: modprobe: Can't locate module ipt_conntrack -Oct 30 11:13:17 fwr modprobe: modprobe: Can't locate module ipt_pkttype -Oct 30 11:13:18 fwr modprobe: modprobe: Can't locate module ipt_pkttype -Oct 30 11:13:57 fwr last message repeated 2 times -Oct 30 11:14:06 fwr root: Shorewall Restarted + Oct 30 11:13:12 fwr modprobe: modprobe: Can't locate + module ipt_conntrack Oct 30 11:13:17 fwr modprobe: modprobe: Can't + locate module ipt_pkttype Oct 30 11:13:18 fwr modprobe: modprobe: Can't + locate module ipt_pkttype Oct 30 11:13:57 fwr last message repeated 2 + times Oct 30 11:14:06 fwr root: Shorewall Restarted The "shorewall status" output seems complying with my rules set. Should I worry ? and is there any way to get rid of these errors @@ -1663,8 +1654,8 @@ Oct 30 11:14:06 fwr root: Shorewall Restarted are not disabling a feature in your new kernel that you want to use. - alias ipt_conntrack off -alias ipt_pkttype off + alias ipt_conntrack off alias ipt_pkttype + off For users who don't have the pkttype match feature in their kernel, I also recommend upgrading to Shorewall 2.0.6 or later and then @@ -1689,15 +1680,12 @@ alias ipt_pkttype off shorewall start produces the following output: - … -Processing /etc/shorewall/policy... - Policy ACCEPT for fw to net using chain fw2net - Policy ACCEPT for loc0 to net using chain loc02net - Policy ACCEPT for loc1 to net using chain loc12net - Policy ACCEPT for wlan to net using chain wlan2net -Masqueraded Networks and Hosts: -iptables: Invalid argument - ERROR: Command "/sbin/iptables -t nat -A …" Failed + … Processing /etc/shorewall/policy... Policy ACCEPT for + fw to net using chain fw2net Policy ACCEPT for loc0 to net using chain + loc02net Policy ACCEPT for loc1 to net using chain loc12net Policy + ACCEPT for wlan to net using chain wlan2net Masqueraded Networks and + Hosts: iptables: Invalid argument ERROR: Command "/sbin/iptables -t nat + -A …" Failed Answer: 99.999% of the time, this error is caused by a mismatch between your iptables and kernel. @@ -1771,7 +1759,8 @@ iptables: Invalid argument At the shell prompt, type: - /sbin/shorewall version + /sbin/shorewall + version
@@ -1891,7 +1880,8 @@ iptables: Invalid argument version of Shorewall earlier than 1.3.1, create /etc/shorewall/start and in it, place the following: - run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT + run_iptables -I rfc1918 -s 192.168.100.1 -j + ACCEPT If you are running version 1.3.1 or later, add the following to /etc/shorewall/rfc1918 @@ -1902,8 +1892,7 @@ iptables: Invalid argument Be sure that you add the entry ABOVE the entry for 192.168.0.0/16. - #SUBNET TARGET -192.168.100.1 RETURN + #SUBNET TARGET 192.168.100.1 RETURN If you add a second IP address to your external firewall @@ -1912,9 +1901,8 @@ iptables: Invalid argument configure the address 192.168.100.2 on your firewall, then you would add two entries to /etc/shorewall/rfc1918: - #SUBNET TARGET -192.168.100.1 RETURN -192.168.100.2 RETURN + #SUBNET TARGET 192.168.100.1 RETURN 192.168.100.2 + RETURN
@@ -1933,8 +1921,10 @@ iptables: Invalid argument 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 + 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 @@ -1946,8 +1936,8 @@ TOS=0x00 PREC=0x00 TTL=64 ID=26774 DF PROTO=TCP SPT=32797 DPT=80 WINDOW=5840 RES Add a zone for the modem in /etc/shorewall/zones: - #ZONE DISPLAY COMMENTS -modem ADSLModem Zone for modem + #ZONE DISPLAY COMMENTS modem ADSLModem Zone for + modem @@ -1956,17 +1946,16 @@ modem ADSLModem Zone for modem to your modem) in /etc/shorewall/interfaces: - #ZONE INTERFACE BROADCAST OPTIONS -modem eth0 detect + #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 + #ACTION SOURCE DEST PROTO DEST PORT(S) ACCEPT fw + modem tcp 80 ACCEPT loc modem tcp 80 @@ -1980,8 +1969,8 @@ ACCEPT loc modem tcp 80 /etc/shorewall/masq: - #INTERFACE SUBNET ADDRESS -eth0 eth1 # eth1 = interface to local network + #INTERFACE SUBNET ADDRESS eth0 eth1 # eth1 = interface + to local network For an example of this when the ADSL/Cable modem is bridged, see my configuration. In that case, I @@ -2038,7 +2027,8 @@ eth0 eth1 # eth1 = interface to local netwo Example: - ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22 + ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp + 22
@@ -2063,7 +2053,8 @@ eth0 eth1 # eth1 = interface to local netwo Otherwise, add this command to your /etc/shorewall/start file: - run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP + run_iptables -D OUTPUT -p ! icmp -m state + --state INVALID -j DROP
@@ -2086,19 +2077,14 @@ eth0 eth1 # eth1 = interface to local netwo The last few lines of a startup trace are these: - + run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j -MASQUERADE -+ '[' 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j -MASQUERADE' = 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0. -0/0 -j MASQUERADE' ']' -+ run_iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j -MASQUERADE -+ iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j -MASQUERADE -iptables: Invalid argument -+ '[' -z '' ']' -+ stop_firewall -+ set +x + + run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 + -d 0.0.0.0/0 -j MASQUERADE + '[' 'x-t nat -A eth0_masq -s + 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE' = 'x-t nat -A eth0_masq -s + 192.168.2.0/24 -d 0.0.0. 0/0 -j MASQUERADE' ']' + run_iptables -t nat + -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE + iptables + -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j MASQUERADE + iptables: Invalid argument + '[' -z '' ']' + stop_firewall + set + +x Answer: Your new kernel contains headers that are incompatible with the ones used to compile @@ -2122,15 +2108,15 @@ iptables: Invalid argument everyone's site. Adsense is a Javascript that people add to their Web pages. So I entered the rule: - #ACTION SOURCE DEST PROTO -REJECT fw net:pagead2.googlesyndication.com all + #ACTION SOURCE DEST PROTO REJECT fw + net:pagead2.googlesyndication.com all However, this also sometimes restricts access to "google.com". Why is that? Using dig, I found these IPs for domain googlesyndication.com:216.239.37.99 -216.239.39.99And this for google.com:216.239.37.99 -216.239.39.99 -216.239.57.99So my guess is that you are not actually + 216.239.39.99And this for + google.com:216.239.37.99 216.239.39.99 + 216.239.57.99So my guess is that you are not actually blocking the domain, but rather the IP being called. So how in the world do you block an actual domain name? @@ -2150,24 +2136,23 @@ REJECT fw net:pagead2.googlesyndication.com all - #ACTION SOURCE DEST PROTO -REJECT fw net:216.239.37.99 all -REJECT fw net:216.239.39.99 allGiven that - name-based multiple hosting is a common practice (another example: - lists.shorewall.net and www1.shorewall.net are both hosted on the same - system with a single IP address), it is not possible to filter - connections to a particular name by examiniation of protocol headers - alone. While some protocols such as FTP - require the firewall to examine and possibly modify packet payload, - parsing the payload of individual packets doesn't always work because - the application-level data stream can be split across packets in - arbitrary ways. This is one of the weaknesses of the 'string match' - Netfilter extension available in Patch-O-Matic. The only sure way to - filter on packet content is to proxy the connections in question -- in - the case of HTTP, this means running something like Squid. Proxying allows the - proxy process to assemble complete application-level messages which can - then be accurately parsed and decisions can be made based on the + #ACTION SOURCE DEST PROTO REJECT fw + net:216.239.37.99 all REJECT fw net:216.239.39.99 + allGiven that name-based multiple hosting is a common + practice (another example: lists.shorewall.net and www1.shorewall.net + are both hosted on the same system with a single IP address), it is not + possible to filter connections to a particular name by examiniation of + protocol headers alone. While some protocols such as FTP require the firewall to examine and possibly + modify packet payload, parsing the payload of individual packets doesn't + always work because the application-level data stream can be split + across packets in arbitrary ways. This is one of the weaknesses of the + 'string match' Netfilter extension available in Patch-O-Matic. The only + sure way to filter on packet content is to proxy the connections in + question -- in the case of HTTP, this means running something like + Squid. Proxying allows + the proxy process to assemble complete application-level messages which + can then be accurately parsed and decisions can be made based on the result. @@ -2179,27 +2164,16 @@ REJECT fw net:216.239.39.99 allGiven that check. There is a section near the top of the resulting output that gives you a synopsis of your kernel/iptables capabilities. - gateway:/etc/shorewall # shorewall check -Loading /usr/share/shorewall/functions... -Processing /etc/shorewall/params ... -Processing /etc/shorewall/shorewall.conf... -Loading Modules... - -Notice: The 'check' command is unsupported and problem - reports complaining about errors that it didn't catch - will not be accepted - -Shorewall has detected the following iptables/netfilter capabilities: - NAT: Available - Packet Mangling: Available - Multi-port Match: Available - Connection Tracking Match: Available - Packet Type Match: Not available - Policy Match: Available - Physdev Match: Available - IP range Match: Available -Verifying Configuration... -... + gateway:/etc/shorewall # shorewall check Loading + /usr/share/shorewall/functions... Processing /etc/shorewall/params ... + Processing /etc/shorewall/shorewall.conf... Loading Modules... Notice: + The 'check' command is unsupported and problem reports complaining about + errors that it didn't catch will not be accepted Shorewall has detected + the following iptables/netfilter capabilities: NAT: Available Packet + Mangling: Available Multi-port Match: Available Connection Tracking + Match: Available Packet Type Match: Not available Policy Match: + Available Physdev Match: Available IP range Match: Available Verifying + Configuration... ... \ No newline at end of file diff --git a/Shorewall-docs2/images/Thumbs.db b/Shorewall-docs2/images/Thumbs.db index d8abb6f19..55d63c5fb 100644 Binary files a/Shorewall-docs2/images/Thumbs.db and b/Shorewall-docs2/images/Thumbs.db differ