[Openswan Users] OpenSwan 2.4.7 to Cisco 3745 - no traffic

[Krzysztof Wiórkiewicz]

Krzysztof Wiórkiewicz napisał(a):
> Hi!
> After switching to the new server (Linux Gentoo, kernel 2.6.17 with 
> OpenSwan 2.4.7 NETKEY) we noticed trouble with connection to the CISCO 
> 3745 router. Before, on the old server (Linux Debian, kernel 2.4.18 with 
> OpenSwan 2.2.0 KLIPS) connections works well.
> All options releated to this connection we have copied from old 
> ipsec.conf and ipsec.secrets without any changes. Our new server managed 
> many tunnels to the other peers and all of them works well except 
> tunnels to this Cisco.
> With the Cisco router we have defined several tunnels:
> 
> 
> config setup
> 	nat_traversal=yes
> 	virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,
> 		%v4:192.168.0.0/16,%v4:!our_internal_subnet
>          interfaces=%defaultroute
> 
> conn cisco1
>          leftsubnet=internal_ip_1/32
>          also=cisco_common
>          auto=start
> 
> conn cisco2
>          leftsubnet=internal_ip_2/32
>          also=cisco_common
>          auto=start
> 
> ...
> 
> conn cisco10
>          leftsubnet=internal_ip_10/32
>          also=cisco_common
>          auto=start
> 
> conn cisco_common
>          left=cisco_external_ip
>          right=our_external_ip
>          rightsubnet=our_external_subnet_ip/29
>          rightnexthop=our_extarnal_gateway_ip
>          keyexchange=ike
>          auth=esp
>          authby=secret
>          pfs=no
>          esp=3des-md5-96
>          keylife=1h
>          ikelifetime=1h
>          rekeymargin=60s
> 
> 
> All internal_ip are from the same subnet on the Cisco site. Now after 
> brought up ipsec we have:
> 
> # ipsec auto --up cisco1
> 117 "cisco1" #619: STATE_QUICK_I1: initiate
> 003 "cisco1" #619: ignoring informational payload, type 
> IPSEC_RESPONDER_LIFETIME
> 004 "cisco1" #619: STATE_QUICK_I2: sent QI2, IPsec SA established 
> {ESP=>0xa26168af <0xb107fa76 xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none}
> 
> 
> from all tunnels.
> 
> So, this mean that connection was established but when we trying to ping 
> some internal_ip only one (internal_ip_2) responding! This is very 
> strange because this one working tunnel have not any differences to all 
> other not working tunnels and uses the same cisco_common. We restarting 
> ipsec many times but always only one responding (alway the same 
> internal_ip_2)!
> 
> tcpdump log when we pinging working tunnel (internal_ip_2):
> 
> 
> # tcpdump -n -i our_external_interface host cisco_external_ip or host 
> internal_ip_2
> 14:35:32.440454 IP our_external_ip > cisco_external_ip: 
> ESP(spi=0xedd07580,seq=0x1), length 92
> 14:35:32.762127 IP cisco_external_ip > our_external_ip: 
> ESP(spi=0x31f2a89e,seq=0x1), length 92
> 14:35:32.762127 IP internal_ip_2 > our_external_ip: ICMP echo reply, id 
> 512, seq 42243, length 40
> 
> 
> looks ok, but when we pinging any other tunnel (for example internal_ip_5):
> 
> 
> # tcpdump -n -i our_external_interface host cisco_external_ip or host 
> internal_ip_5
> 14:40:23.373283 IP our_external_ip > cisco_external_ip: 
> ESP(spi=0xa26168af,seq=0x1), length 92
> 14:40:28.812884 IP our_external_ip > cisco_external_ip: 
> ESP(spi=0xa26168af,seq=0x2), length 92
> 
> 
> as can you see any response from Cisco router. At the same time cisco 
> administrator told us that he don't see any packets from our server.
> 
> We checked our iptables rules and routing tables many times and all 
> looks good. Cisco administrator told us that he didn't change anything 
> on his site, so this problem is evidently connected with changing our 
> server.
> 
> Any suggestions?

OK, restarting Cisco router solved this problem.

-- 
Chris.