Discussed in... what? Your text cut off there @tom29739 :)

Logs in http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-labs/20160825.txt from 21:17:49 to 21:44:10
Key things:

• Would be for windows users who can't easily do simple SSH tunnelling?
• Would need to be restricted to only routing connections to Wikimedia IPs (10.0.0.0/8, maybe 208.80.155.128/25?) only, no bouncing outside.
• Would we need to restrict who can be an admin / sudo in this project, like bastion? I imagine things like MySQL credentials would be going through it without end-to-end encryption.

To recap some of the arguments from Cloud-Services:

• ProxyCommand is complex for windows users; a VPN would allow a much more user-friendly connection (directly connecting to e.g. tools-exec-1201.eqiad.wmflabs from putty)
• Corollary: currently bastions need to have shell access to allow windows users to more easily jump through. This could be removed.
• Developing locally becomes easier due to direct access to replicas (instead of ssh tunneling and connecting to localhost:someport, connect to enwiki.labsdb)

Main things that would need to be figured out:

• What VPN software?
• Sane configuration, not allowing traffic through labs (e.g. user -> labs -> google)
• Authentication (some form of public/private key? preferrably linked to existing ssh keys)

OpenVPN

• Using LDAP to authenticate would be easy: https://openvpn.net/index.php/access-server/docs/admin-guides/190-how-to-authenticate-users-with-active-directory.html
• Would only carry traffic to Labs hosts (e.g. *.wmflabs/*.labsdb hosts), and not to internet.
• OpenVPN has clients for many different platforms, including Windows.
• OpenVPN is fast and secure.

There is other VPN software available of course, but I have had a good experience with OpenVPN.

In T143939#2584345, @tom29739 wrote:

• Would only carry traffic to *.wmflabs hosts, not to internet.

You'd need labsdb/wmnet for database replica access. I'm not quite sure how DNS would work actually - the client would need to be able to resolve these, but then all their own DNS lookups would be going through labs?

In T143939#2584425, @AlexMonk-WMF wrote:

You'd need labsdb/wmnet for database replica access. I'm not quite sure how DNS would work actually - the client would need to be able to resolve these, but then all their own DNS lookups would be going through labs?

The OpenVPN client would need to be configured to only route certain traffic through the VPN, otherwise the user's internet connection would not work. We could provide .ovpn files for this purpose.

Sane configuration, not allowing traffic through labs (e.g. user -> labs -> google)

Note that it is possible to configure openvpn so it only provides routes to a subrange (ie. labs hosts). It could be blocked anyway¹ but that would require the user misconfigurating his routes.

¹ Not sure if it is worth it, since labs users already can access the internet through their instances.

In T143939#2584438, @Platonides wrote:

Sane configuration, not allowing traffic through labs (e.g. user -> labs -> google)

Note that it is possible to configure openvpn so it only provides routes to a subrange (ie. labs hosts). It could be blocked anyway¹ but that would require the user misconfigurating his routes.

¹ Not sure if it is worth it, since labs users already can access the internet through their instances.

https://wikitech.wikimedia.org/wiki/Wikitech:Labs_Terms_of_use#What_uses_of_Labs_do_we_not_like.3F - #5

In T143939#2584438, @Platonides wrote:

Sane configuration, not allowing traffic through labs (e.g. user -> labs -> google)

Note that it is possible to configure openvpn so it only provides routes to a subrange (ie. labs hosts). It could be blocked anyway¹ but that would require the user misconfigurating his routes.

¹ Not sure if it is worth it, since labs users already can access the internet through their instances.

We don't want Labs turning into a free VPN service (explicitly prohibited by the Labs ToU).

OpenVPN server can be configured to only provide routes to certain IP ranges/hosts

"can" as in "are technically able to"

So, if it is hard to misconfigure the vpn, we could simply trust our users to do the right thing™

In T143939#2584449, @tom29739 wrote:

OpenVPN server can be configured to only provide routes to certain IP ranges/hosts

That's the configuration I was describing

Doesn't the ssh of Cygwin / MinGW / MSYS (not an expert here) work?

In T143939#2585688, @zhuyifei1999 wrote:

Doesn't the ssh of Cygwin / MinGW / MSYS (not an expert here) work?

Yes, but it's a big pain to set up + it doesn't work reliably.

Some considerations if you want to go down the VPN road:

• VPN should be at least as secure as our current SSH setup or better
• We're talking about user vpn's here, not site-to-site vpn's
• VPN's are generally either ipsec or ssl based.
• Ipsec is generally more open standard: different vendors and different programs can communicate with each other (see https://en.wikipedia.org/wiki/IPsec)
• SSL based VPN's are usually proprietary. They use open standard (SSL), but you need their client to communicate with their server. So you might end up having multiple clients on your machine if you use multiple services.
• VPN should be split tunnel (see https://en.wikipedia.org/wiki/Split_tunneling): Only push the rang(es) you want users to access directly
• Pick the right cypher(s): Plenty of outdated insecure stuff out there
• Terminate the VPN on a firewall: Deny everything and only allow the kind of traffic you want to allow.
• Don't even consider starting this without two-factor authentication.
• I would integrate it with the central LDAP to keep users in one place. Having multiple LDAP instances is a PITA and a security incident waiting to happen. AFAIK the central LDAP setup already provides two-factor authentication

In T143939#2623510, @Multichill wrote:

• I would integrate it with the central LDAP to keep users in one place. Having multiple LDAP instances is a PITA and a security incident waiting to happen. AFAIK the central LDAP setup already provides two-factor authentication

Nope, just password-based auth. The 2FA you see on wikitech and horizon comes from the wikitech database on silver, which won't be accessible by this.

In T143939#2584266, @valhallasw wrote:

To recap some of the arguments from Cloud-Services:

• ProxyCommand is complex for windows users; a VPN would allow a much more user-friendly connection (directly connecting to e.g. tools-exec-1201.eqiad.wmflabs from putty)

[…]

Is the configuration really that complex? https://wikitech.wikimedia.org/wiki/Help:Access_to_instances_with_PuTTY_and_WinSCP#How_to_set_up_PuTTY_for_proxying_through_bastion.wmflabs.org_to_your_instance looks tedious to repeat for every instance, but fairly simple.

In T143939#2820868, @scfc wrote:

In T143939#2584266, @valhallasw wrote:

To recap some of the arguments from Cloud-Services:

• ProxyCommand is complex for windows users; a VPN would allow a much more user-friendly connection (directly connecting to e.g. tools-exec-1201.eqiad.wmflabs from putty)

[…]

Is the configuration really that complex? https://wikitech.wikimedia.org/wiki/Help:Access_to_instances_with_PuTTY_and_WinSCP#How_to_set_up_PuTTY_for_proxying_through_bastion.wmflabs.org_to_your_instance looks tedious to repeat for every instance, but fairly simple.

I have tried this configuration before, and it works, but not reliably. The connection can cut out unexpectedly and often PuTTY is unable to find the plink.exe file. This configuration also means that there is a plink.exe process running on the computer for every SSH connection to Labs machines, and these SSH sessions are slower than SSH to bastion, SSH to other machine in Labs sessions.

plink is a (rudimentary) VPN, just like ssh's -W option in ProxyCommand: It needs to run, it will encrypt the session once again and it can end unexpectedly, so these are not arguments against it.