1. 26

I’m posting a link to Tinc VPN because I am interested in comments about the security and usefulness of tinc. I have started using it for a few projects running on OpenBSD because it is very easy to get up and running and also reconnects quite easily should network conditions change which is something that isakmpd and iked are not always so good at. Any comments or concerns about its use?

  1.  

  2. 12

    There are enough VPN solutions in the OpenBSD base system for my needs:

    • IPsec
    • l2tp (npppd, server only, works with Android and iOS clients),
    • ssh (layer 2 and layer 3, see “SSH-BASED VIRTUAL PRIVATE NETWORKS” in man ssh).

    I consider the various VPN solutions in ports only where interop with a specific VPN software is needed. They all lack proper privilege separation and sandboxing, so why use them in favour of base VPN tools?

    Years ago I used OpenVPN a lot but I found that ssh’s VPN is a good enough replacement (TCP only, no UDP, but if you need stateless VPN connections that much why not just use IPsec).

    It looks like privsep does not even exist as a faint idea in tinc. At best you can expose your tun/tap device to the entire tinc process and let any RCE in tinc inject packets. The only alternative is to make any arbitrary RCE in tinc run with root privileges to begin with.

    It can be useful to set up a tun/tap interface owned by a non-root user, so tinc can be started without needing any root privileges at all.

    https://www.tinc-vpn.org/documentation/Interface-configuration.html

    This kind of software design would never be accepted into OpenBSD base.

    1. 5

      Even better, OpenBSD’s VPN stuff is based on actual standards! OpenIKED works with Windows’ built in VPN client, which does IKEv2. (Because you know, PPTP won’t cut the mustard.)

      OpenVPN always smelled like jank, but sadly it got popular over IPSec based VPNs.

      1. 1

        Besides OpenBSD and FreeBSD, I also use macOS a fair amount for work reasons. I have not tried using IKEv2 with macOS or iOS but there have been some bugs that came across the OpenBSD mailing lists but hopefully those have been ironed out. I used to use PPTP and tried to get L2TP over IPSec working before npppd but never got it working on OpenBSD. Once npppd arrived, everything just worked.

      2. 1

        I had forgotten about SSH-based VPNs. That’s a good idea. Thank you.

        My experience in the past with IPSec has been that it is not very tolerant of any sort of changing network conditions. Do you use IPSec (either isakmpd or iked) with NAT on laptops running OpenBSD or only from servers with fixed addresses?

        The way tinc works reminds me somewhat of PepVPN/SpeedFusion by Peplink. I also use Peplink routers frequently for out of band management because of their embedded cellular modems and so forth. I would love to have an ISC licensed alternative to tinc that worked in a somewhat similar way and very nicely through NAT as tinc does. The two big advantages to tinc as I see it are that it can work in a mesh and also that it automatically reconnects if anything goes wrong with the connection. Is there a way to get the automatic, quick, and reliable reconnect with IPSec that I am overlooking?

        1. 3

          I use SSH for the road-warrior use case (laptop connects home), isakmpd+npppd for my android phone, and plain IPsec (with gif(4) for routing) for permant tunnels, e.g. I provide public wifi where all traffic is tunneled to a dedicated server’s IP before it hits the internet.

          1. 1

            For the IPSec case, are you using tunnel or transport mode? I had not considered using gif(4) with IPSec. That would make routing easier.

            1. 2

              ESP (tunnel) mode.

              Configure ipsec.conf as usual. The IPs used in ipsec.conf are the ones that ‘ifconfig gif’ shows on the ‘tunnel:’ line (i.e. the outer layer of IP-IP encapsulation).

              Use the ‘inner’ (tunelled) IPs on the gif interface for routing purposes. E.g. hosts on the LAN behind the VPN box may refer to these IPs.

              It does not work well if any of the IPs involved ever changes (road warrior), but in a fully static setup it works well (even with NAT).

              1. 1

                Very interesting. I will give that a shot. I never thought about setting up IPSec that way. Are you using route-to in pf.conf to tunnel the public WiFi traffic somewhere else? Thank you for the suggestions!

                1. 3

                  Yes, incoming traffic over wifi is tagged, followed by some exceptions that override with a different and otherwise unused tag. Tagged connections are then routed with route-to.

                  The relevant pf rules look something like:

                  pass in on $wifi_if tag tunnel

                  pass in on $wifi_if proto tcp to self port {http, ssh} tag notunnel

                  pass out tagged tunnel route-to $tunnel_if

                  1. 2

                    Oh, and by the way, you can set the MTU of a gif interface to 1500 (append the line “mtu 1500” to /etc/hostname.gif0).

                    The default gif MTU is smaller than 1500 which avoids fragmentation of encapsulating packets. However, with the default MTU setting I saw MTU path discovery issues on machines that aren’t aware of the VPN. I have seen no apparent problems after bumping the MTU. Large encapsulating packets will now be fragmented, but that is the lesser of the two evils and is handled automatically (definitely works for UDP encap packets to port 4500 which is your only option if behind NAT; plain ESP might work just as well but I have not tried it).

                    1. 1

                      Thanks for all that info! I was wondering about MTU. That makes things simpler if 1500 will work fine.

      3. 3

        I really enjoy tinc, probably one of the easiest to set up and maintain VPNs for the devices + vps setup. Used it for a long time.

        Only big problem I have with it, is their mobile support is still predicated on having a rooted phone (see: https://github.com/Vilbrekin/tinc_gui/issues/5 ). This ended up making it useless for a big subset of hopes I had for my VPN, so I’ve moved on to much sadder configurations so all my devices can connect to the VPN.

        1. 3

          Yes, that is a problem for mobile devices. I solved that in my own use case by using OpenBSD with npppd for L2TP over IPSec from iOS devices. The L2TP over IPSec VPN allows access into my larger tinc mesh which I am now looking at running in switch mode instead of router and using OpenOSPFD for the routing. It is really nice to turn on my OpenBSD machines and connect right into tinc wherever I am.

          1. 2

            How did I not think of that! Great solution! Just run tinc for any device that can manage it, and then run openvpn along side it for “legacy vpn” devices. New weekend project!

            1. 1

              I’ve also done the same with OpenVPN but I prefer not to have to install a separate client on iOS or macOS since they both have built-in support for L2TP over IPSec.

        2. 3

          At work we run tinc as a quasi-VPC clone in production and it’s been good to us so far.

          The only complaints I have is that under a lot of network load it’ll eat up a good amount of processing power on a DO droplet.

          It took some time getting up a lot of the infrastructure in place to manage and hand out keys and configs – FWIW I think had we started with something more zerconf like this might have been easier on us.

          1. 3

            I am usually recommending ipsec as VPC between hosts. Do you have performance numbers? The only downside I saw with these setups was that they add some latency. I did not see unreasonably huge CPU usage even when under heavy load. How is tinc performing. Sparing one core for tinc will usually be ok, if latency is improved.

            1. 2

              In our testing across datacenters tinc did not add any noticable latency. In our tests with iperf bandwidth capped out at about 150Mb/s whereas without it we’d hit line speed (1 Gb/s) we’re not network constrained so that wasnt a deal killer for us – You’re right about it eating up a core, but that’s still a core you’re paying for.

              Prior to selecting tinc we looked at using ipsec but the management burden of it seemed really high. There’s a good talk by Fran Garcia from hostedgraphite who went into their problems with it https://www.usenix.org/sites/default/files/conference/protected-files/srecon16europe_slides_garcia.pdf That presentation and doing some reading pretty much steered us away from ipsec

              In the end I think we’ll probably up switching to a provider who provides a VPC like service and then we’ll do site to site vpns across providers if only to relieve us from the management and overhead burdens of tinc.

              1. 2

                Prior to selecting tinc we looked at using ipsec but the management burden of it seemed really high. There’s a good talk by Fran Garcia from hostedgraphite who went into their problems with it https://www.usenix.org/sites/default/files/conference/protected-files/srecon16europe_slides_garcia.pdf

                Decent write-up. TL;DR: Don’t use Racoon.

                1. 1

                  For hosts you control yourself, ipsec with strongswan and libreswan using ikev2 has always been a great experience for me. Connecting with roadwarriors, running old software versions on odd OSs, has never been the best part though.

                  1. 1

                    Thanks for the link to that talk. It is quite interesting.