Howdy,

Avoid the use of XAUTH in your configuration. XAUTH is the non-standard
which allows IPsec/IKE to authenticate with a usernameassword
(possibly involving a RADIUS DB lookup). This is probably the default in
the Cisco client.

I know of no opensource implementation of XAUTH. Even though it is not
an IETF RFC, Cisco and Microsoft (and others) have implemented it from
the dead IETF draft versions which the working group declined to
recommend.

Stick with standardized IPsec/IKE authentication methods and you should
be able to get Cisco<->isakmpd to work. Password authentication is the
simplest to configure and I recommend using it first as a proving ground
even if you want to move onward from there to certificate based
authentication.

I have made isakmpd work with bunches of implementations and seen it
work with bunches more. But (poor me) I cannot now recall if the Cisco
client was specifically among them.

In the future, IKEv2 promises to add the feature of being able to
interact with usernameassword 'legacy' authentication methods for
IPsec connections.


Ricky Charlet


> -----Original Message-----
> From: Thomas Jacob [mailto:remon@ushustech.com]
> Sent: Thursday, July 22, 2004 1:24 AM
> To: tech@openbsd.org
> Subject: Cisco VPN Client -> OpenBSD
>
>
> Hi all!
>
> I was wondering whether VPN Client 4.0 can be used to connect
> to OpenBSD.
>
> I tried doing it and got an "UNEQUAL_PAYLOAD_LENGTHS" error
> message from the
> OpenBSD box.
>
> Can the Cisco VPN Client be used as a generic IPsec VPN
> client? It supports
> IPsec...why not, eh? Has anybody had any success doing this?
> If no, what's the
> point of having standards like IPsec, I wonder!!! :-S
>
> I tried contacting Cisco for this information and they
> REFUSED to answer !!!
> It was just a query!
>
> Proprietary, Proprietary/
> Secrecy
> So contrary/
> to OpenSource-ee/
>
> :-(
>
> Any ideas?
>
> Regards,
> Thomas Jacob
>
>

-----------------------------------------------------------
Unless otherwise expressly stated, this message does not
create or vary any contractual relationship between you and
ARC International. The contents of this e-mail may be
confidential and if you have received it in error, please
delete it from your system, destroy any hard copies and
telephone the above number. Incoming emails to ARC may be
subject to monitoring other than by the addressee.