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
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.