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