[Openswan Users] Stuck Connection

[Mark Olliver]

Hi,

Thanks for the reply,

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
        type=tunnel
        dpddelay=9
        dpdtimeout=30
        dpdaction=restart
        pfs=yes
        rekey=yes
        rekeymargin=600
        rekeyfuzz=100%
        keylife=3600
        keyingtries=10
        ikelifetime=28800
        compress=yes
        authby=secret
        auto=start

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?

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?

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


Let me know if you need any further info.

Regards,

Mark

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

On Tue, 10 Oct 2006, Mark Olliver wrote:
> Local Lan 192.168.242.0/24 eth0
> 	|
> Local Firewall ipsec0
> 	|
> Local Public 81.17.242.10 eth1
> 	|
> 	|
> Remote Public 212.159.53.154 eth1
> 	|
> Remote Firewall ipsec0
> 	|
> Remote Lan 192.168.234.0/23 eth0


> Config Settings
> conn ielan-ukoflan
>         leftsubnet=192.168.242.0/24
>         rightsubnet=192.168.234.0/24
>         also=iecollo-ukoffice
>
> conn iecollo-ukoflan
>         leftsubnet=81.17.242.10/32

You are better of using a single connection with
both left/right subnets and using leftsourceip= and
rightsourceip= to denote the inner IP's of the gateways
so they can talk to each over over the vpn without the
need for 4 tunnels.

> iptables -t nat -A POSTROUTING -s 192.168.242.0/24 -d \! 192.168.234.0/24
-o
> eth1 -j SNAT --to 81.17.242.81

I assume the other had has the same kind of NAT rule, or packets will still
break.

> Oct 10 14:53:53 ie-fw1 pluto[7054]: 1 bad entries in virtual_private -
none
> loaded

since you're not using NAT harmless, but perhsps fix/comment out the line.

> Oct 10 14:53:53 ie-fw1 pluto[7054]: Using KLIPS IPsec interface code on
> 2.6.18

You are using klips on 2.6.18 with openswan 2.4.6? You must have patched
the source then to fix various config.h related issues?

> sent QI2, IPsec SA established {ESP=>0xee37a1ca <0x
> 6f27582e xfrm=AES_0-HMAC_SHA1 IPCOMP=>0x0000a621 <0x0000daea NATD=none
> DPD=enabled}

looks good.

> Oct 10 14:54:16 ie-fw1 pluto[7054]: packet from 212.159.53.154:500: Quick
> Mode message is for a non-existent (expired?) ISAKMP SA

Not sure what that is. Are all 4 tunnels up and stable, or does it keep
negotiating?

> Oct 10 14:39:15 Pluto[194]: "OFFICE-IE_0" #140: responding to Main Mode
> Oct 10 14:39:15 Pluto[194]: "OFFICE-IE_0" #140: NAT-Traversal: Result
using
> draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
> Oct 10 14:39:16 Pluto[194]: "OFFICE-IE_0" #140: sent MR3, ISAKMP SA
> established
> Oct 10 14:39:16 Pluto[194]: "OFFICE-IE_1" #141: using deflate compression
> Oct 10 14:39:16 Pluto[194]: "OFFICE-IE_1" #141: responding to Quick Mode
> Oct 10 14:39:16 Pluto[194]: "OFFICE-IE_1" #141: ESP transform ESP_AES /
auth
> AUTH_ALGORITHM_HMAC_SHA1 implemented

What is this software? pluto with a capital P? Some messages I do not
recognise. Is this a freeswan/openswan derivative?

> Oct 10 14:42:39 Pluto[194]: "OFFICE-IE_2" #145: using deflate compression
> Oct 10 14:42:39 Pluto[194]: "OFFICE-IE_2" #145: responding to Quick Mode
> Oct 10 14:42:39 Pluto[194]: "OFFICE-IE_2" #145: ESP transform ESP_AES /
auth
> AUTH_ALGORITHM_HMAC_SHA1 implemented
> Oct 10 14:42:48 Pluto[194]: "OFFICE-IE_2" #145: discarding duplicate
packet;
> already STATE_QUICK_R1
> Oct 10 14:43:49 last message repeated 1 time(s)
> Oct 10 14:43:49 Pluto[194]: "OFFICE-IE_2" #145: max number of
> retransmissions (2) reached STATE_QUICK_R1

So it seems negotiating keeps looping. Try using 1 tunnel and see if that
improves things.

Paul