Tom Eastep wrote: > Lukasz Spaleniak wrote: > > The relevant policies are these: > >> fw-wro:~# setkey -DP >> 192.168.6.0/24[any] 10.1.0.0/24[any] any >> in ipsec >> esp/tunnel/195.205.11.34-195.205.101.2/unique#16453 >> created: Jan 13 14:10:16 2008 lastused: >> lifetime: 0(s) validtime: 0(s) >> spid=2552 seq=1 pid=24325 >> refcnt=1 > > ... > >> 192.168.6.0/24[any] 10.1.0.0/24[any] any >> out ipsec >> esp/tunnel/195.205.101.2-195.205.142.34/unique#16458 >> created: Jan 13 14:10:16 2008 lastused: Jan 22 21:37:06 2008 >> lifetime: 0(s) validtime: 0(s) >> spid=2617 seq=9 pid=24325 >> refcnt=1 >
As I was preparing a query to the Netfilter team, I realized that my original
analysis
of the rules was incorrect:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
9138K 6304M eth0_fwd 0 -- eth0 * 0.0.0.0/0 0.0.0.0/0
<============ Rule 1
...
Chain eth0_fwd (1 references)
pkts bytes target prot opt in out source destination
211K 17M dynamic 0 -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID,NEW
203K 16M smurfs 0 -- * * 0.0.0.0/0 0.0.0.0/0
state INVALID,NEW policy match dir in pol none
187K 15M norfc1918 0 -- * * 0.0.0.0/0 0.0.0.0/0
state NEW policy match dir in pol none
8240K 6194M tcpflags tcp -- * * 0.0.0.0/0 0.0.0.0/0
policy match dir in pol none
8778 812K vpn_frwd 0 -- * * 192.168.6.0/24 0.0.0.0/0
policy match dir in pol ipsec <=========== Rule 2
0 0 vpn_frwd 0 -- * * 195.205.11.34 0.0.0.0/0
policy match dir in pol ipsec
191 18390 vpn_frwd 0 -- * * 10.1.0.0/24 0.0.0.0/0
policy match dir in pol ipsec
0 0 vpn_frwd 0 -- * * 195.205.142.34 0.0.0.0/0
policy match dir in pol ipsec
9943 419K vpn_frwd 0 -- * * 192.168.10.0/24 0.0.0.0/0
policy match dir in pol ipsec
0 0 vpn_frwd 0 -- * * 84.40.238.125 0.0.0.0/0
policy match dir in pol ipsec
2838K 2688M wan2lan1 0 -- * eth1.301 0.0.0.0/0
192.168.5.0/24 policy match dir out pol none
0 0 wan2lan1 0 -- * eth1.301 0.0.0.0/0
10.31.4.0/24 policy match dir out pol none
5961 1481K wan2publ 0 -- * eth1.303 0.0.0.0/0
195.205.101.56/29 policy match dir out pol none
1224K 1160M wan2lan2 0 -- * eth1.300 0.0.0.0/0
195.205.101.16/28 policy match dir out pol none
5018K 2450M wan2dmz 0 -- * eth2.201 0.0.0.0/0
195.205.101.8/29 policy match dir out pol none
115 12075 wan2vpn 0 -- * eth0 0.0.0.0/0
192.168.6.0/24 policy match dir out pol ipsec
0 0 wan2vpn 0 -- * eth0 0.0.0.0/0
195.205.11.34 policy match dir out pol ipsec
4000 306K wan2vpn 0 -- * eth0 0.0.0.0/0 10.1.0.0/24
policy match dir out pol ipsec <=========== Rule 3
...
Chain vpn_frwd (6 references)
pkts bytes target prot opt in out source destination
0 0 all2all 0 -- * eth0 0.0.0.0/0 0.0.0.0/0
policy match dir out pol none
14797 932K vpn2lan1 0 -- * eth1.301 0.0.0.0/0
192.168.5.0/24 policy match dir out pol none
0 0 vpn2lan1 0 -- * eth1.301 0.0.0.0/0
10.31.4.0/24 policy match dir out pol none
0 0 all2all 0 -- * eth1.303 0.0.0.0/0
195.205.101.56/29 policy match dir out pol none
0 0 all2all 0 -- * eth1.300 0.0.0.0/0
195.205.101.16/28 policy match dir out pol none
0 0 all2all 0 -- * eth2.201 0.0.0.0/0
195.205.101.8/29 policy match dir out pol none
...
Note that the above chain doesn't handle vpn->vpn traffic!
Chain wan2vpn (6 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0
udp dpt:53
4115 318K wan2all 0 -- * * 0.0.0.0/0 0.0.0.0/0
<========== Rule 4
...
Chain wan2all (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
4115 318K Drop 0 -- * * 0.0.0.0/0 0.0.0.0/0
3523 273K LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0
limit: avg 10/min burst 5 LOG flags 0 level 6 prefix
`Shorewall:wan2all:DROP:'
4115 318K DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0
So traffic that matches rule 2 can fall through the vpn_frwd chain and match
rule 3!
This is a bug that is present in all versions of Shorewall.
The workaround that I gave you yesterday will suffice until we can create a fix.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [EMAIL PROTECTED]
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
