|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: [suse-security] ipsec freeswan - connection established successfully, but packets are dropped ...
From: Andreas Baetz (lac01
web.de)
Date: Fri Oct 17 2003 - 01:28:33 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ed,
You could check the following:
Is the routing between the subnets correct ?
Do the packets arrive at the eth-Interface of your source GW ?
Is forwarding switched on at the GW ?
Andreas
On Friday 17 October 2003 07:02, Techno Ed wrote:
> Hi Markus.
>
> I'm with a similar problem as you with a few (big?) differences.
>
> I'm trying a net-to-net connection (could it be simpler?) :
>
> GW1 is a SuSE Pro 8.2 with FreeS/WAN 1.99_0.9.23-20
> GW2 is a RedHat 9.0 with FreeS/WAN 1.99_2.4.20_8-0
>
> -= Starting IPSEC on GW1 =-
>
> /etc/init.d/ipsec start
> ipsec_setup: Starting FreeS/WAN IPsec 1.99...
> ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1
> ipsec_setup: klipsdebug=`all' ignored, KLIPS lacks debug facilities
> ipsec_setup: done
>
> -= Starting IPSEC on GW2 =-
>
> # /etc/init.d/ipsec start
> ipsec_setup: Starting FreeS/WAN IPsec 1.99...
> ipsec_setup: Using /lib/modules/2.4.20-8/kernel/net/ipsec/ipsec.o
>
> -= Activating the connection on GW1 =-
>
> # ipsec auto --up net-to-net
> 104 "net-to-net" #1: STATE_MAIN_I1: initiate
> 106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> 108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established
> 112 "net-to-net" #2: STATE_QUICK_I1: initiate
> 010 "net-to-net" #2: STATE_QUICK_I1: retransmission; will wait 20s for
> response
> 004 "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
>
> -= Checking tunnel =-
>
> ... on GW1
> # ipsec eroute
> 0 10.21.0.0/16:0 -> 10.31.0.0/16:0 =>
> tun0x1002
aaa.bbb.57.170:0
>
>
> ... Second line after 'ipsec look' begins weird for me... shouldn't it
> be 10.31.0.0/16 ? Maybe it's just a different format...
>
> # ipsec look
> GW1 Fri Oct 17 02:32:37 UTC 2003
> 001003100000016:0:10.21.0.0/16:0 -> 10.31.0.0/16:0 =>
> tun0x1002
aaa.bbb.57.170:0 (0)
> ipsec0->NULL mtu=16260(0)->0
> esp0x532de87c
xxx.yyy.87.83 ESP_3DES_HMAC_MD5: dir=in
> src=aaa.bbb.57.170 iv_bits=64bits iv=0xf7bb2971e2981f85 ooowin=64
> alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(175,0,0)
> esp0x935e8ab8
aaa.bbb.57.170 ESP_3DES_HMAC_MD5: dir=out
> src=xxx.yyy.87.83 iv_bits=64bits iv=0xa8a51aa30756b8ab ooowin=64
> alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(175,0,0)
> tun0x1001
xxx.yyy.87.83 IPIP: dir=in src=aaa.bbb.57.170
> life(c,s,h)=addtime(175,0,0)
> tun0x1002
aaa.bbb.57.170 IPIP: dir=out src=xxx.yyy.87.83
> life(c,s,h)=addtime(175,0,0)
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 0.0.0.0 xxx.yyy.87.81 0.0.0.0 UG 0 0 0
> eth0
> xxx.yyy.87.80 0.0.0.0 255.255.255.240 U 0 0 0
> eth0
>
>
> ... on GW2 (just to be sure)
> ]# ipsec eroute
> 0 10.31.0.0/16 -> 10.21.0.0/16 =>
> tun0x1002
xxx.yyy.87.83
>
> # ipsec look
> GW2 Fri Oct 17 02:27:27 UTC 2003
> 10.31.0.0/16 -> 10.21.0.0/16 => tun0x1002
xxx.yyy.87.83
> esp0x532de87c
xxx.yyy.87.83 (0)
> ipsec0->eth0 mtu=16260(1500)->1500
> esp0x532de87c
xxx.yyy.87.83 ESP_3DES_HMAC_MD5: dir=out
> src=aaa.bbb.57.170 iv_bits=64bits iv=0x002d8b0a1a65f3f8 ooowin=64
> alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(426,0,0)
> esp0x935e8ab8
aaa.bbb.57.170 ESP_3DES_HMAC_MD5: dir=in
> src=xxx.yyy.87.83 iv_bits=64bits iv=0xde7993e484323ee7 ooowin=64
> alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(437,0,0)
> tun0x1001
aaa.bbb.57.170 IPIP: dir=in src=xxx.yyy.87.83
> life(c,s,h)=addtime(436,0,0)
> tun0x1002
xxx.yyy.87.83 IPIP: dir=out src=aaa.bbb.57.170
> life(c,s,h)=addtime(426,0,0)
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 0.0.0.0 aaa.bbb.57.190 0.0.0.0 UG 0 0 0
> eth0
> 10.21.0.0 aaa.bbb.57.190 255.255.0.0 UG 0 0 0
> ipsec0
> aaa.bbb.57.128 0.0.0.0 255.255.255.192 U 0 0 0
> eth0
> aaa.bbb.57.128 0.0.0.0 255.255.255.192 U 0 0 0
> ipsec0
>
>
> -= Conf file =-
>
> # cat /etc/ipsec.conf
>
> config setup
> interfaces=%defaultroute
> klipsdebug=all
> plutodebug=all
> plutoload=%search
> plutostart=%search
> uniqueids=yes
>
> conn net-to-net
> keyingtries=0
> authby=rsasig
> left=xxx.yyy.87.83
> leftsubnet=10.21.0.0/16
> leftid=GW1.domain.com
> leftrsasigkey=SUFpqti6.....
> leftnexthop=%defaultroute
> right=aaa.bbb.57.170
> rightsubnet=10.31.0.0/16
> rightid=GW2.domain.com.br
> rightrsasigkey=YrGqXcM.....
> rightnexthop=%defaultroute
> auto=add
>
>
> -= Firewall Rules =-
>
> Quite the same in both GW's.
>
> #!/bin/bash
>
> IPT=/usr/sbin/iptables
>
> $IPT -t nat -F
> $IPT -t filter -F
> $IPT -t mangle -F
>
> $IPT -P INPUT ACCEPT
> $IPT -P OUTPUT ACCEPT
> $IPT -P FORWARD ACCEPT
>
> $IPT -A INPUT -i eth0 -p icmp -j ACCEPT
> $IPT -A INPUT -i eth1 -p icmp -j ACCEPT
> $IPT -A INPUT -i ipsec+ -p icmp -j ACCEPT
> $IPT -A OUTPUT -p icmp -j ACCEPT
>
> $IPT -A FORWARD -s 10.21.0.0/16 -d 10.31.0.0/16 -j ACCEPT
> $IPT -A FORWARD -s 10.31.0.0/16 -d 10.21.0.0/16 -j ACCEPT
>
> $IPT -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
> $IPT -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
>
> $IPT -A INPUT -p 50 -j ACCEPT
> $IPT -A OUTPUT -p 50 -j ACCEPT
>
>
> $IPT -A INPUT -p 51 -j ACCEPT
> $IPT -A OUTPUT -p 51 -j ACCEPT
>
> $IPT -A INPUT -j LOG --log-prefix "INPUT --- "
> $IPT -A OUTPUT -j LOG --log-prefix "OUTPUT --- "
> $IPT -A FORWARD -j LOG --log-prefix "FORWARD --- "
>
> $IPT -P INPUT DROP
> $IPT -P OUTPUT DROP
> $IPT -P FORWARD DROP
>
> -= The problem =-
>
> Can't PING, for example, from GW1 :
> ping -I eth1 10.31.100.2
>
> Can't ping from 10.31.100.2 to 10.21.100.30
>
> Workstations on the same subnet as the GW ping as expected.
>
> No drops on the firewall... in fact, there is no traffic in the FORWARD
> chain... which seems strange. Tried TCPDUMPing but captured nothing on
> ipsec0.
>
> Am I missing WHAT (besides the packets) ?
> I'm already feeling dizzy and kinda frustrated with this... after all,
> everywhere I read, they say this is the simpler VPN connection.
>
> Thanks!
>
> EdK
--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help
suse.com
Security-related bug reports go to security
suse.de, not here
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]