<div dir="ltr"><div style>I agree with Yi.</div><div style><br></div>+1 for SSL VPN</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 9:20 PM, Yi Yang <span dir="ltr"><<a href="mailto:yyos1999@gmail.com" target="_blank">yyos1999@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>As lack of cloudpipe is one of the
reasons to prevent existing nova network users from migrating to
quantum, it makes sense to give SSL VPN a higher priority.<span class="HOEnZb"><font color="#888888"><br>
<br>
Yi</font></span><div><div class="h5"><br>
<br>
On 4/25/13 3:17 AM, Michael Shieh wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">Hi Nachi,
<div><br>
</div>
<div>I see these are 2 very different use cases:</div>
<div><br>
</div>
<div>[1] is the VPN to support remote access users to connect to
the Openstack networks. This would allow roaming users to
connect with security policy defined by Openstack admin,
without user intervene.</div>
<div><br>
</div>
<div>[2] IPsec is used for site-to-site connection, a must for
Amazon VPC type deployment. If Openstack networks are set up
in the cloud for enterprise tenants, this would provide secure
connectivities between Openstack networks and enterprise
networks. Security policies are agreed and configured by both
sides. (In Amazon VPC, it can generate security policy for
some firewall vendors to import into the firewall of
enterprise networks to reduce the configuration complexity).
IPsec could be used for remote access as well (through Xauth
or IKEv2) but it's not as simple as [1]. AFAIK, few companies
deploy IPsec for remote access.</div>
<div><br>
</div>
<div>As [1] has been used in Nova while [2] is still
new in Quantum, I vote for [1] so current users have a
mechanism to connect to Openstack network to manage or share
the resources. Besides, IPsec alone may not be enough for VPC
deployment, as most likely it needs dynamic routing support to
detect the tunnel liveness.</div>
<div><br>
</div>
<div>Michael</div>
<div><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Apr 24, 2013 at 4:53 PM,
Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
folks<br>
<br>
I would like to ask your opinions.<br>
[1] Nova parity VPN (Cloudpipe) is OpenStack Networking
VPN first step.<br>
Amazon VPC compatible api(*) is also great candidate to
start.<br>
And it is using IPSec.<br>
The IPSec has more widely used than SSL-VPN in industry.<br>
so, How about start with IPSec?<br>
<br>
Currently, Cloudpipe is using SSL-VPN, However,
Cloudpipe was intended to<br>
let users to access to the VLAN, so I tend to think any
VPN method is<br>
OK if we can<br>
accomplish it.<br>
<br>
so if you want to start with SSL-VPN, please let us
know.<br>
In that case, we will start with SSL-VPN.<br>
<br>
(*) may be not fully same API, but similer model<br>
<br>
[2] Generic VPN Service model<br>
It looks like there is no strong opinion to have "mode"
attribute on<br>
Generic VPN Service.<br>
so we would like to remove this attribute.<br>
<br>
I registered the BP for Generic VPN service here.<br>
<a href="https://blueprints.launchpad.net/quantum/+spec/generic-vpn-service" target="_blank">https://blueprints.launchpad.net/quantum/+spec/generic-vpn-service</a><br>
<br>
Is this OK for you guys?<br>
<br>
Thanks<br>
Nachi<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Vinay Bannai<br>Email: <a href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>Google Voice: 415 938 7576<br>
</div>