Dear Shorewall Users :-) I''ve been playing with shorewall for some time now - I found it really interesting and easy tool to organise all the rules and so on (beforethat I''ve been using simple iptables rules in shell script ;-) Generally it''s quite easy to be used, but anyway found one problem which I cannot handle myself - or in other words - cannot find appropriate way :-) I''ve set up VPN (IPSEC on 2.6 and racoon) on linux machine with iptables - generally VPN traffic lan<->vpn works fine. But I would like to make this box to be a VPN hub and I would like to allow vpn<->vpn traffic. I''ve spent a lot of time making Ipsec to work and finally I''ve achieved situation when IPSEC without shorewall is passing packets from VPN to another VPN. But once shorewall gets started VPN<->VPN packets are dropped by wan2all rule, for example: Shorewall:wan2all:DROP:IN=eth0 OUT=eth0 SRC=192.168.6.91 DST=10.1.0.250 LEN=106 TOS=0x00 PREC=0x00 TTL=126 ID=46540 PROTO=UDP SPT=1026 DPT=161 LEN=86 And my question is: How should I configure shorewall correctly to allow this traffic to be passed ? I know I can setup rule to allow wan to all traffic, but I feel this is not a good solution :-) I would like to set it up properly - that''s the reason of my question to you - proffesionals. And here is a piece of my VPN shorewall configuration: zones: #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall wan ipv4 lan1 ipv4 publ ipv4 lan2 ipv4 dmz ipv4 vpn ipv4 tunnels: #TYPE ZONE GATEWAY GATEWAY ipsec wan 195.205.11.34 ipesc wan 195.205.142.34 ipsec wan 84.40.238.125 policy: # Policies for traffic between VPN''s lan1 vpn ACCEPT vpn lan1 ACCEPT vpn vpn ACCEPT hosts: #ZONE HOST(S) OPTIONS vpn eth0:192.168.6.0/24,195.205.11.34 ipsec vpn eth0:10.1.0.0/24,195.205.142.34 ipsec vpn eth0:192.168.10.0/24,84.40.238.125 ipsec I''m sure someone will be able to help me :-) Thank you and best regards, Lukasz Spaleniak -- Lukasz Spaleniak GCM dpu s: a--- C++ UL++++ P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ ------------------------------------------------------------------------- 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/
Lukasz Spaleniak wrote:> Dear Shorewall Users :-) > > I''ve been playing with shorewall for some time now - I found it really > interesting and easy tool to organise all the rules and so on (beforethat > I''ve been using simple iptables rules in shell script ;-) > > Generally it''s quite easy to be used, but anyway found one problem which I > cannot handle myself - or in other words - cannot find appropriate way :-) > > I''ve set up VPN (IPSEC on 2.6 and racoon) on linux machine with iptables - > generally VPN traffic lan<->vpn works fine. > But I would like to make this box to be a VPN hub and I would like to allow > vpn<->vpn traffic. > > I''ve spent a lot of time making Ipsec to work and finally I''ve achieved > situation when IPSEC without shorewall is passing packets from VPN to > another VPN. >We can''t give you advice unless we know how you configured IPSEC. The output of "shorewall dump" collected as described at http://www.shorewall.net/support.htm#Guidelines should suffice (Assuming that you are running a recent version of Shorewall). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep>We can''t give you advice unless we know how you configured IPSEC.>The output of "shorewall dump" collected as described at >http://www.shorewall.net/support.htm#Guidelines should >suffice (Assuming that you are running a recent version of >Shorewall).Tom I''m using Shorewall ver 3.2.6 (debian etch). As attached file please find shorewall dump. Rgds, Lukasz -- Lukasz Spaleniak GCM dpu s: a--- C++ UL++++ P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ ------------------------------------------------------------------------- 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/
On Tue, Jan 22, 2008 at 11:19:34PM +0100, Lukasz Spaleniak wrote:> > I''m using Shorewall ver 3.2.6 (debian etch). >Lukasz, Can I recommend that you upgrade to Shorewall 4.0.7 and switch to Shorewall-perl? I maintain the official Debian packages and I have created Etch backports and placed them here: http://people.connexer.com/~roberto/debian/ Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- 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/
Lukasz Spaleniak wrote:> From: shorewall-users-bounces@lists.sourceforge.net > [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom > Eastep > >> We can''t give you advice unless we know how you configured IPSEC. > >> The output of "shorewall dump" collected as described at >> http://www.shorewall.net/support.htm#Guidelines should >> suffice (Assuming that you are running a recent version of >> Shorewall). > > Tom > > I''m using Shorewall ver 3.2.6 (debian etch). > > As attached file please find shorewall dump. >The rejected packets are coming out of the wan2vpn chain. 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 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 Regrettably, with Shorewall 3.2.6, the dump doesn''t show the SPD (Security Policy Database). So I would like to see the output of "setkey -DP" also. Here is your log entry: Shorewall:wan2all:DROP:IN=eth0 OUT=eth0 SRC=192.168.6.91 DST=10.1.0.250 LEN=106 TOS=0x00 PREC=0x00 TTL=126 ID=46540 PROTO=UDP SPT=1026 DPT=161 LEN=86 Note that the above packet does not match rule 2. This means that the policy match does not consider it to be an unencapsulated IPSEC packet! I''ve not seen an IPSEC HUB configuration before so I don''t know if this is normal or not. But the packet *is* matching rule 3 which means that policy match knows that this packet is going to be encapsulated on the way out. So the packet is being treated as a wan->vpn packet; that is why it is being dropped. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users- [cut]>Regrettably, with Shorewall 3.2.6, the dump doesn''t show the SPD (Security >Policy Database). >So I would like to see the output of "setkey -DP" also.>Here is your log entry:>Shorewall:wan2all:DROP:IN=eth0 OUT=eth0 SRC=192.168.6.91 DST=10.1.0.250 >LEN=106 TOS=0x00 PREC=0x00 TTL=126 ID=46540 PROTO=UDP SPT=1026 DPT=161 >LEN=86>Note that the above packet does not match rule 2. This means that the >policy match does not consider it to be an unencapsulated IPSEC packet! >I''ve not seen an IPSEC HUB configuration before so I don''t know if this is >normal or not. But the packet *is* matching rule 3 which means that >policy match knows that this packet is going to be encapsulated on the >way out. So the packet is being treated as a wan->vpn packet; that is >why it is being dropped.Tom, Thanks for above explanation - it''s impressive. Regarding the version of shorewall I will follow suggestion of Roberto to upgrade to new packages of shorewall. Anyway please also find below result of setkey: 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 10.1.0.0/24[any] 192.168.5.0/24[any] any in ipsec esp/tunnel/195.205.142.34-195.205.101.2/unique#16455 created: Jan 13 14:10:16 2008 lastused: Jan 22 15:26:45 2008 lifetime: 0(s) validtime: 0(s) spid=2576 seq=2 pid=24325 refcnt=1 192.168.10.0/24[any] 192.168.5.0/24[any] any in ipsec esp/tunnel/84.40.238.125-195.205.101.2/unique#16457 created: Jan 13 14:10:16 2008 lastused: Jan 13 16:09:39 2008 lifetime: 0(s) validtime: 0(s) spid=2600 seq=3 pid=24325 refcnt=1 10.1.0.0/24[any] 192.168.6.0/24[any] any in ipsec esp/tunnel/195.205.142.34-195.205.101.2/unique#16459 created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2624 seq=4 pid=24325 refcnt=1 192.168.6.0/24[any] 192.168.5.0/24[any] any in ipsec esp/tunnel/195.205.11.34-195.205.101.2/unique#16461 created: Jan 13 14:10:16 2008 lastused: Jan 22 15:28:31 2008 lifetime: 0(s) validtime: 0(s) spid=2648 seq=5 pid=24325 refcnt=1 10.1.0.0/24[any] 192.168.6.0/24[any] any out ipsec esp/tunnel/195.205.101.2-195.205.11.34/unique#16452 created: Jan 13 14:10:16 2008 lastused: Jan 21 16:59:01 2008 lifetime: 0(s) validtime: 0(s) spid=2545 seq=6 pid=24325 refcnt=1 192.168.5.0/24[any] 10.1.0.0/24[any] any out ipsec esp/tunnel/195.205.101.2-195.205.142.34/unique#16454 created: Jan 13 14:10:16 2008 lastused: Jan 22 15:25:51 2008 lifetime: 0(s) validtime: 0(s) spid=2569 seq=7 pid=24325 refcnt=1 192.168.5.0/24[any] 192.168.10.0/24[any] any out ipsec esp/tunnel/195.205.101.2-84.40.238.125/unique#16456 created: Jan 13 14:10:16 2008 lastused: Jan 22 23:48:17 2008 lifetime: 0(s) validtime: 0(s) spid=2593 seq=8 pid=24325 refcnt=3 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 192.168.5.0/24[any] 192.168.6.0/24[any] any out ipsec esp/tunnel/195.205.101.2-195.205.11.34/unique#16460 created: Jan 13 14:10:16 2008 lastused: Jan 22 21:37:06 2008 lifetime: 0(s) validtime: 0(s) spid=2641 seq=10 pid=24325 refcnt=1 192.168.6.0/24[any] 10.1.0.0/24[any] any fwd ipsec esp/tunnel/195.205.11.34-195.205.101.2/require created: Jan 13 14:10:16 2008 lastused: Jan 22 21:37:06 2008 lifetime: 0(s) validtime: 0(s) spid=2562 seq=11 pid=24325 refcnt=1 10.1.0.0/24[any] 192.168.5.0/24[any] any fwd ipsec esp/tunnel/195.205.142.34-195.205.101.2/require created: Jan 13 14:10:16 2008 lastused: Jan 21 11:19:03 2008 lifetime: 0(s) validtime: 0(s) spid=2586 seq=12 pid=24325 refcnt=1 192.168.10.0/24[any] 192.168.5.0/24[any] any fwd ipsec esp/tunnel/84.40.238.125-195.205.101.2/require created: Jan 13 14:10:16 2008 lastused: Jan 22 23:48:17 2008 lifetime: 0(s) validtime: 0(s) spid=2610 seq=13 pid=24325 refcnt=3 10.1.0.0/24[any] 192.168.6.0/24[any] any fwd ipsec esp/tunnel/195.205.142.34-195.205.101.2/require created: Jan 13 14:10:16 2008 lastused: Jan 21 16:59:01 2008 lifetime: 0(s) validtime: 0(s) spid=2634 seq=14 pid=24325 refcnt=1 192.168.6.0/24[any] 192.168.5.0/24[any] any fwd ipsec esp/tunnel/195.205.11.34-195.205.101.2/require created: Jan 13 14:10:16 2008 lastused: Jan 22 20:37:10 2008 lifetime: 0(s) validtime: 0(s) spid=2658 seq=15 pid=24325 refcnt=1 (per-socket policy) in none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2747 seq=16 pid=24325 refcnt=1 (per-socket policy) in none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2731 seq=17 pid=24325 refcnt=1 (per-socket policy) in none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2715 seq=18 pid=24325 refcnt=1 (per-socket policy) in none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2699 seq=19 pid=24325 refcnt=1 (per-socket policy) in none created: Jan 13 14:10:16 2008 lastused: Jan 22 23:25:39 2008 lifetime: 0(s) validtime: 0(s) spid=2683 seq=20 pid=24325 refcnt=1 (per-socket policy) in none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2667 seq=21 pid=24325 refcnt=1 (per-socket policy) out none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2756 seq=22 pid=24325 refcnt=1 (per-socket policy) out none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2740 seq=23 pid=24325 refcnt=1 (per-socket policy) out none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2724 seq=24 pid=24325 refcnt=1 (per-socket policy) out none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2708 seq=25 pid=24325 refcnt=1 (per-socket policy) out none created: Jan 13 14:10:16 2008 lastused: Jan 22 23:24:30 2008 lifetime: 0(s) validtime: 0(s) spid=2692 seq=26 pid=24325 refcnt=1 (per-socket policy) out none created: Jan 13 14:10:16 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=2676 seq=0 pid=24325 refcnt=1 Rgds, Lukasz -- Lukasz Spaleniak GCM dpu s: a--- C++ UL++++ P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ ------------------------------------------------------------------------- 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/
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=1Given that the netfilter policy match is not recognizing vpn->vpn traffic as matching the first policy, I guess you will need to augment the definition of the vpn zone as follows: hosts: #ZONE HOST(S) OPTIONS vpn eth0:192.168.6.0/24,195.205.11.34 ipsec vpn eth0:10.1.0.0/24,195.205.142.34 ipsec vpn eth0:192.168.10.0/24,84.40.238.125 ipsec vpn eth0:192.168.6.0/24, vpn eth0:10.1.0.0/24 vpn eth0:192.168.10.0/24 I notice that you don''t have any SPs for the gateways themselves. So you should probably leave them out of the vpn zone definition altogether (although I left them in above). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
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 > > Given that the netfilter policy match is not recognizing vpn->vpn traffic as > matching the first policy, I guess you will need to augment the definition of > the vpn zone as follows: > > > hosts: > #ZONE HOST(S) OPTIONS > vpn eth0:192.168.6.0/24,195.205.11.34 ipsec > vpn eth0:10.1.0.0/24,195.205.142.34 ipsec > vpn eth0:192.168.10.0/24,84.40.238.125 ipsec > vpn eth0:192.168.6.0/24, > vpn eth0:10.1.0.0/24 > vpn eth0:192.168.10.0/24 > > I notice that you don''t have any SPs for the gateways themselves. So you should > probably leave them out of the vpn zone definition altogether (although I left them > in above). >Given this limitation of the policy match, it would actually be more secure to define the net<->net SPs directly between the endpoints and not involve the "central HUB" (define tunnels from 195.205.11.34 and 192.205.142.34, between 195.205.142.34 and 84.40.238.125, ...). And fw-wro wouldn''t have to handle all of the VPN traffic between the other endpoints (including decrypting and encrypting every routed packet). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
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 \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
Tom Eastep wrote:> > 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. >I''ve read the code and apparently I intended this situation to be handled by specifying ''routeback'' on each of the host entries. Please see if this doesn''t fix your issue: #ZONE HOST(S) OPTIONS vpn eth0:192.168.6.0/24,195.205.11.34 ipsec,routeback vpn eth0:10.1.0.0/24,195.205.142.34 ipsec,routeback vpn eth0:192.168.10.0/24,84.40.238.125 ipsec,routeback -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- 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/
From: shorewall-users-bounces@lists.sourceforge.net [mailto:shorewall-users-bounces@lists.sourceforge.net] On Behalf Of Tom Eastep>I''ve read the code and apparently I intended this situation to be handled >by >specifying ''routeback'' on each of the host entries. > >Please see if this doesn''t fix your issue: > >#ZONE HOST(S) OPTIONS >vpn eth0:192.168.6.0/24,195.205.11.34 ipsec,routeback >vpn eth0:10.1.0.0/24,195.205.142.34 ipsec,routeback >vpn eth0:192.168.10.0/24,84.40.238.125 ipsec,routebackTom, This accualy solves the problem completley ! Thank you very much for solution (which is very quick). Neverthenless will migrate to new version of shorewall :-) Thank you and my kind regards, Lukasz Spaleniak -- Lukasz Spaleniak GCM dpu s: a--- C++ UL++++ P+ L+++ E--- W+ N+ K- w O- M V- PGP t--- 5 X+ R- tv-- b DI- D- G e-- h! r y+ ------------------------------------------------------------------------- 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/
Seemingly Similar Threads
- OpenVPN tun Interface
- Problem while trying to set up an ipsec vpn
- Shorewall + IPSec: help debugging why gw1<->gw2 SA works, but loc<->gw2 traffic doesn't trigger SA
- 26sec kame ipsec tunnel : packets leave unencrypted...
- Anyone using National ISDN (NI-1) BRI under Linux?