1

I am renting a set of dedicated servers, and they only have a single interface to internet.

However, for a lot of use cases, I would like my servers to communicate through a private IP network. For instance, that would allow me to expose internal services (ldap, puppet master, apt repository, bind) only to the LAN.

Ideally, I would like to be able to have an overlay network that would look like a private network (each machine would have a new virtual interface, with a local IP), but runs on internet.

I've previsouly used freelan for that, which works like a charm, except that I don't want to use such an exotic stack anymore.

I wondered if that would be possible with GRE/IPSec? From what I've seen, I would have to configure one GRE interface for each peer, on each host, to get a full mesh. Is there a simpler solution? That doesn't seem to scale well with the number of peers.

NewbiZ
  • 111
  • 5
  • Why not just use IPSec in transport mode? No additional network required. – EEAA Sep 28 '15 at 11:53
  • > Why not just use IPSec in transport mode? Because ideally I would want to be able to work "as if I have a protected, isolated, private LAN in between all my hosts". That would allow me for instance to have an intranet webserver listening only on the LAN. Or a BIND9 configured to expose internal zones (ldap.mydomain, puppet.mydomain, apt.mydomain, ...), or cacti listening on an internal interface, etc – NewbiZ Sep 28 '15 at 12:02
  • Got it. Fair enough. – EEAA Sep 28 '15 at 12:03
  • Why don't you have IPv6? – Michael Hampton Sep 28 '15 at 12:27
  • I honestly didn't look much at how ipv6 works. I just remember "oh, so it's much more complicated than just bigger IPv4" :) Would you mind writing a response to the post, explaining how IPv6 would solve this problem? – NewbiZ Sep 28 '15 at 12:33

1 Answers1

1

Yes. You can configure the gre interfaces, and then encrypt your gre interserver traffic with ipsec. Same thing is achievable with ipip (some UNIX systems calls this type of interface gif). But, actually, it's an old legacy way. What is even more legacy - is configuring a non-gre ipsec, because this way it will be hard to support and almost unrouteable, because no dynamic routing protocols are able to run on top of the legacy interfaceless ipsec.

In the same time there's a technolgy that Cisco calls VTI (Virtual Tunnel Interface) and Juniper calls st (secure tunnel). It's in the same time a bit more complicated (you need to create a special type of interface that is capable of handling ip traffic and terminate ipsec) but in the same time is more simplier, because it doesn't add intermediate IP header (though so does gre with ipsec in transport mode). Modern Linux support this technology, plus it's interoperable with Cisco and Juniper equipment.

So basically you have the following choices, I list them in order the complexity increases:

  • unencrypted ipip/gre tunnels (safe if your transport is already TLS-protected), rather simple to configure
  • pure legacy IPsec (obsolete, but worth to mention)
  • gre/ipip along with IPsec encryption
  • VTI/st

Plus, there's lot of software that constructs user-level VPNs. The main disadvantage of those is limited interoperability - it can communicate only with same software. However, it's actually better than legacy ipsec, because it's closer to a decent routing. However, if we talk about dynamic routing protocols, several limitation apply and I don't recommend using it in an environment that is supposed to be scaling:

  • openvpn
  • stunnel
  • tinc

And finally I should notice, that if we speak about dedicated servers that are located in one datacenter, VPN is a bit of overkill. Right solution would be to set up a VLAN for them, with private addressing, add this vlan to a 802.1q trunk that your server will handle and create a vlan interface. This way one interface will be still used (however, most moder server platforms have at least two copper gigabits, so I don't see a problem to enable one more plain ethernet interface - this is just the simpliest thing).

drookie
  • 8,051
  • 1
  • 17
  • 27