9

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):

  1. IPSec tunnel support on the virtual or dedicated host
  2. tinc
  3. 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.

0

2 Answers 2

6

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.

1
  • 2
    Also this may seem like a minor nitpick but, you can't map ESP back by TCP port without setting up a prior tunnel over another protocol. This is because ESP works at the IP level and therefore has no access to port numbers. There is Nat-T which is ESP over UDP but that is even more complex. Anyway figured I would suggest this edit. Commented May 8, 2013 at 5:56
1

Yes you're right. Looks like you'll have to deal with having separate IPs unless aggregating via a VPN concentrator. TBH the concentrator is probably the best bet, you'll just need 1 extra IP for all VPN connections, but its outside interface will need to reside in a different subnet/VLAN from the public IP hosts. I would go with that otherwise you're configuring IPSEC VPN directly on each individual server, what a nightmare

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.