-
-
Notifications
You must be signed in to change notification settings - Fork 7
IPSec VS tinc VPN #2
Comments
@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. |
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 :-) |
@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. |
@NielsKSchjoedt Yet another reason to avoid |
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? :-)
The text was updated successfully, but these errors were encountered: