cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clayton Weise <cwe...@iswest.net>
Subject RE: VPN with CS 3.0.2
Date Tue, 29 May 2012 16:39:49 GMT
I had a similar issue once before with 2.2.14 and I was never able to reproduce it so I couldn't
file a bug.  But it was resolved in exactly the same fashion.

-----Original Message-----
From: Tamas Monos [mailto:tamasm@veber.co.uk] 
Sent: Tuesday, May 29, 2012 6:06 AM
To: cloudstack-users@incubator.apache.org
Subject: RE: VPN with CS 3.0.2

Hi,

I have simply had enough and destroyed the virtual router. The system generated a new one
next time I started an instance.
I have disabled and re-enabled the VPN and created a new user and just started working out
of the box.
I will never find out what did not work previously.
NOTE: you need to allow inbound UDP 1701 on your VPN client's firewall.

Regards

Tamas Monos                                               DDI         +44(0)2034687012
Chief Technical                                             Office    +44(0)2034687000
Veber: The Hosting Specialists               Fax         +44(0)871 522 7057
http://www.veber.co.uk

Follow us on Twitter: www.twitter.com/veberhost
Follow us on Facebook: www.facebook.com/veberhost

-----Original Message-----
From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com] 
Sent: 29 May 2012 06:39
To: cloudstack-users@incubator.apache.org
Subject: Re: VPN with CS 3.0.2

Citrix QA team verified with a Win7 client not behind NAT as recently as a couple of weeks
ago:
http://bugs.cloudstack.org/browse/CS-14855


On 5/28/12 10:18 AM, "Tamas Monos" <tamasm@veber.co.uk> wrote:

