tinc - Mar 2018 - How to set up an extensible VPN with VirtualBox VMs as nodes

Hello,

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.

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/)?

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?

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?

Thank you!

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>

Thank you for quick and detailed response!

On Mon, 2018-03-12 at 22:41 +0100, Guus Sliepen wrote:
> 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.
OK. What is easier to set up and then to maintain (especially add remove
new nodes/VMs)?
> 
> > 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..
> 
> > 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.
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...
> > 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.
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.

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.

Again - thank you very much for such a quick and detailed reply!