Skip to content
This repository has been archived by the owner on May 11, 2022. It is now read-only.

IPSec VS tinc VPN #2

Closed
NielsKSchjoedt opened this issue Sep 3, 2018 · 4 comments
Closed

IPSec VS tinc VPN #2

NielsKSchjoedt opened this issue Sep 3, 2018 · 4 comments

Comments

@NielsKSchjoedt
Copy link

NielsKSchjoedt commented Sep 3, 2018

Hi,

I have quite a few dedicated servers residing in different datacenters. I need to be able to connect them in a private network, so e.g. my web servers can communicate securely with memcached, postgresql etc. on different servers. Currently I'm using tinc for this, but I have seen something that looks like network overhead in this setup: https://stackoverflow.com/questions/47350951/tinc-shh-ipsec-tuning-for-high-throughput

As part of renewing the servers I'm considering switching to use IPsec provisioned using this ansible role instead. Do you have any thoughts on the performance or experience you care to share? :-)

@kravietz
Copy link
Owner

kravietz commented Sep 3, 2018

@NielsKSchjoedt my main reservation against using Tinc is that it's a typical home-baked VPN solution without much cryptographic audit and had suffered cryptographic issues in the past. IPSec on the other hand is a protocol with over 20 years of thorough auditing and core design by NSA folks. I have not performed any performance measurements on the IPSec setup but the Linux implementation is highly optimized, works at kernel level and the packet size overhead is minimal.

@NielsKSchjoedt
Copy link
Author

NielsKSchjoedt commented Sep 4, 2018

Really nice of you to give me an answer. That's very much appreciated! One thing I have a hard time wrapping my head around is how IPsec differs from a VPN solution in connection to local vs public IP's. For my current tinc setup it creates a local network between the servers with IP's in ranges of 10.0.0.1-50, which I then conveniently have given each host a name in /etc/hosts. This makes it easy for me to know, that as long as I am communicating on those local IP's (and not the public ones of the servers), my traffic is secure. It also makes it easy to setup e.g. my databases to ONLY listen on those local IP's/hostnames and not the public ones. Am I getting it wrong, or is IPsec different on this part? I would have to bind my services to the public IP's of the servers right? And then "trust" that IPsec is kicking in correctly between the servers? Or can I setup a private network for IPsec as well? Sorry, but I'm a bit noob here :-)

@kravietz
Copy link
Owner

kravietz commented Sep 4, 2018

@NielsKSchjoedt IPSec can work in tunnel mode, which is similar to VPN, and transport mode, which is much better suited for server-to-server scenarios as we're discussing here. In transport mode the packets are encrypted without any tunneling or address changes - for example, if you have appserver 8.8.8.8 talking to database at 8.8.4.4 over TCP you will see packets being sent from 8.8.8.8 to 8.8.4.4, but they will be ESP (IPSec) packets. What should be encrypted and where is matter of setting simple SPD rule (e.g. all packets 8.8.8.8->8.8.4.4 must be encrypted). I'm using public IPs in this example intentionally, to show that you get a very simple and clear architecture here - this is what I like with IPSec most.

You can also set up IPSec in tunnel mode, in which it will work as a VPN - so you've got app server and database on private IPs, and these are tunneled in an IPSec tunnel with public addresses, so pretty much as you Tinc tunnel works now. But over years I found that each another layer of re-addressing causes more potential issues and this is the second reason why I like IPSec.

@kravietz
Copy link
Owner

kravietz commented Oct 9, 2018

@NielsKSchjoedt Yet another reason to avoid tinc :) https://security-tracker.debian.org/tracker/source-package/tinc

@kravietz kravietz closed this as completed Oct 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants