Re: connecting tinc 1.0.36/libssl3 to older nodes?
On Wed, May 18, 2022 at 01:28:31AM -0400, Nathan Stratton Treadway wrote: > Thus, I believe Xenial's tinc 1.0.26 is attempting to use > EVP_bf_ofb()/EVP_sha1() when setting up the metadata connection -- and > that nothing else related to the metadata connection setup changed > between 1.0.26 and 1.0.33 That's correct. > According to > https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-legacy.html > , Blowfish is part of the legacy provider in libssl3, so it makes sense > that it's not available by default on the Jammy node. > > However, as far as I can tell this does get successfully enabled when my > openssl.cnf override-file is in place (on the Jammy node): [...] > I am not sure how many bits of security the EVP_bf_ofb() algorithm is > considered to have, but it seems I need to have "CipherString = > DEFAULT:@SECLEVEL=1" in my override file in order to get past the > "digital envelope routines::unsupported" error during metadata > negotiation. That's weird, why would you need to set that yourself... But very nice work in finding this out! > Does anyone have any suggestions of additional changes to either the > openssl.cnf override file on the Jammy node or the Tinc config files > that would allow Xenial and Jammy nodes to interoperate on the network > while we work to upgrade the all the old network nodes? This is very annoying of course, but I don't see any option but to either upgrade tinc on Xenial or to downgrade tinc's OpenSSL library on Jammy. Upgrading tinc on Xenial might be the easiest option, it means just compiling a newer version of tinc on Xenial that has AES and SHA256 as the default algorithms for meta-connections, and use that instead of the binary from the tinc package that comes with Xenial. I think it should still work with the OpenSSL library provided by Xenial. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: connecting tinc 1.0.36/libssl3 to older nodes?
On Tue, May 03, 2022 at 07:07:08PM -0400, Nathan Stratton Treadway wrote: > I have a small existing Tinc network to which I'm attempting to add a > new node, running Ubuntu Jammy -- but I seem to be hitting some sort of > incompatibility problem between this Tinc node and my existing Tinc > server (which runs tinc 1.0.26/libssl1.0.0). > > Jammy runs Tinc 1.0.36 linked against libssl3 ... but I previously had > this VM connecting successfully to my network when it was running Ubuntu > Focal, which also has Tinc 1.0.36 but linked against libssl1.1 -- so I'm > thinking the problem is is related to the OpenSSL library change. > > I did some searching on the web but did not manage to find any > discussion of this issue in Tinc, so I'm curious if anyone here is aware > of any documentation of configuration changes that might be needed to > enable compatibility between tinc-on-Jammy and older servers? Hi, as far as tinc itself is concerned it should be fine if nodes are linked against different versions of OpenSSL. However, OpenSSL might have deprecated some cryptographic algorithms, and distributions might sometimes change which algorithms to enable/disable when packaging OpenSSL. Are you using the defaults from tinc, or did you specify which encryption and/or authentication algorithm to use by adding "Cipher = ..." or "Digest = ..." statements to any of tinc's configuration files? Can you tell me which distribution and its version you have on the server that runs tinc 1.0.26? I can then try to reproduce the situation. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
[Announcement] Tinc version 1.1pre18 released
With pleasure we announce the release of tinc version 1.1pre18. Here is a summary of the changes in tinc 1.1pre18: * Check all Address statements when making outgoing connections. * Make more variables safe for use in invitations. * Allow "tinc --force join" to accept all variables sent in an invitation. * Make sure the stop command works on Windows if tincd is running in the foreground. * Handle DOS line endings in invitation files. * Double-quote node names in dump graph output. * Prevent large amounts of UDP probes being sent consecutively. * Try harder to reconnect with unreachable nodes. * Generate tinc-up.bat on Windows. * Fix a possible infinite loop when adding Subnets to a running tincd. * Allow a tun/tap filedescriptor to be passed through a UNIX socket. * Use auto-clone tun/tap devices as default on FreeBSD and DragonFlyBSD. Thanks to Fabian Maurer, Ilia Pavlikhin, Maciej S. Szmigiero, Pacien Tran-Girard, Aaron Li, Andreas Rammhold, Rosen Penev, Shengjing Zhu, Werner Schreiber, iczero and leptonyu for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Secrecy of public keys
On Fri, Jun 25, 2021 at 12:30:46PM -0700, Sean Whitton wrote: > On Fri 25 Jun 2021 at 09:13PM +02, Guus Sliepen wrote: > > > The public key should of course never have to be kept secret. > > The new protocol in tinc 1.1 is not vulnerable to this issue. > > > > Note that both the old and new protocol are designed such that the > > public keys are never made public by tinc itself: you couldn't connect > > to a tinc daemon and get it to to tell you the public key, unlike say > > SSH. > > Thank you for your reply. Very helpful. May I ask why the new protocol > refuses to share the public key, if it is truly not a secret? Just that > it's not necessary? It's indeed not necessary, and just adds some extra defense. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Secrecy of public keys
On Thu, Jun 24, 2021 at 10:43:20PM -0700, Sean Whitton wrote: > In the "Authentication protocol" section of the security page on the > Tinc website it says: > > ... there is a man-in-the-middle possible where an attacker that has > the public key of the peers can gain control over one side of the > communication between two peers. The MITM cannot decrypt messages > between peers, but it can send messages to the peer that initiated > the connection. If the MITM knows enough about the VPN, it could > trick peers into sending it packets that it can decrypt. > > This suggests that knowledge of host public keys should be restricted to > hosts which will be members of the network, unlike, e.g., OpenSSH host > keys, the public parts of which are not secrets at all. > > I was wondering whether tinc 1.1 fixes this issue, such that host public > keys cease to be secrets, and do not need to be handled with extra care > when it comes to things like configuration management tools? The public key should of course never have to be kept secret. The new protocol in tinc 1.1 is not vulnerable to this issue. Note that both the old and new protocol are designed such that the public keys are never made public by tinc itself: you couldn't connect to a tinc daemon and get it to to tell you the public key, unlike say SSH. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc on phone
On Tue, Jun 22, 2021 at 10:50:26PM +0200, Erich Eckner wrote:
> recently, someone mentioned on the mailing list, they were running tinc on
> their phone. May I ask, how this can be achieved? I have an android phone
> and would happily integrate it in my existing tinc vpn. Do I need to root
> the phone? Is there some app? Are there some walkthroughs, tutorials or
> other sketches?
There is an app for Android made by Pacien Tran-Girard. The homepage is
here: https://tincapp.pacien.org/. It doesn't need root, and it has
documentation as well.
For iOS, I don't know of any succesful app that doesn't require root.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Mac OS X and utun
On Sun, Jun 06, 2021 at 08:39:08AM +0200, Fredrik Wendt wrote: > These configurations worked though: > > > DeviceType = utun > > #No Device specified > > #This is the configuration I'm using now btw > > > DeviceType = utun > > Device = utun2 # this happened to be the first free number Ah, I should have read this email before answering your previous one! Great that it works. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Mac OS X and utun
On Sat, Jun 05, 2021 at 11:01:44AM +0200, Fredrik Wendt wrote: > I've not gotten tinc to work out of the box with utun. I've only tested the > version provided in the homebrew package (1.0.36), which I installed into > /opt/homebrew (the default when running the M1/arm64 version of homebrew). [...] > root@mbam1 /opt/homebrew/etc/tinc/wendtvpn # cat tinc.conf [...] > Device = utun0 > > root@mbam1 /opt/homebrew/etc/tinc/wendtvpn # tincd -D --debug=8 -n wendtvpn > tincd 1.0.36 starting, debug level 8 > Could not connect utun socket: Resource busy > > Terminating > > Before I go and start compiling things myself (and possibly try to debug > things), is this a route bound to end in a dead end? Is tinc known to work > with utun on Mac OS X Big Sur on M1/Apple Silicon (with or without Rosetta)? The goal is to have it work with utun. However, first check if nothing else is using utun0. Maybe try Device = utun1. > Should I try with 1.1? > arm64 or i386/Rosetta? Yes, please try 1.1. It should compile fine for arm64, no need for Rosetta. > Anything I need to enable (some magic scutil command or similar) to get > utun to work? I don't know about any magic commands unfortunately. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc still alive?
On Fri, May 28, 2021 at 02:16:07PM +0200, ha...@dandy.nl wrote: > I got a new laptop and stap 1 is install tinc and noticed it was still the > same version since 2019. > > So I was just wondering is tinc vpn is still alive? Hi, tinc is alive, but things are going very slowly at the moment. Also not helping is some bots spamming the mailing list for bogus subscription requests, which has caused me to enable manual approval, but there's enough that I've missed some real subscription requests and some messages that were held for moderation. Sorry about that. Some patches have been accumulating in the git repository, I will release a 1.1pre18 this weekend. There are a number of things that need to be done before a 1.1.0 release. If you want to help make this happen, there's a list of things you can do, even things that don't require any programming: - Test tinc 1.1 on all your platforms. Compile it from scratch, and report any warnings or error messages you encounter. - Go through the list of issues on GitHub, and check if you are affected by any of them. If so, add a comment. If you're the original submitter, just mentioning whether it's still affecting you also helps. If there's no patch and you want to have a go at fixing it, go ahead and create a pull request if you have made a patch. See: https://github.com/gsliepen/tinc/issues - Similar, there is a list of open pull requests. Leave a comment if you want it to get attention. You can also try out if the commits still apply and compile correctly, and check if the patches work. See: https://github.com/gsliepen/tinc/pulls Some other issues that need to be done for 1.1.0: - Ensure it works with recent versions of Linux, macOS and Windows. Especially check that it works with the utun driver on macOS, since non-Apple drivers are going to be very hard to use with the latest restrictions. On Windows, check if tinc works with the latest TAP-Windows driver (https://github.com/OpenVPN/tap-windows6). -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
CVE-2019-14899 can potentially affect tinc VPNs
Hello, Researchers have shown that many operating systems, sometimes in default configurations, allow packets to be received on an interface with a destination address that does not match a route that would send return packets back out of that interface. For example, you have a LAN interface which uses the address range 192.168.1.0/24, and a WAN interface with a public IP address. In some configurations, packets received with destination IP address 192.168.1.x on the WAN interface will be accepted and might even be forwarded to LAN interface. This behaviour might be desirable in some cases, especially if you are roaming from one network to another, switching from Ethernet to WiFi, or when you log in to a captive portal, as it allows old connections to stay alive while routes have been changed. However, if an attacker can see encrypted VPN packets and can send packets with arbitrary destination addresses to a machine on the VPN, they can try to guess IP addresses by looking for response packets being sent via the VPN when they guess right. More worryingly, the researches show it is possible in the same way to guess TCP sequence numbers, which could potentially allow an attacker to inject arbitrary data into an existing TCP connection on the VPN, even if they cannot decrypt any of the data being sent back. The attack depends on being able to send these packets in the first place, the operating system accepting them, and then also guessing which open TCP connections to which services are currently going on on the VPN, so it is not a trivial attack, regardless you should try to configure your operating systems to avoid it. In general, you can add firewall rules to block packets with destination IP addresses in the VPN range arriving on WAN interfaces, and possibly block it for anything but the VPN interface itself. On Linux, the kernel has a facility called "reverse-path filtering", which would normally block these packets if it's enabled. Check the contents of /proc/sys/net/ipv4/all/rp_filter and /proc/sys/net/ipv4/default/rp_filter. If it is not 1, the filter is not on or not effective. Writing 1 to these files as root will turn on the filter, but you might need to check if your distribution can set these values at boot time. On Debian-derived distributions, this can be configured in the file /etc/sysctl.conf. VPNs in general could protect against this attack by making traffic analysis more difficult, by making packets all have the same size, and by sending packets at a fixed rate. However, this will result in lower performance, and will use a lot more bandwidth, so it is unlikely many people will want this. See https://seclists.org/oss-sec/2019/q4/122 for the original report. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Warning: old key(s) found and disabled.
On Sun, Nov 24, 2019 at 04:52:41PM -0500, Frank Myhr wrote: > Well, I goofed and entered the wrong network name while trying to set up > keys for a new network: > > # tincd -n existing_net -K > Generating 2048 bits keys: > + p > ..+ q > Done. > Please enter a file to save private RSA key to > [/etc/tinc/existing_net/rsa_key.priv]: > Warning: old key(s) found and disabled. > Please enter a file to save public RSA key to > [/etc/tinc/existing_net/hosts/host_on_existing_net]: ^C > > I realized my error when tinc warned me, thus the ^C. > Now /etc/tinc/existing_net/rsa_key.priv has been replaced, while > /etc/tinc/existing_net/hosts/host_on_existing_net still contains the old > public key. > > When tinc says it "disabled" the old key, did it it in fact *delete* it? No, it did not. The old key is still in rsa_key.priv, between markers that say "BEGIN OLD" and "END OLD". To recover the old key, remove the new key (which has been placed after the old one), and change the words "OLD" to "RSA". > I assume it will lose > access when tinc is restarted unless I fix the config. Correct. I hope this helps! -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Warning: old key(s) found and disabled.
On Sun, Nov 24, 2019 at 06:07:40PM -0500, Frank Myhr wrote:
> Still, I'd prefer tincd to issue a warning and prompt for confirmation
> *before* it proceeds to overwrite an existing key.
It doesn't ever overwrite old keys. And it does print out a warning when
it disables an old key. But I can indeed add a prompt in this case that
asks whether to update the key files or not.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc 1.1pre17 on fedora 30
On Sun, Aug 25, 2019 at 02:41:03PM +0200, Christopher Klinge wrote: > I am trying to run tinc version 1.1pre17 on fedora 30 hosts and I am running > into a problem. Building and starting tinc works just fine. [...] > However, the hosts cannot connect to each other. When checking the logs, the > following appears over and over again, for any combination of hosts: > > Error while connecting to node04 ( port 655): Permission denied That sounds like there is a local firewall rule that blocks outgoing TCP connections to port 655. Either that, or the Address statement in hosts/node04 contains an error, so that it thinks it's a broadcast address. Check if you can manually connect to node04's address port 655 using the socket or telnet commands. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
[Announcement] Tinc version 1.0.36 released
With pleasure we announce the release of tinc versions 1.0.36. Here is a summary of the changes in tinc 1.0.36: * Fix compiling tinc with certain versions of the OpenSSL library. * Fix parsing some IPv6 addresses with :: in them. * Fix GraphDumpFile output to handle node names starting with a digit. * Fix a potential segmentation fault when fragmenting packets. Thanks to Rosen Penev, Quentin Rameau and Werner Schreiber for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Multicast (ICMP6 router solicitation) flood
On Fri, Dec 14, 2018 at 11:13:55PM +0100, Lars Kruse wrote: > I am a happy user of tinc in multiple environments. It is beautiful - thank > you! > > Today I noticed that a network of around 20 nodes suffered from a flood of > packages like the following: > IP6 fe80::e4eb:74b6:57e0:c3e1 > ff02::2: ICMP6, router solicitation, length 8 [...] > Most of the tinc nodes use v1.0.31. Two use v1.0.24 and a single old one is > still at v1.0.19. > (Debian stable, oldstable and oldoldstable) The issue looks like a routing loop. In fact, there was a bug in versions before 1.0.24 that might cause routing loops of broadcast packets, and this router sollicitation message is in fact a broadcast packet. If possible, upgrade to a newer version of Debian. If that's not possible, try installing tinc 1.0.24 from wheezy-backports. > The setup is running unchanged (besides a few nodes being added from time to > time) for a few years. The only non-default setting is "ReplayWindow 32". That is quite certainly not the cause of this issue. > I am quite confident (due to the age and stability of the setup), that this > was > just a rare occasion, that will likely never happen again. > But maybe someone has an idea, whether this is a tinc related issue and if > there is something that could be done to prevent such a situation. I recommend upgrading the node running 1.0.19. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc: Fix compilation without deprecated OpenSSL APIs
On Tue, Dec 18, 2018 at 09:38:13AM +0100, Saverio Proto wrote: > > I received this PR for the tinc package on OpenWrt. > > > > https://github.com/openwrt/packages/pull/7646/files > > > > Not sure if this is something that is better going upstream instead. > > > > Moreover, from a security point of view, is it okay to merge this patch ? The patch looks perfectly fine, I've applied it to tinc's master branch. Thanks for forwarding this to me! -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: subnet flooded with lots of ADD_EDGE request
On Tue, Dec 11, 2018 at 02:36:18PM +0800, Amit Lianson wrote: > We're suffering from sporadic network blockage(read: unable to ping > other nodes) with 1.1-pre17. Before upgrading to the 1.1-pre release, > the same network blockage also manifested itself in a pure 1.0.33 > network. > > The log shows that there are a lot of "Got ADD_EDGE from nodeX > (192.168.0.1 port 655) which does not match existing entry" and it > turns out that the mismatches were cuased by different weight received > by add_edge_h(). > > This network is consists of ~4 hub nodes and 50+ leaf nodes. Sample > hub config: [...] Could you send me the output of "tincctl -n dump graph"? That would help me to try to reproduce the problem. Also, if you could do "tincctl -n log 5 >logfile" when the issue occurs, on the node that gives those "Got ADD_EDGE which does not match existing entry" messages, and let it run for a few seconds before stopping the logging, and send me the resulting logfile. > Back to the days of pure 1.0.33 nodes, if the network suddenly > fails(users will see tincd CPU usage goes 50%+ and unable to get ping > response from the other nodes), we can simply shutdown the hub nodes, > wait for a few minutes and then restart the hub nodes to get the > network back to normal; however, 1.1-pre release seems to autoconnect > to non-hub hosts based on the information found in /etc/tinc/hosts, which > means that the hub-restarting trick won't work. Additionally, apart > from high CPU usage, 1.1-pre tincd also starts hogging memory until > Linux OOM kills the process(memory leakage perhaps?). You can disable the autoconnect feature by adding "AutoConnect = no" to tinc.conf, unfortunately you'd have to do that on all nodes. And it doesn't solve the actual problem. If it's hogging memory, that definitely points to a memory leak. >Given that many of our leaf nodes are behind NAT thus there's no > direct connection to them expect tinc tunnel, I'm wondering about if > there's any way to bring the network back to work without shutting > down all nodes? Moreover, is there any better way to pin-point the > offending nodes that introduced this symptom? I hope the output from the "log 5" command will shed some more light on the issue, as it will show which nodes the offending ADD_EDGE belongs to. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc invite options
On Wed, Oct 10, 2018 at 01:55:28PM +0200, Wouter Verstraeten wrote: > We are trying the Tinc invites to let nodes join the network. > > This is working as described but we want to push some configuration for > some nodes but this seemed not to be working. [...] > We wanted to add “TunnelServer = yes” to the invitation hoping Tinc would > know to put it into the tinc.conf file. > > But thinc told us it did not understand the parameter. > > Do we do something wrong, or are not all “experimental” features supported > in the invitation files? Actually, only a subset of the options are considered to be safe to be used for invitation files. These are: AutoConnect, Broadcast, BroadcastSubnet, ConnectTo, Mode, Subnet and Weight. Many options don't make sense to push in an invitation, but the list could perhaps by extended by some options, such as TunnelServer, StrictSubnets, and some others. I've also had a request to support the --force option for joins, to allow any statement to be pushed in an invitation. I'll add these things and update the documentation in the next release. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
[Announcement] Tinc version 1.0.35 and 1.1pre17 released
Because of security vulnerabilities in tinc that have recently been discovered, we hereby release tinc versions 1.0.35 and 1.1pre17. Here is a summary of the changes in tinc 1.0.35: * Prevent oracle attacks (CVE-2018-16737, CVE-2018-16738). * Prevent a MITM from forcing a NULL cipher for UDP (CVE-2018-16758). Here is a summery of the changes in tinc 1.1pre17: * Prevent oracle attacks in the legacy protocol (CVE-2018-16737, CVE-2018-16738). * AutoConnect is now enabled by default. * Per-node network traffic statistics are now shown in the output of "info" and "dump nodes" commands. Thanks to Michael Yonli for auditing tinc and reporting the vulnerabilities. Thanks to volth and Rafael Sadowski for their contributions to version 1.1pre17 of tinc. Michael Yonli discovered two security flaws. The first is an issue with the implementation of the authentication protocol used in tinc 1.0, which allows a remote attacker to establish an authenticated connection with a node in the VPN, and send messages one-way. In tinc 1.0.29 and earlier, this is unfortunately trivial to exploit. In tinc 1.0.30 to 1.0.34, the mitigations implemented for the Sweet32 attack also make this attack much harder, but in principle still possible. This is fixed in tinc 1.0.35. The second issue allows a man-in-the-middle that has intercepted the TCP connection between two nodes, to potentially force one of the nodes to start sending unencrypted UDP packets. This is also fixed in tinc 1.0.35. The new protocol used in tinc 1.1 is not affected by these vulnerabilities. However, since it is backwards compatible with tinc 1.0, it uses the legacy protocol when communicating with tinc 1.0 nodes. Tinc 1.1pre17 fixes the first issue, and it wasn't vulnerable to the second issue to begin with. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: 1.0 or 1.1pre?
On Thu, Jun 28, 2018 at 01:36:55PM +1000, Hamish Moffatt wrote: > I just downgraded one of my other devices to 1.0 (1.0.34) to see if this was > going to work, and it doesn't connect. The master is logging: > > Jun 27 20:27:28 rs1 tincd[3169]: Peer dbtest3 > (2400:8901::f03c:91ff:fe2c:2d7e port 48389) tries to roll back protocol > version to 17.0 > Jun 27 20:27:28 rs1 tincd[3169]: Error while processing ID from dbtest3 > (2400:8901::f03c:91ff:fe2c:2d7e port 48389) This is a feature. If you want to allow dbtest3 to connect to the 1.1pre15 nodes, then you manually need to remove the Ed25519PublicKey from hosts/dbtest3 on the 1.1pre15 nodes, or add "ExperimentalProtocol = no" to the tinc.conf on the 1.1pre15 nodes to have them use the old protocol. Of course you can use the CLI for this, for example to remove the Ed25519 key: tinc -n del dbtest3.Ed25519PublicKey -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
[Announcement] Tinc version 1.1pre16 released
With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system. * Added a cache of recently seen addresses of peers. * Add support for --runstatedir to the configure script. * Fixed linking with libncurses on some distributions. * Automatically disable PMTUDiscovery when TCPOnly is enabled. * Fixed removing the tinc service on Windows in some situations. Thanks to Todd C. Miller, Etienne Dechamps, Daniel Lublin, Gjergji Ramku, Mike Sullivan and Oliver Freyermuth for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: iproute2 problems
On Tue, Jun 12, 2018 at 05:11:44PM +0700, Robert Horgan wrote: > Trying to connect to db1 (10.130.39.180 port 655) > Timeout from db1 (10.130.39.180 port 655) during authentication > Could not set up a meta connection to db1 That means it tried to connect to db1 but either the TCP connection itself did not work out, or there was indeed a timeout during authentication. However, the "timeout during authentication" will also appear if the initial TCP connection timed out. > db1 firewall is OK (existing tinc traffic connecting and PF rule for this > server in place) and I wonder whether the message Are you sure? What happens if you manually telnet/socket 10.130.39.180 655 from web3? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
[Announcement] Tinc version 1.0.34 released
With pleasure we announce the release of tinc versions 1.0.34. Here is a summary of the changes in tinc 1.0.34: * Fix a potential segmentation fault when connecting to an IPv6 peer via a proxy. * Minor improvements to the build system. * Make the systemd service file identical to the one from the 1.1 branch. * Fix a potential problem causing IPv4 sockets to not work on macOS. Thanks to Maximilian Stein and Wang Liu Shuai for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: iproute2 problems
On Mon, Jun 11, 2018 at 08:43:26AM +0700, Robert Horgan wrote: > Recently I added two more Ubuntu 18.04 servers at the same location and > attempted to link them to the Tinc mesh already established. The 18.04 > servers do not allow me to use the net-tools ipconfig command and so I have > adapted my tinc-up commands to use iproute2 commands. > > #!/bin/sh > # tinc-up > ip tuntap add dev $INTERFACE mode tun > ip addr add 10.0.0.3/24 dev $INTERFACE > ip link set dev $INTERFACE up > > However, when I run this command I get the error > Error: either "name" is duplicate, or "tun" is a garbage. > Command line is not complete. Try option "help" > Cannot find device "up" You don't need to create a tuntap interface yourself, tinc will do this for you. So you can just omit the whole "ip tuntap add ..." line. However, the error messages suggest that $INTERFACE is empty, which is weird... Did you call tinc-up manually or does this also happen when you start tinc using "tincd -n vpn -d -D"? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Cipher=none seems to be not working
On Wed, May 23, 2018 at 01:39:51PM +0200, Kevin Schmitz wrote: > 2018-05-23 12:08:27 tinc.backbone[14746]: tincd 1.0.31 starting, debug level > 5 > 2018-05-23 12:08:27 tinc.backbone[14746]: Got fatal signal 11 (Segmentation > fault) > 2018-05-23 12:08:27 tinc.backbone[14746]: Trying to re-execute in 5 > seconds... This is a known bug that was fixed in tinc version 1.0.32. If possible, please upgrade to the latest version of tinc (1.0.33). If you are using a distribution package, then please ask the package maintainer to update the package or to backport the fix. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Slow Speed
On Mon, Apr 30, 2018 at 10:54:22AM +0200, mailmant...@mobfunk.de wrote: > I´m using Tinc for several years, but I didn´t fix a performance problem. > > There a about 20 nodes in this network. > > Master: > > 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) > > tinc.conf: > > Name = TincKnoten12 > AddressFamily = ipv4 > Interface = tun > ProcessPriority=high > mode = router > #DirectOnly = no > Compression=0 > PMTUDiscovery = yes > #IndirectData = yes > #ReplayWindow = 64 > #ConnectTo = TincKnoten1 > GraphDumpFile = /tmp/tinc-graph > LocalDiscovery = yes > ClampMSS = yes > PMTU = 1400 > #DirectOnly=yes > #IndirectData=yes > Cipher=AES-128-CBC > #TCPOnly=yes > > > mac:10.0.0.20 (1gig directly to our backbone via mpls from out office-vlan) > > Name=TincKnoten20 > AddressFamily = ipv4 > Device = /dev/tap0 > ConnectTo = TincKnoten12 > ProcessPriority=high > mode = router > #DirectOnly = no > Compression=0 > Cipher=AES-128-CBC > IndirectData = yes > #ReplayWindow = 64 > ClampMSS = yes > PMTU = 1400 > PMTUDiscovery = yes > > frechly installed debian 10.0.0.27 (50/10MBit DSL Access): > > Name=TincKnoten27 > AddressFamily=ipv4 > Device=/dev/net/tun > ConnectTo = TincKnoten12 > LocalDiscovery = yes > AddressFamily = ipv4 > Compression=0 > ClampMSS = yes > Cipher=AES-128-CBC > ProcessPriority=high > mode = router > PMTUDiscovery = yes > > > Test with scp: > > 10.0.0.20->10.0.0.12 7.8MegaByte/s (good enough) > 10.0.0.20->10.0.0.27 700kByte (slow) > 10.0.0.12-> 10.0.0.20 26MegaByte > 10.0.0.12 -> 10.0.0.27 700kByte (slow, should be 10mBit) > 10.0.0.27 -> 10.0.0.20 700kByte (slow) > 10.0.0.27 -> 10.0.0.12 1MegaByte/s (Linespeed 10mBit->fine) There are several possible reasons why you may not get the full speed that you think you should get. For DSL: the quality of your line might not have a constant quality. Unless your line is rated for much higher speeds, don't expect to get the full speed promised by your ISP. However, since you are getting the full 10 Mbit/s to the datacenter, it might be that this is not the problem. Another reason for lower speeds is packet loss. With a single TCP connection (like you have with scp), packet loss might be mistaken for/caused by congestion, and the speed will drop. Some ISPs might also drop packets on purpose, especially if it looks like undesired traffic. It is not uncommon for some ISPs to drop a significant percentage of UDP packets, in order to make the quality of VoIP calls go down. As you hinted, MTU might be a problem. But tinc tries to detect the path MTU and will normally adjust the size of packets accordingly. Lastly, tinc will normally use UDP between peers, but if that is not possible for some reason (because of firewalls or some forms of NAT), it will fall back to using TCP. This can be much slower. All the slow connections you listed involve 10.0.0.27, so it seems like the issue is there, or with an ISP somewhere along the path to 10.0.0.27. There is nothing in your configuration that I can see that is wrong. You might try to change the MTU, the best way to force a lower MTU is to set a lower MTU value on the tun interface, for example by adding this to your tinc-up script: ip link set $INTERFACE mtu 1400 You can also check with tcpdump on your LAN interface if packets from tinc are being fragmented or not, and whether tinc is predominantly using UDP or TCP when you are running scp. > There a much more nodes (with the same master 10.0.0.12) and the same > speed-problemes on different sites (with 1-2 old openwrt-routers with very > old tinc-versions). > > I think the problem is mtu related. > > How can I improve the speed? The cpu-speed on the computers should by high > enough. Well, for OpenWRT routers the CPU speed might not be enough; you will have both tinc and scp doing encryption. The easy way to check this is to run top and check the CPU usage of tinc and scp. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc starts too early on boot
On Mon, Apr 16, 2018 at 09:10:02AM +1000, Hamish Moffatt wrote: > I have a bunch of Debian stretch machines with systemd where I find that > tinc starts too early during boot, and fails to work. > > Typically it is running, but printing out > > Apr 14 00:53:41 db7 tinc[3077]: Can't write to Linux tun/tap device (tun > mode) /dev/net/tun: Input/output error [...] > Apr 16 06:54:43 dbtest3 tinc[3206]: tincd 1.1pre14 (Jun 5 2017 01:24:43) > starting, debug level 0 > Apr 16 06:54:43 dbtest3 tinc[3206]: /dev/net/tun is a Linux tun/tap device > (tun mode) > Apr 16 06:54:43 dbtest3 tinc[3206]: Error starting /usr/sbin/tincd > Apr 16 06:54:43 dbtest3 tinc[3206]: SIOCSIFADDR: No such device > Apr 16 06:54:43 dbtest3 tinc[3206]: rsvpn: ERROR while getting interface > flags: No such device > Apr 16 06:54:43 dbtest3 tinc[3206]: SIOCSIFNETMASK: No such device > Apr 16 06:54:43 dbtest3 tinc[3206]: SIOCADDRT: No such device > Apr 16 06:54:43 dbtest3 tinc[3206]: SIOCADDRT: No such device That sounds like tinc's tun interface is not being configured correctly. Can you show us your tinc-up script? > The tinc.service file says that tinc should start after networking > (After=network.target). I wonder if After=network-online.target might be > better? As defined by > https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ > > I changed my local copy and tinc came up on boot successfully. Hm, tinc itself should handle the network not being online just fine. It will automatically retry after a while if it cannot make any outgoing connections. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Relaying some UDP traffic through tinc?
On Thu, Apr 12, 2018 at 11:57:27PM +0200, Alex Corcoles wrote: > I've got a four site site-to-site tinc mesh working nicely. I have the > following systems at two of those sites: > > 10.a.a.2: Linux box running tinc and DHCP/DNS for site A > 10.a.a.dhcp: Windows desktop with a GPU > 10.b.b.2: Linux box running tinc and DHCP/DNS for site B > 10.b.b.dhcp: Linux laptop > > I'd like to use Steam In-Home Streaming to game in the laptop streaming > from the desktop. The Steam protocol is not well documented, but it > seems to rely on UDP broadcasts to x.x.x.127 UDP port 27036 to discover > remote nodes. Tinc itself supports UDP broadcast packets. However, in router mode, it will only treat 255.255.255.255/32 and 224.0.0.0/4 as broadcast address ranges. If you are using tinc 1.1pre11 or later, you can add the following to your tinc.conf files: BroadcastSubnet = x.x.x.127 -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Route certain trafic via a tinc node that is not directly connected.
On Tue, Apr 10, 2018 at 03:36:08PM +0200, Hans de Groot wrote: > hosta <--> hostb <--> hostc > > Hosta and hostc are not directly connected via tinc. But both are conncted > via hostb (I called my network tincnet). This works fine I can ssh from > hosta to hostc and vice versa without any problems. > > hostc is in a whitelisted iprange at some service provider. > > I need hosta to talk to a certain ip (lets call it ipaddressx) via hostc. > > I added the iptables mangle rule to mark all traffic to ipaddressx at port > 700. > > -A OUTPUT -p 6 -m tcp -d ipaddressx/255.255.255.255 --dport 700 -j MARK > --set-mark 0x1 > > I added: > ip route add default via iphostc dev tincnet table hostc > ip rule add from 0.0.0.0/0 fwmark 1 table hostc If you are running tinc in router mode (which is the default), then the "via iphostc" option does not have any effect. The packets will go to dev tincnet, but there is nothing in the header of IP packets that contains the address of the gateway. Also, if you are using router mode, then you must inform tinc about which peer to send packets with destination address ipaddressx to. So you can add "Subnet = ipaddressx/" to hostc's hosts/hostc. But tinc only routes on address, not on ports. > Now when I try this: > > traceroute -T -n ipaddressx -p 700 > > The route goes via the ip of hostb and not via the ip of hostc as I would > have expected. There are two possibilities for this: one is that tinc thinks the packets with destination address ipaddressx should go to hostb (because of what is in the Subnet statements), the other is that hosta and hostc cannot directly communicate with each other, and traffic is routed via hostb, and you have Forwarding = kernel in your tinc.conf. The latter will force the packets to be sent to the tun interface on hostb, and if you don't have any rules on hostb to send packets for ipaddressx port 700 to hostc, they will not be forwarded the way you want. > A weird thing is when I try the add route with any ip in the tincnet subnet > the route gets added even if that ip is not in use and all traffic still > goes via the ip of hostb. > ie: ip route add default via any_ip_in_the_tincnet_subnet dev tincnet table > hostc Again, in router mode, the "via ..." option has no effect at all. > Is it tincd at hostb that intercepts the traffic actually meant for hostc > and thinks it's meant for hostb and rewrites stuff automaticaly? Or am I > missing something in the ip route / ip rules part? Tinc itself does not rewrite anything. > But I really would like to understand how to do this via mangle/fwmark and > ip route / ip rule way. It would help if you could show us your tinc.conf from hostb, and all hosts/* files, so we can check how you configured tinc exactly. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: "firewall mark" (Linux only)
On Thu, Mar 22, 2018 at 09:29:04AM +, Clemens Schrimpe wrote: > I was about to add code to allow for specifying a „firewall mark“ for the > traffic generated by tinc in order to make it easier to be policy routed and > just wanted to check if somebody else might be „on it“ already. > > Was this discussed somewhere else already? Is it even already on the > todo-list? Yes, it was discussed before, and to my shock and horror a patch was made by Olivier Tirat in 2016 that I seem to have totally forgotten about: https://www.tinc-vpn.org/pipermail/tinc/2016-October/004679.html I have committed a new patch for tinc 1.1 that does the same, the difference with Olivier's patch is that it is configured using the new "FWMark" option in tinc.conf. My apologies to Olivier! -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Help on a Nat To Nat soluction - tinc servers won't ping remote clients
On Sat, Mar 31, 2018 at 12:00:57PM +, John Radley (yahoo) wrote: > I have a three tinc server setup, similar to "4.3 How Connections > Work" using the configuration mostly like > http://ostolc.org/site-to-site-vpn-with-tinc.html > > The clients (Ubuntus, Debians and Windows 10s) can all ping (and SSH) > to each other remotely. As far as that is concerned it's working great > - thanks so much for some great software. > > However, on each of the Tinc servers (A and C) neither of them can > ping other remote clients. Of course, A and C can ping each other. If > I use tcpdump -nni tun0 icmpI can see the echo packets leave the > server, and on a remote client see the request received and the reply > sent. However the server never gets the reply. It seems that on each > server there is no internal routing between enp1s0 and tun0 for IPs > that are not server IPs. I guess I can live with such a limitation, > but would still like to know why!! Tinc itself doesn't take of that routing outside of the VPN itself, so it is up to you to configure it correctly. > TINC-UP > ip link set $INTERFACE up > ip addr add 192.168.20.3/24 dev $INTERFACE > route add -net 192.168.14.0/24 gw 192.168.20.3 > route add -net 192.168.6.0/24 gw 192.168.4.99 First, if you are already using "ip" to assign an address, then instead of the "route" command, use the "ip route" command to configure extra routes, like so: ip route add 192.168.14.0/24 via 192.168.20.3 ip route add 192.168.6.0/24 via 192.168.4.99 Note that the first route command is equivalent to: ip route add 192.168.14.0/24 dev $INTERFACE > ROUTE TABLE on A > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > default 192.168.4.1 0.0.0.0 UG 100 0 0 enp1s0 > link-local * 255.255.0.0 U 1000 0 0 enp1s0 > 192.168.4.0 * 255.255.255.0 U 100 0 0 enp1s0 > 192.168.6.0 192.168.4.99 255.255.255.0 UG 0 0 0 enp1s0 > 192.168.14.0 192.168.20.3 255.255.255.0 UG 0 0 0 tun0 > 192.168.20.0 * 255.255.255.0 U 0 0 0 tun0 [...] > Net 192.168.4.0 is the A local network > IP of A is 192.168.4.30, IP of C is 192.168.14.20 [...] > Only thing wrong is, for example on A, ping 192.168.14.60 does not work > On C, ping 192.168.4.26 does not work The problem is most likely with the hosts 192.168.14.60 and 192.168.4.26. What does their routing table look like? If 192.168.4.26 just has: Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.4.1 0.0.0.0 UG 100 0 0 enp1s0 link-local * 255.255.0.0 U 1000 0 0 enp1s0 192.168.4.0 * 255.255.255.0 U 100 0 0 enp1s0 Then packets for 192.168.20.* or 192.168.14.* will go the the default gateway 192.168.4.1, and will not go to your host running tinc. A ping packet from C might reach host 192.168.14.26, but that host will send the return packet in the wrong direction. To fix this, you must either add a route that looks like this to each host on A: 192.168.14.0 192.168.4.30 255.255.255.0 UG 0 0 0 enp1s0 Or you have to tell the router (192.168.4.1) that packets for 192.168.14.0/24 should be forwarded to 192.168.4.30. And you have to do something similar on the other sites. > But on clients 192.168.14.60 and 192.168.4.26 can ping each other. Ok, that is weird... if those can ping each other, they should both be able to ping A and C as well. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: issues connecting to other working sites.
On Thu, Mar 29, 2018 at 09:44:03PM +, Chris . wrote: > 2018-03-15 22:57:36 tinc.NETNAME[871]: Read packet of 74 bytes from Linux > tun/tap device (tun mode) > 2018-03-15 22:57:36 tinc.NETNAME[871]: Sending packet of 74 bytes to > pfsense201 (PFSENSE201-PUBLICIP port 655) > 2018-03-15 22:57:41 tinc.NETNAME[871]: Read packet of 74 bytes from Linux > tun/tap device (tun mode) > 2018-03-15 22:57:41 tinc.NETNAME[871]: Sending packet of 74 bytes to > pfsense201 (PFSENSE201-PUBLICIP port 655) > 2018-03-15 22:57:46 tinc.NETNAME[871]: Read packet of 74 bytes from Linux > tun/tap device (tun mode) > 2018-03-15 22:57:46 tinc.NETNAME[871]: Sending packet of 74 bytes to > pfsense201 (PFSENSE201-PUBLICIP port 655) [...] This looks like the tinc daemon is reading packets from the tun/tap device correctly, and is sending them to pfsense201, however there is no response from pfsense201. You should look at the logs on pfsense201 to find out what happens with those packets. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc and android 6
On Thu, Mar 29, 2018 at 01:19:48PM +0200, Perry Couprie wrote: > I compiled tinc 1.1pre14 for android 6, then i created the config for tinc. > > When i try to start tinc, it can not connect to /dev/tun > > I have looked for information on android/tinc and /dev/tun. > > The information i found is about system permissions, how can i start tinc on > android whitout rooting my android tablet ? > > And set extra routing to the tinc interface. Indeed, direct access to /dev/tun requires root privileges. However, Android has a VPN API that allows an app to request a tun interface, and configure it. The filedescriptor for this interface can then be handed to tincd. Unfortunately, this API is Java-only, so this is not something that can easily be called from tinc's C codebase. That said, have a look at this Android app that probably does what you want: http://tincapp.pacien.org/ -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: site-site vpn setup..
On Sat, Mar 24, 2018 at 02:16:20PM -0700, al so wrote: > > Is there any quickstart guide to setup site-to-site VPN using Tinc 1.1 > > pre-rel? You can find an example of a site-to-site VPN with four sites here: http://tinc-vpn.org/documentation/Example-configuration.html > > Assuming I have two routers at two sites running tinc vpn along with > > routing feature. If you only have two sites, then just look at the example configuration for "Branch A" and "Branch B" in the page I linked, and ignore the other two sites. > > Once I setup manually and validate the connection, I want to automate > > using REST APIs. Tinc does not expose any REST APIs. With tinc 1.1, you can use the command line tool to automate things though, see: http://tinc-vpn.org/documentation-1.1/Controlling-tinc.html -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Port numbers
On Thu, Mar 22, 2018 at 06:31:27AM +, Peter Whisker wrote: > In the case where you have access to TCP and UDP outbound initiated > connections and no choice of the port numbers due to the firewall setup it > would be very useful to be able to specify both the UDP and TCP ports that > tinc uses separately. Currently in 1.0 I end up with a TCP based VPN > because I can't tell tinc which UDP port to connect to the remote side on. > Could this be added to 1.1? If you really cannot have the same port number for both TCP and UDP, then the workaround is to add this to tinc.conf: ListenAddress = * ListenAddress = * And in the host config file of that node: Port = Address = This works for both tinc 1.0 and 1.1. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc deployments in the USA
On Tue, Mar 20, 2018 at 12:53:55PM -0700, al so wrote: > Are there any Tinc deployments in the USA in Medium sized businesses and > small Enterprises? Yes. However, VPNs are Virtual *Private* Networks, and I don't know of any company that publicly states what VPN technology they use (unless it's a company that sells VPN software/access of course). So I will not name any companies, although if employees of such companies that are on this mailing list want to say so, that's fine of course. > Use case is to provide site-to-site VPN functionality. Site-to-site networks are supported by tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: typo in the docs?
On Tue, Mar 20, 2018 at 05:15:28PM +0200, ST wrote: > Here > https://www.tinc-vpn.org/documentation/Example-configuration.html#Example-configuration > > BranchA would be configured like this: > > In /etc/tinc/company/tinc-up: > > # Real interface of internal network: > # ifconfig eth0 10.1.54.1 netmask 255.255.0.0 > > ifconfig $INTERFACE 10.1.54.1 netmask 255.0.0.0 > > Is netmask 255.255.0.0 or 255.0.0.0 ? The documentation is correct, the netmask in that last line is 255.0.0.0. The example is for a VPN with 4 sites, each has a 10.x.0.0/16 out of the 10.0.0.0/8 range. By setting the netmask on the VPN interface to 255.0.0.0, all packets for 10.0.0.0/8 are automatically being routed to the VPN interface. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: issues connecting in other sites
On Thu, Mar 15, 2018 at 03:41:00PM +, Chris . wrote: > I admit that I am not familiar with Tinc very well, but have Tinc running at > approximately 20 sites and functioning as a mesh vpn/network. I am having > issues adding an additional site as it will not communicate with the rest. I > have taken the firmware of one and flashed it on another router to make it > duplicate and then tested it working but when I change the hostname, and IP > to what we need it to be (in this case 172.16.100.0) it no longer > communicates with the rest of the network even though I have the same public > key (they all have the same key) as well as adding it to the host folder and > tinc config file on every other router. Am I missing something? The current > system seems to be working now but having issues to add new. I suspect you do have an error in your configuration somewhere. Either on the new node, or in the other node(s) that will have connections with the new node. Check for typos. > Partial file contents of /etc/config/tinc > > config tinc-net NETNAME > option enabled 1 > option logfile /tmp/log/tinc.log > option debug 1 > option AddressFamily ipv4 > > list ConnectTo=pfsense2 > list ConnectTo=pfsense4 > list ConnectTo=pfsense12 > list ConnectTo=pfsense201 > list ConnectTo=pfsense11 > list ConnectTo=pfsense1 > list ConnectTo=pfsense19 > list ConnectTo=pfsense7 > list ConnectTo pfsense26 > list ConnectTo pfsense27 > list ConnectTo pfsense100 > option Name pfsense16 I'm no pfsense expert. But why do some lines have ConnectTo=pfsense with a = sign between ConnectTo and pfsense, and other lines have a space instead of the =? > To be clear (also not sure how it works without it) but tinc.conf is not in > the /etc/tinc/NETNAME folder. We can see it in the /tmp/tinc/NETNAME > directory only and its contents are below. > File contents of /tmp/tinc/NETNAME/tinc.conf (this is on the pfsense16 unit > with subnet 172.16.16.0) > AddressFamily = ipv4 > ConnectTo = pfsense26 > ConnectTo = pfsense27 > Name = pfsense16 I see only two ConnectTo's here, ConnectTo = pfsense100 is missing. Could that be the problem? -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc blocking on DNS requests?
On Wed, Mar 14, 2018 at 03:45:50PM +0100, codl wrote: > I have a tinc network of hosts composed of two hosts on a network, let's call > them A and B, and a number of remote hosts over the internet, that I'll > collectively call C. A and B both ConnectTo each other and to C > > The config files for C refer to them by DNS hostname, while A and B have > plain IP addresses. This will be relevant > > When A and B are cut off from the internet, I'd expect A and B to still be > able to talk to each other, but in practice it works for a time and then > stops working for a few minutes, comes back for a time, etc. Modifying the > host config files for C on both A and B to point at IP addresses rather than > DNS hosts seems to fix it. > > I suspect that tinc is waiting for DNS requests to time out and not routing > any packets in the meantime That's indeed the problem. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Fwd: Tinc: performance
On Wed, Mar 14, 2018 at 08:42:20AM -0700, al so wrote: > Is there performance issue with Tinc compared to alternatives? Performance depends on many variables, it is impossible to say "A is nn% faster/slower than alternative B". The best way to check which alternative has the best performance is to try them out yourself. > Is it still single threaded? Yes. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How to set up an extensible VPN with VirtualBox VMs as nodes
On Wed, Mar 14, 2018 at 07:48:13PM +0200, ST wrote: > > If you are not interested in the mesh functionality that tinc provides, > > then both are probably similar in ease of setup and maintenance. > > If so - we'll choose tinc, as we might need this functionality in > future, who knows... As far as I understand it means, i.a., that tinc > provides the ability to run several central servers, while OpenVPN only > one, thus creating a danger of VPN failure if this single central server > goes down. Correct? I'm sure you can set up multiple central servers with OpenVPN with failover if one goes down as well. However, it is probably easier with tinc, since it will handle any topology you want without having to do anything special. > > If you just want to have access to the Linux VM, then you don't need > > bridging or proxy ARP at all. The Linux VM will have its own unique IP > > address on the VPN, and you will be able to access it directly via > > whatever protocol you want without needing to do anything. > > Yes, that is exactly what we want. But will this go through all possible > NATs/Firewalls/etc. of the users behind home routers? The way TeamViewer > does? Yes, as long as your central servers are not behind a NAT, the tinc daemons in the Linux VMs will be able to connect to them without problems, and once they are connected any traffic back to them via the VPN will just work. Unless there are firewalls that block the outgoing TCP connections from tinc, you don't have to do anything special. > Could you, please, post a link to relevant tinc documentation and > examples of how to implement this particular use case?... Thank you! Well this is kind of the trivial case, so there is nothing special in the documentation about this use case. > > If you are certain that the only way you can access the VM is via the > > VPN, then in principle you could use the same key/password for SSH. But > > I would personally not take that risk. I would just have all members' > > public SSH key in .ssh/authorized_keys on the VM. This file can just be > > the same on all VMs. So if a member's access is revoked, I'd remove his > > public key from the master copy of the authorized_keys file, and > > redistribute it to all VMs. > > The tricky part is the redistribution - how would you do it? One of two ways: 1) have a cron job in the Linux VMs that regularly tries to download a new authorized_keys file from one of the central servers via the VPN, or 2) have a cron job on the central servers that rsyncs/scps the master authorized_keys files to all VPN nodes. The second option is perhaps a bit harder to set up; the cron job should read the tinc configuration files to find out which nodes there are. The advantage is that you can more easily check that the update of each node was succesful. > I started to read about link-local IP6 addresses. Is it possible to > assign a network interface several such address (since one it has > already)? I'll have to figure out how to do this on Windows 10. On Linux that should be no problem at all, on Windows you might have to use the netsh command to add addresses to interfaces. See: https://tinc-vpn.org/documentation/Interface-configuration.html -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How to set up an extensible VPN with VirtualBox VMs as nodes
ocal IPs should not cause any > problems, I think. You do have to be careful about which IP address you are going to use. You have no control over the IP address that the Windows hosts are going to get from the ISP they are connected to. They can get a public IP address, or they could get any IP address from the private ranges such as 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. If possible, the best way to ensure you will not have an address conflict is to use IPv6 for the host-guest network. Then you can use link-local addresses which for sure will not conflict with anything, or if that is not an option, assign a Unique Local Address, see: https://en.wikipedia.org/wiki/Unique_local_address -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How to set up an extensible VPN with VirtualBox VMs as nodes
On Mon, Mar 12, 2018 at 06:46:24PM +0200, ST wrote: > We have not so tech-savvy colleagues in different locations around the > world who now use Windows 10 and need access to Linux (Debian 9). Linux > will be provided in form of VirtualBox VMs. We, the technical support > team, need to have access to the guest VMs (via SSH and occasionally as > remote desktop) and to the host (through the guest while VM runs in > bridged mode; via Windows 10 built in SSH Server). > > What is the best approach to create such an infrastructure in a > flexible, secure and efficient way, so that: > > (A) adding/removing an employee requires minimal effort, > (B) adding/removing a tech-support team member requires minimal effort. > > While we don't have experience with VPNs we assume that it's better to > invest in setting up a VPN (with VMs as its nodes) once rather than > enable port forwarding on all possible router models in order to get > access to the VMs. > > 1. What open-source VPN software would you recommend for such a case? We > are considering [Tinc](https://www.tinc-vpn.org) as it seems to be > rather flexible and provides an easy way to add new nodes thus helping > us to achieve the above mentioned goal A. Tinc should work just fine. However, if you don't really need the mesh network functionality, and just need the VMs to connect back to a central server, then other open-source VPN software, such as OpenVPN, would work as well. > 2. If yes, in which mode should we run Tinc - > [bridge](https://www.tinc-vpn.org/examples/bridging/) or [proxy > ARP](https://www.tinc-vpn.org/examples/proxy-arp/)? You might not need either of those modes. Plain routing can probably also work in your situation, perhaps in combination with a NAT firewall rule in the VM. > 3. How should we manage authentication of the tech support team in order > to achieve the goal B? Asymmetric keys? One pair for all or a pair for > each member? Maybe passwords? Tinc only supports assymetric keys. You should use one pair for each node in the VPN (ie, each VM gets its own pair, the central server(s) also each get their own pair, and if each tech-support team member has its own VPN node they also get their own unique pairs). I strongly discourage using the same keypair for more than one node. In your case, this is also very important to allow revoking access to the VPN for employees and/or tech-support members; if you reuse keys then they can simply use a copy of their key to impersonate other nodes. > 4. In order to get an easy (to remember) access to the host from the > guest via built in SSH Server on all machines we probably need to give > all hosts the same IP in the Network bridge mode. Are there other > important configuration tricks for host and/or the VM appliance that you > can think of? If each Windows host has the same IP address on the VPN, it will be impossible to directly SSH to a specific Windows host directly from other VPN nodes. However, since I assume the Linux VMs will get unique IP addresses in the VPN, you can SSH into the Linux VM, and from there SSH to the host. That way, you don't have to consider whether to route/bridge/proxy-arp at all. If you do want to SSH directly to the Windows host, but still want a fixed IP address, then the best solution I can think of is to have a port forwarding firewall rule in each Linux VM that redirect connections to a certain port (say, 222) to the SSH port of the Windows host. Then, you can just use "ssh -p 222 ". -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: networking remote systems over unknown ip's
On Mon, Jan 15, 2018 at 01:56:11AM -0500, waltfea...@gmail.com wrote: > I am making some systems that are going to be donated to different > organizations and I want the kids to be able to share programs they > write with each other on the different disk automatically securely. Can > I network these systems without knowing individual ip's and not > touching firewalls. I was thinking maybe I could use a dns service like > duckdns to substitute ip's with comp1.duckdns.org, comp2.duckdns.org, > etc. > Is this even possible/advisable using tinc? Yes. > I am guessing I would minimally need to know the internal private ip's > to avoid conflicts. Indeed, you need to carefully choose an address range for your tinc network so that there are no conflicts with the local network of any of the peers. If possible, try to use IPv6. With RFC 4193, you can generate a unique private address range that is virtually certain to not conflict with anything. Also, you will have a huge address space to work with. You might also be able to acquire a globally unique address range for your project. As for the external addresses of the systems: there is no need for all nodes in the VPN to know the external address of all other nodes up front. Also, you can use hostnames instead of numeric addresses so indeed, if you have a DNS zone set up you can make use of that. As long as you have one or more central nodes with a known IP address or hostname that other nodes can connect to, you do not need to know the external IP addresses of any of the other nodes. As soon as tinc daemons connect to the central nodes, they will learn about each other's addresses, and will use this information to connect to each other directly, if possible. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc routing question
On Wed, Jan 10, 2018 at 11:29:22AM +0100, cr0n wrote: > Meta connection graph: > > A – B – C – D > │ │ > └─ E ───┘ > > Node configuration: > > • StrictSubnets = yes > • AutoConnect = yes > • B has Forwarding = internal, all other nodes have Forwarding = off > > All nodes can reach each other directly with UDP *except* A and D. > Packets from A to D and vice versa have to be forwarded. Unfortunately, that is not going to work. The shortest path (in number of hops) between A and D is via E. If E has Forwarding = off, then no data will be forwarded and A and D will not be able to communicate with each other. I am afraid this currently is a hard limitation in tinc. > Now I'd like to transfer data from A to D. Since C and E only have small > bandwidth, I'd like to have data from A to D being forwarded by B > directly to D (and not via C or E). How can I get this done? The best way is to have D ConnectTo B instead of E. This way, B will be the best path. > If I could somehow tell A to send packets for D always via B (and not > via E): Would B try to directly connect to D in order to forward packets > from A to D? Or would B forward A's packets for D to C (because of its > meta connection to C)? If B can make a direct UDP connection to D, then it will use that, otherwise it will try to forward packets via C. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Using keyring on tinc
On Fri, Jan 05, 2018 at 05:30:53PM -0300, Inaki Malerba wrote:
> Also, autodiscovery over lan is working? Keys shared between all hosts
> is enough?
There is the LocalDiscovery option that can be enabled. However, it does
not automatically exchanging keys with nodes on the LAN. Instead, it is
there to assist when two nodes that are on the same LAN, are part of the
same VPN, and are connect to an external node in that VPN, but don't
know each other's local address. The LocalDiscovery option will then
help them connect directly via the LAN.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc at startup Debian 8 Jessie
On Sat, Jan 06, 2018 at 05:14:47PM +0100, Jip de Beer wrote: > How do I make Tinc auto start on Debian 8 Jessie? Jessie uses systemd by default, so normally you'd have to tell systemd to start tinc automatically. The tinc package that comes with Debian provides the systemd service files necessary, however: > I’ve compiled and installed the latest stable release tinc-1.0.33 and I’ve > tried this: > > nano /usr/local/etc/tinc/nets.boot There are two problems here: the systemd service files don't read nets.boot, and if you installed tinc in /usr/local, then the systemd service files that come with tinc (both from the official Debian package and the 1.0.33 tarball) assume that the tincd binary is installed in /usr/sbin/. > Should work according to: > https://www.digitalocean.com/community/tutorials/how-to-install-tinc-and-set-up-a-basic-vpn-on-ubuntu-14-04 > > <https://www.digitalocean.com/community/tutorials/how-to-install-tinc-and-set-up-a-basic-vpn-on-ubuntu-14-04> Ubuntu 14.04 is much older than Debian jessie, and doesn't use systemd, so the instructions about nets.boot are not appropriate for your system. > Also tried: > > systemctl enable tinc > systemctl enable tinc@vpnname That's the correct way. However, you may have to edit the file /lib/systemd/system/tinc@.service, and change /usr/sbin/tincd to /usr/local/sbin/tincd. > What’s the official recommended way to run Tinc at startup on Debian? > Can’t find anything mentioned about this in the documentation. You're right, I'll add a section about it in the manual. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Using keyring on tinc
On Fri, Jan 05, 2018 at 02:34:00PM -0300, Inaki Malerba wrote: > Public keys I mean. > > I'd like to manage an easier way to distribute public keys when a new > user is added to the network. > > I'm thinking of mounting hosts/ over ssh on the servers and have it > centralized. > Also, distributing server config (host file, ConnectTo, etc) to the > clients via debian package or git maybe. > > Has anyone done something different with this? For tinc 1.0, have a look at the ChaosVPN tools. These take care of distributing configuration files to any number of clients, securely, from a central repository: https://github.com/ryd/chaosvpn If you can live with just distributing the hosts/ directory, then pretty much anything will work, including Debian packages or git. For tinc 1.1, things are a bit different: you can use the invitation system to add new nodes to a VPN and automatically have them exchange information on how to connect. It's not perfect yet, but the idea is that this will automatically keep all hosts in sync. See: https://tinc-vpn.org/documentation-1.1/Invitations.html -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Using keyring on tinc
On Fri, Jan 05, 2018 at 01:15:17PM -0300, Inaki Malerba wrote: > Is there any way to make tinc use keys from a keyring or similar? > > I'm trying to find a way to manage multiple server, making it easier to > register a new user to the network. Are you talking about public keys or private keys? Also, which keyring technology do you have in mind? -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Will tinc try go re-negotiate to UDP if failed to TCP at beginning?
On Thu, Oct 26, 2017 at 10:09:48AM +0800, Bright Zhao wrote: > Due to unknown reason, tinc failed to negotiate into UDP mode when first > connecting, but will tinc keep trying/negotiating into UDP? or it has to be > restart the tinc in order to start the negotiation process? It will keep trying. If it has detected that UDP is not working, it will keep sending a small UDP packet every PingTimeout seconds (so by default, every minute). -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc Digest, Vol 156, Issue 4
On Thu, Oct 12, 2017 at 10:45:55AM -0400, Heng Wang wrote:
> What's the purpose of SUBNET msg? Is it even useful in switch mode?
Yes, in switch mode tinc is using SUBNET messages to notify other peers
of which MAC addresses belong to which nodes, so don't disable them. You
can even use MAC addresses in Subnet statements host config files.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Configuration working with 2 hosts but not with 3
On Sat, Sep 30, 2017 at 03:29:41PM +0200, Marius Fröhlich wrote: > There are three hosts: > > 1. h181 > 2. h182: Should ConnectTo h181 > 3. h183: Should ConnectTo h181 [...] > The occuring errors are: > > * Ping from h182 (172.16.1.2) and h183 (172.16.1.3) to h181 > (172.16.1.1) is not possible > * Ping from h181 to h182 and h183 and between h182 and h183 are > possible, but extremely slow (some about 1000ms; ping to public IP > is about 10ms) > > When I start tinc with tincd -n netname -d5 -D everything seems normal, > many PINGs and PONGs are displayed. > > In route -n it is displayed on all hosts: > > 172.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 vpn0 > > When stopping tincd on h182 or h183 pings between the two remaining > hosts are possible and fast. Are h182 and h183 behind the same router? It might help to show us a copy of the output from tincd -d5 -D on a node while you are trying to ping over the VPN. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Anyone tried tinc with TCP-BBR?
On Sat, Sep 30, 2017 at 11:28:40AM +0800, Bright Zhao wrote: > I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is > natively designed to optimize TCP, instead of TCP-over-TCP, but could you > articulate a bit more about the beneficial of “sending host when there is a > UDP tinc tunnel” in the middle”? It is *ALWAYS* better to have tinc tunnel packets via UDP instead of TCP. Regardless of which congestion algorithm is used, TCP-over-TCP is bad for performance, due to interactions between the two TCP layers. UDP has no congestion algorithm, so TCP-over-UDP has the same performance as that TCP layer. Note that tinc normally autodetects whether UDP is possible or not, and if not it falls back to TCP, so you should never need to set TCPOnly. It's mainly a relic from older versions of tinc that did not automatically detect this. (Though, there are perhaps networks that give more bandwidth to TCP traffic than UDP traffic, or do other weird things to UDP traffic, that might benefit from manually forcing TCP.) -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc 1.0 syslog dump explanation
On Tue, Sep 19, 2017 at 11:27:07PM +0200, Marko Bencek wrote: > I failed to find any explanation about node statuses in syslog dump. > Could you please enlight what these status codes mean and how to interpret > these? > > Sep 19 07:08:26 ip-10-255-1-200 tinc.routers[20543]: 10_254_5_11 at > 10.255.5.11 port 58045 options c socket 7 status 01c2 outbuf 157/0/0 > Sep 19 07:08:26 ip-10-255-1-200 tinc.routers[20543]: 10_254_3_113 at > 10.255.3.113 port 58233 options c socket 8 status 01c2 outbuf 351/0/0 It's mainly for debugging. Not all values are guaranteed to mean the same thing for different versions of tinc. However, options c means PMTUDiscovery and ClampMSS is enabled for this node, status 01c2 means the node has a valid session key, is using SPTPS and has a working UDP connection. Note that some of that information can be seen in a human-friendly form using the info command. For example, try: tinc -n routers info 10_254_5_11 -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Packet capture to analysis the tinc connection close
On Thu, Sep 14, 2017 at 10:59:22AM +0800, Bright Zhao wrote: > Earlier, my tinc topology is this: https://ibb.co/bP1EJa > <https://ibb.co/bP1EJa>, let me explain a little bit: > > client configuration: > Name = client > AddressFamily = ipv4 > ProcessPriority = high > PingTimeout = 10 > TunnelServer = yes [...] > But after I changed the tinc topology to this: https://ibb.co/eOS4ZF > <https://ibb.co/eOS4ZF>, the connection from client1 to a1 is much stable, > never drop after couple of days…. Hm, I don't think TunnelServer is really suitable for that first topology. It was meant for a central node, to which clients connect. It's not meant for a client that connects to multiple nodes that have connections between themselves. I'd try removing TunnelServer = yes first from all nodes, and then check whether that improves things or not. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How to route between tinc and physical interface.
On Mon, Sep 18, 2017 at 07:57:39PM -0500, Leonardo Taborda wrote: > I am working on a community wireless project where we have an isolated > mesh network that we want to link by VPN. In order to fulfill this > requirement we setup a tinc VPN, with two "nodes", servera and serverb. > Servera has ip 10.0.0.1/24 and serverb has 10.0.0.2/24, and a spare > network interface (enx00010a0b7359) where we intend to connect a mesh > router with 10.1.1.1/24 as ip address. The final goal is to have all the > mesh being accesible through tinc by anyone having our vpn set up in > their laptops. It will help us to diagnose and troubleshoot issues. > > Thus, I am having a hard time trying to get this setup working. I > assigned enx00010a0b7359 10.1.1.2 on serverb and i can ping it from > 10.0.0.1, but if i plug the mesh router with 10.1.1.1 as ip, i got no > response, but a traceroute partially works, getting the first hop but > failing to finish the trace. Check whether forwarding of packets between interfaces is allowed. You need to set /proc/sys/net/ipv4/ip_forward to 1, and if you have any firewall rules, check that the FORWARD table allows traffic between the VPN interface and the one where the mesh router is connected to. > Tried doing a bridge with brctl but i end having the same results, > almost done but something little is missing. Bridges are also affected by FORWARD rules. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: purge doesn't remove dead nodes
On Wed, Sep 13, 2017 at 09:58:58AM -0700, Nirmal Thacker wrote: > > Maybe I should allow the reachable keyword for the dump graph command as > > well, so you can do: > > > > tincctl -n dump reachable graph > > This would help since dead nodes do not clutter the visual representation. > > What are the effects, if any, of dead nodes in the hosts/ dir? If you have AutoConnect enabled, it will (since pre15) periodically try to connect to any unreachable node for which an Address is known. Other than that, there are no effects. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Docker container for Raspberry Pi
On Mon, Sep 11, 2017 at 10:56:10PM +, Guillermo Bisheimer wrote: > Just wanted to mention that I've published a docker image of tinc 1.1pre15 > for the raspberry pi 2/3. > > It was compiled from source on a raspberry 3 and published as > byscontrol/tinc-rpi <https://hub.docker.com/r/byscontrol/tinc-rpi/> along > witht the configuration instructions. > > The latest tag refers to 1.1pre15 only, but I can publish other versions as > well if needed. Nice. But why is a Raspberry-specific image necessary? Looking at your Dockerfile, it should build just as well for any architecture supported by Debian or any of its derivatives. I see that there are actually quite a lot of images for tinc on Docker Hub. The most popular one is jenserat/tinc. It seems it's somewhat simpler than yours. In particular, it's missing a configure.sh script that parses environment variables. However, where you say something like "-e TINC_NAME:client1", which gets parsed by your configure.sh script, with jenserats's version you just add "-o Name=client1" as an argument to the docker run command, which is then directly interpreted by tinc. It's also less typing and more flexible than your approach. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Packet capture to analysis the tinc connection close
On Fri, Sep 08, 2017 at 06:35:41AM +0800, Bright Zhao wrote: > And, I ran a constant ping from the tinc client’s IP to the tinc server’s IP, > it shows, the pings are all successfully back and forth, no any packet loss > during the connection drop happens, so will this help to exclude any > NAT/firewall cause the connection drop? > > And as you saw from the earlier screen shot, when it happens, it drop all > tinc connections, and those connections are for different direction of tinc > servesr, and the packet capture is just show one of the connections. > > I do realize the connection drop in the picture happens 10 mins, but the tinc > client is direct connect to SP with public routable IP, without any > firewall/NAT. Just trying to know if there’s any other reason might cause > this? > > And BTW, this type of connection drop is not regularly with pattern, > sometimes it happens, sometimes it doesn’t. Tinc itself wouldn't cause these kind of reconnections. It clearly sees a timeout, which means it didn't receive a response to its PING packets in time. Unfortunately, there are two classes of devices that are not uncommon that could cause this to happen: consumer ADSL/cable modems tend to have very short timeouts on connections or NAT mappings, and some providers just randomly drop long-lived connections for various reasons (mainly because they think you should only browse webpages, which only requires short-lived TCP connections, which is also easy to analyze, and they want to discourage VPNs, VoIP et cetera). But just to be sure, just set up a TCP connection between the two nodes using netcat or socket for example, send something over that connection every minute, and see how long it lasts. You can also try to reduce PingInterval to, say, 30, and see if that improves anything. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: [Announcement] Tinc versions 1.0.32 and 1.1pre15 released
On Mon, Sep 04, 2017 at 04:16:46PM +, Nirmal Thacker wrote:
> Can 1.1pre15 nodes coexist with 1.1pre14 nodes?
Yes, but I have not tested this extensively.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
[Announcement] Tinc versions 1.0.32 and 1.1pre15 released
With pleasure we announce the release of tinc versions 1.0.32 and 1.1pre15. Here is a summary of the changes in tinc 1.0.32: * Fix segmentation fault when using Cipher = none. * Fix Proxy = exec. * Support PriorityInheritance for IPv6 packets. * Fixes for Solaris tun/tap support. * Bind outgoing TCP sockets when ListenAddress is used. Thanks to Vittorio Gambaletta for his contribution to this version of tinc. Here is a summary of the changes in tinc 1.1pre15: * Detect when the machine is resuming from suspension or hibernation. * When an old PID file is found, check whether the old daemon is still alive. * Remember scope_id for IPv6 addresses when sending UDP packets to link-local addresses. * Ensure compatibility with OpenSSL 1.1. * Only log about dropped packets with debug level 5. * Warn when trying to generate RSA keys less than 2048 bits. * Use AES256 and SHA256 as the default encryption and digest algorithms. * Add DeviceType = fd to support tinc on Android without requiring root. * Support PriorityInheritance for IPv6 packets. * Fixes for Solaris tun/tap support. * Add a configurable expiration time for invitations. * Store invitation data after a succesful join. * Exit gracefully when the tun/tap device is in a bad state. * Add the LogLevel option. * AutoConnect now actively tries to heal split networks. Thanks to Etienne Dechamps, Rafał Leśniak, Sean McVeigh, Vittorio Gambaletta, Dennis Lan, Pacien Tran-Girard, Roman Savelyev, lemoer and volth for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: using both ConnectTo and AutoConnect to avoid network partitions
On Thu, Aug 31, 2017 at 01:37:28PM -0700, Nirmal Thacker wrote: > If you make the yellow nodes ConnectTo all other nodes, and not have > > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > > no ConnectTo's, then you will get the desired graph. > > The reason this approach is not desirable is because it fails at > automation. It requires us to add a new line of AutoConnect = that joined tinc> to both yellow nodes everytime a new node node joins, > while in the current setup as long as the keys of every new node are > exchanged between the new nodes and the yellow nodes, the ConnectTo's can > stay constant That's true. Although it wouldn't be impossible to script that a little, for example by adding the following host-up script: #!/bin/sh tinc add ConnectTo $NODE > > Yes, AutoConnect will still remove outgoing connections that it thinks > > are redundant. So even if the initial ConnectTo's will cause nodes to > > connect to the yellow ones, after a while they can remove those. > > Is this optimization also vulnerable to the bug we saw earlier with regard > to the network split? Or given that the ConnectTo's exist, peer nodes, will > fall back onto these, thereby 'recovering' in some sense if a network split > were to occur due to the the AutoConnect bug? Yes, in 1.1pre14 enabling AutoConnect on all nodes, regardless of how many ConnectTo's they have, may result in a split network. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Behavior like -R and -L SSH
On Mon, Aug 28, 2017 at 10:48:56PM -0400, Rafael Wolf wrote: > I wanted a TINC tunnel like this, where I have a server on the Internet > with a public IPv4 address as my TINC server. Then I can have clients > connect to it and see each other except that the client at a customer > site would allow me to route behind it so I could see hosts on site beyond > my device on premise. [...] > Internal Devices <-- Customer Site with a rasperry pi --> Internet --> > Public Server <-- Laptop, PC, whatever > > Server with public IPv4 address: [...] > /etc/tinc/devtun/tinc-up > > #!/bin/sh > ifconfig $INTERFACE 192.168.2.1/29 > route add -net 192.168.0.0/24 gw 192.168.2.1 dev $INTERFACE The route statement is correct. However, "gw 192.168.2.1" does not do anything when tinc is in router mode. You can leave it out. > /etc/tinc/devtun/hosts/devtun > TunnelServer = yes > Address = 10.0.10.3 > Subnet = 192.168.2.1/32 > > -BEGIN RSA PUBLIC KEY- > xxx > -END RSA PUBLIC KEY- > > * Note that I also tried putting in another "Subnet" for the 192.168.0.0 > but it > didn't seem to do anything. You should only put in Subnet statements for those address ranges that belong to that node itself. It seems like 192.168.0.0/24 is the address range for the internal devices at the customer site, so this does not belong to devtun. > Client config (rasperry pi at the client site): [...] > /etc/tinc/tinc-up > > #!/bin/sh > ifconfig $INTERFACE 192.168.2.2/29 > # This route breaks networking! Definitely don't use this! > # route add -net 192.168.0.0/24 gw 192.168.2.2 dev $INTERFACE You should indeed not add this route. If 192.168.0.0/24 belongs to the internal network, then adding a route for 192.168.0.0/24 to the VPN interface will ensure demo can no longer talk to its internal network. > /etc/tinc/demo/hosts/demo > > TunnelServer = yes > Address = 67.219.201.3 > Subnet = 192.168.2.2/32 > Subnet = 192.168.0.0/24 > Mode = router > > -BEGIN RSA PUBLIC KEY- > xxx > -END RSA PUBLIC KEY- [...] > Got ADD_SUBNET from demo (75.134.104.213 port 54059): 10 3d2ef9c2 demo > 192.168.2.2/32#10 > Ignoring unauthorized ADD_SUBNET from demo (75.134.104.213 port 54059): > 192.168.2.2/32#10 [...] > Both server and client can ping each other. > > So...why would I be getting that "unauthorized subnet" from the demo site? Because you are using the TunnelServer option, which implicitly also enables the StrictSubnets option. Try it without TunnelServer = yes. > Once I iron out the subnet issue how can I "route" from the server or other > clients connected to the server beyond the client (which is my pi)? Your configuration looks correct to me, as long as you remove the TunnelServer option. > OH and also...when I have the client config files like this on each host: > > server has: > devtun <-- what I actually fire up with tincd to "listen" > demo > > client has: > devtun > demo <-- what I actually fire up with tincd to "connect" > > ...does the client really care what the "devtun" config file has in it > besides the authentication key? Yes, if you use TunnelServer = yes then it will also use the Subnets from that file, and will not allow devtun use any other Subnet. Otherwise, no. > ...does the server really care what the "demo" config file has in it > besides the autnetication key? Yes, it also reads the Subnets because TunnelServer = yes, and it reads the Address statement so it knows how to connect to demo. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: using both ConnectTo and AutoConnect to avoid network partitions
On Wed, Aug 23, 2017 at 06:08:36PM -0700, Nirmal Thacker wrote: > - We see several log messages that we dont currently understand - Can you > comment on what they mean and if they are concerning? I've obfuscated IP's > and node names so please ignore those. Our tinc daemon command is: tincd -n > > > -- Received short packet > -- Got REQ_KEY from node003 while we already started a SPTPS session! > -- Failed to verify SIG record from node003 (22.22.22.22 port 655) > -- message repeated 3 times: [ Received short packet] > -- Failed to decrypt and verify packet from node005 (44.44.44.44 port 655) The above are caused by packets being received while key exchange hasn't been finished yet. This can happen because the key exchange can go over TCP, one side has finished and starts sending encrypted UDP packets which overtake the TCP packets, and then the other side receives the UDP packets before it got the last bit of data via TCP to finish the key exchange on this side. These are not concerning. > -- Invalid packet seqno: 7951 != 1 from node003 (22.22.22.22 port 655) This happens while rekeying, and a packet from before the rekeying finished was received after the recipient finished the rekeying. This is also not concerning. > -- Metadata socket read error for node004 (33.33.33.33 port 655): > Connection reset by peer That means the other side closed the connection. If you want to know why, you have to look at the logs of node004. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: What if two tinc daemons received the same Subnet but with different weight?
On Wed, Aug 23, 2017 at 08:04:08AM +, Bright Zhao wrote: > Guus Sliepen <g...@tinc-vpn.org>于2017年8月22日 周二下午11:10写道： > > > If there are two completely identical Subnets, then it's currently > > undefined what happens (in practice it will choose the one with the > > lowest name alphabetically, but don't rely on that). > > I referre to the two separate tinc process/network(received same subnet), > not Sunbet selection within one tinc process/network. > > My understanding is if different tinc process comes with exact subnet, as > they are not related with each other(they have no idea regarding weights > with each other), I guess the routing depends on the host's main routing > table, for specific route it depends on which tinc interface as the "Via" > to determine this? In that case, it's up to you what happens. Tinc itself never modifies the kernel's routing table, it only calls scripts that you provide. But the kernel's routing table works pretty much the same as how tinc works internally: you can assign a metric (the equivalent to tinc's Subnet weight) to routes, but if you have two completely identical routes to different interfaces, it might be unclear to which interface it will route packets. On most platforms, it depends on which route was added first. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How to set tinc not to forward Subnet learned from other nodes?
On Sat, Aug 19, 2017 at 08:09:52AM +0800, Bright Zhao wrote: > Reason behind that is we have some use cases wouldn’t like to make some nodes > to become the transit node, but there’re some other nodes in the topology act > as the transit nodes. > > So if the tinc node forward subnet update it learning from one side to the > other side, then it possible to become transit node if one side only have > route to go through it. > > That node I would call it “spoke-only” node, which dual/triple connection go > to multiple “hub” node, “hub” definitely need to forward traffic for the > “spoke”, but “spoke” shouldn’t forward subnets learning from one “hub” to > another. > > Any idea to achieve this in one tinc “network”? You can use the TunnelServer option on the hub to prevent it from forwarding Subnet updates from spokes. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: What if two tinc daemons received the same Subnet but with different weight?
On Sat, Aug 19, 2017 at 09:21:11AM +0800, Bright Zhao wrote: > Two tinc networks/daemons, and received same subnet from the two daemons, how > tinc will choose which one is preferred? And the weight settings in each > daemon for subnet will or will not be the judge? If you use weights for Subnets, then the Subnet with the lowest weight will be chosen, unless the node that owns that Subnet is offline, in which case the Subnet with the next lowest weight is chosen. If there are two completely identical Subnets, then it's currently undefined what happens (in practice it will choose the one with the lowest name alphabetically, but don't rely on that). -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: using both ConnectTo and AutoConnect to avoid network partitions
On Tue, Aug 22, 2017 at 03:19:18PM -0700, Nirmal Thacker wrote: > - How do we patch 1.1pre14 with this fix? Or will there be a 1.1pre15 to > upgrade to? There will be an 1.1pre15, but if you want you can apply the following commit: https://tinc-vpn.org/git/browse?p=tinc;a=commitdiff;h=92fdabc439bdb5e16f64a4bf2ed1deda54f7c544 > - What is the workaround until we patch with this fix? Using a combination > of AutoConnect and ConnectTo? Yes. > - When we use ConnectTo, is it mandatory to have a cert file in the hosts/* > dir with an IP to ConnectTo ? Yes. Tinc always needs the public key of a peer and an Address in order to be able to connect to it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: using both ConnectTo and AutoConnect to avoid network partitions
On Mon, Aug 21, 2017 at 05:37:06PM -0700, Nirmal Thacker wrote: > Today our Tinc network saw a network partition when we took one tinc node > down. > > We knew there was a network partition since the graph showed a split. This > graph is not very helpful but its what I have at the moment: > > http://i.imgur.com/XP2PSWc.png The graph is very clear. > Some questions: > - should we have a combination of both ConnectTo and AutoConnect to avoid > such a network split? No, it's a bug in AutoConnect. I've just pushed a fix to the 1.1 branch that will try to continue to connect to unreachable nodes, even if a node already has 3 or more connections. > - Say we have 3 ConnectTo variables and then AutoConnect=yes, would there > ever be more than 3 connections ? (I read somewhere that AutoConnect will > make upto 3 connections only) There can always be more than 3 connections, even when AutoConnect is enabled. When starting, tinc will try to make outgoing connections to all nodes listed in ConnectTo statements. This can be more than 3 nodes. After that, the AutoConnect algorithm kicks in. The AutoConnect algorithm tries to regulate the number of established connections, either by creating more outgoing connections, or by closing connections that it made itself. It will never close incoming connections, and it also won't close outgoing connections to a node that isn't already connected to at least one other node. Ideally, after a while connections get rearranged such that no node has more than 3 connections. But this can take a while, or it might never happen; for example if you have 5 nodes behind NAT, and one public node, then the public node will always have 5 connections. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: The reconnect timer can be adjusted in 1.0.31?
On Sat, Aug 12, 2017 at 09:17:10AM +, Bright Zhao wrote: > I noticed th default reconnect for the first time is 5s, if failed the > timer will be increase, I would like to know if this timer can be adjusted? No, this cannot be adjusted. > The Max Timeout you mentioned seems not exactly the one, from the > description below, it looks to me it is the total time for connect to be > re-established, if not it trying other tinc daemon? Different tinc deamons > have nothing related to each other, why try other daemon? Timeouts are handled separately for each ConnectTo. So if you have multiple ConnectTo's, they will all be tried in parallel, and each has its own timeout that starts at 5 seconds, gets incremented by 5 every time it fails, but it will never increase it beyond MaxTimeout. So if you have a connection to A that is failing, and after a while the timeout for it is 300 seconds, and if a working connection to B suddenly fails, then tinc will try to reconnect to B after 5 seconds. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc encryption with intermediate hosts
On Sat, Aug 05, 2017 at 01:30:16PM +, Jan Ernsting wrote: > So my topology looks like this: > > [n1]->[host1]<-->[host2]<-[n2] [...] > But how are the packets encrypted? > > Are they really peer to peer encrypted from node1 to node2, or are they > wrapped into another encrypted packet between host1 and host2? That depends. If you run tinc 1.1 on both node1 and node2, then they will use end-to-end encryption. However, if you use tinc 1.0, then packets are encrypted hop-by-hop. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Can't use proxy after client upgrade
On Sat, Jul 29, 2017 at 12:47:02PM +0200, Nikolaus Rath wrote:
> Could you tell me which commit this is? I'd rather just revert that
> commit than switch to older version?
I've pushed a fix to git, if you want to, try out the master branch and
see if it works for you.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: PGP signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Can't use proxy after client upgrade
On Sat, Jul 29, 2017 at 12:47:02PM +0200, Nikolaus Rath wrote: > >> Proxy = exec /etc/tinc/rath/triv_proxy.sh > > > > Indeed, it seems like Proxy = exec was broken by a commit that fixed > > some issue with the other proxy types. For now the workaround is to use > > 1.0.29 or earlier if you need this. I'll let you know when this is > > fixed. > > Could you tell me which commit this is? I'd rather just revert that > commit than switch to older version? Version 1.0.29 should be fine. But if you want, try checking out tinc from git, and then do: git revert 3c37fe38019ec9c08be6158a4f64128fc83ed605 -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Some tinc clatifications
On Tue, Jul 11, 2017 at 09:58:39AM +0200, Alessandro Briosi wrote: > I understand on a security bug or something, but having to rekey all the > hosts 'cause someone gets fired to me it sounds insane. > There must be an easy way to block somebody from connecting to the VPN? > Isn't removing it's reference on the "servers" enough? The proper way is to remove the host key files of those nodes on all other nodes. If only the "servers" have a copy of those host files, you only need to remove it on the servers. Note that you need to send the tinc daemons on those servers the HUP signal (or "tincd -kHUP" for tinc 1.0, "tinc reload" for tinc 1.1) to have them reread the host config files and disconnect any nodes for which it doesn't have a host config file anymore. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Can't use proxy after client upgrade
On Mon, Jul 03, 2017 at 02:24:55PM +0200, Nikolaus Rath wrote: > After upgrading my client system from Debian jessie to Debian stretch > (which includes an update from tinc 1.0.24 to tinc 1.0.31), I am > having trouble with my VPN: [...] > Proxy = exec /etc/tinc/rath/triv_proxy.sh Indeed, it seems like Proxy = exec was broken by a commit that fixed some issue with the other proxy types. For now the workaround is to use 1.0.29 or earlier if you need this. I'll let you know when this is fixed. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Significance of port 655?
On Wed, Jun 21, 2017 at 04:57:23PM -0700, Nirmal Thacker wrote: > What is the significance of port 655 with regards to tinc? This port is officially reserved for tinc. It is also below number 1024, which means that on most operating systems, only a priviliged user can listen on that port, and prevents regular users from starting tinc on port 655. However, you don't have to use port 655, you can configure tinc to run on any port(s) you like. > [protected] : protected behind a private network in the cloud > [bastion]: also runs in the cloud, has an interface into the private > network but also has a public ip. accepts connections on port 655 > [outside-1]: a laptop behind a home router > [outside-2]: similar to outside-1 > > I found that when I ran tinc (v1.1pre14) among these 4 nodes and dumped a > graph at [bastion], there were green edges from [bastion] to all other > nodes. > > But dumping graphs on every other node had a black edge going to all other > nodes, other than [bastion] This is because the graph dump shows information known by the local node. An edge shows a TCP connection between nodes. Information about edges is forwarded to all other nodes. If the local node has a working UDP connection to a peer, this will show up as green in its own graph dump, otherwise not. UDP connections are made on demand, so the graph dump doesn't always show green even if UDP connection is possible. > So it appears to be a Star topology? For the TCP connections, yes. > But obviously if I started a netcat listener on [protected], at port , > both [outside-1] and [outside-2] could telnet in using [protected] VPN IP. > In this case I hope the traffic is going via [bastion]. Tinc will try to make direct connections between [outside-*] and [protected], but if that is not possible, it will route traffic via [bastion]. > Likewise [outside-1] and [outside-2] could also communicate via a > telnet-netcat session using VPN IP's > But does it mean this traffic is actually going over [bastion] too? Again, tinc will try to make a direct connection between, but if that is not possible, it will go via [bastion]. In your case, if both [outside-1] and [outside-2] are behind the same home router, it could be that they cannot communicate with each other via their public addresses. You can try to add "LocalDiscovery = yes" to the tinc.conf of both outside nodes. If they are behind different routers, then it depends on the exact make and model whether they will allow UDP hole punching to work. > In both of those cases I would expect to see orange edges in the graph, but > I see only black edges. Actually, a node will only be orange in the graph if tinc is configured such that it will never try to make a direct connection to that node. For example, if the IndirectData option is used. Note that the "tinc info " command gives more clear information. > What are the benefits of opening(forwarding) ports 655 on [outside-1] and > [outside-2]? Would they connect directly by learning of each other? If they are behind different routers, then yes, port forwarding will definitely help. > With regard to host files, all nodes have [bastion] host file only and > [bastion] has host files from all nodes That's fine. Each node will learn about all other nodes via bastion then. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How to diagnostic UDP discovery failed situation
On Wed, Jun 21, 2017 at 09:11:47AM +0800, Bright Zhao wrote: > I found the server(1.1.1.1) didn’t receive the MTU probe from client, so I > add iptables -A INPUT -p udp —port 443 -j ACCEPT. > > After this, I see one packet matching on the server side, and the MTU > negotiation works, but when I tear down the tinc, and re-establish the tinc > connection, the counter of below UDP/443 never increase, and also my other > tinc nodes never add this statement on iptables, but they alll works well for > the MTU negotiation(finally works on UDP) > > pkts bytes target prot opt in out source > destination > 1 104 ACCEPT udp -- anyany anywhere anywhere > udp dpt:https > > The above statement is necessary, or not? Yes, if it would otherwise block UDP packets coming in to the server, you need it to ensure tinc can communicate via UDP. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: PGP signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Replacing of non-alphanumeric chars in Name can be confusing
On Sat, May 27, 2017 at 05:46:17PM +0200, Niklas Hambüchen wrote:
> Tinc replaces non-alphanumeric characters in the `Name` field of
> tinc.conf by '_' (see [1] and [2]).
Only if you use Name = $something. This is clearly mentioned in the
manpage. In particular, it says:
Name may only consist of alphanumeric and underscore characters (a-z,
A-Z, 0-9 and _), and is case sensitive.
So it's clear about what names are normally allowed. It then goes on to
mention:
If Name starts with a $, then the contents of the environment variable
that follows will be used. In that case, invalid characters will be
converted to underscores.
This was done specifically to make it easy to use Name = $HOST, and
still work when the hostname contains hyphens. However, since some
operating systems don't provide the equivalent of $HOST, or when tinc is
run in a restricted environment where $HOST is not set, tinc will use
gethostname() as a convenience. But there is no reason to expect that
this would suddenly allow hyphens.
So I believe your suggestions 1) and 2) are already implemented!
I know it was not perhaps the best choice for tinc to prevent the use of
the hyphen in Names, however it would be problematic to allow it for two
backwards-compatibility reasons: all versions of tinc up to now will
disconnect from any nodes that send any information about nodes with
hyphens in their name, and the possible ambiguity when you have node
names ending in -up or -down.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: Digital signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How can I resolve the "abc (x.x.x.x port 655) could not flush for 14 seconds (15846 bytes remaining)"
On Sat, May 27, 2017 at 04:12:48PM +0800, Bright Zhao wrote:
> Happened couple of times, do you have any suggestions?
This means the local tinc daemon tried to send some information to abc,
but the TCP buffers are filled up. That usually means there is network
congestion, or abc has very little bandwidth. The message does not
necessarily mean there is an error. There is not much you can do about
this.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: Digital signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: What/why this event happens: Can't write to Linux tun/tap device (tun mode) /dev/net/tun: Input/output error
On Fri, May 26, 2017 at 09:10:53PM +0800, Bright Zhao wrote: > But one question here is if I don’t add "/sbin/ifconfig myvpn 10.0.0.1 > netmask 255.255.255.0”, it seems the crontab wouldn’t trigger tinc-up, and > then the ip addr of myvpn wouldn’t be configured, then it will prompt the > error of "Can't write to Linux tun/tap device (tun mode) /dev/net/tun: > Input/output error” Perhaps your cron restricts the contents of $PATH. Make sure you also use "/sbin/ifconfig" in tinc-up. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: What/why this event happens: Can't write to Linux tun/tap device (tun mode) /dev/net/tun: Input/output error
On Fri, May 26, 2017 at 09:30:44AM +0800, Bright Zhao wrote: > Due to some routing rotation purpose, I use crontab to add below info: > > 0 * * * * echo Subnet = 54.169.128.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 0 * * * * echo Subnet = 54.169.0.0/17 >> /etc/tinc/myvpn/hosts/aws_sgp > 1 * * * * /usr/sbin/tincd -n myvpn -k > 1 * * * * /usr/sbin/tincd -n myvpn --debug=3 > > 30 * * * * sed -i '/54.169.128.0\/17/d' /etc/tinc/myvpn/hosts/aws_sgp > 30 * * * * sed -i '/54.169.0.0\/17/d' /etc/tinc/myvpn/hosts/aws_sgp > 31 * * * * /usr/sbin/tincd -n myvpn -k > 31 * * * * /usr/sbin/tincd -n myvpn --debug=3 This is not the right way to do it. Cronjobs are being run in parallel. So if you both stop and start tinc at the same time, there is no guarantee that it will happen in the right order. The easiest way is to create two scripts, one that adds the Subnets and the other that removes them, and the other that adds them. Another issue is that with tinc 1.0, the -k option sends a TERM signal to the running tinc daemon, but it might take a little time before it actually stops. So add a sleep command inbetween, or check for /var/run/tinc.myvpn.pid to disappear. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Does the INT signal will force the tinc to re-read the tinc.conf file
On Wed, May 24, 2017 at 11:48:26PM +0800, Bright Zhao wrote:
> I mean, if I changed pingtimeout on tinc.conf, -kHUP will force the tinc to
> re-read that parameter into effective? If no, any other ways to make it
> effective other that kill the process?
>
> for tinc 1.0.
You have to restart tinc 1.0 for this change to take effect.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: Digital signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Advertising a Public IP address
On Mon, May 22, 2017 at 11:03:30AM +0200, Keith Whyte wrote: > I have two tinc nodes (A and B) behind a firewall > > NodeA and NodeB have 192.168.1.2 and 192.168.1.3 assigned on an internal > LAN, and they both have different public IP addresses forwarded to them, > port 655 udp/tcp > > I would like any given node in the C-Z group to be able to find Node B > on it's public IP and therefore not forward via NodeA, but I would like > to be able to do this without having to distribute NodeBs host key file > with an Address = line to every node in the C-Z group. [...] > Node B is reachable on the publicIP from the LAN (Nat reflection is in > operation) The problem is getting the information about NodeB's public IP address to the other nodes. Since you have NAT reflection working, the easiest way is for NodeA and NodeB to connect to each other using their public IP address. This will cause these address to propagate to the other nodes. > Right now, if I ask any node in C-Z for > > info NodeB > > I get: > > Address: 192.168.1.3 port 655 > Reachability: none, forwarded via NodeA The info command gives the address that is currently selected by the local node for communication with NodeB. However, tinc might know more than one address. You can do: tinc -n dump edges | grep 'to NodeB' The "at" addresses are the externally visible addresses for NodeB. Recent versions of tinc 1.1 however also report there own local address. You can find the local addresses of NodeB using: tinc -n dump edges | grep '^NodeB' And looking at the address after "local". Since you enabled the LocalDiscovery in NodeB's tinc.conf, then it will likely pick NodeA's local address for direct UDP communication with it, which is more efficient than using NAT reflection. But you have to make a connection between NodeA and NodeB using their public IP addresses, otherwise they themselves will not know they have those, and will only tell the other nodes about their local addresses. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Any way to set the subnet/suggest of invitation?
On Wed, May 17, 2017 at 04:43:37PM +, Martin Eskdale Moen wrote:
> Just curious if there is any way to set the Subnet of an invitation.
Yes. When you generate an invitation, there is a corresponding
invitation file on the node that created the invitation. You can change
this file to include a Subnet. For documentation, see here:
https://tinc-vpn.org/documentation-1.1/Invitations.html
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: Digital signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: What's the weight means in the dump of edge info from USR2?
On Thu, May 11, 2017 at 08:03:02AM +0800, Bright Zhao wrote: > 1. This weight is not the one specified in Subnet, this should be something > related to the host, where can I manually configure this? Either in tinc.conf, then it applies to all connections made, or in individual host config files, then it applies only to connections with that host. > 2. The weight value is ONLY take round trip latency as the measurement, or > including CPU power and other factors into consideration? It takes into account the total time for doing the authentication between two peers. That is not just latency, but also how fast the nodes can do cryptography. > 3. I don't know how this Weight named, but let's say it Path-weight; So in > 1.1, tinc will first evaluate Subnet-weight, and if certain route have the > same Subnet-weight, they will compare the Path-weight for deciding which path > to forward(if direct not possible, and same hops to the destination)? Tinc separately determines the final destination of a packet, and how to route to that final destination. Subnet-weight is used for the former, and path-weight for the latter. > 4. When will 1.1 been released as official version? I'm afraid my past predicitions have been meaningless, so I can't answer this. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc to create VPN between cluster nodes (at different datacenters) for High Availability
On Tue, May 09, 2017 at 06:24:55PM -0500, John Griessen wrote: > I've not really dug into testing tinc yet, but if you all will humor me in an > uneducated blast of questions, > I'd appreciate it. > > What can you do to keep tinc going if your high availability comes from > cluster nodes being dispensable? > Can tinc run on the cluster nodes? > That seems like chicken/egg problem though to get tinc server installed and > cluster nodes brought up... > If tinc needs to be providing gateways separately from the cluster nodes, how > do you make tinc high available? > Install tinc on more than one simple VPS nodes? > Would this scenario always require your hosting provider to offer a kind of > private network? There are two ways to do high-availability with tinc. Assuming you want to have multiple distinct "exit nodes" on the VPN (that provide a default gateway for other nodes), then just assign Subnet = 0.0.0.0/0 to each of the exit nodes. The other nodes will then choose one of those that is online. So if they are using one that goes offline, they will switch to another one. The other way is to set up the exit nodes identically (same Name, same public/private key), but as I already mentioned in the response to Bright Zao's question, only one of them should ever be up at the same time. Depending on your setup, you might be able to use an external high-availability solution to ensure that. The other nodes then just see one exit node, but you specify multiple Address statements for it (one for each physical exit node). Tinc will try each address in turn until it finds a working one. If the node it's connected to goes down, it will try another address to reconnect. So yes, it can be done by just running tinc on your cluster nodes. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: If two identical host get up, what will happen?
On Tue, May 09, 2017 at 05:28:43PM +0800, Bright Zhao wrote:
> I mean exactly the same configuration, including the pub-pri key.
You should only have one of them running at the same time. If you have
both running, then the two identical nodes will start to fight with each
other. There is some code in tinc to detect this situation, and one of
those two nodes will shutdown at some point.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: Digital signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: How tinc route traffic when two subnets are identical?
On Thu, May 04, 2017 at 02:24:42PM -0700, Dave Warren wrote: > I'm a tinc n00b, not yet actually using it yet but investigating as it > seems it will solve a lot of problems with our current solutions. > > Can I rely on this configuration as a lazy man's failover solution? I > understand I can't set priorities or anything of that sort, I just want > a simplistic failover if one or the other internet connection dies for > locations that have multiple external routes/connections. Yes you can; failover works. > There might be a better way, I'm still wrapping my head around > everything. Another option besides having two different nodes announcing the same Subnet, is to use an external high-availability solution like heartbeat for example, and have two machines with completely identical tinc nodes (same Name, same public/private keypair). Heartbeat will ensure only one of them is active. Other nodes that want to connect to this high-availability pair have to Address statements in the corresponding host config file, one for each of the pair. The drawback is slightly slower failover (because tinc has no second connection already standing by when the first dies), a possible advantage is that tinc does not switch unnecessarily between the HA nodes. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Multiple default gateway from tinc node
On Wed, May 03, 2017 at 02:15:36PM +0800, Bright Zhao wrote: > 1. The destination of IPv4 wouldn’t be changed, Yes I agree, that’s the goal > and final destination for the communication. But during the path, it may be > encapsulated into another packet(tunnel mode), where the outside IP header is > the physical address, but the inner destination remain unchanged, and I think > Tinc encapsulates into UDP packet, where the outside S/D IP is the physical > adapter IP address, but the whole original packet was encapsulated into the > UDP content part. Conceptually, it’s the same as IPSec site-to-site VPN: > http://www.unixwiz.net/images/IPSec-ESP-Tunnel-Mode.gif > <http://www.unixwiz.net/images/IPSec-ESP-Tunnel-Mode.gif> Yes. But we were talking about traffic and routing inside the tunnels, that the VPN packets are encapsulated in UDP packets is not relevant. > 2. Regarding the “via 10.0.0.3”, you’re right, it’s only for Ethernet ARP > resolution for the next hop. And after my test, my understanding is as below > for the routing part of Tinc: > a. When tinc get up, the tun0 assigned an IP address by tinc-up, let’s > say 10.0.0.100/24, this will add an direct attached route into host’s route > table which appears as “10.0.0.0 255.255.255.0 tun0”, which is not deletable; > this route will enable traffic head to 10.0.0.0/24 will throw into the tun0 > interface Yes, except that you can delete that route if you want. The route is just added as a convenience for you by ifconfig. > b. Also, if there’s any other traffic need to convey by tinc VPN, you > just add another route, for example: “ip route 8.8.8.8/32 dev tun0”, and > actually we don’t need to specify the via, since we only need throw the > traffic into tun0 interface. Correct. > c. No matter for above a or b, when the traffic send to tun0, from the > tunnel’s perspective, the source IP will be 10.0.0.100(since routed through > this interface), and the destination IP will be the one I pinged, which is > 8.8.8.8 > d. After above c, then the tinc need to figure out how to encapsulate > the original packet (S/10.0.0.100 > D/8.8.8.8) into the tunnel and send to > the other Tinc node. Then I guess Tinc will check “ADD_SUBNET” messages it > received from the ConnectTo node(learn the whole network), and try to > encapsulate the original packet into UDP packets, send to the node where its > subnet of 8.8.8.8 is preferred(weight setting on Subnet) Correct. > e. If Tinc configured by default, then the local host will try to send > UDP packet directly to the preferred host which advertise 8.8.8.8 > f. If IndirectData = yes configured everywhere, then the local host > will always encapsulate the UDP packet to the ConnectTo/aly_hk Yes. > (No matter 8.8.8.8 is advertised or not), if aly_hk doesn’t > advertise 8.8.8.8, it will check it’s Tinc daemon, to see who advertised > 8.8.8.8, and then encapsulate UDP to him as the next step to relay It does matter whether there is a Subnet advertised that includes 8.8.8.8 or not. If the only difference in configuration is whether IndirectData is set or not, then packets with a given destination IP address will always be sent to the same node. > Interestingly, earlier I check the below post for my setup, but now I found, > the configuration can be simplified into, because tinc-up will make the > 172.16.1.0/24 to $INTERFACE, and for those two default routes, the via is not > required as well: > > #!/bin/sh > VPN_GATEWAY=172.16.1.1 > ORIGINAL_GATEWAY=`ip route show | grep ^default | cut -d ' ' -f 2-5` > > ip route add $REMOTEADDRESS $ORIGINAL_GATEWAY > ip route add $VPN_GATEWAY dev $INTERFACE > ip route add 0.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE > ip route add 128.0.0.0/1 via $VPN_GATEWAY dev $INTERFACE > > https://www.tinc-vpn.org/examples/redirect-gateway/ > <https://www.tinc-vpn.org/examples/redirect-gateway/> Correct. This is also mentioned at the end of that page. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Upcoming laws and the state of privacy in Europe?
On Wed, Apr 12, 2017 at 11:28:02AM +, Martin Eskdale Moen wrote: > Hi, I'm not trying to rock any boats or make noise and I'm not interested > in discussing politics either, but I just wanted to get a general feel for > what the rest of the tinc community felt in regards to how the EU looks > like it wants to completely break encryption and make tools like > tinc unfeasible. > Both Germany and France want this to happen and in the UK the snoopers > charter has provisions for this (although not tested in court yet). > I think Netherlands, Norway and Finland are considering similar laws. > Not sure which country isn't doing this. > > Any ideas on how we can keep tinc safe if for instance tomorrow the > majority of countries in Europe decided that encryption is no longer > allowed without government keys being used. If that would really become the law, then there is nothing technical that we can do about it. Tinc would still work as it does. You can either comply with the law, and perhaps give your tinc keys to the government in escrow, or disobey the law and keep the keys to yourself. Each option has its own consequences, and it's up to you to decide which ones you prefer. > I think simply saying that tinc is open source isn't exactly an answer, it > would mean we individually have to read every line of source, understand > and continue to read every patch that is made going forwards. I don't think that tinc being open source is in any way relevant here, such laws would most likely impact both open and closed source software. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Timeout during authentication - connection timeout not configurable?
On Wed, Mar 29, 2017 at 08:59:33PM +0200, Nick Hibma wrote: > >> Is there an option somewhere to set the connection timeout? I've already > >> set the ping timeout to 15s and I would like to set the connect timeout to > >> 15s as well. > > > > The connection timeout is always the same as PingTimeout in tinc. > > I remember it being faster than that, but in that case I must be mistaken. I > had a look around at how to set that timeout and noticed people use a > select() construct to do it, not a simple socket setting. So I guess your > comment make sense then. > > Well, I'll check again and get back to you if I can figure out what actually > goes wrong. In tinc connection timeouts are handled with exactly the same code as the ping timeouts. Each connection has a variable tracking the last time a ping was sent. When a connection is created, it is set to the current time. In the event loop, it regularly checks whether the current time is greater than last_ping_time + pingtimeout. If so, it terminates the connection. The timer is only reset when the connection is "activated", ie. after the authentication phase finished. If your ping times are 5 seconds then beware that it takes multiple round trips to set up the TCP connection and perform the authentication. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Timeout during authentication - connection timeout not configurable?
On Wed, Mar 29, 2017 at 10:14:30AM +0200, Nick Hibma wrote: > We use tincd over VSAT connections, and if the contract has been reduced to a > bare minimum -and- the ship is moving, latency reaches 2 - 5 seconds (yes, > seconds). Generally this is not a problem if you are patient (and most smart > phones are), but tincd is slightly too fast in deciding that it is not going > to work. We also use the tinc connection to check whether any traffic is > possible. > > Is there an option somewhere to set the connection timeout? I've already set > the ping timeout to 15s and I would like to set the connect timeout to 15s as > well. The connection timeout is always the same as PingTimeout in tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc can't connect to names defined in /etc/hosts
On Mon, Mar 13, 2017 at 01:20:11PM +0100, Niklas Hambüchen wrote: > I have a host name defined in /etc/hosts (say "1.2.3.4 host1") that > resolves via that but not via DNS; consequently pinging and netcatting > to it works fine. > > When I try to use that in a tinc host definition like "Address = host1", > tinc 1.1 tells me > > Error looking up host1 port 655: Name or service not known > > Why is that? Does getaddrinfo() tinc uses not consider /etc/hosts? Tinc uses the standard getaddrinfo() function from libc. That one does read /etc/hosts. However, if you run tinc with --chroot, then you have to make sure you have a copy of /etc/hosts inside the chroot directory. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: tinc 1.1 - import
On Sun, Mar 05, 2017 at 08:51:18PM +0300, Yazeed Fataar wrote: > I have been testing the "import" function in tinc. It works great however > there is one thing I need help doing. When I import the RSA keypairs from > multiple devices into a tinc node using the import , the last RSA key pair > data is not saved. I only get a blank host file. For example > > *Hub* > :~#Tinc -n import > name = site 1 > --- --- name = site 2 > --- --- name = site 3 > --- --- the hosts files site 3 has nothing written to it and its blank. What is the > correct method of exiting out of the "import" standard input? Ctrl-D is correct. If it still doesn't work, then do: cat >data And enter the import data like you would otherwise, end with Ctrl-D and send me that file, so I can have a look at it. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc hangs if started with network disconnected
On Fri, Feb 17, 2017 at 01:20:59PM +0100, Sandro Stiller wrote: > > Does it not log anything anymore after those messages? Or does it > > continue giving the "Error looking up..." message periodically? > > It stops working completely. > > > In the first case, try sending tinc the ALRM and/or HUP signal (tincd -n > > -kALRM). This should cause tinc to retry outgoing connections > > immediately. > > After that, it continues trying. > > I think, I found the cause of the problem: > Is tinc using a monotonic / steady clock for timeouts or is it using the > system time? I think you are right! It uses time() and gettimeofday() to calculate how long to wait for the timeouts. I'll have to look at a portable way to get a monotonic clock. > > In any case, which Linux distribution are you using? > > It's an OpenEmbedded-based distribution for embedded devices Ok, that probably explains why you always have a large jump in time at boot. Just curious: what hardware are you running tinc on? The best solution for now is to send tinc an ALRM signal after the time is set. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Tinc hangs if started with network disconnected
On Fri, Feb 17, 2017 at 09:55:26AM +0100, Sandro Stiller wrote: > On my system, tinc is started on bootup. > If the Network cable is not connected, tincd hangs forever after these > messages: [...] > 2017-02-13 11:34:02 tinc.XXX[403]: Error looking up XXX.net port 2300: > Temporary failure in name resolution [...] > Even if I reconnect the interface, tinc does not continue. > If I restart the service manually, everything works fine, even with > disconnected network interface (it tries again and again until internet > connection works). > I think, there is some kind of boot-time race condition. > It's the same problem with version 1.0.28 and 1.0.31. Does it not log anything anymore after those messages? Or does it continue giving the "Error looking up..." message periodically? In the first case, try sending tinc the ALRM and/or HUP signal (tincd -n -kALRM). This should cause tinc to retry outgoing connections immediately. If that doesn't help, it could be that libc doesn't reload /etc/resolv.conf after the network connection came up. Tinc has code to force glibc to reload that file every time it wants to do a hostname lookup. Did you compile tinc yourself? If so, can you send us a copy of the config.h file? In any case, which Linux distribution are you using? -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: wireguard what do you guys tinc?
On Sun, Feb 05, 2017 at 02:36:52PM +0100, Jelle de Jong wrote: > I saw Guus already had contact with Jason over email. I also had a nice talk with him after his presentation at FOSDEM. > What do you guys tinc of wireguards, are there advantages? Jason seems to > have a good grip of what he is talking about. The main advantage of WireGuard is that it is completely in the kernel, so it can be significantly faster. There are several reasons for it: - Userspace VPNs require 3 times the number of context switches for sending a packet. - They also suffer from roughly twice the amount of cache pressure. - It is much harder to do batch processing of packets outside the kernel. In his slides he showed that OpenVPN is 3 times as slow as WireGuard. Tinc suffers from exactly the same issues. WireGuard is doing pretty much a subset of what tinc does (and its cryptography is also very similar to that of tinc 1.1): you have one virtual network interface, and it is capable of making connections to multiple other nodes, and knows which IP addresses belong to which peers. The biggest drawback is that it is very static; you can't just add a node to a VPN like you do with tinc, which spreads information about a new node throughout the VPN, and is able to set up new connections on demand. There are also some features that tinc has that are not in WireGuard, such as PMTU discovery, STUN-like NAT traversal, forwarding using a third node in case two nodes really cannot communicate with each other directly, and some more things. It would be very interesting to see if tinc could make use of WireGuard if it knows that two nodes that want to communicate with each other both are running Linux and have the WireGuard module installed. That way, you get the best of both worlds. One important step to make that happen is to have the ability to send out-of-band messages through a WireGuard tunnel. This is necessary so that tinc nodes can communicate with each other through WireGuard, and very that the connection is working properly. Jason has said that this is a planned feature, so that's great news. Personally, I would like to see WireGuard only do the actual VPN packet handling with symmetric crypto, and leave all the rest, including key exchange using asymmetric crypto, to userspace. However, at the moment WireGuard is pretty self-contained, not requiring any userspace daemons, but just some simple tools to provision it with keys and the IP addresses of peers. Both ways have their uses. Maybe it will be able to do both in the future. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Help with iptables && tinc
On Mon, Jan 30, 2017 at 02:05:43PM +, Dave Albert wrote: > I've been able to get tinc setup when I flush all my iptables, but after > enabling iptables and a delay I get a "Destination Net Unknown". Destination Net Unknown means that tinc does not know a Subnet that matches the destination IP address of VPN packets, either because there is no such Subnet, or because the host that has that Subnet is not connected. So it seems that with the iptables rules enabled, WEB and MASTER cannot make a TCP connection with HOME (and/or vice versa). From the firewall rules you posted: > Chain INPUT [...] > 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp > dpt:655 state NEW,ESTABLISHED > 6 8976 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0udp > dpt:655 state NEW,ESTABLISHED That means no TCP connection to port 655 was ever attempted. But your OUTPUT rules are more interesting: > Chain OUTPUT [...] > 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0tcp > spt:655 state NEW,ESTABLISHED > 6 8976 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0udp > spt:655 state NEW,ESTABLISHED This only allows TCP connections from port 655 if they are NEW or ESTABLISHED. But tinc never makes outgoing TCP connections with source port 655! Outgoing TCP connections normally have a random port number. There is no other rule that allows outgoing TCP connections to port 655, except to those hosts within the IP range 10.0.3.0/24. I recommend you add a rule that ACCEPTs anything with state RELATED,ESTABLISHED in the OUTPUT chain. Put that rule first. Then you want to allow NEW outgoing connections with *destination* port 655. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Disallow binding via tinc
On Fri, Jan 27, 2017 at 01:24:37AM +0100, Niklas Hambüchen wrote:
> I'm looking for a way to add some (Linux) participants into my tinc
> network, but I want to protect them from accidentally binding a port so
> that it's accessible via tinc.
[...]
> I imagine the easiest way would be to make it so that tinc creates no
> tun device. Is the `DeviceType = raw_socket` option what I'm looking for?
You can use DeviceType = dummy to make tinc run without a tun device.
Note that the node running tinc then cannot access the VPN at all, it
then only acts as a forwarder and/or NAT helper for other nodes.
Otherwise, the best option is to add firewall rules that disallow any
new incoming connections from the VPN interface, but still allow
outgoing connections. Example commands to do this:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i -j DROP
Don't forget about IPv6, where you have to add similar rules.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <g...@tinc-vpn.org>
signature.asc
Description: Digital signature
___
tinc mailing list
tinc@tinc-vpn.org
https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
Re: Firewall rules for TINC server
On Mon, Jan 16, 2017 at 12:29:59PM +, Guillermo Bisheimer wrote: > One more thing. I can run two tinc daemons one for each group, but I sill > need to communicate clients from one group to the other. > > Clients from group 2 (admin group) need to reach clients from group 1 > (remote server group), but clients from group 1 must not be able to reach > each other nor the server. > > If I'm not using TunnelServer and Forwarding, How can I setup the routes > between the two Tinc daemons? For group 1, set TunnelServer = yes and Forwarding = off. This prevents clients from seeing and talking to each other. Also don't use DeviceType. Now that you have two VPN interfaces on the server, one for group 1 and one for group 2, you can use the routing table and/or firewall rules to control who can reach who. You still need to block traffic from the clients to the server itself. Instead of: > sudo iptables -A INPUT -s 10.100.0.0/17 -d 10.100.0.1/32 -j DROP Try: sudo iptables -A INPUT -i -j DROP This should drop all packets from the clients. Note that the INPUT chain only applies to packets destined for the server itself, packets that are to be forwarded between group 1 and 2 go via the FORWARD chain. -- Met vriendelijke groet / with kind regards, Guus Sliepen <g...@tinc-vpn.org> signature.asc Description: Digital signature ___ tinc mailing list tinc@tinc-vpn.org https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
