How to set up an extensible VPN with VirtualBox VMs as nodes

[Guus Sliepen]

On Mon, Mar 12, 2018 at 06:46:24PM +0200, ST wrote:

> We have not so tech-savvy colleagues in different locations around the
> world who now use Windows 10 and need access to Linux (Debian 9). Linux
> will be provided in form of VirtualBox VMs. We, the technical support
> team, need to have access to the guest VMs (via SSH and occasionally as
> remote desktop)  and to the host (through the guest while VM runs in
> bridged mode; via Windows 10 built in SSH Server).
> 
> What is the best approach to create such an infrastructure in a
> flexible, secure and efficient way, so that:
> 
> (A) adding/removing an employee requires minimal effort,  
> (B) adding/removing a tech-support team member requires minimal effort.
> 
> While we don't have experience with VPNs we assume that it's better to
> invest in setting up a VPN (with VMs as its nodes) once rather than
> enable port forwarding on all possible router models in order to get
> access to the VMs.
> 
> 1. What open-source VPN software would you recommend for such a case? We
> are considering [Tinc](https://www.tinc-vpn.org) as it seems to be
> rather flexible and provides an easy way to add new nodes thus helping
> us to achieve the above mentioned goal A.

Tinc should work just fine. However, if you don't really need the mesh
network functionality, and just need the VMs to connect back to a
central server, then other open-source VPN software, such as OpenVPN,
would work as well.

> 2. If yes, in which mode should we run Tinc -
> [bridge](https://www.tinc-vpn.org/examples/bridging/) or [proxy
> ARP](https://www.tinc-vpn.org/examples/proxy-arp/)?

You might not need either of those modes. Plain routing can probably
also work in your situation, perhaps in combination with a NAT firewall
rule in the VM.

> 3. How should we manage authentication of the tech support team in order
> to achieve the goal B? Asymmetric keys? One pair for all or a pair for
> each member? Maybe passwords?

Tinc only supports assymetric keys. You should use one pair for each
node in the VPN (ie, each VM gets its own pair, the central
server(s) also each get their own pair, and if each tech-support team
member has its own VPN node they also get their own unique pairs). I
strongly discourage using the same keypair for more than one node. In
your case, this is also very important to allow revoking access to the
VPN for employees and/or tech-support members; if you reuse keys then
they can simply use a copy of their key to impersonate other nodes.

> 4. In order to get an easy (to remember) access to the host from the
> guest via built in SSH Server on all machines we probably need to give
> all hosts the same IP in the Network bridge mode. Are there other
> important configuration tricks for host and/or the VM appliance that you
> can think of?

If each Windows host has the same IP address on the VPN, it will be
impossible to directly SSH to a specific Windows host directly from
other VPN nodes. However, since I assume the Linux VMs will get unique
IP addresses in the VPN, you can SSH into the Linux VM, and from there
SSH to the host. That way, you don't have to consider whether to
route/bridge/proxy-arp at all.

If you do want to SSH directly to the Windows host, but still want a
fixed IP address, then the best solution I can think of is to have a
port forwarding firewall rule in each Linux VM that redirect connections
to a certain port (say, 222) to the SSH port of the Windows host. Then,
you can just use "ssh -p 222 <IP of Linux VM>".

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20180312/bca0565d/attachment.sig>