[Ipsec-tools-devel] Is there a work-around for the initial failing of "connect" in transport mode?

[Peder C. N. <Ped...@er...>]

I have a reasonably simple setup with some nodes that have mutual IPSec
transport modes defined, with the SPs permanently in the kernel by way of
"setkey", and the SAs negotiated by racoon.  The kernel is a
user-mode-linux 2.6.11, the nodes are pure IPv6, the distro is Debian
sarge.  ipsec-tools is 0.5.2.

My problem is that the initial attempt to connect over the transport fails
consistently - a repeated attempt succeeds, just a second later:

guest4:~# nc6 3ffe:0:0:2::2 22
nc6: unable to connect to address 3ffe:0:0:2::2, service 22
guest4:~# nc6 3ffe:0:0:2::2 22
SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4

To me it looks as if the "connect" system call fails more or less
immediately, because the outgoing PDU hits an SP with no SA.  This events
then triggers racoon into the negotiation, allowing the next attempt to
succeed.

But this is problematic; most Internet applications are coded under the
assumption that a failed "connect" call means serious long-lasting
problems - very few applications react on a failed "connect" call with a
wait and a repeated attempt.

Any input to this problem scenario is welcome - I have found no discussion
of this in the ipsec-tools documentation, nor in various HOWTOs and
similar documents on the net (such as Linux Advanced Routing ...).

Is there no way around it?  Or is it something that should work, just some
factor in my local environment prevents it (user-mode-linux, kernel
version, distro, IPv6 ...?).  Or is there a work-around?

thanks in advance
--
Peder Chr. N=F8rgaard        =09 Senior System Developer, M. Sc.
Ericsson Telebit A/S       =09 tel: +45 30 91 84 31
Skanderborgvej 232         =09 fax: +45 89 38 51 01
DK-8260 Viby J, Denmark
        e-mail: Ped...@er...
(old e-mail 2000-2003: Ped...@te...)
         (old e-mail 1992-2000: pc...@tb...)