New concentrator, new problems

Hi there,

today I was forced to change my VPN-Client configuration and things stopped 
working.
What has changed?
The first thing I noticed was that the concentrator is load balanced and if I 
connect using cisco VPN client I get:

Cisco Systems VPN Client Version 4.6.02 (0030)
Copyright (C) 1998-2004 Cisco Systems, Inc. All Rights Reserved.
Client Type(s): Linux
Running on: Linux 2.6.12-rc3-mm3 #6 Tue May 17 15:53:12 CEST 2005 i686
Config file directory: /etc/opt/cisco-vpnclient
[...]
Initializing the VPN connection.
Contacting the gateway at 82.53.187.30
Contacting the gateway at 82.53.187.28 (balancing)

You can see the routing table setted up by cisco VPN client in the 
attachments.
Not to say that using cisco VPN client everything is working smoothly.
Using vpnc it seems everything is OK but I cannot get even a ping working 
through the tunnel. I thought the problem was the balancing and then changed 
the concentrator IP from 82.53.187.30 to 82.53.187.28 but this did not solved 
the problem.
Attached you can find also the debug3 level of vpnc.

Any ideas?
Thanks
Piero

Re: Re: New concentrator, new problems

hi,

On Thu, Jun 09, 2005 at 11:08:31AM +0200, Piero Ottuzzi wrote:
> just an update on the problem.
> To recap: the problem is that the concentrator is loadBalanced: the official 
> address is 82.53.187.30 and then you'll be redirected toward 82.53.187.28 or 
> 82.53.187.29.
> 
> If I use the latter adresses (82.53.187.28 or 82.53.187.29) sometimes it 
> works, sometimes not... maybe it is not possible to select a default one but 
> I have to guess where the balancer would redirect me.

this problem sounds strange. Looking at your routing table it seems that
between you and this concentrator, but NAT-T is support is not announced
by your concentrator. Have you tried "--udp" resp. "UDP Encapsulate"?

cu
maurice

Re: New concentrator, new problems

Hi there,

just an update on the problem.
To recap: the problem is that the concentrator is loadBalanced: the official 
address is 82.53.187.30 and then you'll be redirected toward 82.53.187.28 or 
82.53.187.29.

If I use the latter adresses (82.53.187.28 or 82.53.187.29) sometimes it 
works, sometimes not... maybe it is not possible to select a default one but 
I have to guess where the balancer would redirect me.

Any ideas? Would it be possible to understand this IP redirection inside vpnc?

Many thanks
Piero

Alle 16:43, martedì 7 giugno 2005, Piero Ottuzzi ha scritto:
> Hi there,
>
> today I was forced to change my VPN-Client configuration and things stopped
> working.
> What has changed?
> The first thing I noticed was that the concentrator is load balanced and if
> I connect using cisco VPN client I get:
>
> Cisco Systems VPN Client Version 4.6.02 (0030)
> Copyright (C) 1998-2004 Cisco Systems, Inc. All Rights Reserved.
> Client Type(s): Linux
> Running on: Linux 2.6.12-rc3-mm3 #6 Tue May 17 15:53:12 CEST 2005 i686
> Config file directory: /etc/opt/cisco-vpnclient

vpnc with Nortel Contivity

I've managed to get vpnc working with a Nortel Contivity VPN
concentrator.

Basically the differences are:

* The group name and password are pre-transformed:
  key_id = SHA1(group_name)
  shared_key = HMAC_SHA1(group_name, SHA1(group_password))

* The XAUTH implementation follows
  draft-ietf-ipsec-isakmp-xauth-02.txt (whereas CISCO uses a
  later version).  Specifically:
  - the encoding of the proposal is not defined in that spec,
    and Nortel does it differently
  - the XAUTH attributes have different numerical values
    (which overlap with Mode-Config, argh)
  - success/failure are encoded as Mode-Config message types
    5/6 (or sometimes as an ISAKMP notify?) rather than in
    an attribute
  - the concentrator always sends 0 in XAUTH_TYPE and the
    client may have to return a different value (xauth-02 is
    not clear on whether this is allowed, it is not
    clarified until xauth-05).  In my case I'm using an
    ActivCard token for which I have to specify 5 (SecurID).

* Mode-Config is done as a push, i.e. the server sends SET,
  instead of a pull.

* The concentrator wants to be the initiator in phase 2
  quick mode, so we have to support being a responder.

CPU Load under Mac OS X

Hello everybody!

Frustrated by Ciscos Implementation of VPN I tried to build vpnc  
under Mac OS X 10.4.
In 2004, somebody posted a patch to the list for vpnc-0.2-rm+zomb  
which built with no errors. Also, I managed to build the latest  
version with minor patches (and without kernel-ipsec), but both gave  
the same error: Even when idling CPU usage is at 99%; data transfers  
work but it is really slow.

Is somebody using vpnc under OS X? Or can somebody give me general  
hints how to debug the client?

