[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] ipsec freeswan - connection established successfully, but packets are dropped ...



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@xxxxxxxxxxxxxx: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@xxxxxxxxxxxxxx:0 (0)
> ipsec0->NULL mtu=16260(0)->0
> esp0x532de87c@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxx IPIP: dir=in  src=aaa.bbb.57.170
> life(c,s,h)=addtime(175,0,0)
> tun0x1002@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxx
>
> # ipsec look
> GW2 Fri Oct 17 02:27:27 UTC 2003
> 10.31.0.0/16       -> 10.21.0.0/16       => tun0x1002@xxxxxxxxxxxxx
> esp0x532de87c@xxxxxxxxxxxxx  (0)
> ipsec0->eth0 mtu=16260(1500)->1500
> esp0x532de87c@xxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx IPIP: dir=in  src=xxx.yyy.87.83
> life(c,s,h)=addtime(436,0,0)
> tun0x1002@xxxxxxxxxxxxx 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@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here