Hi,
I read in the errata section that the "new" shorewall features (I
assume
version >2.0) do not work correctly with iptables 1.2.9. I am not sure,
if that is the explanation for the behaviour I see.
The setup:
[root@gatekeeper shorewall]# rpm -q iptables
iptables-1.2.9-2.3.1
[root@gatekeeper shorewall]# uname -a
Linux gatekeeper 2.6.6-1.435WLAN #1 Sat Jul 3 10:38:51 CEST 2004 i686
i686 i386 GNU/Linux
[root@gatekeeper shorewall]# shorewall version
2.0.3
[root@gatekeeper shorewall]# ip addr show
1: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:10:83:02:36:ce brd ff:ff:ff:ff:ff:ff
inet 192.168.200.1/24 brd 192.168.200.255 scope global eth2
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:60:b0:c2:2c:2b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.9/24 brd 192.168.0.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:10:83:02:55:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1
4: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
5: wifi0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ieee802.11 00:09:5b:12:0f:58 brd ff:ff:ff:ff:ff:ff
6: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:09:5b:12:0f:58 brd ff:ff:ff:ff:ff:ff
inet 192.168.30.1/24 brd 192.168.30.255 scope global wlan0
7: wlan0ap: <BROADCAST,MULTICAST,UP> mtu 2290 qdisc noqueue
link/ieee802.11 00:09:5b:12:0f:58 brd ff:ff:ff:ff:ff:ff
[root@gatekeeper shorewall]# ip route show
192.168.100.0/24 dev eth1 scope link
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.9
192.168.30.0/24 dev wlan0 scope link
192.168.200.0/24 dev eth2 scope link
169.254.0.0/16 dev wlan0 scope link
127.0.0.0/8 dev lo scope link
default via 192.168.0.1 dev eth0
==========
I have made two observations:
1) the setting in the /etc/shorewall/policy file is ignored with respect
to icmp from one zone to another, but that is not really a problem,
since I can use the /etc/shorewall/rules for that.
2) Given this zone set up:
#ZONE INTERFACE BROADCAST OPTIONS
#
net eth0 detect dhcp
loc eth1 detect
dmz eth2 detect
wlan wlan0 detect
I have a transparent squid proxy in zone dmz (and a Web server as well).
In order to force the use of the proxy for clients in zone loc and wlan
I have used the setting as described in
http://www.shorewall.net/Shorewall_Squid_Usage.html
I have noticed that this only works if I insert the iptables rules in
the /etc/shorewall/start, it does not work, if I use the tcrules with
the respective settings.
This may very well be an iptables bug, but I would like to get
confirmation on that.
Here is some information I gathered. Note the 0 packet count for the
chain tcpre at the bottom:
[root@gatekeeper shorewall]# iptables -L -v -t mangle
Chain PREROUTING (policy ACCEPT 198K packets, 81M bytes)
pkts bytes target prot opt in out source
destination
87826 37M pretos all -- any any anywhere
anywhere
87822 37M tcpre all -- any any anywhere
anywhere
12 507 MARK tcp -- eth1 any anywhere
anywhere tcp dpt:http MARK set 0xca
1004 99057 MARK tcp -- wlan0 any anywhere
anywhere tcp dpt:http MARK set 0xc9
Chain INPUT (policy ACCEPT 38339 packets, 7802K bytes)
.... uninteresting stuff deleted...
Chain tcpre (1 references)
pkts bytes target prot opt in out source
destination
0 0 MARK tcp -- wlan0 any anywhere
0.0.0.0 tcp dpt:http MARK set 0xc9
0 0 MARK tcp -- eth1 any anywhere
0.0.0.0 tcp dpt:http MARK set 0xca
[root@gatekeeper shorewall]#
tcrules:
##############################################################################
#MARK SOURCE DEST PROTO PORT(S) CLIENT
USER
# PORT(S)
# 201:P wlan0 0.0.0.0 tcp 80
# 202:P eth1 0.0.0.0 tcp 80
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
###########################################################################
# Shorewall 2.0 -- /etc/shorewall/start
#
# Add commands below that you want to be executed after shorewall has
# been started or restarted.
#
iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 80 -j MARK
--set-mark 202
iptables -t mangle -A PREROUTING -i wlan0 -p tcp --dport 80 -j MARK
--set-mark 201
Best Regards,
Uwe Behle
Uwe Behle wrote:> Hi, > I read in the errata section that the "new" shorewall features (I assume > version >2.0) do not work correctly with iptables 1.2.9.The iptables 1.2.9 problem has to do with Shorewall''s intergration with iptables-save/iptables-restore; iptables-restore fails because iptables-save is resolving an IP address to a DNS name in a place where it should be using the raw IP address.> I am not sure, if that is the explanation for the behaviour I see.If you are not seeing the above problem then iptables 1.2.9 is likely not at fault.> > The setup: > > [root@gatekeeper shorewall]# rpm -q iptables > iptables-1.2.9-2.3.1 > [root@gatekeeper shorewall]# uname -a > Linux gatekeeper 2.6.6-1.435WLAN #1 Sat Jul 3 10:38:51 CEST 2004 i686 > i686 i386 GNU/Linux > [root@gatekeeper shorewall]# shorewall version > 2.0.3 > [root@gatekeeper shorewall]# ip addr show > 1: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:10:83:02:36:ce brd ff:ff:ff:ff:ff:ff > inet 192.168.200.1/24 brd 192.168.200.255 scope global eth2 > 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:60:b0:c2:2c:2b brd ff:ff:ff:ff:ff:ff > inet 192.168.0.9/24 brd 192.168.0.255 scope global eth0 > 3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ether 00:10:83:02:55:40 brd ff:ff:ff:ff:ff:ff > inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1 > 4: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo > 5: wifi0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 > link/ieee802.11 00:09:5b:12:0f:58 brd ff:ff:ff:ff:ff:ff > 6: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue > link/ether 00:09:5b:12:0f:58 brd ff:ff:ff:ff:ff:ff > inet 192.168.30.1/24 brd 192.168.30.255 scope global wlan0 > 7: wlan0ap: <BROADCAST,MULTICAST,UP> mtu 2290 qdisc noqueue > link/ieee802.11 00:09:5b:12:0f:58 brd ff:ff:ff:ff:ff:ff > [root@gatekeeper shorewall]# ip route show > 192.168.100.0/24 dev eth1 scope link > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.9 > 192.168.30.0/24 dev wlan0 scope link > 192.168.200.0/24 dev eth2 scope link > 169.254.0.0/16 dev wlan0 scope link > 127.0.0.0/8 dev lo scope link > default via 192.168.0.1 dev eth0 > > ==========> > I have made two observations: > 1) the setting in the /etc/shorewall/policy file is ignored with respect > to icmp from one zone to another''ping'' requests are goverened by the policy just like any other traffic. ICMPs that are in response to earlier allowed traffic are always permitted, regardless of policy but that is a consequence of the stateful nature of the Shorewall-based firewall. but that is not really a problem,> since I can use the /etc/shorewall/rules for that. > > 2) Given this zone set up: > > #ZONE INTERFACE BROADCAST OPTIONS > # > net eth0 detect dhcp > loc eth1 detect > dmz eth2 detect > wlan wlan0 detect > > I have a transparent squid proxy in zone dmz (and a Web server as well). > In order to force the use of the proxy for clients in zone loc and wlan > I have used the setting as described in > http://www.shorewall.net/Shorewall_Squid_Usage.html > > I have noticed that this only works if I insert the iptables rules in > the /etc/shorewall/start, it does not work, if I use the tcrules with > the respective settings. > > This may very well be an iptables bug, but I would like to get > confirmation on that. > > Here is some information I gathered. Note the 0 packet count for the > chain tcpre at the bottom: > [root@gatekeeper shorewall]# iptables -L -v -t mangle > Chain PREROUTING (policy ACCEPT 198K packets, 81M bytes) > pkts bytes target prot opt in out source > destination > 87826 37M pretos all -- any any anywhere > anywhere > 87822 37M tcpre all -- any any anywhere > anywhere > 12 507 MARK tcp -- eth1 any anywhere > anywhere tcp dpt:http MARK set 0xca > 1004 99057 MARK tcp -- wlan0 any anywhere > anywhere tcp dpt:http MARK set 0xc9 > > Chain INPUT (policy ACCEPT 38339 packets, 7802K bytes) > .... uninteresting stuff deleted... > Chain tcpre (1 references) > pkts bytes target prot opt in out source > destination > 0 0 MARK tcp -- wlan0 any anywhere > 0.0.0.0 tcp dpt:http MARK set 0xc9 > 0 0 MARK tcp -- eth1 any anywhere > 0.0.0.0 tcp dpt:http MARK set 0xca > [root@gatekeeper shorewall] > > tcrules: > ############################################################################## > #MARK SOURCE DEST PROTO PORT(S) CLIENT > USER > # PORT(S) > # 201:P wlan0 0.0.0.0 tcp 80 > # 202:P eth1 0.0.0.0 tcp 80You want 0.0.0.0/0 -- not 0.0.0.0!!! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net