[Openswan Users] Stuck Connection

[Paul Wouters]

On Tue, 10 Oct 2006, Mark Olliver wrote:

> Sorry, the kernel is 2.6.18 #1 SMP.

Then I am confused that you got 2.4.6 to work out of the box, because we
had to put in some changes to make it compile for 2.6.18 that has only been
released in 2.4.7dr1


> [root at ie-fw1 ~]# ipsec verify

Can you confirm you're not running Selinux in enforced mode?

> 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

That might be a false positive, but it might be true as well. It would
explain what you see.

> /> 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

does snapgear suppotr "ipsec barf" ?

> 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,

So packets going only one way.

> 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)

I don't see packets coming back. I just see the same. Sending packets
without a reply. The isakmp packets you're seeing is not related to the
current tunnel that your end thinks it has up (or it is a rekey). But
it does NOT receive ESP packets in the answer. In fact, the other end
seems to still be negotiating your tunnel......

Paul