Thanks!
chris

Re: CPU Load under Mac OS X

On Tue, 14 Jun 2005, Christophe Thil wrote:
> Hello everybody!
> 
> Frustrated by Ciscos Implementation of VPN I tried to build vpnc  
> under Mac OS X 10.4.
> In 2004, somebody posted a patch to the list for vpnc-0.2-rm+zomb  
> which built with no errors. Also, I managed to build the latest  
> version with minor patches (and without kernel-ipsec), but both gave  
> the same error: Even when idling CPU usage is at 99%; data transfers  
> work but it is really slow.
> 
> Is somebody using vpnc under OS X? Or can somebody give me general  
> hints how to debug the client?

Wasn't this issue related to the OS X substandard implementation of poll()?  
Earlier versions of OS X didn't have a poll() at least, so lots of software used 
other less optimal code that could have pegged the CPU.  Is there any chance you 
could use vpnc 0.3.3 or 0.3.2 instead of 0.2?

Dan

Re: CPU Load under Mac OS X

> Hello everybody!
> 
> Frustrated by Ciscos Implementation of VPN I tried to build vpnc  
> under Mac OS X 10.4.
> In 2004, somebody posted a patch to the list for vpnc-0.2-rm+zomb  
> which built with no errors. Also, I managed to build the latest  
> version with minor patches (and without kernel-ipsec), but both gave  
> the same error: Even when idling CPU usage is at 99%; data transfers  
> work but it is really slow.

Hey, are you getting packets through without kernel-ipsec? I will be quite
surprised if that is possible 

The CPU usage problem is caused by the fact that OS X Tiger breaks poll().
vpnc calls poll() and gets an error. And then there is a loop. However,
using kernel-ipsec, vpnc is actually done at that stage, so the tunnel works
... what a hack.

However replacing the poll() by select() restores normal operation. It is
quite trivial, but if you like I can send you a patch against 0.2-rm+zomb.

Mattias

--

-- 
Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++

Re: CPU Load under Mac OS X

Am 14.06.2005 um 15:41 schrieb Mattias Nissler:

> Hey, are you getting packets through without kernel-ipsec? I will  
> be quite
> surprised if that is possible 

I don't know. 0.3 built clean but then I discovered the Mac patch for  
0.2 which worked. Haven't tested 0.3 on OS X.

> However replacing the poll() by select() restores normal operation.  
> It is
> quite trivial, but if you like I can send you a patch against 0.2-rm 
> +zomb.

I'll try it later at home on my devel system. Thanks for the hint :)

Chris

hold on "NAT-T mode, adding non-esp marker"

hi all

I can not connect to my office after I add a router
behind the adsl modem.

debug 3 msg is too much , I just post the bottom part
of msg. 

anyone could give me a hand?

btw: I 'v got Revision 54 , and compiled by hand.

thank you in advanced

--------debug 3 msg--------

DONE PARSING PAYLOAD type: 03
PARSING PAYLOAD type: 00
DONE PARSING PAYLOAD type: 02
PARSING PAYLOAD type: 00
DONE PARSING PAYLOAD type: 01
PARSING PAYLOAD type: 04
next_type: 0a
length: 0084
ke.data:
3b6bbd4c 4adc49df 87bca130 b9e6601e 00121668 143d6551
9790afe6 6f1b7dca
594aa23e f2638ff8 282d5dbb 78e751e0 f8a2b66b 54320e4f
817fcaa6 7e0602f2
4b474c84 f008cd89 1022ee1e 43f19d12 2003923e 73a00a0c

Patch to make vpnc work with DragonFly BSD

Hello,

attached there's a small patch against 0.3.3 that adds support for
Dragonfly BSD (1.2 and 1.3 tested). Works flawlessly there.

Regards,

Hans-Werner Hilse

--- Makefile.O	2005-06-20 21:15:55.000000000 +0200
+++ Makefile	2005-06-20 21:17:04.000000000 +0200
 <at>  <at>  -33,6 +33,10  <at>  <at> 
 CFLAGS += -DSOCKADDR_IN_SIN_LEN -DHAVE_SA_LEN
 SYSDEP=sysdep-bsd.o
 endif
+ifeq ($(shell uname -s), DragonFly)
+CFLAGS += -DSOCKADDR_IN_SIN_LEN -DHAVE_SA_LEN -DDRAGONFLY_BSD
+SYSDEP=sysdep-bsd.o
+endif
 ifeq ($(shell uname -s), NetBSD)
 CFLAGS += -DSOCKADDR_IN_SIN_LEN -DHAVE_SA_LEN
 SYSDEP=sysdep-bsd.o
--- sysdep-bsd.c.O	2005-06-20 21:13:57.000000000 +0200
+++ sysdep-bsd.c	2005-06-20 21:15:38.000000000 +0200
 <at>  <at>  -28,8 +28,11  <at>  <at> 

 #include <sys/socket.h>
 #include <net/if.h>