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.c...@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.vit...@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.vit...@citrix.com> wrote: > > > > > > >On 7/2/12 2:33 PM, "Sheng Yang" <sh...@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 > >
