Just to be sure, what CloudStack > v4.15 uses Strongswan/l2tp or strongswan/ikev2 ?
Because l2tp became complicated to configure on native vpn clients on some OSes, kind of deprecated remote management VPN, compared to IKEv2. I'm a bit concerned about OpenVPN for the clients, what if binaries become subscription based availability or become proprietary ? For sure we need the option to select what type of VPN solution to offer when deploying a cloud. >From my perspective I cannot use/offer OpenVPN as a solution to my customers because it involves forcing them to download third party software on their workstations and I don't want to be responsible for a security breach on their workstation because of a requirement for 3rd party software that we don't control. On Fri, Jun 11, 2021 at 10:14 AM Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Thanks all for the feedback so far, looks like the majority of people on > the thread would prefer OpenVPN but for s2s they may continue to prefer > strongswan/ipsec for site-to-site VPC feature. If we're unable to reach > consensus then a general-purpose provider-framework may be more flexible to > the end-user or admin (to select which VPN provider they want for their > network, we heard in this thread - openvpn, strongswan/l2tp, wireguard, and > maybe other providers in future). > > Btw, ikev2 is supported now with strongswan with this - > https://github.com/apache/cloudstack/pull/4953 > > My personal opinion: As user of most of these VPN providers, I personally > like OpenVPN which I found to be easier to use both on desktop/laptop and > on phone. With openvpn as the default I imagine in CloudStack I could > enable VPN for a network and CloudStack gives me an option to download a > .ovpn file which I can import in my openvpn client (desktop, phone, cli...) > click connect to connect to the VPN. For certificate generation/storage, > the CA framework could be used so the openvpn server certs are the same > across network restarts (with cleanup). I think a process like this could > be simpler than what we've right now, and the ovpn download+import workflow > would be easier than what we'll get from either strongswan/current or > wireguard. While I like the simplicity of wireguard, which is more like SSH > setup I wouldn't mind doing setup on individual VMs (much like setting up > ssh key) or use something like TailScale. > > > Regards. > > ________________________________ > From: Gabriel Bräscher <gabrasc...@gmail.com> > Sent: Friday, June 11, 2021 19:28 > To: dev <dev@cloudstack.apache.org> > Cc: users <us...@cloudstack.apache.org> > Subject: Re: [DISCUSS] Moving to OpenVPN as the remote access VPN provider > > I understand that OpenVPN is a great option and far adopted. > I am ++1 in allowing Users/Admins to choose which VPN provider suits them > best; creating an offering (or global settings) that would allow setting > which VPN provider will be used would be awesome. > > I understand that OpenVPN is a great option and far adopted; however, I > would be -1 if this would impact on removing support for Strongswan -- > which from what I understood is not the proposal, but saying anyway to be > sure. > > Thanks for raising this proposal/discussion, Rohit. > > Cheers, > Gabriel. > > > Em sex., 11 de jun. de 2021 às 08:46, Pierre-Luc Dion <pdion...@apache.org > > > escreveu: > > > Hello, > > > > Daan, I agree we should provide capability to select the vpn solution to > > use, the question would be, should it be a global setting generic for > the > > whole region or per VPC? > > I think it should be a global setting to reduce the requirement > complexity > > of a region, but per VPC or customer(account or domain) would be ideal. > > > > Hean, the current implementation from PR:2850 > > <https://github.com/apache/cloudstack/pull/2850> that use strongswan > does > > support multiple users behind the same public IPs, but I don't recall for > > Windows generic clients. > > With OpenVPN, can you be connected to multiple VPN tunnels at the same > time > > ? We had the challenge a few times where we needed to be connected to 2 > > VPCs at the same time. > > > > I think adding support to OpenVPN is a good idea, the more options > > available the better Cloudstack will be. > > > > I don't know if 4.15 still uses L2TP from strongswan but we've moved away > > from it a while ago because it was not reliable, connection kept > > dropping, support only one windows client at a time, issue configuring > > clients, no helpful connection logs.. > > > > An interesting improvement is made to remote access VPN, would be to > > optionally use dns resolution of the VR from VPN clients so a user > > connected to the VPN could use hostname to access VMs. I think iptable > > currently blocks dns query from the vpn. > > > > Cheers, > > > > > > > On Fri, Jun 11, 2021 at 5:58 AM Hean Seng <heans...@gmail.com> wrote: > > > > > If thinking of only Site-to-Site VPN , then OpenVPN and WireGuard is > no > > > much different , or even current one is gpod. Only only time setup at > > > router. However if considering of Mobile Client, OpenVPN is more > > > complicated. > > > > > > The only concern now is multiple people in the same public IP need to > > > access the VPN. And this consideration will be OpenVPN or Wireguard to > > > handle this requirement. And for this purpose of multiple people in > > same > > > public ip need to access to VPN, then we will have think of usability > > and > > > easy installation of VPN client. > > > > > > We are using OpenVPN for more then 5 years, but always there is new PC > > > need to configure VPN Client, windows , android, ios, it is painful ( > we > > > are not using access server) . > > > > > > Currently we test on WireGuard, just forgot about performance or > > > whatsoever, just the conveniences of implementation, that is very > great > > > and easy for client installation , even mobile client on phone or > > tablet. > > > > > > > > > > > > > > > On Fri, Jun 11, 2021 at 5:04 PM Daan Hoogland <daan.hoogl...@gmail.com > > > > > wrote: > > > > > > > This is a potential religious debate, I think it makes the most sense > > to > > > > try and make the provider optional and let the operator or even the > > > > end-user decide. I see how this is an extra challenge, but does it > make > > > > sense? > > > > > > > > On Thu, Jun 10, 2021 at 10:24 AM Rohit Yadav < > > rohit.ya...@shapeblue.com> > > > > wrote: > > > > > > > > > All, > > > > > > > > > > We've historically supported openswan and nowadays strongswan as > the > > > VPN > > > > > provider in VR for both site-to-site and remote access modes. After > > > > > discussing the situation with a few users and colleagues I learnt > > that > > > > > OpenVPN is generally far easier to use, have clients for most OS > and > > > > > platforms (desktop, laptop, tablet, phones...) and allows multiple > > > > clients > > > > > in the same public IP (for example, multiple people in the office > > > > sharing a > > > > > client-side public IP/nat while trying to connect to a VPC or an > > > isolated > > > > > network) and for these reasons many users actually deploy pfSense > or > > > > setup > > > > > a OpenVPN server in their isolated network or VPC and use that > > instead. > > > > > > > > > > Therefore for the point-to-point VPN use-case of remote access [1] > > does > > > > it > > > > > make sense to switch to OpenVPN? Or, are there users using > > > > > strongswan/ipsec/l2tpd for remote access VPN? > > > > > > > > > > A general-purpose VPN-framework/provider where an account or admin > > (via > > > > > offering) can specify which VPN provider they want in the network > > > > > (strongswan/ipsec, OpenVPN, Wireguard...). However, it may be more > > > > complex > > > > > to implement and maintain. Any other thoughts in general about VPN > > > > > implementation and support in CloudStack? Thanks. > > > > > > > > > > [1] > > > > > > > > > > > > > > > http://docs.cloudstack.apache.org/en/latest/adminguide/networking_and_traffic.html#remote-access-vpn > > > > > > > > > > > > > > > > > > > > Regards. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Daan > > > > > > > > > > > > > -- > > > Regards, > > > Hean Seng > > > > > >
