diff --git a/Shorewall-docs2/Documentation_Index.xml b/Shorewall-docs2/Documentation_Index.xml index 4a8ed8820..9b1720f5e 100644 --- a/Shorewall-docs2/Documentation_Index.xml +++ b/Shorewall-docs2/Documentation_Index.xml @@ -15,7 +15,7 @@ - 2005-04-23 + 2005-05-09 2001-2005 @@ -23,7 +23,7 @@ Thomas M. Eastep - 2.2.4 + 2.3.0 Permission is granted to copy, distribute and/or modify this @@ -363,6 +363,10 @@ 2.1 or Later. + + Ipsets + + Kazaa Filtering diff --git a/Shorewall-docs2/FAQ.xml b/Shorewall-docs2/FAQ.xml index c44cff964..b12448286 100644 --- a/Shorewall-docs2/FAQ.xml +++ b/Shorewall-docs2/FAQ.xml @@ -17,7 +17,7 @@ - 2005-05-08 + 2005-05-09 2001-2005 @@ -99,27 +99,22 @@ 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 @@ -235,8 +230,8 @@ 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
@@ -262,27 +257,26 @@ 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
@@ -298,8 +292,8 @@ 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
@@ -361,9 +355,9 @@ - If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then if you are running Shorewall 2.0.0 or - 2.0.1 then please see the If you insist on a stupid IP solution to the accessibility problem + rather than a more efficient DNS solution, then if you are running + Shorewall 2.0.0 or 2.0.1 then please see the Shorewall 1.4 FAQ. @@ -379,42 +373,40 @@ 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 @@ -438,8 +430,7 @@ 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 @@ -452,8 +443,8 @@ addresses and can be accessed externally and internally using the same address. - If you don't like those solutions and prefer routing all Z->Z - traffic through your firewall then: + If you don't like those solutions and prefer to stupidly route + all Z->Z traffic through your firewall then: @@ -469,26 +460,23 @@ Example: - Zone: dmz Interface: eth2 Subnet: 192.168.2.0/24, Address 192.168.2.254 + Zone: dmz Interface: eth2 Subnet: 192.168.2.0/24 Address: 192.168.2.254 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. - In /etc/shorewall/masq: + In /etc/shorewall/masq: - #INTERFACE SUBNET ADDRESS -eth2 192.168.2.0/24 192.168.2.254 + #INTERFACE SUBNETS ADDRESS +eth2 eth2 192.168.2.254 - As in FAQ 2 above, all redirected traffic will appear to the - server to originate on the firewall (which is yet one more reason - that you should use DNS to correct this problem rather than applying - horrible IP hacks). + Like the idiotic hack in FAQ 2 above, this will make all + dmz->dmz traffic appear to originate on the firewall. @@ -515,27 +503,26 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -554,22 +541,23 @@ eth2 192.168.2.0/24 192.168.2.254 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 for a solution for MSN IM - but be aware that there are significant security risks involved with - this solution. Also check the Netfilter mailing list archives at Look here + for a solution for MSN IM but be aware that there are significant + security risks involved with this solution. Also check the Netfilter + mailing list archives at http://www.netfilter.org. @@ -746,16 +734,16 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -765,8 +753,9 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -795,7 +784,8 @@ eth2 192.168.2.0/24 192.168.2.254 /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 @@ -809,14 +799,12 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1094,14 +1082,13 @@ eth2 192.168.2.0/24 192.168.2.254 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: @@ -1254,21 +1241,23 @@ eth2 192.168.2.0/24 192.168.2.254 /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. @@ -1327,9 +1327,10 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1343,8 +1344,8 @@ eth2 192.168.2.0/24 192.168.2.254 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: @@ -1355,8 +1356,8 @@ eth2 192.168.2.0/24 192.168.2.254 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. @@ -1365,11 +1366,12 @@ eth2 192.168.2.0/24 192.168.2.254 '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 @@ -1392,8 +1394,8 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1470,21 +1472,20 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1507,13 +1508,21 @@ eth2 192.168.2.0/24 192.168.2.254 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? @@ -1628,11 +1637,11 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1662,8 +1671,8 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1688,12 +1697,15 @@ eth2 192.168.2.0/24 192.168.2.254 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. @@ -1767,8 +1779,7 @@ eth2 192.168.2.0/24 192.168.2.254 At the shell prompt, type: - /sbin/shorewall - version + /sbin/shorewall version
@@ -1888,8 +1899,7 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1900,7 +1910,8 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1909,8 +1920,9 @@ eth2 192.168.2.0/24 192.168.2.254 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
@@ -1929,10 +1941,8 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1944,8 +1954,8 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1954,16 +1964,17 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -1977,8 +1988,8 @@ eth2 192.168.2.0/24 192.168.2.254 /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 @@ -2035,8 +2046,7 @@ eth2 192.168.2.0/24 192.168.2.254 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
@@ -2061,8 +2071,7 @@ eth2 192.168.2.0/24 192.168.2.254 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
@@ -2085,14 +2094,19 @@ eth2 192.168.2.0/24 192.168.2.254 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 @@ -2116,15 +2130,15 @@ eth2 192.168.2.0/24 192.168.2.254 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? @@ -2144,23 +2158,24 @@ eth2 192.168.2.0/24 192.168.2.254 expressed in terms of those IP addresses. So the rule that you entered was equivalent to: - #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. @@ -2172,16 +2187,27 @@ eth2 192.168.2.0/24 192.168.2.254 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