incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Kluge <Kevin.Kl...@citrix.com>
Subject RE: site-to-site VPN review
Date Tue, 03 Jul 2012 00:03:19 GMT
I've heard some requests for that and I do think it would be a good feature.  CloudBridge is
notably different from site-site VPN though.  It works at layer 2, does WAN optimization,
and requires CloudBridge at both ends of the connection.

-kevin

> -----Original Message-----
> From: Clement Chen [mailto:clement.chen@citrix.com]
> Sent: Monday, July 02, 2012 3:21 PM
> To: CloudStack DeveloperList
> Subject: RE: site-to-site VPN review
> 
> Regarding performance, is there a plan to incorporate Netscaler's
> CloudBridge feature (basically a site-to-site VPN) ?
> 
> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Monday, July 02, 2012 3:09 PM
> To: CloudStack DeveloperList
> Subject: Re: site-to-site VPN review
> 
> Also, if we could put out an example Cisco / Juniper configuration that is
> known to work with the CloudStack site-to-site VPN, that would be great.
> 
> On 7/2/12 3:06 PM, "Chiradeep Vittal" <Chiradeep.Vittal@citrix.com> wrote:
> 
> >
> >
> >On 7/2/12 2:33 PM, "Sheng Yang" <sheng@yasker.org> wrote:
> >
> >>On Monday, July 02, 2012 12:48:33 PM Chiradeep Vittal wrote:
> >>> I took another look at the FS
> >>>
> >>>http://wiki.cloudstack.org/display/DesignDocs/Site-to-site+VPN+functi
> >>>ona
> >>>l
> >>>+sp
> >>> ec And the test suite
> >>> http://wiki.cloudstack.org/display/QA/Site-to-Site+VPN
> >>>
> >>>
> >>>  1.  It isn't clear if we are going to use pre-shared keys (PSK) or
> >>> public-key (RSA keys) *   If PSK, who generates this and what is the
> >>> strength of this key? *   Can this PSK be changed / revoked ?
> >>
> >>We're using PSK. Currently user generate the psk key and program it on
> >>the both side of VPN. Update the spec.
> >
> >The Remote Access Vpn service generates the PSK on the user's behalf.
> >This makes it easier for the cloud admin to enforce key strength.
> >This is also the way AWS VPC works.
> >
> >>
> >>>  2.  Why is this restricted to admin only?
> >>
> >>Currently only admin can create/delete private gateway and vpn gateway
> >>of VPC.
> >>Though Alena just update me that he/she can do it on behavior of other
> >>account.
> >>
> >>>  3.  Does this require "conserve mode = true" ?
> >>
> >>Currently we only support VPC, so it's no conserve mode here.
> >>
> >>I think even in the future when we support isolated guest network,
> >>this wouldn't be an restriction.
> >>
> >>>  4.  Is NAT traversal supported?
> >>
> >>Yes. I enabled it in openswan configuration.
> >>
> >>>  5.  FS and test suite in my mind should cover FCAPS (faults,
> >>>configuration,
> >>> administration, performance, security) *   How do you deal with faults?
> >>
> >>DPD would try to keep it recover and connected.
> >>
> >>> What happens when the VR is restarted?
> >>
> >>Currently we didn't restart VPN connection automatically. I would fix
> >>that.
> >>
> >>> What happens if VR gets disconnected from the remote end?
> >>
> >>DPD would try to recover it. I've set a 3 time retry for initial
> >>connection, but not sure about how many time it would retry in the
> >>disconnection after that.
> >>
> >>> *   The API parameters and responses need to be more
> >>> completely documented.
> >>
> >>Sure.
> >>
> >>> *   If a user complains that his s-2-s VPN is not
> >>> working / used to work but does not now, how can customer support
> >>>diagnose  this problem?
> >>
> >>Log is in the /var/log/auth.log and /var/log/daemon.log. I didn't pull
> >>it out to separate files because openswan separate log output lacks of
> >>timestamp.
> >
> >Can we think of a better way? Are these logs being rotated / archived?
> >I think the former is, not sure about the latter.
> >
> >>
> >>> *   How well does this perform: what is the target throughput
> >>> and what is the size (RAM/CPU) needed to achieve this performance?
> >>
> >>Not tested yet.
> >>
> >>> *   Is there a need for a later kernel on the VR for AES support?
> >>
> >>No. AES can be done by software as well.
> >
> >What I mean is: take advantage of acceleration offered by Intel chips
> >that implement the AES-NI instruction. It is my understanding that the
> >current bits of the VR are unable to do this.
> >
> >>
> >>> *   How secure
> >>> is this implementation? Can the PSK be guessed? Are the latest
> >>> security patches for OpenSwan available in the VR?
> >>
> >>The level of security is the same as normal site to site implementation.
> >>So it
> >>depends on PSK to be generated. Since we didn't generated it, user
> >>controls it.
> >>
> >>For the security upgrade, it would be a common issue rather than vpn
> >>specified.
> >>We lack of up-to-date security upgrade mechanism. I suppose it's
> >>should in the plan.
> >
> >My point is that when the feature is released, there shouldn't be any
> >known security issues with the software and it should be patched to the
> >latest level. Of course, future security issues is a different question.
> >
> >>
> >>--Sheng
> >


Mime
View raw message