>Hi,
>
>I've got further into it. On windows 7 L2TP over IPSec with pre-shared 
>key seems to build up the tunnel right but throws Error 619 when wants 
>to authenticate the user.
>On ubuntu desktop 12.04 with openswan I get a kernel panic when tries 
>to authenticate after the SA is established.
>
>On the virtual router the pppd bails out with exitcode 1 on
>authentication:
>May 28 15:19:36 r-119-VM xl2tpd[20287]: control_finish: Peer requested 
>tunnel 25 twice, ignoring second one.
>May 28 15:19:36 r-119-VM xl2tpd[20287]: Connection established to 
>217.168.x.y, 1701.  Local: 32420, Remote: 25 (ref=0/0).  LNS session is 
>'default'
>May 28 15:19:36 r-119-VM xl2tpd[20287]: check_control: Received out of 
>order control packet on tunnel 25 (got 3, expected 2) May 28 15:19:36 
>r-119-VM xl2tpd[20287]: handle_packet: bad control packet!
>May 28 15:19:36 r-119-VM xl2tpd[20287]: result_code_avp: result code 
>not appropriate for Incoming-Call-Request.  Ignoring.
>May 28 15:19:36 r-119-VM xl2tpd[20287]: start_pppd: I'm running:
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "/usr/sbin/pppd"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "passive"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "nodetach"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "10.1.2.1:10.1.2.2"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "refuse-pap"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "debug"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "file"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "/etc/ppp/options.xl2tpd"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: "/dev/pts/0"
>May 28 15:19:36 r-119-VM xl2tpd[20287]: Call established with 
>217.168.x.y, Local: 11851, Remote: 1, Serial: 0 May 28 15:19:36 
>r-119-VM xl2tpd[20287]: child_handler : pppd exited for call 1 with 
>code 1 May 28 15:19:36 r-119-VM xl2tpd[20287]: call_close: Call 11851 
>to 217.168.x.y disconnected May 28 15:19:36 r-119-VM xl2tpd[20287]: 
>control_finish: Connection closed to 217.168.x.y, port 1701 (), Local: 
>32420, Remote: 25 May 28 15:19:36 r-119-VM xl2tpd[20287]: Terminating 
>pppd: sending TERM signal to pid 20337
>
>According to the pppd manual that exitcode 1 means Pppd has detached, 
>or otherwise the connection was successfully established and terminated 
>at the peer's request.
>This would mean my client is crap.. I've tried both Windows and Linux.
>
>Regards
>
>Tamas Monos                                               DDI
>+44(0)2034687012
>Chief Technical                                             Office
>+44(0)2034687000
>Veber: The Hosting Specialists               Fax         +44(0)871 522
>7057
>http://www.veber.co.uk
>
>Follow us on Twitter: www.twitter.com/veberhost Follow us on Facebook: 
>www.facebook.com/veberhost
>
>
>-----Original Message-----
>From: James Kahn [mailto:jkahn@idea11.com.au]
>Sent: 28 May 2012 11:31
>To: cloudstack-users@incubator.apache.org
>Subject: Re: VPN with CS 3.0.2
>
>Have you tried from Mac or Windows? Both of those worked with minimal 
>configuration for us. It could be your client xl2tpd settings.
>
>Also, if your client is from behind a NAT firewall, it will need to be 
>VPN aware.
>
>
>
>-----Original Message-----
>From: Tamas Monos <tamasm@veber.co.uk>
>Reply-To: "cloudstack-users@incubator.apache.org"
><cloudstack-users@incubator.apache.org>
>Date: Saturday, 26 May 2012 3:10 AM
>To: "cloudstack-users@incubator.apache.org"
><cloudstack-users@incubator.apache.org>
>Subject: RE: VPN with CS 3.0.2
>
>>Hi,
>>
>>I can get this far on the client side:
>>
>>May 25 18:01:20.706 Starting xl2tpd: xl2tpd.
>>May 25 18:01:20.731 ipsec__plutorun: 002 added connection description 
>>"cloud"
>>May 25 18:01:20.828 104 "cloud" #1: STATE_MAIN_I1: initiate May 25
>>18:01:20.828 003 "cloud" #1: ignoring unknown Vendor ID payload 
>>[4f45517b4f7f6e657a7b4351] May 25 18:01:20.828 003 "cloud" #1: 
>>received Vendor ID payload [Dead Peer Detection] May 25 18:01:20.828 003 "cloud"
>>#1: received Vendor ID payload [RFC 3947] method set to=109 May 25
>>18:01:20.828 106 "cloud" #1: STATE_MAIN_I2: sent MI2, expecting MR2 
>>May
>>25 18:01:20.829 003 "cloud" #1: NAT-Traversal: Result using RFC 3947
>>(NAT-Traversal): no NAT detected
>>May 25 18:01:20.829 108 "cloud" #1: STATE_MAIN_I3: sent MI3, expecting
>>MR3 May 25 18:01:20.829 003 "cloud" #1: received Vendor ID payload 
>>[CAN-IKEv2] May 25 18:01:20.829 004 "cloud" #1: STATE_MAIN_I4: ISAKMP 
>>SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 
>>prf=oakley_sha group=modp2048} May 25 18:01:20.829 117 "cloud" #2: STATE_QUICK_I1:
>>initiate May 25 18:01:20.829 004 "cloud" #2: STATE_QUICK_I2: sent QI2, 
>>IPsec SA established transport mode {ESP=>0x6dad627d <0x503f8ead
>>xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=none} May 25
>>18:01:20.833 xl2tpd[5252]: Connecting to host 217.168.x.y, port
>>1701
>>May 25 18:01:25.836 xl2tpd[5252]: Maximum retries exceeded for tunnel 
>>2545.  Closing.
>>May 25 18:01:25.837 xl2tpd[5252]: Connection 0 closed to 217.168.x.y, 
>>port 1701 (Timeout) May 25 18:01:30.842 xl2tpd[5252]: Unable to 
>>deliver closing message for tunnel 2545. Destroying anyway.
>>
>>On the server side I get:
>>
>>May 25 17:01:23 r-119-VM xl2tpd[9094]: control_finish: Peer requested 
>>tunnel 2545 twice, ignoring second one.
>>May 25 17:01:23 r-119-VM xl2tpd[9094]: control_finish: Peer requested 
>>tunnel 2545 twice, ignoring second one.
>>May 25 17:01:24 r-119-VM xl2tpd[9094]: control_finish: Peer requested 
>>tunnel 2545 twice, ignoring second one.
>>May 25 17:01:25 r-119-VM xl2tpd[9094]: control_finish: Peer requested 
>>tunnel 2545 twice, ignoring second one.
>>May 25 17:01:26 r-119-VM xl2tpd[9094]: check_control: Received out of 
>>order control packet on tunnel -1 (got 1, expected 0) May 25 17:01:26 
>>r-119-VM xl2tpd[9094]: handle_packet: bad control packet!
>>May 25 17:01:27 r-119-VM xl2tpd[9094]: check_control: Received out of 
>>order control packet on tunnel -1 (got 1, expected 0) May 25 17:01:27 
>>r-119-VM xl2tpd[9094]: handle_packet: bad control packet!
>>May 25 17:01:28 r-119-VM xl2tpd[9094]: Maximum retries exceeded for 
>>tunnel 20224.  Closing.
>>May 25 17:01:28 r-119-VM xl2tpd[9094]: check_control: Received out of 
>>order control packet on tunnel -1 (got 1, expected 0) May 25 17:01:28 
>>r-119-VM xl2tpd[9094]: handle_packet: bad control packet!
>>May 25 17:01:28 r-119-VM xl2tpd[9094]: Connection 2545 closed to 
>>217.168.u.v, port 1701 (Timeout) May 25 17:01:29 r-119-VM xl2tpd[9094]:
>>check_control: Received out of order control packet on tunnel -1 (got 
>>1, expected 0) May 25 17:01:29 r-119-VM xl2tpd[9094]: handle_packet:
>>bad control packet!
>>May 25 17:01:30 r-119-VM xl2tpd[9094]: check_control: Received out of 
>>order control packet on tunnel -1 (got 1, expected 0) May 25 17:01:30 
>>r-119-VM xl2tpd[9094]: handle_packet: bad control packet!
>>May 25 17:01:33 r-119-VM xl2tpd[9094]: Unable to deliver closing 
>>message for tunnel 20224. Destroying anyway.
>>
>>I suspect a network problem between hosts on port 1701 but I don't see 
>>any outgoing attempts any directions via tcpdump on port 1701.
>>I'll play around a bit more.
>>If anyone has any ideas, welcome :)
>>
>>Regards
>>
>>Tamas Monos                                               DDI
>>+44(0)2034687012
>>Chief Technical                                             Office
>>+44(0)2034687000
>>Veber: The Hosting Specialists               Fax         +44(0)871 522
>>7057
>>http://www.veber.co.uk
>>
>>Follow us on Twitter: www.twitter.com/veberhost Follow us on Facebook:
>>www.facebook.com/veberhost
>>
>>-----Original Message-----
>>From: Tamas Monos [mailto:tamasm@veber.co.uk]
>>Sent: 25 May 2012 12:13
>>To: cloudstack-users@incubator.apache.org
>>Subject: VPN with CS 3.0.2
>>
>>Hi,
>>
>>I have tried a few times with earlier version to setup VPN.
>>I can get the tunnel up and see the ESP packets back and forth but I 
>>get no IP from the virtual router (tunnel endpoint) so I can't send 
>>any traffic through the tunnel.
>>Any suggestions what I'm missing here?
>>
>>Regards
>>
>>Tamas Monos                                               DDI
>>+44(0)2034687012
>>Chief Technical                                             Office
>>+44(0)2034687000
>>Veber: The Hosting Specialists               Fax         +44(0)871 522
>>7057
>>http://www.veber.co.uk<http://www.veber.co.uk/>
>>
>>Follow us on Twitter:
>>www.twitter.com/veberhost<http://www.twitter.com/veberhost>
>>Follow us on Facebook:
>>www.facebook.com/veberhost<http://www.facebook.com/veberhost>
>>
>>
>>
>
>
>
>




Mime
View raw message