[Openswan Users] Stuck Connection

Tue Oct 10 14:58:25 EDT 2006

Hi,

Sorry, the kernel is 2.6.18 #1 SMP.

On the NAT I believe the other end is doing the same so natting the internal
network if it is destined for the internet but not down the ipsec. On other
tunnels from the other end I can see internal lan packets ok.

I can't do an ipsec verify on the remote end

[root at ie-fw1 ~]# uname -a
Linux ie-fw1.thermeon.eu 2.6.18 #1 SMP Tue Oct 3 13:01:34 BST 2006 i686 i686
i38                                             6 GNU/Linux

Local end
[root at ie-fw1 ~]# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan 2.4.6 (klips)
Checking for IPsec support in kernel                            [OK]
Checking for RSA private key (/etc/ipsec.secrets)               [OK]
Checking that pluto is running                                  [OK]
Two or more interfaces found, checking IP forwarding            [OK]
Checking NAT and MASQUERADEing
Checking tun0x100c at 212.159.53.154 from 192.168.242.0/24 to 192.168.234.0/24
[FAILED]
  SNAT from 192.168.242.60 to 0.0.0.0/0 kills tunnel 192.168.242.60 ->
192.168.234.0/24
        [FAILED]
  SNAT from 192.168.242.52 to 0.0.0.0/0 kills tunnel 192.168.242.52 ->
192.168.234.0/24
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Remote End
/> ipsec verify
Ipsec configurator.  (C) Copyright 2002 SnapGear (www.snapgear.com).
ipsec: fatal error unknown command `verify'

 (C) Copyright 2002 SnapGear (www.snapgear.com).
/> ipsec eroute
Ipsec configurator.  (C) Copyright 2002 SnapGear (www.snapgear.com).
0          192.168.234.0/24   -> 192.168.242.0/24   =>
tun0x11bd at 81.17.242.10
/> ping -I eth0 192.168.242.254
PING 192.168.242.254 (192.168.242.254) from 192.168.234.1 eth0: 56(84) bytes
of data.
>From 192.168.234.1 icmp_seq=2 Destination Host Unreachable
>From 192.168.234.1 icmp_seq=3 Destination Host Unreachable
>From 192.168.234.1 icmp_seq=4 Destination Host Unreachable

--- 192.168.242.254 ping statistics ---
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5019ms
, pipe 3

Local end
[root at ie-fw1 ~]# tcpdump -i ipsec0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type EN10MB (Ethernet), capture size 96 bytes

0 packets captured
0 packets received by filter
0 packets dropped by kernel
[root at ie-fw1 ~]# tcpdump -i ipsec0 -nvv
tcpdump: listening on ipsec0, link-type EN10MB (Ethernet), capture size 96
bytes
19:56:29.830431 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 0
19:56:30.829705 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 1
19:56:31.829797 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 2
19:56:32.829877 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 3
19:56:33.829962 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 4
19:56:34.830044 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 5
19:56:35.830130 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 6
19:56:36.830211 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 7
19:56:37.830294 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 1,
length: 84) 192.168.242.254 > 192.168.234.1: icmp 64: echo request seq 8

Remote end shows replys as well

[root at ie-fw1 ~]# tcpdump -i eth1 -nvv host 212.159.53.154
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96
bytes
19:57:33.698080 IP (tos 0x0, ttl  64, id 55333, offset 0, flags [none],
proto 50, length: 152) 81.17.242.10 > 212.159.53.154:
ESP(spi=0xee37a256,seq=0xa)
19:57:34.699060 IP (tos 0x0, ttl  64, id 55334, offset 0, flags [none],
proto 50, length: 152) 81.17.242.10 > 212.159.53.154:
ESP(spi=0xee37a256,seq=0xb)
19:57:35.531518 IP (tos 0x0, ttl  54, id 0, offset 0, flags [DF], proto 17,
length: 112) 212.159.53.154.isakmp > 81.17.242.10.isakmp: isakmp 1.0 msgid
cookie ->: phase 2/others ? inf[E]: [encrypted hash]
19:57:35.531699 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto 17,
length: 112) 81.17.242.10.isakmp > 212.159.53.154.isakmp: isakmp 1.0 msgid
cookie ->: phase 2/others ? inf[E]: [encrypted hash]
19:57:35.699144 IP (tos 0x0, ttl  64, id 55335, offset 0, flags [none],
proto 50, length: 152) 81.17.242.10 > 212.159.53.154:
ESP(spi=0xee37a256,seq=0xc)
19:57:36.699227 IP (tos 0x0, ttl  64, id 55336, offset 0, flags [none],
proto 50, length: 152) 81.17.242.10 > 212.159.53.154:
ESP(spi=0xee37a256,seq=0xd)
19:57:37.699307 IP (tos 0x0, ttl  64, id 55337, offset 0, flags [none],
proto 50, length: 152) 81.17.242.10 > 212.159.53.154:
ESP(spi=0xee37a256,seq=0xe)
19:57:38.699391 IP (tos 0x0, ttl  64, id 55338, offset 0, flags [none],
proto 50, length: 152) 81.17.242.10 > 212.159.53.154:
ESP(spi=0xee37a256,seq=0xf)

Hope those give more insight.

Regards,

Mark

******************************************************************
Mark Olliver BSc (Hons) 
-----Original Message-----
From: Paul Wouters [mailto:paul at xelerance.com] 
Sent: 10 October 2006 17:59
To: Mark Olliver
Cc: users at openswan.org
Subject: RE: [Openswan Users] Stuck Connection

On Tue, 10 Oct 2006, Mark Olliver wrote:

> I presume you mean the following for the config:
> conn iecollo-ukoffice
>         left=81.17.242.10
>         leftsubnet=192.168.242.0/24
>         leftsourceip=192.168.242.254
>         right=212.159.53.154
>         rightsubnet=192.168.234.0/24
>         rightsourceip=192.168.234.1

Yes.

> You say the NAT will break the connection, surely as I am only NAT'ing
eth0
> packets that are going directly out eth1 and not via ipsec then the ipsec
> packets should not be effected?

I meant, provided the *other* end does the same and not accidently NAT
the reply packets, so your end will those them away for not matching the
digital signatures.

> Yes I am using kernel 2.6.8 and ipsec 2.4.6 but I did not see any errors
> when building both built ok,as far as I know, would you suggest a
different
> combination?

Oh, you wrote 2.6.18 before, not 2.6.8.

> The remote device is a snapgear cyberquard device running their latest
> kernel which runs some form of Pluto/klips I belive.

Ahh. so it should work yes. What does 'ipsec verify' say?

Paul
-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155