I am in the process of designing a virtual private network setup for a cloud hosting environment. Given our requirements I don't really see this as different from a dedicated server environment. The idea is that we want to allow customers to be able to require that their users connect to specific virtual machines or dedicated servers using a VPN which could provide auxiliary encryption (for example for print jobs submitted back to customer networks).
We are looking at supporting host to host IPSec (ESP and AH), and of course SSH tunnels, but neither of these really offer an ability to use VPN adapters. We are considering consequently adding at least some of the following, but since space is at a premium we want to standardize on no more than one or two of these (one would be better):
- IPSec tunnel support on the virtual or dedicated host
- tinc
- PPTP
Because our servers taking backups etc may be in different data centers, we'd prefer to be able to re-use our VPN approach here. This would seem to rule out PPTP. My current thinking is that IPSec is likely to be better because we can use standard VPN adaptors, but setting up routing (based on customer requirements) is likely to be significantly more difficult, which is why we are also looking at tinc.
Which of these two is preferable? Is my fear that routing management is likely to be a severe headache with IPSec unjustified? Is there an easy way around this? Are there other gotchas regarding tinc that I am missing (i.e. other than requiring a separate client)?
Update in response to @Wintermute's answer:
Yes, this question is from a server perspective. The reason is that these are effectively disconnected servers from client's networks. Yes our target market is the SME network. Yes, we are expecting to use public IP's for each client server unless they need something different (and then we can talk).
The solution we are leaning towards is one where clients define IP tunnels and the network ranges accessible by those tunnels and where we string these together with our own management tools (which are under development), which connect customer requests to configuration changes. The problem is that since we aren't likely to run routing software on the vms and servers, the routing table needs to be statically managed so customers who make mistakes in configuration will find that the VPN's don't work right.
It is also likely that we will be using ESP over the network for our own internal operations (for things like backups). The whole setup is rather complex and has many different perspectives, from server-centric (our client vpn to hosted instance) to network-centric (internal stuff), to database-centric (our tools). So I wouldn't say the question is representative of our whole approach (and questions are getting asked on a bunch of SE sites).
None of this really affects the question as a whole though. It is perhaps useful context though.
Best Answer
Not sure about tinc but IPSEC is almost mandatory. No serious business would trust PPTP.
Not sure how IPSEC affects routing. A tunnel is a tunnel is a tunnel regardless of the encryption. You'll be running into the same issues re: split tunnel or not, getting customers to understand the concept / oh look a particular customer's LAN IP clashes with the VPN pool you've picked, etc.
Sounds like you're aiming at SME market (individual servers, direct login etc.) so that rules out more sophisticated solutions, but I'll list two possible approaches anyway
some kind of VPN concentrator that allows profiles. All customers login to VPN concentrator then depending on their profile/group/whatever vendor teminology, get permissions to use protocol X to IP Y (ie their own server).
Cisco ASR1000V virtual routers - each customer gets one, you can then run direct IPSEC tunnels (with VTIs so makes routing appear easy) or even direct MPLS back to the customers so the router appears as just another branch in their topology, then allocate your VNICs VLANs etc. on the inside so they get a nice virtual 'branch'.
a smaller scale version of the above, we've used monowall to great effect for this purpose (i.e. each customer gets a layer 3 virtual device that acts as a router/firewall, they VPN into this device and get access to their VLANs only), however then each router/firewall needs their own public IP address.
Re: your current approach, you do realise then each server needs a public IP or you have a complicated and convoluted system of NATs where each customer's VPN path gets allocated a single port or similar.
I'd recommend getting a full time networker in to look over any design / proposal you have, it sounds like you're coming at it from a server background.