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!
Guus Sliepen
2018-Mar-14 08:47 UTC
How to set up an extensible VPN with VirtualBox VMs as nodes
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>
On Wed, 2018-03-14 at 09:47 +0100, Guus Sliepen wrote:> 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.If so - we'll choose tinc, as we might need this functionality in future, who knows... As far as I understand it means, i.a., that tinc provides the ability to run several central servers, while OpenVPN only one, thus creating a danger of VPN failure if this single central server goes down. Correct?> > > > 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.Yes, that is exactly what we want. But will this go through all possible NATs/Firewalls/etc. of the users behind home routers? The way TeamViewer does? Could you, please, post a link to relevant tinc documentation and examples of how to implement this particular use case?... Thank you!> > > 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.The tricky part is the redistribution - how would you do it?> > > 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_addressI started to read about link-local IP6 addresses. Is it possible to assign a network interface several such address (since one it has already)? I'll have to figure out how to do this on Windows 10. Again - thank you very much!> > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
> > > > 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_addressThank you for this last remark. I indeed have no control over the IP address that the Windows hosts are going to get from the ISP or from its router (as most of the employees will probably be behind a NAT). After some experiments I came to the conclusion that it is better to run Linux VMs in the VirtualBox's NAT network mode (Windows hosts acts as router for the guest Linux VM). So at the end the VMs will be behind two NATs: (1) guest <-> host and (2) host <-> router/ISP. I want to build a /16 or /12 VPN. My question is - what ip range should I choose for the VPN itself (to assign ips to each node/VM) so that it doesn't interfere with other IPs that might be assigned within (1) or (2)? Thank you!
Apparently Analagous Threads
- How to set up an extensible VPN with VirtualBox VMs as nodes
- How to set up an extensible VPN with VirtualBox VMs as nodes
- How to set up an extensible VPN with VirtualBox VMs as nodes
- How to set up an extensible VPN with VirtualBox VMs as nodes
- Having more info, like the ip address of the vpn nodes in the xdot graph file of tinc