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

[Guus Sliepen]

On Tue, Mar 13, 2018 at 11:09:05PM +0200, ST wrote:

> > > 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.
> 
> OK. What is easier to set up and then to maintain (especially add remove
> new nodes/VMs)?

If you are not interested in the mesh functionality that tinc provides,
then both are probably similar in ease of setup and maintenance.

> > > 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.
> 
> Could you, please, elaborate on this possible setup, as my knowledge of
> networks is really basic. We are indeed interested to keep everything as
> simple as possible. Do we need Tinc for this plain routing? Ideally the
> end result should be as simple as TeamViewer - you just drop VM on the
> host and have access to it via SSH/VNC without messing with port
> forwarding, dynamic DNS, etc..

As I see it you want this situation:

*----------------*
|  Windows host  |
|                |
|  *----------*  |
|  | Linux VM |  |
|  |   tinc---+--+--------------> rest of the VPN
|  *----------*  |
|                |
*----------------*

If you just want to have access to the Linux VM, then you don't need
bridging or proxy ARP at all. The Linux VM will have its own unique IP
address on the VPN, and you will be able to access it directly via
whatever protocol you want without needing to do anything.

If you want to access the Windows host directly from another node on the
VPN, then there are several ways to do make this happen, and you will
probably have to decide for yourself which method works best for you.

You can just log in on the Linux VM by connecting to it via SSH, and
from there start other programs that will connect to the Windows host.
Or, you can set up some kind of forwarding in the Linux VM to be able to
directly connect to a network port on the Windows host from another node
on the VPN, without first having to log in to the Linux VM. This can be
done with a simple port forwarding rule on the Linux VM, without needing
any support or special configuration of tinc.

> Is it a bad (or maybe good) idea to use unique pairs for each VPN node,
> but the same key/password for the SSH authentication on the VM itself?
> This way we can revoke access of each member by revoking access to VPN,
> so his knowledge of the SSH key/password will not help him to get access
> to the nodes. It will also reduce the management burden as the same
> key/password will be distributed within VM image...

If you are certain that the only way you can access the VM is via the
VPN, then in principle you could use the same key/password for SSH. But
I would personally not take that risk. I would just have all members'
public SSH key in .ssh/authorized_keys on the VM. This file can just be
the same on all VMs. So if a member's access is revoked, I'd remove his
public key from the master copy of the authorized_keys file, and
redistribute it to all VMs.

> > 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.
> 
> Again, please, elaborate. We indeed do not need direct access to Windows
> hosts, they actually should not/needn't be part of the VPN at all - only
> the guest VMs. From guests VMs we want to get to the hosts. That's why I
> thought to choose the same IP for the hosts in this small host-guest
> networks. This way, no matter on which VM I currently am - I always can
> SSH from it to a known IP and will land on its host.

Yes, in that case using the same IP address for the Windows host in the
host-guest networks is perfectly fine.

> I probably need to mention that those employees with Windows hosts are
> people working from home in different cities, each with probably
> different ISP. So giving them same local IPs should not cause any
> problems, I think.

You do have to be careful about which IP address you are going to use.
You have no control over the IP address that the Windows hosts are
going to get from the ISP they are connected to. They can get a public
IP address, or they could get any IP address from the private ranges
such as 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. If possible, the
best way to ensure you will not have an address conflict is to use IPv6
for the host-guest network. Then you can use link-local addresses which
for sure will not conflict with anything, or if that is not an option,
assign a Unique Local Address, see:
https://en.wikipedia.org/wiki/Unique_local_address

-- 
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/20180314/69806b27/attachment.sig>