From: Guus Sliepen Date: Mon, 14 Sep 2009 17:01:53 +0000 (+0200) Subject: Import old website, converted to MarkDown format. X-Git-Url: https://tinc-vpn.org/git/browse?a=commitdiff_plain;h=7c74a57cd95cfc0358fdd5980d9170ea16751dfb;p=wiki Import old website, converted to MarkDown format. --- diff --git a/activities.mdwn b/activities.mdwn new file mode 100644 index 0000000..f955d5f --- /dev/null +++ b/activities.mdwn @@ -0,0 +1,72 @@ +## Activities + +Here you can find events and articles that are related to tinc. If +you are holding a meeting or writing an article about VPNs and also +mention tinc, please [tell us](contact). If you know of any we have +not listed here, we would also like to hear about it. + +### Past events + +* [Online tutorial](), + November 8, 2003, + on [irc.debian.org #tinc]() at 18:00 GMT. + During this online tutorial installation, configuration and + practical issues regarding tinc were discussed. +* [Linux World Expo](http://www.linuxworldexpo.com/), + October 29, 2003, Frankfurt, Germany. + At this expo, Marc Lehmann gave a talk (in German) titled + "Einfache VPN-Netzwerke". One of the solutions mentioned was tinc. +* [NLUUG Spring Conference](http://www.nluug.nl/events/vj01/), + May 31, 2001, Ede, the Netherlands. + This conference was on High Availability, + and so we held a talk about the HA aspects of tinc. + You can find some information in the + [abstract](/presentations/nluug-20010531/abstract). + You can also download the + [conference paper](/presentations/nluug-20010531/havpns.ps.gz) (Dutch only). +* [Open Source Developers Europe Meeting](http://www.fosdem.org/), + February 3-4, 2001, Brussels, Belgium. + We were there, but unfortunately the official schedule was + completely filled up. We did talk to some people in one of the + extra classrooms that were available though. The sheets we brought + were the same as those used during the Linux Expo. +* Linux Expo Amsterdam, + January 23-24, 2001 In Amsterdam. + We held a presentation about Virtual Private Networks, + and of course especially tinc. You can find some information in the + [abstract](presentations/linuxexpo/abstract). + You can have a look at the + [slides](/presentations/linuxexpo-20010123/), + or download the + [presentation](presentations/linuxexpo/slides.tgz). +* [NLLGG](http://www.nllgg.nl/) meeting, + October 7th, 2000. + You can look at a copy of the + [sheets](/presentations/nllgg/tp.ps.gz) we used. + +### Press + +Articles we have published: + +* Linux News, year 2, issue 1: + *"Virtual Private Networks meer dan een buzzword"* (Dutch). +* [Linux Magazine](http://www.linuxmag.nl/), year 1, issue 2: + *"Virtual Private Networks met tinc"* (Dutch). + +References to tinc that can be found in other articles: + +* [c't magazin](http://www.heise.de/ct/), 2009, issue 19: + *"[Maschen-VPN](http://www.heise.de/ct/inhalt/2009/19/176/)"* (German). +* [Linux Magazin](http://www.linux-magazin.de), October 2003: + *"[Einfache Verbindung: VPN-Daemon im Userspace: Tinc](http://www.linux-magazin.de/Heft-Abo/Ausgaben/2003/10/Einfache-Verbindung)"* (German). +* [Building Linux Virtual Private Networks](http://www.buildinglinuxvpns.net/contents/), + a book by Oleg Kolesnikov and Brian Hatch, + published February 2002 by New Riders Publishing; ISBN: 1578702666. +* *"What Can VPN Do For You?"*, + an article on "32 bits online", January 2001 (website gone). +* [Computer Shopper](http://www.computershopper.co.uk/), + issue 151, September 2000, page 491. + A copy of the article can be found + [here](http://www.antipope.org/charlie/linux/shopper/151.html). +* [Tucows](http://linux.tucows.com/preview/8920.html), + rates tinc with 4 tuxes (out of 5) diff --git a/contact.mdwn b/contact.mdwn new file mode 100644 index 0000000..47c6722 --- /dev/null +++ b/contact.mdwn @@ -0,0 +1,29 @@ +## Contacting the authors + +### Mailing lists + +If you have a question about tinc, or would like some help in +configuring tinc or your networking setup, you should write to the +tinc [[mailing lists|mail]], preferably not to the authors in +private. You will get a response faster this way. + +### By mail + +If you wish to contact us in private you can do so via the +following addresses. Note that we use +[GnuPG](http://www.gnupg.org/), our emails are (almost) always +signed. This will also allow you to send us encrypted emails. + +- Guus Sliepen + +### On IRC + +There is a channel on the [FreeNode](http://www.freenode.net/) and +[OFTC](http://www.oftc.net/) IRC networks. Connect to +[irc.freenode.net](irc://irc.freenode.net/#tinc) +or [irc.oftc.net](irc://irc.oftc.net/#tinc) and join channel `#tinc`. +We are logged in most of the time, but may not be active. If you +run your IRC client in screen just like us, just ask your question +and wait. If you cannot stay on IRC and really want to ask a +question, please do so via email, see above. +A history of the channel is available on request. diff --git a/docs.mdwn b/docs.mdwn new file mode 100644 index 0000000..4d1fc2c --- /dev/null +++ b/docs.mdwn @@ -0,0 +1,44 @@ +## Documentation + +Most of the documentation you can find here is in the tinc packages +as well. If you have any questions you cannot find answered here, +please try the list of [[Frequently Asked Questions|faq]]. If you +still have a problem or comments you can send them to the +[[mailing list|mail]] or you can [[contact]] the authors. + +Note: documentation is always behind. If you think you miss +something, you spotted an error or you notice that the program does +something else than the documentation says, please tell us! + +### Manual + +The main source of information is the +[tinc manual](/documentation/tinc_toc). This text describes how to +set up a VPN using tinc. It also contains a chapter with more +technical details, which you may want to read, as well as the ideas +behind tinc. This manual is currently up to date with version +1.0.9. + +### Manpages + +You can also view the HTML version of the manpages that come with +version 1.0.9 of tinc: + +- [tincd(8)](/documentation/tincd.8) +- [tinc.conf(5)](/documentation/tinc.conf.5) + +### Examples + +After reading the manual, you can look at further +[[examples]] of configuration files and scripts for +various setups. There is also an example of +[[installing tinc on Windows|examples/windows-install]]. + +### Other material + +- The sheets of the + [presentation about VPNs and tinc](/presentations/linuxexpo-20010123/) + we gave during the Linux Expo in Amsterdam, 2001/01/23. +- The sheets of the + [presentation about VPNs and tinc](/presentations/nllgg/tp.ps.gz) + we gave at the NLLGG meeting 2000/10/07. diff --git a/download.mdwn b/download.mdwn new file mode 100644 index 0000000..db53569 --- /dev/null +++ b/download.mdwn @@ -0,0 +1,372 @@ +## Download + +Here is a full listing of all versions of tinc that have been made +public. If you wish to get the current development version, please +get it from our git [[repository]]. +The source code is the primary means of distribution of tinc. In +addition, we try to make packages for operating system +distributions available and provide static binaries for some +operating systems and architectures. We do not support the packages +and static binaries though. If there are any problems with the +packages you should contact its maintainer. + +### Latest release + + +
**Version**1.0.9 +
**Source** +[tinc-1.0.9.tar.gz](packages/tinc-1.0.9.tar.gz) +([sig](packages/tinc-1.0.9.tar.gz.sig)) +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.9-install.exe) +
+ +### Mirror sites + +These tinc pages are hosted in the Netherlands. If you live more +closely to one of the following countries, please go to the mirror +site for better performance. + +- Australia, + at [Wiretapped.net](http://www.wiretapped.net/) in Sydney, updated nightly: + - [ftp://ftp.wiretapped.net/pub/security/network-security/tinc/](ftp://ftp.wiretapped.net/pub/security/network-security/tinc/) + - [http://the.wiretapped.net/security/network-security/tinc/](http://the.wiretapped.net/security/network-security/tinc/) + +- Sweden, + at [Endpoint](http://www.endpoint.nu/), updated daily: + - [ftp://ftp.endpoint.nu/pub/software/tinc/](ftp://ftp.endpoint.nu/pub/software/tinc/) + - [http://ftp.endpoint.nu/pub/software/tinc/](http://ftp.endpoint.nu/pub/software/tinc/) + - [rsync://ftp.endpoint.nu::pub/software/tinc/](rsync://ftp.endpoint.nu::pub/software/tinc/) + (only within Sweden) + +### Distributions providing tinc + +This is a list of distributions and unofficial package repositories +that provide packages for tinc: + +- [Debian](http://packages.debian.org/tinc) +- [Ubuntu](http://packages.ubuntu.com/tinc) +- [ALT Linux](http://www.altlinux.org/index.php?module=sisyphus&package=tinc) +- [NetBSD](http://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/net/tinc/README.html) +- [FreeBSD](http://www.freebsd.org/cgi/ports.cgi?query=tinc&stype=name&sektion=security) +- [Dag Wieërs RPM packages](http://dag.wieers.com/rpm/packages/tinc/) +for Red Hat and Fedora Core + +This list is not complete and may not be up to date. If you want to +add a distribution or repository to the list, please +[contact us](/contact). We do not support any of these packages, +contact the respective package maintainer if you have problems +using one of these packages. + +### Older versions + + +
**Version**1.0.8 +
**Source** +[tinc-1.0.8.tar.gz](packages/tinc-1.0.8.tar.gz) +([sig](packages/tinc-1.0.8.tar.gz.sig)) +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.8-install.exe) +
**Extra** +When compiling with an old version of GCC, try the following patch, kindly provided by "Borg": +[tinc-1.0.8-gcc-2.95.patch](contrib/tinc-1.0.8-gcc-2.95.patch). +
+ + +
**Version**1.0.7 +
**Source** +[tinc-1.0.7.tar.gz](packages/tinc-1.0.7.tar.gz) +([sig](packages/tinc-1.0.7.tar.gz.sig)) +
**Static binaries** +[OpenBSD i386](packages/tincd-1.0.7-openbsd-i386-static.gz) +([sig](packages/tincd-1.0.7-openbsd-i386-static.gz.sig)), +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.7-install.exe) +
+ + +
**Version**1.0.6 +
**Source** +[tinc-1.0.6.tar.gz](packages/tinc-1.0.6.tar.gz) +([sig](packages/tinc-1.0.6.tar.gz.sig)) +
**Static binaries** +[FreeBSD i386](packages/tincd-1.0.6-freebsd-i386-static.gz) +([sig](packages/tincd-1.0.6-freebsd-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0.6-openbsd-i386-static.gz) +([sig](packages/tincd-1.0.6-openbsd-i386-static.gz.sig)), +[NetBSD i386](packages/tincd-1.0.6-netbsd-i386-static.gz) +([sig](packages/tincd-1.0.6-netbsd-i386-static.gz.sig)), +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.6-install.exe) +
+ + +
**Version**1.0.5 +
**Source** +[tinc-1.0.5.tar.gz](packages/tinc-1.0.5.tar.gz) +([sig](packages/tinc-1.0.5.tar.gz.sig)) +
**Static binaries** +[FreeBSD i386](packages/tincd-1.0.5-freebsd-i386-static.gz) +([sig](packages/tincd-1.0.5-freebsd-i386-static.gz.sig)), +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.5-install.exe), +[Debian on Nokia 770](packages/debian/tinc_1.0.5-1_armel.deb) +
+ + +
**Version**1.0.4 +
**Source** +[tinc-1.0.4.tar.gz](packages/tinc-1.0.4.tar.gz) +([sig](packages/tinc-1.0.4.tar.gz.sig)) +
**Static binaries** +[Linux x86_64](packages/tincd-1.0.4-linux-x86_64-static.gz) +([sig](packages/tincd-1.0.4-linux-x86_64-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0.4-freebsd-i386-static.gz) +([sig](packages/tincd-1.0.4-freebsd-i386-static.gz.sig)), +[NetBSD i386](packages/tincd-1.0.4-netbsd-i386-static.gz) +([sig](packages/tincd-1.0.4-netbsd-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0.4-openbsd-i386-static.gz) +([sig](packages/tincd-1.0.4-openbsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0.4-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0.4-solaris-sparc32-dynamic.gz.sig)), +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.4-install.exe) +
+ + +
**Version**1.0.3 +
**Source** +[tinc-1.0.3.tar.gz](packages/tinc-1.0.3.tar.gz) +([sig](packages/tinc-1.0.3.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0.3-linux-i386-static.gz) +([sig](packages/tincd-1.0.3-linux-i386-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0.3-freebsd-i386-static.gz) +([sig](packages/tincd-1.0.3-freebsd-i386-static.gz.sig)), +[NetBSD i386](packages/tincd-1.0.3-netbsd-i386-static.gz) +([sig](packages/tincd-1.0.3-netbsd-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0.3-openbsd-i386-static.gz) +([sig](packages/tincd-1.0.3-openbsd-i386-static.gz.sig)), +[Darwin powerpc](packages/tincd-1.0.3-darwin-powerpc-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0.3-darwin-powerpc-dynamic.gz.sig)), +[Solaris sparc32](packages/tincd-1.0.3-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0.3-solaris-sparc32-dynamic.gz.sig)), +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0.3-install.exe), +[OpenWRT](packages/openwrt/tinc_1.0.3_mipsel.ipk) +
+ + +
**Version**1.0.2 +
**Source** +[tinc-1.0.2.tar.gz](packages/tinc-1.0.2.tar.gz) +([sig](packages/tinc-1.0.2.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0.2-linux-i386-static.gz) +([sig](packages/tincd-1.0.2-linux-i386-static.gz.sig)), +[NetBSD i386](packages/tincd-1.0.2-netbsd-i386-static.gz) +([sig](packages/tincd-1.0.2-netbsd-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0.2-openbsd-i386-static.gz) +([sig](packages/tincd-1.0.2-openbsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0.2-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0.2-solaris-sparc32-dynamic.gz.sig)), +
**Packages** +[Slackware 9.1](packages/slackware/tinc-1.0.2-i486-2.tgz), +[Windows 2000/XP](packages/windows/tinc-1.0.2-install.exe) +
+ + +
**Version**1.0.1 +
**Source** +[tinc-1.0.1.tar.gz](packages/tinc-1.0.1.tar.gz) +([sig](packages/tinc-1.0.1.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0.1-linux-i386-static.gz) +([sig](packages/tincd-1.0.1-linux-i386-static.gz.sig)), +[NetBSD i386](packages/tincd-1.0.1-netbsd-i386-static.gz) +([sig](packages/tincd-1.0.1-netbsd-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0.1-openbsd-i386-static.gz) +([sig](packages/tincd-1.0.1-openbsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0.1-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0.1-solaris-sparc32-dynamic.gz.sig)), +[Darwin powerpc](packages/tincd-1.0.1-darwin-powerpc-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0.1-darwin-powerpc-dynamic.gz.sig)), +[Windows 2000/XP](packages/tincd-1.0.1-windows-i386-static.exe) +([sig](packages/tincd-1.0.1-windows-i386-static.exe.sig)), +
**Packages** +[Slackware 9.1](packages/slackware/tinc-1.0.1-i486-1.tgz), +[Windows 2000/XP](packages/windows/tinc-1.0.1-install.exe) +
+ + +
**Version**1.0 +
**Source** +[tinc-1.0.tar.gz](packages/tinc-1.0.tar.gz) +([sig](packages/tinc-1.0.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0-linux-i386-static.gz) +([sig](packages/tincd-1.0-linux-i386-static.gz.sig)), +[NetBSD i386](packages/tincd-1.0-netbsd-i386-static.gz) +([sig](packages/tincd-1.0-netbsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0-solaris-sparc32-dynamic.gz.sig)), +[Darwin powerpc](packages/tincd-1.0-darwin-powerpc-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0-darwin-powerpc-dynamic.gz.sig)), +[Windows 2000/XP](packages/tincd-1.0-windows-i386-static.exe) +([sig](packages/tincd-1.0-windows-i386-static.exe.sig)), +
**Packages** +[Windows 2000/XP](packages/windows/tinc-1.0-install.exe) +
**Remarks** +When compiling under OpenBSD, you will need a small +[patch](packages/tinc-1.0-openbsd-patch.gz) +([sig](packages/tinc-1.0-openbsd-patch.gz.sig)). +
+ + +
**Version**1.0pre8 +
**Source** +[tinc-1.0pre8.tar.gz](packages/tinc-1.0pre8.tar.gz) +([sig](packages/tinc-1.0pre8.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0pre8-linux-i386-static.gz) +([sig](packages/tincd-1.0pre8-linux-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0pre8-openbsd-i386-static.gz) +([sig](packages/tincd-1.0pre8-openbsd-i386-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0pre8-freebsd-i386-static.gz) +([sig](packages/tincd-1.0pre8-freebsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0pre8-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0pre8-solaris-sparc32-dynamic.gz.sig)), +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre8-1_i386.deb) +([woody](packages/debian/tinc_1.0pre8-1.woody_i386.deb)), +[Slackware i386](packages/slackware/tinc-1.0pre8-i386-1.tgz) +([Slackware 9](packages/slackware/tinc-1.0pre8-i386-slackware9.tgz)), +
+ + +
**Version**1.0pre7 +
**Source** +[tinc-1.0pre7.tar.gz](packages/tinc-1.0pre7.tar.gz) +([sig](packages/tinc-1.0pre7.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0pre7-linux-i386-static.gz) +([sig](packages/tincd-1.0pre7-linux-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0pre7-openbsd-i386-static.gz) +([sig](packages/tincd-1.0pre7-openbsd-i386-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0pre7-freebsd-i386-static.gz) +([sig](packages/tincd-1.0pre7-freebsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0pre7-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0pre7-solaris-sparc32-dynamic.gz.sig)) +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre7-1_i386.deb), +[Redhat](packages/redhat/tinc-1.0pre7-1.i386.rpm), +[Slackware i386](packages/slackware/tinc-1.0pre7-i386-1.tgz) +
+ + +
**Version**1.0pre6 +
**Source** +[tinc-1.0pre6.tar.gz](packages/tinc-1.0pre6.tar.gz) +([sig](packages/tinc-1.0pre6.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0pre6-linux-i386-static.gz) +([sig](packages/tincd-1.0pre6-linux-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0pre6-openbsd-i386-static.gz) +([sig](packages/tincd-1.0pre6-openbsd-i386-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0pre6-freebsd-i386-static.gz) +([sig](packages/tincd-1.0pre6-freebsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0pre6-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0pre6-solaris-sparc32-dynamic.gz.sig)) +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre6-1_i386.deb) +
**Remarks** +Doesn't like signals and prefixlengths which are not divisible by 8. +
+ + +
**Version**1.0pre5 +
**Source** +[tinc-1.0pre5.tar.gz](packages/tinc-1.0pre5.tar.gz) +([sig](packages/tinc-1.0pre5.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0pre5-linux-i386-static.gz) +([sig](packages/tincd-1.0pre5-linux-i386-static.gz.sig)), +[OpenBSD i386](packages/tincd-1.0pre5-openbsd-i386-static.gz) +([sig](packages/tincd-1.0pre5-openbsd-i386-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0pre5-freebsd-i386-static.gz) +([sig](packages/tincd-1.0pre5-freebsd-i386-static.gz.sig)), +[Solaris sparc32](packages/tincd-1.0pre5-solaris-sparc32-dynamic.gz)[*](#dynamic) +([sig](packages/tincd-1.0pre5-solaris-sparc32-dynamic.gz.sig)) +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre5-1_i386.deb), +[Debian potato i386](packages/debian/tinc_1.0pre5-1.potato_i386.deb) +
**Remarks** +Blocking connect()s. +
+ + +
**Version**1.0pre4 +
**Source** +[tinc-1.0pre4.tar.gz](packages/tinc-1.0pre4.tar.gz) +([sig](packages/tinc-1.0pre4.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0pre4-i386-static.gz) +([sig](packages/tincd-1.0pre4-i386-static.gz.sig)), +[FreeBSD i386](packages/tincd-1.0pre4-freebsd-i386-static.gz) +([sig](packages/tincd-1.0pre4-freebsd-i386-static.gz.sig)), +
**Remarks** +Contains key expiry bug, see [[FAQ|faq#keyexpire]]. +
+ + +
**Version**1.0pre3 +
**Source** +[tinc-1.0pre3.tar.gz](packages/tinc-1.0pre3.tar.gz) +([sig](packages/tinc-1.0pre3.tar.gz.sig)) +
**Static binaries** +[Linux i386](packages/tincd-1.0pre3-i386-static.gz) +([sig](packages/tincd-1.0pre3-i386-static.gz.sig)), +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre3-1_i386.deb), +[Debian potato i386](packages/debian/tinc_1.0pre3-1potato_i386.deb) +
+ + +
**Version**1.0pre2 +
**Source** +[tinc-1.0pre2.tar.gz](packages/tinc-1.0pre2.tar.gz) +([sig](packages/tinc-1.0pre2.tar.gz.sig)) +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre2-1_i386.deb), +[Redhat i386](packages/redhat/tinc-1.0pre2-1.i386.rpm) +
**Remarks** +Contains security hole, see [[news|news/2000-09-10]]. +
+ + +
**Version**1.0pre1 +
**Source** +[tinc-1.0pre1.tar.gz](packages/tinc-1.0pre1.tar.gz) +([sig](packages/tinc-1.0pre1.tar.gz.sig)) +
**Packages** +[Debian i386](packages/debian/tinc_1.0pre1-0.4_i386.deb), +[Redhat i386](packages/redhat/tinc-1.0pre1-2.i386.rpm) +
**Remarks** +Contains security hole, see [[news|news/2000-09-10]]. +
+ + +
**Version**0.3.3 +
**Source** +[tinc-0.3.3.tar.gz](packages/tinc-0.3.3.tar.gz) +([sig](packages/tinc-0.3.3.tar.gz.sig)) +
**Remarks** +Contains security hole, see [[news|news/2000-09-10]]. +
+ + +
**Version**0.2.19 +
**Source** +[tinc-0.2.19.tar.gz](packages/tinc-0.2.19.tar.gz) +([sig](packages/tinc-0.2.19.tar.gz.sig)) +
diff --git a/examples.mdwn b/examples.mdwn new file mode 100644 index 0000000..421ecc3 --- /dev/null +++ b/examples.mdwn @@ -0,0 +1,5 @@ +## Example setups + +A list of examples of common setups can be found here, along with the typical configuration files, firewall rules and other issues. If you have any questions, comments or examples of your own, please inform us. + +[[!map pages="examples/* and !*/Discussion and !examples/*/* and !*.png and !*.dia" show=title]] diff --git a/examples/bridging.mdwn b/examples/bridging.mdwn new file mode 100644 index 0000000..ca5e6ec --- /dev/null +++ b/examples/bridging.mdwn @@ -0,0 +1,130 @@ +[[!meta title="bridging Ethernet segments using tinc under Linux"]] + +## Example: bridging Ethernet segments using tinc under Linux + +Normally, in the default router mode, tinc will only tunnel IPv4 and IPv6 +unicast packets. However, since 1.0pre5 there is an option to let the tinc +daemon act as a switch or a hub (using the Mode configuration variable). This +mode is necessary for tinc to pass non-IP based protocols (NetBEUI, AppleTalk, +IPX, etcetera), and to allow broadcast-based functionality in some applications +(Windows 'Network Neighborhood' without a WINS server, among others) to be +usable on a VPN created with tinc. + +In switch and hub mode, broadcast packets are broadcast to other daemons and +(in switch mode) MAC addresses are dynamically learned from other tinc daemons +in order to route packets. With these mode tinc can be used to act as a bridge +between two or more Ethernet segments. + +### Overview + +The network setup is as follows: + +* Internal network, on both sides, is 192.168.0.0/16 +* The host's own IP address on the internal network is 192.168.10.20 + +The gateway of each segment has an external interface, eth0, and an internal +interface eth1. Furthermore a bridge interface will be created with name +"bridge", and the internal interface will be made a slave of this bridge. The +virtual network interface used by tinc will also be a slave. Configuration of +the kernel In addition to the standard kernel configuration described in the +Configuring the kernel section of the manual, a bridge device needs to be added +to your kernel configuration. + +To add the bridge device to the Linux 2.4.0 and higher kernels, select the +option under 'Networking options' called 802.1d Ethernet Bridging. You may +either compile this option as a module or build it into the kernel. +Configuration of the interfaces Switch and hub modes require that both sides of +a tinc VPN be contained within the same subnet (in this example, the subnet is +192.168.0.0/16). This is no different from the configuration that would be +required if tinc was replaced with an actual switch or hub. + +> host# brctl addbr bridge +> host# ifconfig bridge 192.168.10.20 netmask 255.255.0.0 +> +> host# ifconfig eth1 0.0.0.0 +> host# brctl addif bridge eth1 +> host# ifconfig eth1 up +> +> After starting tinc: +> +> host# brctl show +> bridge name bridge id STP enabled interfaces +> bridge 8000.005004003002 yes eth1 +> vpn +> +> host# ifconfig +> eth0 Link encap:Ethernet HWaddr 00:20:30:40:50:60 +> inet addr:123.234.123.42 Bcast:123.234.123.255 Mask:255.255.255.0 +> UP BROADCAST RUNNING MTU:1500 Metric:1 +> ... +> +> eth1 Link encap:Ethernet HWaddr 00:11:22:33:44:55 +> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 +> ... +> +> lo Link encap:Local Loopback +> inet addr:127.0.0.1 Mask:255.0.0.0 +> UP LOOPBACK RUNNING MTU:3856 Metric:1 +> ... +> +> bridge Link encap:Ethernet HWaddr 00:11:22:33:44:55 +> inet addr:192.168.10.20 Bcast:192.168.255.255 Mask:255.255.0.0 +> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 +> +> vpn Link encap:Ethernet HWaddr 00:11:22:33:44:55 +> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 +> ... +> +> host# route +> Kernel IP routing table +> Destination Gateway Genmask Flags Metric Ref Use Iface +> 123.234.123.0 * 255.255.255.0 U 0 0 0 eth0 +> 192.168.0.0 * 255.255.0.0 U 0 0 0 bridge +> default 123.234.123.1 0.0.0.0 UG 0 0 0 eth0 + +### Configuration of tinc + +Note that switch' and hub' mode do not utilize the Subnet variable in the host +files. Instead, any packet received by the bridge interface will be passed to +the TUN/TAP device for processing. If your tinc instance is running in hub +mode, all packets are forwarded to the remote tinc instance. In switch mode, +tinc maintains an ARP cache to determine whether any received packet should be +forwarded to the remote tinc instance. + +> host# cat /etc/tinc/vpn/tinc.conf +> Name = segment1 +> Device = /dev/tun +> Mode = switch +> ConnectTo = segment2 +> +> host# cat /etc/tinc/vpn/tinc-up +> #!/bin/sh +> +> ifconfig vpn 0.0.0.0 +> brctl addif bridge vpn +> ifconfig vpn up +> +> host# ls /etc/tinc/vpn/hosts +> segment1 segment2 ... +> +> host# cat /etc/tinc/vpn/hosts/segment1 +> Address = 123.234.123.42 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- +> +> host# cat /etc/tinc/vpn/hosts/segment2 +> Address = 200.201.202.203 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- + +### Additional Configuration + +If the Ethernet interface added to the bridge was used for the default route, +you will need to re-add the default route. + +If you want to be able to filter packets on your bridge interface, you will +need to a kernel with [ebtables](http://ebtables.sourceforge.net/) support. +More information For more information on Linux bridging, see the [bridge-utils +homepage](http://www.linuxfoundation.org/en/Net:Bridge). diff --git a/examples/fig-firewall.png b/examples/fig-firewall.png new file mode 100644 index 0000000..ce915e0 Binary files /dev/null and b/examples/fig-firewall.png differ diff --git a/examples/fig-ipv6-network.dia b/examples/fig-ipv6-network.dia new file mode 100644 index 0000000..09dec47 Binary files /dev/null and b/examples/fig-ipv6-network.dia differ diff --git a/examples/fig-ipv6-network.png b/examples/fig-ipv6-network.png new file mode 100644 index 0000000..eea2b83 Binary files /dev/null and b/examples/fig-ipv6-network.png differ diff --git a/examples/fig-on-firewall.png b/examples/fig-on-firewall.png new file mode 100644 index 0000000..2cebd0b Binary files /dev/null and b/examples/fig-on-firewall.png differ diff --git a/examples/firewall.mdwn b/examples/firewall.mdwn new file mode 100644 index 0000000..dee8c5e --- /dev/null +++ b/examples/firewall.mdwn @@ -0,0 +1,162 @@ +[[!meta title="tinc from behind a firewall"]] + +## Example: tinc from behind a firewall + +When running tinc from behind a firewall (not on the firewall itself), one must +be careful to configure the firewall so that it allows the tinc traffic to pass +through. Example firewall rules are included in this example. They are written +for iptables (Linux 2.4 firewall code), but commented so that you may apply the +same kind of rules to other firewalls. + +[[!toc levels=2]] + +### Overview + +[[!img examples/fig-firewall.png]] + +The network setup is as follows: + +* Internal network is 123.234.123.0/24 +* Firewall IP is 123.234.123.1 +* Host running tinc has IP 123.234.123.42 +* VPN the host wants to connect to has address range 192.168.0.0/16 +* The host has it's own VPN IP 192.168.10.20 + +Note that the internal network has real Internet addresses, and is therefore +entirely accessible from the outside (except for the restrictions the firewall +places). If the internal network has private addresses refer to the +masquerading firewall example. + +### Configuration of the host running tinc + +> host# ifconfig +> eth0 Link encap:Ethernet HWaddr 00:20:30:40:50:60 +> inet addr:123.234.123.42 Bcast:123.234.123.255 Mask:255.255.255.0 +> UP BROADCAST RUNNING MTU:1500 Metric:1 +> ... +> +> lo Link encap:Local Loopback +> inet addr:127.0.0.1 Mask:255.0.0.0 +> UP LOOPBACK RUNNING MTU:3856 Metric:1 +> ... +> +> vpn Link encap:Point-to-Point Protocol +> inet addr:192.168.10.20 P-t-P:192.168.10.20 Mask:255.255.0.0 +> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 +> ... +> +> host# route +> Kernel IP routing table +> Destination Gateway Genmask Flags Metric Ref Use Iface +> 123.234.123.0 * 255.255.255.0 U 0 0 0 eth0 +> 192.168.0.0 * 255.255.0.0 U 0 0 0 vpn +> default 123.234.123.1 0.0.0.0 UG 0 0 0 eth0 +> +> host# iptables -L -v +> Chain INPUT (policy ACCEPT 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> +> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain OUTPUT (policy ACCEPT 2161K packets, 364M bytes) +> pkts bytes target prot opt in out source destination +> +> host# iptables -L -v -t nat +> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination + +### Configuration of tinc + +> host# cat /etc/tinc/vpn/tinc.conf +> Name = atwork +> Device = /dev/tun +> ConnectTo = home +> +> host# cat /etc/tinc/vpn/tinc-up +> #!/bin/sh +> +> ifconfig vpn 192.168.10.20 netmask 255.255.0.0 +> +> host# ls /etc/tinc/vpn/hosts +> atwork home +> +> host# cat /etc/tinc/vpn/hosts/atwork +> Address = 123.234.123.42 +> Subnet = 192.168.10.20/32 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- +> +> host# cat /etc/tinc/vpn/hosts/home +> Address = 200.201.202.203 +> Subnet = 192.168.1.0/24 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- + +### Configuration of the firewall + +> firewall# ifconfig +> ppp0 Link encap:Point-to-Point Protocol +> inet addr:123.234.123.1 P-t-P:123.234.120.1 Mask:255.255.255.255 +> UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 +> ... +> +> eth0 Link encap:Ethernet HWaddr 00:20:13:14:15:16 +> inet addr:123.234.123.1 Bcast:123.234.123.255 Mask:255.255.255.0 +> UP BROADCAST RUNNING MTU:1500 Metric:1 +> ... +> +> lo Link encap:Local Loopback +> inet addr:127.0.0.1 Mask:255.0.0.0 +> UP LOOPBACK RUNNING MTU:3856 Metric:1 +> ... +> +> firewall# route +> Kernel IP routing table +> Destination Gateway Genmask Flags Metric Ref Use Iface +> 123.234.123.0 * 255.255.255.0 U 0 0 0 eth0 +> default 123.234.120.1 0.0.0.0 UG 0 0 0 ppp0 +> +> firewall# iptables -L -v +> Chain INPUT (policy ACCEPT 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> +> Chain FORWARD (policy DROP 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> 1234 123K ACCEPT tcp -- ppp0 eth0 anywhere 10.20.30.0/24 tcp flags:!SYN,RST,ACK/SYN +> 1234 123K ACCEPT any -- eth0 ppp0 10.20.30.0/24 anywhere +> 1234 123K ACCEPT tcp -- ppp0 eth0 anywhere 123.234.123.42 tcp dpt:655 +> 1234 123K ACCEPT udp -- ppp0 eth0 anywhere 123.234.123.42 udp dpt:655 +> +> Chain OUTPUT (policy ACCEPT 2161K packets, 364M bytes) +> pkts bytes target prot opt in out source destination +> +> firewall# iptables -L -v -t nat +> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> firewall # cat /etc/init.d/firewall +> #!/bin/sh +> +> echo 1 >/proc/sys/net/ipv4/ip_forward +> +> iptables -P FORWARD DROP +> iptables -F FORWARD +> iptables -A FORWARD -j ACCEPT -i ppp0 -d 10.20.30.0/24 -p tcp ! --syn +> iptables -A FORWARD -j ACCEPT -i eth0 -s 10.20.30.0/24 +> iptables -A FORWARD -j ACCEPT -i ppp0 -o eth0 -d 123.234.132.42 -p tcp --dport 655 +> iptables -A FORWARD -j ACCEPT -i ppp0 -o eth0 -d 123.234.132.42 -p udp --dport 655 diff --git a/examples/ipv6-network.mdwn b/examples/ipv6-network.mdwn new file mode 100644 index 0000000..485f566 --- /dev/null +++ b/examples/ipv6-network.mdwn @@ -0,0 +1,107 @@ +[[!meta title="setting up an IPv6 network managed by tinc"]] + +## Example: IPv6 Networking + +Michael Adams, 8-27-2007 +http://www.wolfsheep.com/ + +### Purpose + +This document is to highlight an example setup for using tinc to create an IPv6 network. + +### Example Layout + +[[!img examples/fig-ipv6-network.png link=examples/fig-ipv6-network.dia]] +*Click on the image for the original [DIA](http://en.wikipedia.org/wiki/Dia_(software)) file.* + +### Scenario Parameters + +1. IPv6 is provided via a native or tunnel-brokered service at a main site. If you need a tunnel, refer to Wikipedia's list of IPv6 tunnel brokers. +2. The IPv6 allocation given is 2001:db8:beef::/48, using a tunnel from 2001:db8:dead:beef::1 to 2001:db8:dead:beef::2. +3. All the tinc connections share a subnet of 2001:db8:beef:0::/64, and their addresses are tied to 2001:db8:beef:(subnet #)::/64 allocations. For example, "routerc" will listen on tinc at 2001:db8:beef::3, will have a LAN address of 2001:db8:beef:3::1, and a subnet of 2001:db8:beef:3::/64. +4. All the routers and servers using tinc connect over the IPv4 Internet, using WAN addresses based on 192.0.2.0/24. "routerc" uses 192.0.2.3. +5. "routera" is a Linux server that manages the #1 subnet, and makes the connection to the IPv6 Internet. +6. All other routers are assumed to be Linux based for their TUN/TAP support of bridged-Ethernet. + +### Configuration Files + +1. On Debian/Ubuntu systems, an entry in "/etc/network/interfaces" can be used to statically assign the ::1 address for the local LAN. Example: +> iface eth1 inet6 static +> address 2001:db8:beef::1::1 +> netmask 64 +> mtu 1280 + On non Debian/Ubuntu systems, a line can be put in a boot script, such as "ip -6 addr add 2001:db8:beef:1::1/64 dev eth1". + +2. IPv6 forwarding needs to be enabled: put "echo "1" >/proc/sys/net/ipv6/conf/all/forwarding" in a boot script, or "net.ipv6.conf.all.forwarding = 1" in "/etc/sysctl.conf". + +3. This setup uses tinc's "switch" mode: subnets are not assigned in the host files; only Address (for ConnectTo targets only) and the key are required in host files. + +4. It is assumed that the config files go into something like "/etc/tinc/link" and "/etc/tinc/nets.boot" has an entry for "link". The following table can be used to guide configuration of routers: + * "routera" configuration for tinc (the master router): +> >cat tinc.conf +> Name = routera +> Device=/dev/net/tun +> TCPOnly = on +> PMTU = 1280 +> PMTUDiscovery = yes +> Mode = switch +> Interface = vpn6 +> +> >cat tinc-up +> #!/bin/sh +> #Enable tinc +> ip -6 link set vpn6 up mtu 1280 txqueuelen 1000 +> ip -6 addr add 2001:db8:beef::1/64 dev vpn6 +> ip -6 route add 2001:db8:beef::/48 dev vpn6 +> #Static routing table +> ip -6 route add 2001:db8:beef:2::/64 via 2001:db8:beef::2 +> ip -6 route add 2001:db8:beef:3::/64 via 2001:db8:beef::3 +> ip -6 route add 2001:db8:beef:4::/64 via 2001:db8:beef::4 +> +> >cat tinc-down +> #!/bin/sh +> #Static routing table +> ip -6 route del 2001:db8:beef:2::/64 via 2001:db8:beef:::2 +> ip -6 route del 2001:db8:beef:3::/64 via 2001:db8:beef:::3 +> ip -6 route del 2001:db8:beef:4::/64 via 2001:db8:beef:::4 +> #Disable tinc +> ip -6 route del 2001:db8:beef::/48 dev vpn6 +> ip -6 addr del 2001:db8:beef::1/64 dev vpn6 +> ip -6 link set vpn6 down +> + * "routerb" configuration for tinc (the other non-master routers will be like this one): +> >cat tinc.conf +> Name=routerb +> Device=/dev/net/tun +> TCPOnly = yes +> PMTU = 1280 +> PMTUDiscovery = yes +> Mode = switch +> Interface = vpn6 +> ConnectTo = routera +> +> >cat tinc-up +> #!/bin/sh +> ip -6 link set vpn6 up mtu 1280 +> ip -6 addr add 2001:db8:beef::2/64 dev vpn6 +> ip -6 route add default via 2001:db8:beef::1 +> +> >cat tinc-down +> #!/bin/sh +> ip -6 route del default via 2001:db8:beef::1 +> ip -6 addr del 2001:db8:beef::2/64 dev vpn6 +> ip -6 link set vpn6 down + +5. You can use [radvd](http://www.litech.org/radvd/) or [Quagga](http://www.quagga.net/) to perform [stateless address autoconfiguration](http://www.ietf.org/rfc/rfc2462.txt) on your LAN. This is an example zebra.conf for LAN autoconfiguration (don't forget to enable the zebra daemon): +> ipv6 forwarding +> ! +> interface eth1 +> no ipv6 nd suppress-ra +> ipv6 address 2001:db8:beef:1::1/64 +> ipv6 nd prefix 2001:db8:beef:1::/64 +> ipv6 nd ra-interval 10 +> ! +> interface vpn6 +> ! +> interface lo + diff --git a/examples/masquerading-firewall.mdwn b/examples/masquerading-firewall.mdwn new file mode 100644 index 0000000..63377c1 --- /dev/null +++ b/examples/masquerading-firewall.mdwn @@ -0,0 +1,167 @@ +[[!meta title="tinc from behind a masquerading firewall"]] + +## Example: tinc from behind a masquerading firewall + +When running tinc from behind a masquerading firewall (not on the firewall +itself), one must be careful to configure the firewall so that it allows the +tinc traffic to pass through without altering the source and destination ports. +Example firewall rules are included in this example. They are written for +iptables (Linux 2.4 firewall code), but commented so that you may apply the +same kind of rules to other firewalls. + +[[!toc levels=2]] + +### Overview + +[[!img examples/fig-firewall.png]] + +The network setup is as follows: + +* Internal network is 10.20.30.0/24 +* Firewall IP is 123.234.123.1 on the outside, 10.20.30.1/24 on the inside. +* Host running tinc has IP 10.20.30.42 +* VPN the host wants to connect to has address range 192.168.0.0/16 +* The host has it's own VPN IP 192.168.10.20 + +### Configuration of the host running tinc + +> host# ifconfig +> eth0 Link encap:Ethernet HWaddr 00:20:30:40:50:60 +> inet addr:10.20.30.42 Bcast:10.20.30.255 Mask:255.255.255.0 +> UP BROADCAST RUNNING MTU:1500 Metric:1 +> ... +> +> lo Link encap:Local Loopback +> inet addr:127.0.0.1 Mask:255.0.0.0 +> UP LOOPBACK RUNNING MTU:3856 Metric:1 +> ... +> +> vpn Link encap:Point-to-Point Protocol +> inet addr:192.168.10.20 P-t-P:192.168.10.20 Mask:255.255.0.0 +> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 +> ... +> +> host# route +> Kernel IP routing table +> Destination Gateway Genmask Flags Metric Ref Use Iface +> 10.20.30.0 * 255.255.255.0 U 0 0 0 eth0 +> 192.168.0.0 * 255.255.0.0 U 0 0 0 vpn +> default 10.20.30.1 0.0.0.0 UG 0 0 0 eth0 +> +> host# iptables -L -v +> Chain INPUT (policy ACCEPT 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> +> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain OUTPUT (policy ACCEPT 2161K packets, 364M bytes) +> pkts bytes target prot opt in out source destination +> +> host# iptables -L -v -t nat +> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination + +### Configuration of tinc + +> host# cat /etc/tinc/vpn/tinc.conf +> Name = atwork +> Device = /dev/tun +> ConnectTo = home +> +> host# cat /etc/tinc/vpn/tinc-up +> #!/bin/sh +> +> ifconfig vpn 192.168.10.20 netmask 255.255.0.0 +> +> host# ls /etc/tinc/vpn/hosts +> atwork home +> +> host# cat /etc/tinc/vpn/hosts/atwork +> Address = 123.234.123.1 +> Subnet = 192.168.10.20/32 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- +> +> host# cat /etc/tinc/vpn/hosts/home +> Address = 200.201.202.203 +> Subnet = 192.168.1.0/24 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- + +### Configuration of the firewall + +> firewall# ifconfig +> ppp0 Link encap:Point-to-Point Protocol +> inet addr:123.234.123.1 P-t-P:123.234.120.1 Mask:255.255.255.255 +> UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 +> ... +> +> eth0 Link encap:Ethernet HWaddr 00:20:13:14:15:16 +> inet addr:10.20.30.1 Bcast:10.20.30.255 Mask:255.255.255.0 +> UP BROADCAST RUNNING MTU:1500 Metric:1 +> ... +> +> lo Link encap:Local Loopback +> inet addr:127.0.0.1 Mask:255.0.0.0 +> UP LOOPBACK RUNNING MTU:3856 Metric:1 +> ... +> +> firewall# route +> Kernel IP routing table +> Destination Gateway Genmask Flags Metric Ref Use Iface +> 10.20.30.0 * 255.255.255.0 U 0 0 0 eth0 +> default 123.234.120.1 0.0.0.0 UG 0 0 0 ppp0 +> +> firewall# iptables -L -v +> Chain INPUT (policy ACCEPT 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> +> Chain FORWARD (policy DROP 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> 1234 123K ACCEPT any -- ppp0 eth0 anywhere 10.20.30.0/24 +> 1234 123K ACCEPT any -- eth0 ppp0 10.20.30.0/24 anywhere +> +> Chain OUTPUT (policy ACCEPT 2161K packets, 364M bytes) +> pkts bytes target prot opt in out source destination +> +> firewall# iptables -L -v -t nat +> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> 1234 123K DNAT tcp -- ppp0 any anywhere anywhere tcp dpt:655 to:10.20.30.42:655 +> 1234 123K DNAT udp -- ppp0 any anywhere anywhere udp dpt:655 to:10.20.30.42:655 +> +> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> 1234 123K MASQUERADE all -- eth0 ppp0 anywhere anywhere +> +> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> firewall# cat /etc/init.d/firewall +> #!/bin/sh +> +> echo 1 >/proc/sys/net/ipv4/ip_forward +> +> iptables -P FORWARD DROP +> iptables -F FORWARD +> iptables -A FORWARD -j ACCEPT -i ppp0 -o eth0 -d 10.20.30.0/24 +> iptables -A FORWARD -j ACCEPT -i eth0 -o ppp0 -s 10.20.30.0/24 +> +> iptables -t nat -F POSTROUTING +> # Next rule prevents masquerading from altering source port of outbound tinc packets +> iptables -t nat -A POSTROUTING -p udp -m udp -sport 655 -j MASQUERADE -o ppp0 --to-ports 655 +> iptables -t nat -A POSTROUTING -j MASQUERADE -o ppp0 +> +> iptables -t nat -F PREROUTING +> # Next two rules forward incoming tinc packets to the host behind the firewall running tinc +> iptables -t nat -A PREROUTING -j DNAT -i ppp0 -p tcp --dport 655 --to 10.20.30.42:655 +> iptables -t nat -A PREROUTING -j DNAT -i ppp0 -p udp --dport 655 --to 10.20.30.42:655 diff --git a/examples/on-firewall.mdwn b/examples/on-firewall.mdwn new file mode 100644 index 0000000..e2cce3f --- /dev/null +++ b/examples/on-firewall.mdwn @@ -0,0 +1,127 @@ +[[!meta title="tinc on a masquerading firewall"]] + +## Example: tinc on a masquerading firewall + +This example shows a setup with tinc running on a masquerading +firewall, allowing the private subnet behind the firewall to access +the VPN. Example firewall rules are included in this example. They +are written for iptables (Linux 2.4 firewall code), but commented +so that you may apply the same kind of rules to other firewalls. + +[[!toc levels=2]] + +### Overview + +[[!img examples/fig-on-firewall]] + +The network setup is as follows: + +* Internal network is 10.20.30.0/24 +* Firewall IP is 123.234.123.1 on the outside, 10.20.30.1/24 on the inside. +* VPN the host wants to connect to has address range 10.20.0.0/16. + +### Configuration of the firewall running tinc + +> firewall# ifconfig +> ppp0 Link encap:Point-to-Point Protocol +> inet addr:123.234.123.1 P-t-P:123.234.120.1 Mask:255.255.255.255 +> UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 +> ... +> +> eth0 Link encap:Ethernet HWaddr 00:20:13:14:15:16 +> inet addr:10.20.30.1 Bcast:10.20.30.255 Mask:255.255.255.0 +> UP BROADCAST RUNNING MTU:1500 Metric:1 +> ... +> +> lo Link encap:Local Loopback +> inet addr:127.0.0.1 Mask:255.0.0.0 +> UP LOOPBACK RUNNING MTU:3856 Metric:1 +> ... +> +> vpn Link encap:Point-to-Point Protocol +> inet addr:10.20.30.1 P-t-P:10.20.30.1 Mask:255.255.0.0 +> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 +> ... +> +> firewall# route +> Kernel IP routing table +> Destination Gateway Genmask Flags Metric Ref Use Iface +> 10.20.30.0 * 255.255.255.0 U 0 0 0 eth0 +> 10.20.0.0 * 255.255.0.0 U 0 0 0 vpn +> default 123.234.120.1 0.0.0.0 UG 0 0 0 ppp0 +> +> firewall# iptables -L -v +> Chain INPUT (policy ACCEPT 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> +> Chain FORWARD (policy DROP 1234 packets, 123K bytes) +> pkts bytes target prot opt in out source destination +> 1234 123K ACCEPT any -- ppp0 eth0 anywhere 10.20.30.0/24 +> 1234 123K ACCEPT any -- eth0 ppp0 10.20.30.0/24 anywhere +> 1234 123K ACCEPT any -- vpn eth0 10.20.0.0/16 10.20.30.0/24 +> 1234 123K ACCEPT any -- eth0 vpn 10.20.30.0/24 10.20.0.0/16 +> +> Chain OUTPUT (policy ACCEPT 2161K packets, 364M bytes) +> pkts bytes target prot opt in out source destination +> +> firewall# iptables -L -v -t nat +> Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> 1234 123K MASQUERADE all -- eth0 ppp0 anywhere anywhere +> +> Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) +> pkts bytes target prot opt in out source destination +> +> firewall# cat /etc/init.d/firewall +> #!/bin/sh +> +> echo 1 >/proc/sys/net/ipv4/ip_forward +> +> iptables -P FORWARD DROP +> iptables -F FORWARD +> iptables -A FORWARD -j ACCEPT -i ppp0 -o eth0 -d 10.20.30.0/24 +> iptables -A FORWARD -j ACCEPT -i eth0 -o ppp0 -s 10.20.30.0/24 +> iptables -A FORWARD -j ACCEPT -i vpn -o eth0 -s 10.20.0.0/16 -d 10.20.30.0/24 +> iptables -A FORWARD -j ACCEPT -i eth0 -o vpn -s 10.20.30.0/24 -d 10.20.0.0/16 +> +> iptables -t nat -F POSTROUTING +> iptables -t nat -A POSTROUTING -j MASQUERADE -i eth0 -o ppp0 + +### Configuration of tinc + +> firewall# cat /etc/tinc/vpn/tinc.conf +> Name = office +> Device = /dev/tun +> ConnectTo = branch +> +> firewall# cat /etc/tinc/vpn/tinc-up +> #!/bin/sh +> +> ifconfig vpn 10.20.30.1 netmask 255.255.0.0 +> +> firewall# ls /etc/tinc/vpn/hosts +> office branch employee_smith employee_jones ... +> +> firewall# cat /etc/tinc/vpn/hosts/office +> Address = 123.234.123.1 +> Subnet = 10.20.30.0/24 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- +> +> firewall# cat /etc/tinc/vpn/hosts/branch +> Address = 123.234.213.129 +> Subnet = 10.20.40.0/24 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- +> +> firewall# cat /etc/tinc/vpn/hosts/employee_smith +> Address = 200.201.202.203 +> Subnet = 10.20.50.1/32 +> -----BEGIN RSA PUBLIC KEY----- +> ... +> -----END RSA PUBLIC KEY----- diff --git a/examples/osx-install.mdwn b/examples/osx-install.mdwn new file mode 100644 index 0000000..abde571 --- /dev/null +++ b/examples/osx-install.mdwn @@ -0,0 +1,161 @@ +[[!meta title="installing tinc on Mac OS/X"]] + +## Example: installing tinc on Mac OS/X + +This example shows how to install and configure tinc on Mac OS X. +The following was tested on Leopard based system, however should be +generalisable to other Apple systems as well. +This document is intended to give a step-by-step instruction on how +to install tinc and how to configure it to be used as a basic +client for tinc server. + +[[!toc levels=3]] + +### Overview and assumptions + +The following documents is designed to allow you an easy and fast +installation/configuration of tinc. It deals with the client side +only and the assumption is that you have a tinc server configured +and running properly. + +### Installing tinc + +There are two ways of getting tinc: +compiling it or downloading a precompiled binary. +The second option (download it) - is easier and faster way of +getting tinc to work. + +#### Compile it + +In the case of compiling tinc the following is required: + +* [XCode](http://developer.apple.com/technology/Xcode.html) (requires + free online ADC Membership); it can also be obtained from original + OSX installation DVD +* [LZO libraries](http://www.oberhumer.com/opensource/lzo/) + +It is expected that you know how to install XCode. Moreover, most +of the operations will be carried using Terminal/Console and thus +you should be comfortable using some basic commands. +The general steps are as follows - install XCode, install LZO, +install Tinc. + +Before starting, create a new folder `tmp` in your home directory +and enter it (it can be any other location). From Terminal level it +can be done in the following way: + +[[!img examples/osx-tmp.png]] + +##### LZO + +Download LZO (you can use `wget` or Safari to do it). I used LZO +version 2.03 ("lzo-2.03.tar.gz"). Using `wget:` + +[[!img examples/osx/lzo1.png]] + +Unpack it, enter the directory: + +[[!img examples/osx/lzo2.png]] + +And issue `configure/make:` + +[[!img examples/osx/lzo3.png]] + +If everything goes well, after a few minutes the operation will be +finished, execute make install using root rights (using `sudo` +prefix): + +[[!img examples/osx/lzo4.png]] + +Having installed LZO, we can install tinc. + +##### Tinc + +Download Tinc (again you can use `wget` or Safari to do it). I used +Tinc version 1.09 ("tinc-1.09.tar.gz"). Using the same approach as +before - download and extract it: + +[[!img examples/osx/tinc1.png]] + +Enter the directory, and execute configure, make, make install: + +[[!img examples/osx/tinc2.png]] + +Having installed Tinc, you can move to the [next section](#config). + +#### Download it + +Link: [tincd](tincd-1.0.9.zip). Please note that this archieve +provides only the executable and does not include any manual. Once +downloaded, place the extracted executable into `/usr/sbin/`. + +### Configuring tinc + +Tinc on OS X looks for configuration files in `/usr/etc/tinc`. In +our case we will place configuration files in `~/Library/tinc/`. +Navigate to your home directory and create configuration folders +for your `company` (see manual for details). In my case it is +called `myvpn`. + +[[!img examples/osx/config1.png]] + +For further steps the following assumptions are made: the server to +connect to has name `myserver` and the client we are configuring: +`myclient0`. +You will need to create the following files and folders within: + +- [[tinc.conf|examples/osx/tinc.conf]] +- [[tinc-up|examples/osx/tinc-up]] +- [[tinc-down|examples/osx/tinc-down]] +- [[hosts/myserver|examples/osx/myserver]] +- [[hosts/myclient0|examples/osx/myclient0]] + +The sample files contain necessary explanation to make it work. +Make sure `tinc-up` and `tinc-down` are executable: + +[[!img examples/osx/config2.png]] + +You will also need to generate pair of keys (private/public) for +your client. Do it only after the above files are configured +properly! You will be asked for locations of certain files. The +default locations are fine. + +[[!img examples/osx/config3.png]] + +Once you are done, copy `hosts/myclient0` file and place it on your +server in the same location (`hosts/myclient0`). At this stage your +client should be able to connect to the server. + +### Starting tinc + +To start tinc everything you need is to execute: + +[[!img examples/osx/start1.png]] + +Tincd will issue a notice once it is successfully connected. For +more details on the syntax check `tincd --help`. +To stop the client you can kill it be executing: + +[[!img examples/osx/start2.png]] + +### Configuring tinc-up and tinc-down scripts + +`tincd-up` and `tincd-down` are two files that tincd executes on +start of the service and on stop respectively. They are usually +used to notify system to use the vpn as a default gateway. The +files provided in the previous page are minimalistic and used only +to bring up and down the interface. If you would like to tunnel all +the traffic over vpn use the scripts provided below. You have to +modify them accordingly to your configuration. Please see the notes +inside them: + +- [[tinc-up|examples/osx/tinc-up-1]] (Advanced example) +- [[tinc-down|examples/osx/tinc-down-1]] (Advanced example) + +Please remember to rename the files to `tinc-up` and `tinc-down` +respectively and place them in your configuration folder replacing +the two existing files (if applicable). + +* * * * * + +Grzegorz Dymarek (gd58 (at) alumni . st-andrews . ac . uk) diff --git a/examples/osx/config1.png b/examples/osx/config1.png new file mode 100644 index 0000000..bfb796a Binary files /dev/null and b/examples/osx/config1.png differ diff --git a/examples/osx/config2.png b/examples/osx/config2.png new file mode 100644 index 0000000..dc319c1 Binary files /dev/null and b/examples/osx/config2.png differ diff --git a/examples/osx/config3.png b/examples/osx/config3.png new file mode 100644 index 0000000..4d51b26 Binary files /dev/null and b/examples/osx/config3.png differ diff --git a/examples/osx/lzo1.png b/examples/osx/lzo1.png new file mode 100644 index 0000000..5f240ea Binary files /dev/null and b/examples/osx/lzo1.png differ diff --git a/examples/osx/lzo2.png b/examples/osx/lzo2.png new file mode 100644 index 0000000..5ac2c0f Binary files /dev/null and b/examples/osx/lzo2.png differ diff --git a/examples/osx/lzo3.png b/examples/osx/lzo3.png new file mode 100644 index 0000000..9088e12 Binary files /dev/null and b/examples/osx/lzo3.png differ diff --git a/examples/osx/lzo4.png b/examples/osx/lzo4.png new file mode 100644 index 0000000..f5a1f4f Binary files /dev/null and b/examples/osx/lzo4.png differ diff --git a/examples/osx/myclient0 b/examples/osx/myclient0 new file mode 100644 index 0000000..683c469 --- /dev/null +++ b/examples/osx/myclient0 @@ -0,0 +1 @@ +Subnet = 192.168.1.2/32 ;here goes subnet, however in the most cases the client is an end node and therefore a subnet equal to a host is totally fine. In such case be sure to specify 32bit mask! diff --git a/examples/osx/myserver b/examples/osx/myserver new file mode 100644 index 0000000..83b389d --- /dev/null +++ b/examples/osx/myserver @@ -0,0 +1,5 @@ +;this file should be obtained from the server side! Here is a standard configuration! + +Subnet 0.0.0.0/0 ;if you intend the server to act as default gateway leave the subnet as it is + +Address = server.com ;the address of the computer to connect to IP/hostname \ No newline at end of file diff --git a/examples/osx/start1.png b/examples/osx/start1.png new file mode 100644 index 0000000..d53aa03 Binary files /dev/null and b/examples/osx/start1.png differ diff --git a/examples/osx/start2.png b/examples/osx/start2.png new file mode 100644 index 0000000..b1cd563 Binary files /dev/null and b/examples/osx/start2.png differ diff --git a/examples/osx/tinc-down b/examples/osx/tinc-down new file mode 100644 index 0000000..5c34b78 --- /dev/null +++ b/examples/osx/tinc-down @@ -0,0 +1,4 @@ +#!/bin/sh +ifconfig $INTERFACE down #just bring down the interface. leave it as it is + + diff --git a/examples/osx/tinc-down-1 b/examples/osx/tinc-down-1 new file mode 100644 index 0000000..8ad42c9 --- /dev/null +++ b/examples/osx/tinc-down-1 @@ -0,0 +1,7 @@ +#!/bin/sh +ifconfig $INTERFACE down + +#delete according to tinc-up +route delete 192.168.1.0/24 +route delete server_ip/32 #modify server_ip +route delete 192.168.1.2 diff --git a/examples/osx/tinc-up b/examples/osx/tinc-up new file mode 100644 index 0000000..999f651 --- /dev/null +++ b/examples/osx/tinc-up @@ -0,0 +1,3 @@ +#!/bin/sh + +ifconfig $INTERFACE 192.168.1.2 192.168.1.3 mtu 1500 netmask 255.255.255.255 #bring up an interface with ip 192.168.1.2. (the ip has to be the same as in you /hosts/myclient0 file). The second ip (192.168.1.3) is the ip of the client on the other side of the vpn tunnel. Usually it is set to be the next available ip. diff --git a/examples/osx/tinc-up-1 b/examples/osx/tinc-up-1 new file mode 100644 index 0000000..54116bd --- /dev/null +++ b/examples/osx/tinc-up-1 @@ -0,0 +1,14 @@ +#!/bin/sh + +ifconfig $INTERFACE 192.168.1.2 192.168.1.3 mtu 1500 netmask 255.255.255.255 + +#route traffic on 192.168.1.0/24 over our vpn +route add -net 192.168.1.2 192.168.1.3 255.255.255.0 + +#make all traffic to be sent over our vpn + route add -net 0.0.0.0 192.168.1.3 128.0.0.0 + route add -net 128.0.0.0 192.168.1.3 128.0.0.0 + +#keep normal route to server +route add -net server_ip our_default_gateway 255.255.255.255 + diff --git a/examples/osx/tinc.conf b/examples/osx/tinc.conf new file mode 100644 index 0000000..48fa42b --- /dev/null +++ b/examples/osx/tinc.conf @@ -0,0 +1,5 @@ +Name = myclient0 ;specify name for your client (remember that a file of the same name has to be in hosts folder!) Tinc uses the name as a reference to a file in hosts/ and read further configuration from there + +ConnectTo = myserver ;as above, but specify the name of your server (not address!!). Address is read from respective /hosts/ file + +TCPonly=no ;use UDP for connection diff --git a/examples/osx/tinc1.png b/examples/osx/tinc1.png new file mode 100644 index 0000000..52cb7ad Binary files /dev/null and b/examples/osx/tinc1.png differ diff --git a/examples/osx/tinc2.png b/examples/osx/tinc2.png new file mode 100644 index 0000000..ca7bf3c Binary files /dev/null and b/examples/osx/tinc2.png differ diff --git a/examples/osx/tmp.png b/examples/osx/tmp.png new file mode 100644 index 0000000..0aa3c1c Binary files /dev/null and b/examples/osx/tmp.png differ diff --git a/examples/windows-install.mdwn b/examples/windows-install.mdwn new file mode 100644 index 0000000..c41c8f7 --- /dev/null +++ b/examples/windows-install.mdwn @@ -0,0 +1,106 @@ +[[!meta title="installing tinc on Windows 2000/XP"]] + +## Example: installing tinc on Windows 2000/XP + +This example shows how to install and configure tinc on Windows 2000 or XP. It +is not a HOWTO, it is recommended that you read the manual as well. + +[[!toc levels=2]] + +### Downloading and installing tinc + +First, [[download]] the installer from the website. You don't have to save it, +run it from its current location. + +[[!img examples/windows/download.png]] + +Follow the instructions of the installer. If you already installed a TAP-Win32 +or CIPE driver, you can uncheck the TAP-Win32 driver component. + +[[!img examples/windows/components.png]] + +### Configuring tinc + +Next, open the explorer and go to the directory where you installed tinc. This +probably is `C:\Program Files\tinc`. To start configuring tinc for your VPN, +create a new folder and give it the name of your VPN (if you don't have a name +for it, use `vpn` or make one up). + +[[!img examples/windows/newfolder.png]] + +In this folder you will have to create a new file named `tinc.conf`. + +[[!img examples/windows/newfile.png]] + +Open this file with notepad or wordpad. In this file you have to specify the +name of your computer on the VPN. This doesn't have to be the name you gave to +Windows, we assume you're calling it `home`. You can also specify to which other +tinc daemons you want to connect. You should also specify the network interface +that tinc will use. We will create that interface later, we will assume it is +called something like `VPN`. + +[[!img examples/windows/editconf.png]] + +In the current directory, you have to create a directory called `hosts`. In this +directory the host configuration files are stored. First you have to create one +for your own tinc daemon. The name of the file must be the same as the Name you +specified in the `tinc.conf` file: `home`. This file should contain a Subnet +variable, indicating which IP addresses your tinc daemon represents on the VPN. +This is probably just a single address, we will assume the subnet is +10.20.40.1/32. + +[[!img examples/windows/hostshome.png]] + +Now you have to generate the public and private key for your tinc daemon. You +do this by starting command.com. Go to the directory where tinc is installed. +Start tinc with the `-n` option set to the name of your VPN and use the `-K` +option: `tincd -n vpn -K`. The keypair will be generated, and you are asked to +enter the names of the files to store them. + +[[!img examples/windows/genkey.png]] + +Now that the keys are generated, you should give the office a copy of your +`hosts\home`, and you should get a copy of `hosts\office` and store it in your +`hosts\ directory`. The configuration of tinc is finished. + +[[!img examples/windows/files.png]] + +### Configuring the virtual network device + +Next you will have to set up the virtual network device. The installer will not +create those for you, you have to run `addtap.bat` in tinc's installation +directory. This will add a new virtual network device. (If you want to run more +than one tinc daemon, you will need to create extra virtual network devices.) + +[[!img examples/windows/addtap.png]] + +After that, open the Network and Dial-up connections control panel, and change +the name of the new interface to the same as you specified in `tinc.conf`, in +our case to `VPN`. + +[[!img examples/windows/rename.png]] + +Then, double-click on the new interface. You can enable the icon in the taskbar +if you want. Click on Internet Protocol and then on Configure. Manually set the +address to that of your computer on the VPN, in this example 10.20.40.1. The +subnet mask should be set to that of the entire VPN, in this example +255.255.0.0. + +[[!img examples/windows/configure.png]] + +### Starting tinc + +Now that everything has been set up, it is time to start tinc. Start +command.com, go to tinc's installation directory and start tinc with the right +`-n` option: `tincd -n vpn`. If everything went well, it will tell you that it +installed itself as a service and started it. + +[[!img examples/windows/start.png]] + +If you enabled the taskbar icon, you will notice that it changes form: + +[[!img examples/windows/iconstarted.png]] + +You can temporarily stop and start tinc from the Service control panel. + +[[!img examples/windows/servicemgr.png]] diff --git a/examples/windows/addtap.png b/examples/windows/addtap.png new file mode 100644 index 0000000..60e02fa Binary files /dev/null and b/examples/windows/addtap.png differ diff --git a/examples/windows/components.png b/examples/windows/components.png new file mode 100644 index 0000000..32d9167 Binary files /dev/null and b/examples/windows/components.png differ diff --git a/examples/windows/configure.png b/examples/windows/configure.png new file mode 100644 index 0000000..91cf9f7 Binary files /dev/null and b/examples/windows/configure.png differ diff --git a/examples/windows/download.png b/examples/windows/download.png new file mode 100644 index 0000000..afbe92a Binary files /dev/null and b/examples/windows/download.png differ diff --git a/examples/windows/edithostshome.png b/examples/windows/edithostshome.png new file mode 100644 index 0000000..99edd58 Binary files /dev/null and b/examples/windows/edithostshome.png differ diff --git a/examples/windows/edittincconf.png b/examples/windows/edittincconf.png new file mode 100644 index 0000000..b5daf7a Binary files /dev/null and b/examples/windows/edittincconf.png differ diff --git a/examples/windows/files.png b/examples/windows/files.png new file mode 100644 index 0000000..a559bbd Binary files /dev/null and b/examples/windows/files.png differ diff --git a/examples/windows/genkey.png b/examples/windows/genkey.png new file mode 100644 index 0000000..e0c8cd2 Binary files /dev/null and b/examples/windows/genkey.png differ diff --git a/examples/windows/iconstarted.png b/examples/windows/iconstarted.png new file mode 100644 index 0000000..e96c713 Binary files /dev/null and b/examples/windows/iconstarted.png differ diff --git a/examples/windows/newfile.png b/examples/windows/newfile.png new file mode 100644 index 0000000..7ba0505 Binary files /dev/null and b/examples/windows/newfile.png differ diff --git a/examples/windows/newfolder.png b/examples/windows/newfolder.png new file mode 100644 index 0000000..6ca562d Binary files /dev/null and b/examples/windows/newfolder.png differ diff --git a/examples/windows/rename.png b/examples/windows/rename.png new file mode 100644 index 0000000..54bb2e9 Binary files /dev/null and b/examples/windows/rename.png differ diff --git a/examples/windows/servicemgr.png b/examples/windows/servicemgr.png new file mode 100644 index 0000000..fbeadf0 Binary files /dev/null and b/examples/windows/servicemgr.png differ diff --git a/examples/windows/start.png b/examples/windows/start.png new file mode 100644 index 0000000..4a3b17a Binary files /dev/null and b/examples/windows/start.png differ diff --git a/examples/windows/startservice.png b/examples/windows/startservice.png new file mode 100644 index 0000000..a9137b0 Binary files /dev/null and b/examples/windows/startservice.png differ diff --git a/faq.mdwn b/faq.mdwn new file mode 100644 index 0000000..6e5dcb3 --- /dev/null +++ b/faq.mdwn @@ -0,0 +1,71 @@ +## Frequently Asked Questions + +If you have a common problem or question, you will probably be able to find an answer here. If it is not here, and even the documentation is of no help, please contact the authors. + +[[!toc levels=2]] + +##Error messages + +### Tinc doesn't start, but doesn't show an error message + +If you're are using tinc 1.0.2, chances are tinc cannot write the pidfile. Normally tinc would tell you this, but in this particular version that error message is missing. When starting tinc, add --pidfile=/tmp/tinc.pid or run mkdir -p /usr/local/var/run to solve this problem. + +This bug is fixed in 1.0.3. + +### File descriptor in bad state + + Jan 1 12:00:00 host tinc.net[1234]: Error while reading from ethertap device: File descriptor in bad state + +Due to some changes in the header files in recent Linux 2.4 kernels, a tinc daemon that is not recompiled against your kernel headers will fail to work. You must recompile tinc and make sure it uses the header files from the kernel source tree. Some distributions ship with their own copy of these files in /usr/include/linux, you can explicitly override this by running ./configure --with-kernel=[path to kernel source]. + +### Tinc stops functioning after a few hours + +There is a small bug in the tinc 1.0pre4 tarball which prevents tinc from notifying the other daemons that its key has expired. One workaround is to edit tinc.conf and add KeyExpire = 30000000, which will set the lifetime of a key to roughly one year. + +The bug is fixed in 1.0pre5 and later versions. + +### Packets looping back to us + + Jan 1 12:00:00 host tinc.net[1234]: Packet with destination 192.168.1.1 is looping back to us! + +A packet is received from the tapdevice, and tinc tries to send it to the right destination, but finds out that this packet should be send to itself. Chances are that a "Subnet = ..." line in the host configuration file of this tinc daemon is wrong. Change it to a subnet that is accepted locally by another interface, or if that is not the case, try changing the prefix length into /32. + +### Address family not supported by protocol + + Jan 1 12:00:00 host tinc.net[1234]: Creating metasocket failed: Address family not supported by protocol + Jan 1 12:00:00 host tinc.net[1234]: Ready + +This is not an error, but a warning. Tinc 1.0 and later try to create IPv6 sockets by default. If your kernel has no support for IPv6, this message is logged. However, if tinc logs "Ready", an IPv4 socket was created without problems, and that one will be used. You can ignore this message, or prevent it from appearing in your logs by adding the following to tinc.conf: + + AddressFamily = ipv4 + +## Platform specific questions + +### No TAP-Win32 interface under Windows XP SP2 + +Because of changes in Windows XP since SP2, the TAP-Win32 driver distributed with the tinc-1.0.2 installer doesn't work correctly. Remove all tap devices (use deltapall.bat) and install tinc 1.0.4. + +## Generic questions + +### Why tinc? + +> Question: I've been using VPNs in a production environment, and until now that has been with FreeS/WAN. I would like to know what the differences are between tinc and FreeS/WAN. + +Here's what we think of that: + +* FreeS/WAN requires a kernel patch (IPSec is not yet a part of the mainstream kernel), while tinc runs completely in userspace. The advantages of the latter should be clear: portability is increased and errors in the implementation will not lead to kernel crashes. +* Both FreeS/WAN and tinc use tunnels to send packets, but with FreeS/WAN, all tunnels have to be explicitly configured on all hosts, while tinc can set up a large part of the tunnels without requiring too much changing of configuration files. For the addition of 1 extra host in a VPN that is already made out of X hosts, FreeS/WAN requires a modification in X+1 configuration files, while for tinc, only 2 modifications are required. +* tinc is made for solidness: some disfunctional hosts on the VPN won't lead to the coming down of the entire VPN, while this is not true for most VPN implementations (especially when a star topology is used and the central node goes down). +* Configuring tinc is mostly experienced to be easier than that of FreeS/WAN (according to users of both packages). +* tinc will support the transmission of any kind of network package, not limiting it to IPv4 or IPv6. Multicast and broadcast packets will also be supported in the future. + +Other reasons to use tinc instead of other solutions: + +* Although tinc uses a non-standard protocol, it does not suffer from the inefficiencies of most of the standard protocols. +* The executable is very small, less than 100 kilobytes, the virtual memory footprint is about 4 megabytes (this includes the libraries it uses). + +### Is there a MS Windows client for tinc? + +> Question: We are about to use a Linux machine as a firewall to protect our office setup. We are interested in using tinc to allow us to VPN through the firewall from home however home machines have a tendency to be running "that" operating system, the one from Redmond. Is there a tinc compatible VPN client for machines running Microsoft operating systems? + +As of tinc 1.0, Windows 2000 and XP are supported. It uses the TAP-Win32 driver as a virtual network device. There are two ways of compiling tinc: in a Cygwin environment or in a MinGW environment. The former provides a complete UNIX environment with all facilities common to UNIX. When compiled with Cygwin, tinc must be run in the Cygwin environment, but native Windows programs will also be able to use the VPN. When compiled with MinGW, tinc will be a native Windows program. When started, it will register itself as a service, which will run in the background and will be restarted after reboots. diff --git a/features.mdwn b/features.mdwn new file mode 100644 index 0000000..1875856 --- /dev/null +++ b/features.mdwn @@ -0,0 +1,8 @@ +## Features + +- Uses OpenSSL library for all cryptographic routines +- Protection against packet alteration and replay attacks +- Tunnels over UDP for high efficiency +- Scalable to many sites +- Supports bridging multiple ethernet segments +- Runs on many UNIX platforms (Linux, Net/Free/OpenBSD, Solaris, MacOS/X) as well as Windows (2000, XP) diff --git a/footer.mdwn b/footer.mdwn new file mode 100644 index 0000000..139597f --- /dev/null +++ b/footer.mdwn @@ -0,0 +1,2 @@ + + diff --git a/goals.mdwn b/goals.mdwn new file mode 100644 index 0000000..41a5a10 --- /dev/null +++ b/goals.mdwn @@ -0,0 +1,181 @@ +## Design goals + +This is a list of the design goals for tinc, sorted on importance. +Although we already achieved a lot of what is below, not all goals +are covered yet. + +**Be as secure as possible** + +This should of course be the primary goal of any VPN +implementation. Security is not only achieved by applying strong +cryptography, we are also trying to make tinc free of buffer +overflows and other design faults that could allow root exploits, +trying to prevent private data from lying around (in memory, swap +or regular files), trying to prevent errors from human carelessness +(wrong permissions on files containing the configuration and +private keys), trying to avoid security problems arising from the +interaction between different (security) mechanisms. We also hope +we can get a lot of people and possibly security experts to audit +our code. + +**Allow for scalability** + +After our first real stable implementation of tinc (around version +0.2.19), we noticed that setting up a large VPN with many sites +required a lot of tunnels. Even worse, because we used a star +network, the node in the middle was passing through a lot of +network traffic for other nodes. From then on we tried to make the +tinc daemon accept more than one connection, and let the tinc +daemons contact each other directly in the most direct way, without +requiring the VPN sites to configure all those direct routes +themselves. We hope to let tinc scale to VPNs with over 1000 +sites. + +**Stability and reliability** + +We are trying to make sure the tinc daemons stay up and running no +matter what happens. Network errors should not be a reason for +requiring an administrator to restart the daemons. We try to make +sure tinc runs as long as your UPS does. + +**Easy configuration** + +The configuration of tinc should be as easy as possible. Any error +made in the configuration files can be a compromise to security. +However, we do require the administrator to have a good knowledge +of network administration. + +**Flexibility** + +Of course, we want tinc to be able to run in any kind of setup or +environment. We try to make tinc run on as many operating systems +and architectures as possible, and make it provide a solution for +any network topology. + +## Plans for tinc 1.0.x + +The stable branch of tinc, with version numbers 1.0.x, will not see +any significant development. Only bugs will be fixed, and perhaps +non-invasive features that do not conflict with existing features +and do not depend on new libraries might be added. + +## Plans for tinc 1.1 + +The 1.1 branch of tinc has been created as a stepping stone towards +2.0. Only gradual changes to the source code are allowed, ensuring +that the code is always in a mostly usable state. The protocol will +stay compatible with that of the 1.0 branch. The following features +are planned in this branch: + +**Replaceble cryptography backend** + +The 1.0 branch uses OpenSSL exclusively. Although this library is +well known and widely available, it has two drawbacks: it is quite +large and its license is not completely compatible with the GPL. In +1.1 there will be an abstraction layer that allows tinc to be +linked with different cryptography libraries. At least OpenSSL and +libgcrypt will be supported. + +**Control socket** + +The 1.0 branch has limitted support to control a running tinc +daemon. In 1.1 the tinc daemon will have a control socket that +allows a tinc control program to connect to it and issue commands +to or retrieve information from the running daemon. This will also +allow for a GUI or dock applet to control tinc or show its status. + +**Automatic connection management** + +The 1.0 branch can exchange packets directly with other peers via +UDP, creating a full mesh. However, the TCP control connections are +only made according to the manually specified ConnectTo statements +in the tinc.conf files. It is desirable to have tinc manage the +creation of control connections as well, so that the administrator +does not have to do this manually anymore. + +**Deal with NAT** + +The 1.0 branch by default tries to exchange packets via UDP. +However, if one or more peers are behind a NAT, and source ports +might be changed or packets may not arrive at all, the +administrator had to manually enable the TCPOnly option or use +another workaround to get tinc to work. Tinc should be able to cope +with altered source ports, and should detect whether or not packet +exchange via UDP works at all, and if not fall back to TCP. + +## Plans for tinc 2.0 + +The 2.0 branch will be a complete rewrite of tinc. Expectations +have changed in the past 10 years. Applications should just work, +and should do as much as possible automatically. For example, +setting up a VPN with 1.0 requires the administrator to create a +number of configuration files (tinc.conf, tinc-up, a host config +file), generate keys, and exchange host config files with peers +somehow. This should be reduced to a simple `tinc setup` +command, which asks the user a few relevant details (name, subnet), +and perhaps asks if the credentials (the host config file in 1.0) +should be sent to another person, via email or other means. The +recipient of these credentials should just pipe them through +`tinc import` which would show a fingerprint and ask the +user if he was sure, and would then automatically update the +running tinc daemon's configuration with the new information. Of +course, there should also be a GUI to manage one's setup, +preferably well integrated into the OS and desktop environment of +the user's choice. Features from the 1.0 and 1.1 branches will be +included in the 2.0 branch if possible. Other features planned for +2.0 are: + +**Certificate based authorisation** + +In tinc 1.x authentication and authorisation is based on exchange +of public RSA keys and full trust principles. For finer control +over the VPN, and to limit the damage a rogue peer can do, a web of +trust should be formed using certificates. This can be in the style +of X.509, i.e. with a single authority who can sign certificates +for peers and the subnets they are allocated, or in the style of +PGP, where peers can sign each other, and if there are enough +signatures, they can allow communication. Trust management should +be simple, for example using a command like + + tinc trust *foo* + +which should let the local tinc +daemon trust information from the peer named *foo*. To authorise +the use of addresses on the VPN, a command like the following could +be used: + + tinc allow *bar* 192.168.3.0/24 + +This should generate a small certificate that proves that the node that +issued this command trusts node *bar* with the 192.168.3.0/24 range +of addresses. This certificate should then be added to the local +tinc daemon's configuration, but also spread immediately amongst +the other peers in the VPN. It is also important to allow trust and +authorisation to be revoked in the same way: + + tinc distrust *foo* + +This should make the local tinc daemon stop trusting any information from *foo*. + + tinc deny *bar* + +This should generate a certificate (with a newer timestamp than the previous one) denying +*bar* any access, and spread this amongst the other peers as well. +The other peers should replace the previous certificates for *bar* +from this peer with the new one, and recalculate their trust of +*bar* based on other certificates they might have. + +**Replacable tunnel backend** + +Tinc 1.x uses its own protocols to set up tunnels to other tinc +daemons. Once a tunnel has been set up, it synchronises the other +end with the rest of the VPN. Whereas most other VPN daemons +concentrate on the workings of a single tunnel, this is of less +importance to tinc, which is more about managing lots of tunnels +between peers to create a seamless network. It also is better to +use a well-established protocol such as SSH or TLS instead of our +own. Also, it is not necessary at all to use the same protocol for +all the connections in a single VPN. Tinc should therefore allow +tunnel backends as plugins, and allow other peers to be reached via +URLs such as `ssh://some.server.org` or +`https://another.server.net:4443`. diff --git a/goals/discussion.mdwn b/goals/discussion.mdwn new file mode 100644 index 0000000..2f1f3f2 --- /dev/null +++ b/goals/discussion.mdwn @@ -0,0 +1,3 @@ +I'd like to add a whizbang-o-matic autoglitter function to the wishlist. + +> No I want more *ponies*. diff --git a/header.mdwn b/header.mdwn new file mode 100644 index 0000000..7be77eb --- /dev/null +++ b/header.mdwn @@ -0,0 +1,28 @@ +![tinc](/images/tinclogo) +## *The network is virtual, your privacy is not...* + + +* * * * * + +## Links: + +[Main screen](/) +[Activities](/activities) +[Contact](/contact) +[Documentation](/docs) +[Download](/download) +[Examples](/examples/) +[FAQ](/faq) +[Goals](/goals) +[Mailing lists](/mail) +[News](/news) +[Search](/search) +[Security issues](/security) +[Repository](/repository) +[Supported platforms](/platforms) +[VPN links](/vpnlinks) +## Hosted by: + +[![non-gnu.uvt.nl](/images/uvt)](http://non-gnu.uvt.nl/) + + diff --git a/images/bwheli.png b/images/bwheli.png new file mode 100644 index 0000000..f302f55 Binary files /dev/null and b/images/bwheli.png differ diff --git a/images/logo3.jpg b/images/logo3.jpg new file mode 100644 index 0000000..272b560 Binary files /dev/null and b/images/logo3.jpg differ diff --git a/images/nllo.png b/images/nllo.png new file mode 100644 index 0000000..56909a6 Binary files /dev/null and b/images/nllo.png differ diff --git a/images/tinc1-small.png b/images/tinc1-small.png new file mode 100644 index 0000000..0451a7d Binary files /dev/null and b/images/tinc1-small.png differ diff --git a/images/tinc1.png b/images/tinc1.png new file mode 100644 index 0000000..5cd26db Binary files /dev/null and b/images/tinc1.png differ diff --git a/images/tinc3.gif b/images/tinc3.gif new file mode 100644 index 0000000..9b66351 Binary files /dev/null and b/images/tinc3.gif differ diff --git a/images/tinc3.png b/images/tinc3.png new file mode 100644 index 0000000..149fbd2 Binary files /dev/null and b/images/tinc3.png differ diff --git a/images/tinccard.png b/images/tinccard.png new file mode 100644 index 0000000..40de113 Binary files /dev/null and b/images/tinccard.png differ diff --git a/images/tinclogo.png b/images/tinclogo.png new file mode 100644 index 0000000..84e06b0 Binary files /dev/null and b/images/tinclogo.png differ diff --git a/images/uvt.png b/images/uvt.png new file mode 100644 index 0000000..d94649c Binary files /dev/null and b/images/uvt.png differ diff --git a/index.mdwn b/index.mdwn new file mode 100644 index 0000000..56165d2 --- /dev/null +++ b/index.mdwn @@ -0,0 +1,51 @@ +# Welcome to tinc! + +### Latest version: [1.0.9](news#1.0.9) + +### What is tinc? + +tinc is a Virtual Private Network (VPN) daemon that uses tunnelling +and encryption to create a secure private network between hosts on +the Internet. +tinc is Free Software and licensed under the +[GNU General Public License](http://www.gnu.org/licenses/old-licenses/gpl-2.0.html) +version 2 or later. +Because the VPN appears to the IP level network code as a normal +network device, there is no need to adapt any existing software. +This allows VPN sites to share information with each other over the +Internet without exposing any information to others. In addition, +tinc has the following features: + +
+
Encryption, authentication and compression
+
All traffic is optionally compressed using zlib or LZO, and OpenSSL +is used to encrypt the traffic and protect it from alteration with +message authentication codes and sequence numbers. +
+ +
Automatic full mesh routing
+
Regardless of how you set up the tinc daemons to connect to each +other, VPN traffic is always (if possible) sent directly to the +destination, without going through intermediate hops. +
+ +
Easily expand your VPN
+
When you want to add nodes to your VPN, all you have to do is add +an extra configuration file, there is no need to start new daemons +or create and configure new devices or network interfaces. +
+ +
Ability to bridge ethernet segments
+
You can link multiple ethernet segments together to work like a +single segment, allowing you to run applications and games that +normally only work on a LAN over the Internet. +
+ +
Runs on many operating systems and supports IPv6
+
Currently Linux, FreeBSD, OpenBSD, NetBSD, MacOS/X, Solaris, +Windows 2000, XP, Vista and Windows 7 platforms are supported. See our section about +supported platforms for more information about the +state of the ports. tinc has also full support for IPv6, providing +both the possibility of tunneling IPv6 traffic over its tunnels and +of creating tunnels over existing IPv6 networks. +
diff --git a/mail.mdwn b/mail.mdwn new file mode 100644 index 0000000..6e96ff4 --- /dev/null +++ b/mail.mdwn @@ -0,0 +1,17 @@ +## Mailing lists + +If you wish to be kept up to date of the progress of tinc, or want +to ask questions or discuss things, you can subscribe to one of the +mailing lists: + +| Mailing list | Web interface and archive | Description | +| ------------ | ------------------------- | ----------- | +| [tinc](mailto:tinc@tinc-vpn.org) | [web interface](/lists/tinc) | This is the mailing list for all users of tinc. You can ask any questions you have here. This list will also be used to announce new versions or any security problems we might find. | +| [tinc-devel](mailto:tinc-devel@tinc-vpn.org) | [web interface](/lists/tinc-devel) | This mailing list is mainly used for the developers. If you wish to discuss something technical about tinc, you can do it on this list. | +| tinc-svn | [web interface](/lists/tinc-svn) | This is a read-only mailing list. All the Subversion commit messages will be posted here. You can use it to track development. | + +To prevent spam on our mailing lists, you are required to subscribe before you can post to the mailing lists. This will also ensure that you receive any responses to your emails that are sent to the mailing list. + +### Subscribing to a mailing list + +Use the web interface links to subscribe to the mailing list of your choice. You can also use the web interface to unsubscribe or to change your settings. diff --git a/news-archive.mdwn b/news-archive.mdwn new file mode 100644 index 0000000..eaf262c --- /dev/null +++ b/news-archive.mdwn @@ -0,0 +1,3 @@ +## News archive + +[[!map pages="news/* and !*/Discussion" archive=yes]] diff --git a/news.mdwn b/news.mdwn new file mode 100644 index 0000000..7b3176a --- /dev/null +++ b/news.mdwn @@ -0,0 +1,7 @@ +## News + +[[!inline pages="news/* and !*/Discussion" template=newsitem]] + +----- + +You can find older news in the [[archive|news-archive]]. diff --git a/news/2000-05-04.mdwn b/news/2000-05-04.mdwn new file mode 100644 index 0000000..18d15d2 --- /dev/null +++ b/news/2000-05-04.mdwn @@ -0,0 +1,7 @@ +[[!meta author="zarq"]] +[[!meta date="May 4th 2000"]] + +It's time for some news again. Well, version 1.0pre1 is coming. It has a new +protocol (this protocol is not compatible with 0.3 versions). There will be an +rpm and deb. Maybe it will even work with FreeBSD, and other architectures. In +short: tinc 1.0 will be packed with good stuff. diff --git a/news/2000-06-03.mdwn b/news/2000-06-03.mdwn new file mode 100644 index 0000000..fb4fc91 --- /dev/null +++ b/news/2000-06-03.mdwn @@ -0,0 +1,4 @@ +[[!meta date="June 3rd 2000"]] +[[!meta author="zarq"]] + +I changed the colours on the web site, hope you'll like them. diff --git a/news/2000-09-10.mdwn b/news/2000-09-10.mdwn new file mode 100644 index 0000000..4e6967f --- /dev/null +++ b/news/2000-09-10.mdwn @@ -0,0 +1,27 @@ +[[!meta author="zarq"]] +[[!meta date="September 10th 2000"]] + +Although we (the authors of tinc) have done our best to make tinc as secure as +possible, an unfortunate combination of encryption and key exchange techniques +has created a hole in at least all versions of tinc >= 0.3, including the +current CVS version. + +*** Exploit: + +If somebody can intercept the meta protocol to a host that is running a tinc +daemon, it is possible to decrypt the passphrase, which can then be used to +gain unauthorised access to the VPN, and become a part of it. + +*** Workaround: + +Add firewall rules so that only trusted hosts can connect to the tinc daemon. + +*** Fix: + +We are currently working on the implementation of a new protocol, with a +different authentication scheme. We expect to have a working version in CVS +around next weekend, we will release a new version (1.0pre3) when this becomes +stable. + +Guus Sliepen +Ivo Timmermans diff --git a/news/2000-11-12.mdwn b/news/2000-11-12.mdwn new file mode 100644 index 0000000..e36e8d4 --- /dev/null +++ b/news/2000-11-12.mdwn @@ -0,0 +1,4 @@ +[[!meta author="guus"]] +[[!meta date="November 12th 2000"]] + +New web pages. diff --git a/news/2000-11-25.mdwn b/news/2000-11-25.mdwn new file mode 100644 index 0000000..70e8cec --- /dev/null +++ b/news/2000-11-25.mdwn @@ -0,0 +1,4 @@ +[[!meta author="guus"]] +[[!meta date="November 25th 2000"]] + +Got tinc to work under FreeBSD. For more information see supported [[platforms]]. diff --git a/news/2001-01-06.mdwn b/news/2001-01-06.mdwn new file mode 100644 index 0000000..5c134c7 --- /dev/null +++ b/news/2001-01-06.mdwn @@ -0,0 +1,4 @@ +[[!meta author="guus"]] +[[!meta date="January 6th 2000"]] + +Updated tinc manual to current version. See [[documentation section|docs]]. diff --git a/news/2001-01-26.mdwn b/news/2001-01-26.mdwn new file mode 100644 index 0000000..1ce61d8 --- /dev/null +++ b/news/2001-01-26.mdwn @@ -0,0 +1,4 @@ +[[!meta author="zarq"]] +[[!meta date="January 26th 2001"]] + +Whee, we have a [[search]] page! diff --git a/news/2001-07-21.mdwn b/news/2001-07-21.mdwn new file mode 100644 index 0000000..c246d3c --- /dev/null +++ b/news/2001-07-21.mdwn @@ -0,0 +1,4 @@ +[[!meta author="guus"]] +[[!meta date="July 26th 2001"]] + +Got tinc to work under Solaris 7. For more information see supported [[platforms]]. diff --git a/news/2001-12-31.mdwn b/news/2001-12-31.mdwn new file mode 100644 index 0000000..d3122b8 --- /dev/null +++ b/news/2001-12-31.mdwn @@ -0,0 +1,8 @@ +[[!meta author="guus"]] +[[!meta date="December 31st 2001"]] + +Jerome Etienne, author of [Yavipin](http://yavipin.sourceforge.net), has done a +security analysis of tinc. You can read his findings in our [[mailing list +archive|mail]] or on his homepage. His points are valid, although the higher +protocols will protect you against most of the weaknesses. We will further +increase tinc's security in the upcoming release. diff --git a/news/2003-09-26.mdwn b/news/2003-09-26.mdwn new file mode 100644 index 0000000..b8b4599 --- /dev/null +++ b/news/2003-09-26.mdwn @@ -0,0 +1,5 @@ +[[!meta author="guus"]] +[[!meta date="September 26th 2003"]] + +Peter Gutmann, a well known security expert, has done a security analysis of +tinc. You can find our response in a new section about [[security]] issues. diff --git a/news/2003-11-01.mdwn b/news/2003-11-01.mdwn new file mode 100644 index 0000000..c268af1 --- /dev/null +++ b/news/2003-11-01.mdwn @@ -0,0 +1,5 @@ +[[!meta author="guus"]] +[[!meta date="November 1th 2003"]] + +On Saturday, November the 8th, there will be an online tutorial held on IRC. +Installation, configuration and practical issues will be discussed. diff --git a/news/2004-04-03.mdwn b/news/2004-04-03.mdwn new file mode 100644 index 0000000..c154195 --- /dev/null +++ b/news/2004-04-03.mdwn @@ -0,0 +1,7 @@ +[[!meta author="guus"]] +[[!meta date="April 3rd 2004"]] + +The website has moved from [nl.linux.org](http://nl.linux.org/) to +[non-gnu.uvt.nl](http://www.non-gnu.uvt.nl/). From now on we will use our own +domain name, [tinc-vpn.org](http://www.tinc-vpn.org/), for our website and our +email addresses. diff --git a/news/2008-05-14.mdwn b/news/2008-05-14.mdwn new file mode 100644 index 0000000..16ddb61 --- /dev/null +++ b/news/2008-05-14.mdwn @@ -0,0 +1,5 @@ +[[!meta author="guus"]] +[[!meta date="May 14th 2008"]] + +[Debian Security Advisory 1571](http://www.debian.org/security/2008/dsa-1571) +affects tinc as well. Read more about it [[here|security]]. diff --git a/news/2008-12-26.mdwn b/news/2008-12-26.mdwn new file mode 100644 index 0000000..0ea28cd --- /dev/null +++ b/news/2008-12-26.mdwn @@ -0,0 +1,6 @@ +[[!meta author="guus"]] +[[!meta date="December 26th 2008"]] + +Tinc development has moved from Subversion to a [git repository](/git/tinc/). +The [old Subversion repository](/svn/tinc/), with commits up to the release of +tinc 1.0.9, is still available for now, but will not be updated anymore. diff --git a/news/2009-03-13.mdwn b/news/2009-03-13.mdwn new file mode 100644 index 0000000..233dd91 --- /dev/null +++ b/news/2009-03-13.mdwn @@ -0,0 +1,4 @@ +[[!meta date="March 13th 2009"]] + +Peter Dey reports that tinc works fine under 64-bit Vista. +He used a recent TAP-Win64 driver from OpenVPN, which is signed. diff --git a/news/2009-08-16.mdwn b/news/2009-08-16.mdwn new file mode 100644 index 0000000..05e26a1 --- /dev/null +++ b/news/2009-08-16.mdwn @@ -0,0 +1,4 @@ +[[!meta date="August 16th 2009"]] + +Christoph Rackwitz reported that tinc 1.0.9 ran on Windows 7. +The TAP-Win32 driver from OpenVPN is signed, and can be installed instead of the one that comes with the Windows installer. diff --git a/news/2009-09-09.mdwn b/news/2009-09-09.mdwn new file mode 100644 index 0000000..680c9ee --- /dev/null +++ b/news/2009-09-09.mdwn @@ -0,0 +1,6 @@ +[[!meta date="September 9th 2009"]] + +Native access to the git [[repository]] has been enabled, since the denial-of-service bug in git-daemon has been fixed. + +Grzegorz Dymarek has managed to build tinc for the iPhone and iPod touch. +These devices do not have a native tun or tap device, but make use of the [tunemu](http://code.gerade.org/tunemu/) driver. His patches have been committed to the [[repository]]. diff --git a/news/2009-09-10.mdwn b/news/2009-09-10.mdwn new file mode 100644 index 0000000..3feae52 --- /dev/null +++ b/news/2009-09-10.mdwn @@ -0,0 +1,3 @@ +[[!meta date="September 10th, 2009"]] + +Flynn Marquardt noticed that an article about tinc has appeared in the German c't Magazin, titled "*[Maschen-VPN](http://www.heise.de/ct/inhalt/2009/19/176/)*". diff --git a/news/release-0.3.3.mdwn b/news/release-0.3.3.mdwn new file mode 100644 index 0000000..dd65f8e --- /dev/null +++ b/news/release-0.3.3.mdwn @@ -0,0 +1,4 @@ +[[!meta author="zarq"]] +[[!meta date="February 9th 2000"]] + +Version 0.3.3. There was a problem when using kernel 2.2.14 or the newer 2.3 kernels, packets would no longer be accepted when using the wrong MAC address. The documentation was also updated. diff --git a/news/release-1.0.1.mdwn b/news/release-1.0.1.mdwn new file mode 100644 index 0000000..0b80636 --- /dev/null +++ b/news/release-1.0.1.mdwn @@ -0,0 +1,10 @@ +[[!meta author="guus"]] +[[!meta date="August 14th 2003"]] + +Version 1.0.1 released. + +* Allow empty lines in config files. +* Fix handling of spaces and backslashes in filenames under native Windows. +* Allow scripts to be executed under native Windows. +* Fix compiling under OpenBSD. +* Update documentation, make it less Linux specific. diff --git a/news/release-1.0.2.mdwn b/news/release-1.0.2.mdwn new file mode 100644 index 0000000..02d3d44 --- /dev/null +++ b/news/release-1.0.2.mdwn @@ -0,0 +1,11 @@ +[[!meta author="guus"]] +[[!meta date="November 8th 2002"]] + +Version 1.0.2 released. + +* Fix address and hostname resolving under Windows. +* Remove warnings about non-existing scripts and unsupported address families. +* Use the event logger under Windows. +* Fix quoting of filenames and command line arguments under Windows. +* Strict checks for length incoming network packets and return values of cryptographic functions, +* Fix a bug in metadata handling that made the tinc daemon abort. diff --git a/news/release-1.0.3.mdwn b/news/release-1.0.3.mdwn new file mode 100644 index 0000000..47c7378 --- /dev/null +++ b/news/release-1.0.3.mdwn @@ -0,0 +1,13 @@ +[[!meta author="guus"]] +[[!meta date="November 11th 2004"]] + +Version 1.0.3 released. + +* Show error message when failing to write a PID file. +* Ignore spaces at end of lines in config files. +* Fix handling of late packets. +* Unify BSD tun/tap device handling. This allows IPv6 on tun devices and anything on tap devices as long as the underlying OS supports it. +* Handle IPv6 on Solaris tun devices. +* Allow tinc to work properly under Windows XP SP2. +* Allow VLAN tagged Ethernet frames in switch and hub mode. +* Experimental PMTUDiscovery, TunnelServer and BlockingTCP options. diff --git a/news/release-1.0.4.mdwn b/news/release-1.0.4.mdwn new file mode 100644 index 0000000..f801e03 --- /dev/null +++ b/news/release-1.0.4.mdwn @@ -0,0 +1,7 @@ +[[!meta author="guus"]] +[[!meta date="May 4th 2005"]] + +Version 1.0.4 released. + +* Fix switch and hub modes. +* Optionally start scripts when a Subnet becomes (un)reachable. diff --git a/news/release-1.0.5.mdwn b/news/release-1.0.5.mdwn new file mode 100644 index 0000000..1774f78 --- /dev/null +++ b/news/release-1.0.5.mdwn @@ -0,0 +1,10 @@ +[[!meta author="guus"]] +[[!meta date="November 14th 2006"]] + +Version 1.0.5 released. + +* Lots of small fixes. +* Broadcast packets no longer grow in size with each hop. This should fix switch mode (again). +* Generic host-up and host-down scripts. +* Optionally dump graph in graphviz format to a file or a script. +* Support LZO 2.0 and later. diff --git a/news/release-1.0.6.mdwn b/news/release-1.0.6.mdwn new file mode 100644 index 0000000..17d9bf9 --- /dev/null +++ b/news/release-1.0.6.mdwn @@ -0,0 +1,7 @@ +[[!meta author="guus"]] +[[!meta date="December 18th 2006"]] + +Version 1.0.6 released. + +* More flexible detection of the LZO libraries when compiling. +* Fixed a bug where broadcasts in switch and hub modes sometimes would not work anymore when part of the VPN had become disconnected from the rest. diff --git a/news/release-1.0.7.mdwn b/news/release-1.0.7.mdwn new file mode 100644 index 0000000..664fb17 --- /dev/null +++ b/news/release-1.0.7.mdwn @@ -0,0 +1,7 @@ +[[!meta author="guus"]] +[[!meta date="January 5th 2007"]] + +Version 1.0.7 released. + +* Fixed a bug that caused slow network speeds on Windows. +* Fixed a bug that caused tinc unable to write packets to the tun device on OpenBSD. diff --git a/news/release-1.0.8.mdwn b/news/release-1.0.8.mdwn new file mode 100644 index 0000000..0400b20 --- /dev/null +++ b/news/release-1.0.8.mdwn @@ -0,0 +1,7 @@ +[[!meta author="guus"]] +[[!meta date="May 16th 2007"]] + +Version 1.0.8 released. + +* Fixed some memory and resource leaks. +* Made network sockets non-blocking under Windows. diff --git a/news/release-1.0.9.mdwn b/news/release-1.0.9.mdwn new file mode 100644 index 0000000..e0a571e --- /dev/null +++ b/news/release-1.0.9.mdwn @@ -0,0 +1,12 @@ +[[!meta author="guus"]] +[[!meta date="December 26th 2008"]] + +Version 1.0.9 released. + +* Fixed tinc as a service under Windows 2003. +* Fixed reading configuration files that do not end with a newline. +* Fixed crashes in situations where hostnames could not be resolved or hosts would disconnect at the same time as session keys were exchanged. +* Improved default settings of tun and tap devices on BSD platforms. +* Make IPv6 sockets bind only to IPv6 on Linux. +* Enable path MTU discovery by default. +* Fixed a memory leak that occured when connections were closed. diff --git a/news/release-1.0.mdwn b/news/release-1.0.mdwn new file mode 100644 index 0000000..2b3a660 --- /dev/null +++ b/news/release-1.0.mdwn @@ -0,0 +1,10 @@ +[[!meta author="guus"]] +[[!meta date="August 4th 2003"]] + +Version 1.0 released. + +* Lots of small bugfixes and code cleanups. +* Throughput doubled and latency reduced. +* Added LZO compression support. +* No need to set MAC address or disable ARP anymore. +* Added support for Windows 2000 and XP, both natively and in a Cygwin environment. diff --git a/news/release-1.0pre1.mdwn b/news/release-1.0pre1.mdwn new file mode 100644 index 0000000..03f057e --- /dev/null +++ b/news/release-1.0pre1.mdwn @@ -0,0 +1,7 @@ +[[!meta date="May 11th 2000"]] +[[!meta author="zarq"]] + +Version 1.0pre1. It has a new protocol (this protocol is not compatible with +0.3 versions). A rpm for Redhat Linux is also available, thanks to work from +Lubomír Bulej and Mads Kiilerich. The Debian package is delayed. Please test +this version, so that the final 1.0 will be rock stable. diff --git a/news/release-1.0pre2.mdwn b/news/release-1.0pre2.mdwn new file mode 100644 index 0000000..7e57188 --- /dev/null +++ b/news/release-1.0pre2.mdwn @@ -0,0 +1,13 @@ +[[!meta date="May 31 2000"]] +[[!meta author="zarq"]] + +Version 1.0pre2. + +* This version has been internationalised and a Dutch translation has been included. +* Two configuration variables have been added: + * VpnMask - the IP network mask for the entire VPN, not just our subnet (as given by MyVirtualIP). The Redhat and Debian packages use this variable in their system startup scripts, but it is ignored by tinc. + * Hostnames - if set to `yes', look up the names of IP addresses trying to connect to us. Default set to `no', to prevent lockups during lookups. +* The system startup scripts for Debian and Redhat use /etc/tinc/nets.boot to find out which networks need to be started during system boot. +* Fixes to prevent denial of service attacks by sending random data after connecting (and even when the connection has been established), either random garbage or just nonsensical protocol fields. +* tinc will retry to connect upon startup, does not quit if it doesn't work the first time. +* Hosts that are disconnected implicitly if we lose a connection get deleted from the internal list, to prevent hogging each other with add and delete requests when the connection is restored. diff --git a/news/release-1.0pre3.mdwn b/news/release-1.0pre3.mdwn new file mode 100644 index 0000000..776ddff --- /dev/null +++ b/news/release-1.0pre3.mdwn @@ -0,0 +1,15 @@ +[[!meta author="zarq"]] +[[!meta date="November 9th 2000"]] + +Version 1.0pre3. It's been a while, but it's finally here. + +* The protocol has been redesigned, and although some details are still under discussion, this is secure. Care has been taken to resist most, if not all, attacks. +* Unfortunately this protocol is not compatible with earlier versions, nor are earlier versions compatible with this version. Because the older protocol has huge security flaws, we feel that not implementing backwards compatibility is justified. +* Some data about the protocol: + * It uses public/private RSA keys for authentication (this is the actual fix for the security hole). + * All cryptographic functions have been taken out of tinc, instead it uses the OpenSSL library functions. + * Offers support for multiple subnets per tinc daemon. +* New is also the support for the universal tun/tap device. This means better portability to FreeBSD and Solaris. +* tinc is tested to compile on Solaris, Linux x86, Linux alpha. +* tinc now uses the OpenSSL library for cryptographic operations. More information on getting and installing OpenSSL is in the manual. This also means that the GMP library is no longer required. +* Further, thanks to Enrique Zanardi, we have Spanish messages; Matias Carrasco provided us with a Spanish translation of the manual. diff --git a/news/release-1.0pre4.mdwn b/news/release-1.0pre4.mdwn new file mode 100644 index 0000000..52eaf79 --- /dev/null +++ b/news/release-1.0pre4.mdwn @@ -0,0 +1,15 @@ +[[!meta author="guus"]] +[[!meta date="May 25th 2001"]] + +Version 1.0pre4 released. + +* New authentication protocol (better security, and faster too). +* TCPonly and IndirectData are back (but not fully tested). +* Documentation revised, it's really up to date with the released package now. +* tincd -K now stores public/private keys in PEM format, but keys of 1.0pre3 can still be used. +* Faster and more secure encryption of tunneled packets. +* Stresstested to see if it handles large VPNs with more than 100 sites (it does). + +Again, due to the large changes in the protocols this version does not work +together with older versions. However, you don't have to change the +configuration files this time. diff --git a/news/release-1.0pre5.mdwn b/news/release-1.0pre5.mdwn new file mode 100644 index 0000000..9904a35 --- /dev/null +++ b/news/release-1.0pre5.mdwn @@ -0,0 +1,16 @@ +[[!meta author="guus"]] +[[!meta date="February 10th 2002"]] + +Version 1.0pre5 released. + +* Security enhancements: + * Added sequence number and optional message authentication code to the packets. + * Configurable encryption cipher and digest algorithms. +* More robust handling of dis- and reconnects. +* Added a "switch" and a "hub" mode to allow bridging setups. +* Preliminary support for routing of IPv6 packets. +* Supports Linux, FreeBSD, OpenBSD and Solaris. + +Again, due to large changes in the protocols this version does not work +together with older versions. Also, some configuration variables have changed +names, most notably you will have to replace TapDevice by Device. diff --git a/news/release-1.0pre6.mdwn b/news/release-1.0pre6.mdwn new file mode 100644 index 0000000..e1b906a --- /dev/null +++ b/news/release-1.0pre6.mdwn @@ -0,0 +1,17 @@ +[[!meta author="guus"]] +[[!meta date="March 27th 2002"]] + +Version 1.0pre6 released. + +* Improvement of redundant links: + * Non-blocking connects. + * Protocol broadcast messages can no longer go into an infinite loop. + * Graph algorithm updated to look harder for direct connections. +* Good support for routing IPv6 packets over the VPN. Works on Linux, FreeBSD, possibly OpenBSD but not on Solaris. +* Support for tunnels over IPv6 networks. Works on all supported operating systems. +* Optional compression of UDP connections using zlib. +* Optionally let UDP connections inherit TOS field of tunneled packets. +* Optionally start scripts when certain hosts become (un)reachable. + +As always, due to changes in the protocols this version does not work together +with older versions. Configuration is case insensitive again. diff --git a/news/release-1.0pre7.mdwn b/news/release-1.0pre7.mdwn new file mode 100644 index 0000000..a1def37 --- /dev/null +++ b/news/release-1.0pre7.mdwn @@ -0,0 +1,10 @@ +[[!meta author="guus"]] +[[!meta date="April 9th 2002"]] + +Version 1.0pre7 released. + +* Don't do blocking read()s when getting a signal. +* Remove RSA key checking code, since it sometimes thinks perfectly good RSA keys are bad. +* Fix handling of subnets when prefixlength isn't divisible by 8. + +This version features only small bugfixes. It is fully compatible with 1.0pre6. diff --git a/news/release-1.0pre8.mdwn b/news/release-1.0pre8.mdwn new file mode 100644 index 0000000..adeec67 --- /dev/null +++ b/news/release-1.0pre8.mdwn @@ -0,0 +1,12 @@ +[[!meta author="guus"]] +[[!meta date="September 16th 2002"]] + +Version 1.0pre8 released. + +* More fixes for subnets with prefixlength undivisible by 8. +* Added support for NetBSD and MacOS/X. +* Switched from undirected graphs to directed graphs to avoid certain race conditions and improve scalability. +* Generalized broadcasting and forwarding of protocol messages. +* Cleanup of source code. + +Again, due to changes in the protocols this version does not work together with older versions. diff --git a/news/uploaded-0.5.mdwn b/news/uploaded-0.5.mdwn new file mode 100644 index 0000000..05daa0a --- /dev/null +++ b/news/uploaded-0.5.mdwn @@ -0,0 +1,4 @@ +[[!meta date="January 16th 2000"]] +[[!meta author="zarq"]] + +I uploaded my development tree for 0.5 into a Subversion repository. diff --git a/news/uploaded-1.08pre8-deb.mdwn b/news/uploaded-1.08pre8-deb.mdwn new file mode 100644 index 0000000..070e32b --- /dev/null +++ b/news/uploaded-1.08pre8-deb.mdwn @@ -0,0 +1,4 @@ +[[!meta author="guus"]] +[[!meta date="September 29th 2002"]] + +Package for Debian woody (stable) added to the [[download]] page. diff --git a/news/uploaded-1.0pre1-deb.mdwn b/news/uploaded-1.0pre1-deb.mdwn new file mode 100644 index 0000000..cf3b14c --- /dev/null +++ b/news/uploaded-1.0pre1-deb.mdwn @@ -0,0 +1,4 @@ +[[!meta date="May 15th 2000"]] +[[!meta author="zarq"]] + +I uploaded a Debian package of version 1.0pre1. diff --git a/news/uploaded-1.0pre7-rpm.mdwn b/news/uploaded-1.0pre7-rpm.mdwn new file mode 100644 index 0000000..76274c3 --- /dev/null +++ b/news/uploaded-1.0pre7-rpm.mdwn @@ -0,0 +1,4 @@ +[[!meta author="guus"]] +[[!meta date="April 25th 2002"]] + +RedHat package for tinc 1.0pre7 added to the download page, thanks to Nick Patavalis. diff --git a/platforms.mdwn b/platforms.mdwn new file mode 100644 index 0000000..7865a8e --- /dev/null +++ b/platforms.mdwn @@ -0,0 +1,30 @@ +## Supported platforms + +We have confirmed that tinc works on the following platforms and we +will make sure it will work on these in the future as well: + +| OS | Architecture | Remarks | +| -- | ------------ | ------- | +| Linux | i386, alpha, sparc, powerpc, x86\_64 | | +| FreeBSD | i386, x86\_64 | | +| Solaris | sparc32 | | +| OpenBSD | i386, x86\_64 | | +| NetBSD | i386 | | +| Darwin (MacOS/X) | powerpc, i386 | See the [[tinc manual|docs]] for requirements. | +| Windows (Cygwin) | i386, x86\_64 with tap64 driver | Runs in a Cygwin environment. | +| Windows (MinGW) | i386, x86\_64 with tap64 driver | Runs natively under Windows 2000, XP, Vista and Windows 7. May need an updated TAP-Win32 driver to work. | + +We are in the process porting tinc to the following architectures. +On some it may already work, on others it will not. You can check +in which stage we are in the table. + +| OS | Architecture | Compiles | Runs | Really works | Remarks | +| -- | ------------ | -------- | ---- | ------------ | ------- | +| Linux | m68k, mips, mipsel, S/390, SH, HPPA | yes | unknown | unknown | Debian autobuilder binaries. | +| GNU HURD | i386 | yes | unknown | unknown | Debian has hurd binaries, but probably misses a tun/tap device. | +| iPhone, iPod touch | arm | yes | yes | yes | Experimental support for these devices is in the [[repository]]. | + +On other platform tinc will likely not compile at all. If you do +want to report a successful compile or if you have succeeded in +actually running tinc on an unsupported platform, please +[[tell us|contact]]. diff --git a/repository.mdwn b/repository.mdwn new file mode 100644 index 0000000..26bc94b --- /dev/null +++ b/repository.mdwn @@ -0,0 +1,48 @@ +## Source code repository + +You can get the latest development source code from our git +repository if you want to. This code may not work, run, or even +compile. You'll also *need* to have the latest versions of +autoconf, automake, libtool and gettext installed. The files that +can be generated using these tools are *not* in the repository. + +### Accessing the repository + +You can [browse the repository](/git/tinc/) online. However, to +make real use of it you should have to have the git tools +installed. If you do not have them, you can find them at +[http://git.or.cz/](http://git.or.cz/). +Then run either one of these commands: + + git clone git//www.tinc-vpn.org/tinc + +or: + + git clone http://www.tinc-vpn.org/git/tinc + +This creates a copy of the public repository of tinc. For every +release of tinc there is a corresponding tag in the git repository, +you can get an old version by running +`git checkout release-`*version* on your copy of the git +repository. If you have checked out a copy of the public +repository, you can bring it up to date using the command +`git pull`. + +### Log messages + +Whenever something is changed in the repository, a log message is +sent to the tinc-svn list. If you wish to be kept up to date, you +can subscribe yourself to that [[mailing list|mail]]. + +### Old Subversion repository + +Prior to git, Subversion was used for the source code repository. +Although the repository was converted to git, and almost all +history is also available from the git repository, the Subversion +repository is still available for now. It may disappear in the +future however. You can +[browse the old Subversion repository](/svn/tinc/) online, or check +out a working copy of the main development branch of tinc (up to +1.0.9) with the following command: + + svn co http://www.tinc-vpn.org/svn/tinc/trunk tinc diff --git a/search.mdwn b/search.mdwn new file mode 100644 index 0000000..d10aad4 --- /dev/null +++ b/search.mdwn @@ -0,0 +1,15 @@ +
+ +Google +
+ + + + + +
+Search WWW +Search tinc site + +
+
diff --git a/security.mdwn b/security.mdwn new file mode 100644 index 0000000..f2a1a6f --- /dev/null +++ b/security.mdwn @@ -0,0 +1,266 @@ +## Possible weak keys generated by tinc on Debian (and derivates) due to a security bug in Debian's OpenSSL packages + +For those who run tinc on Debian or Debian-based distributions like +Ubuntu and Knoppix, be advised that the following security issue +affects tinc as well: +[http://www.debian.org/security/2008/dsa-1571](http://www.debian.org/security/2008/dsa-1571) +In short, if you generated public/private keypairs for tinc between +2006 and May 7th, 2008 on a machine running Debian or a derivative, +they may have been generated without a properly seeded random +number generator. Please ensure you have updated your OpenSSL +packages and regenerate all suspect keypairs. Do not forget to +restart tinc. +If you have compiled a static version of tinc on an affected +platform, you need to recompile tinc to ensure it is statically +linked with a fixed OpenSSL library. +I do not know if the session keys also have been weak, but it is +best to assume they were. If you exchanged private key material via +your tinc VPN, then an eavesdropper may have seen seen this as +well. Regenerate any keying material that you have exchanged via +your tinc VPN if any of the nodes was running on an affected +platform. + +## Security issues in tinc + +On September 15th, 2003, Peter Gutmann contacted us and showed us part of a +[writeup](http://www.mail-archive.com/cryptography@metzdowd.com/msg00891.html) +which he posted to a +[cryptography mailing list](http://www.mail-archive.com/cryptography%40metzdowd.com/maillist.html) +on the 22th. In this writeup he identifies several security issues +in CIPE, VTun and tinc. Below we will examine his findings and +explain why some flaws or weaknesses Peter Gutmann found are in +fact not a problem at all for a VPN daemon like tinc. As a reader +you are ultimately left to draw your own conclusions, I encourage +you to read all the arguments from both sides and, if possible, +verify them by reading the documentation and source code of tinc. +Comments are welcome. + +### Predictable IV + +> *tinc uses a completely predictable 32-bit IV in combination with CBC encryption, which makes the first encrypted block vulnerable, but isn't quite as bad as the ECB used in vtun (actually it isn't an IV in the true sense, it prepends a 32-bit sequence number to the encrypted data, but it works the same way).* + +When the same key is used to encrypt more than one message with a +symmetric cipher in CBC mode, one should use a different IV for +each message, to prevent that packets with the same plaintext end +up having the same ciphertext. That the IV is known to an attacker +is not of any concern. The best way to provide an IV is to add a +random number the size of one block in plaintext to the packet, or +to add the last ciphertext block from the previous packet sent to +the new packet. + +When exchanging encryption keys, tinc also sends a full IV. +However, although this IV is used it is the same for every packet +sent with the same key, and thus does not provide much more +security over no IV. In addition, tinc has added more data to each +packet to act as a distinct IV for each packet. Because this means +more overhead and possibly more fragmentation, tinc has always used +much less than a full block for this. Up until 1.0pre4, a 16 bit +random number was used (the length could only be changed at +compiletime). After that, the 32 bit sequence number needed for +replay protection was also used to act as an IV. For tinc 2.0, we +will probably optionally add a full IV and move the sequence number +out of the ciphertext, as described in RFC 2405 and 2406. + +### Truncated MAC + +> *Packets are protected with a 32-bit (very) truncated HMAC using encrypt-then-MAC.* + +A MAC makes sure an attacker cannot alter a packet without the +recipient noticing this. Tinc appends a HMAC of the ciphertext at +the end of the packet, which is common practice. SHA1 is used as +the hash function by default, but only the first 32 bits are +appended to the packet by default. The more bits are used the +stronger the MAC is, but it will also increase overhead. Still, +using only 32 bits doesn't mean a trivial attack is possible. Again +there must be a balance between security and performance; tinc will +continue to use only the first 32 bits by default. + +### Use of RSA + +> *tinc's real problem though is the handshake protocol, in which the client and server exchange random RSA-encrypted strings. That's raw bit strings, there's no PKCS #1 or OAEP padding, and the server is happy to act as an oracle for you too. This is a terrible way to use RSA, and usually compromises the key. There is a significant body of literature on this (too much to cite) going back to the early 1980s and continuing through to the current day, with probably the most recent publication in this area being the attack published at Usenix Security '03 only a few weeks ago (in that case it was a timing oracle).* + +When encrypting messages using the RSA algorithm, care must be +taken to prevent certain attacks. The PKCS #1 and OAEP padding +schemes are designed to prevent those attacks. Basically, OAEP +ensures proper termination of the actual message, adds a hash of +that message to make sure it isn't altered by an attacker, and pads +the rest with the output of a PRNG until the resulting message has +the same length as the RSA key, so that the message doesn't have +too low entropy or trivial padding (such as 0 bits) which can be +used in an attack. + +Tinc uses RSA encryption only once, during authentication. A +message is sent which has the same length as the RSA key, and is +completely filled with the output of a PRNG which is assumed to be +secure and seeded using real random data (OpenSSL's +`RAND_bytes()`). So, the message does not have low entropy and +doesn't contain predictable bits. However, there is no guarantee +that the message was encrypted using the correct public key or that +noone has tampered with it. This is of no concern for tinc though. +Part of the message is used as the key for the symmetric cipher +that is used by the sender of this key to encrypt the rest of the +messages it will send. A challenge-response exchange right after +exchanging the RSA encrypted messages is done to ensure that both +the sender of the symmetric cipher key has the right public key, +the recipient has the right corresponding private key, and the +message was not tampered with (because that would change the +symmetric cipher key). + +Currently, tinc can be used as a timing oracle, because no RSA +blinding is done. We tried to implement this, but unfortunately +OpenSSL's library functions which would take care of this let tinc +crash, and we haven't found the reason for this yet. We do not see +how tinc could be used as any other kind of oracle. + +### Authentication protocol + +> *Beyond that, the [protocol writeup](http://www.tinc-vpn.org/documentation/tinc_6.html#SEC61) points out that:* +> > the server sends exactly the same kind of messages over the wire as +> > the client +> +> *In case the problem isn't obvious yet, note that what's being exchanged is purely a random bit string, with no binding of client or server roles or identities into any part of the exchange. Again, there are way too many references to cite on these issues, although my favourite coverage of a lot of the things you need to think about is in "Network Security: Private Communication in a Public World" by Kaufman, Perlman, and Speciner.* + +There are no server and client roles in tinc, because it is +peer-to-peer. When a new TCP connections is made, both peers have +to authenticate themselves to eachother, and both have to be +configured to trust the other to let the authentication succeed. We +do not see how this remark about tinc not identifying a server and +a client diminishes security. + +> *As an example, here's a simple attack. The documentation (section 6.3.1) is a bit vague about the message flow, but assuming I've understood it correctly, the message flow is:* +> client server +> rsa( random_key ) --> +> random_key( challenge ) --> +> <-- random_key( sha1( challenge ) ) +> +> *Simplifying things a bit so that the entire exchange can be abstracted down to "challenge" and "response" (with implied RSA decryption, etc etc taking place as part of that), let's say Mallet wants to mess with Alice and Bob. So Mallet sends a challenge to Bob (claming to be Alice) and gets back a response. Mallet gets Bob's encrypted key and challenge back and forwards it to Alice, who returns a response, which Mallet in turn forwards to Bob, a classic chess grandmaster attack. Bob now thinks he's talking to Alice, when in fact Mallet controls one of the two channels.* + +First of all, we assume Mallet does not know the private keys of +Bob and Alice (Bob and Alice are not compromised), and Bob and +Alice do not know Mallet at all (they don't trust Mallet, otherwise +he could've made a connection without having to resort to a +cryptographic attack). We do assume that Mallet knows the public +keys of Alice and Bob. First, keys for the symmetric cipher +encryption are exchanged. Mallet cannot decrypt keys he gets from +Bob and Alice, because he doesn't have their private keys. He can +send his own keys, encrypted with Bob and Alice's public keys. So +after the key exchange, Mallet can send plaintext to Bob and Alice, +which will decrypt them correctly, but he cannot read the plaintext +Bob and Alice send to him. So Mallet sends a challenge to Bob, who +can decrypt it, and Bob returns a response which Mallet cannot +read. Mallet cannot decrypt it, reencrypt it and send it to Alice, +and neither can he forward the ciphertext from Bob to Alice, +because Alice uses a different key to decrypt messages from Mallet +than Bob uses to encrypt messages to Mallet. Hence, this attack +won't work, and Peter Gutmann is wrong on this point. + +### Configuration + +> *As an extension of the handshake problem, tinc relies heavily on an administrator at both ends of the link configuring the software identically for the handling of the handshake phase, replacing the authenticated parameter negotiation performed by protocols like SSL/TLS, SSH, and IPsec (during the data transfer phase there are ways of negotiating parameters, I haven't looked at this too much).* + +Tinc does not have to be configured identically on each endpoint. +When making an encrypted connection between to hosts, it is common +to negotiate which cipher to use. However, tinc does not just +create a tunnel between two endpoints, it can handle any number of +endpoints. Because it is very hard to negotiate a single cipher for +all endpoints, tinc does not negotiate, and allows each endpoint to +choose which cipher should be used to encrypt packets to it, +regardless of what cipher the other endpoints use. This does not +compromise security in itself, and in fact this might even improve +security. +On the other hand an administrator of one endpoint might choose to +use an insecure cipher instead of the default, and compromise +traffic other endpoints send to it. Tinc could be rewritten to +always enforce the use of the strongest cipher, but we believe you +should trust every participant in the VPN, and if one administrator +is not trustworthy, he should be removed from the VPN: even with +enforcement of strong ciphers, a malicious participant could just +as easily post all the VPN traffic he receives on a website, so it +really doesn't improve security at all. + +### General issues + +> *- Don't use the same key for encryption and authentication.* + +Nowhere in the authentication protocol does this happen. + +> *- Don't have the key chosen entirely by one side (even if it's only Alice and Bob on the line rather than Mallet, if one of the two has a poor RNG, all communications from them are compromised).* + +This is a valid point. Tinc can easily be changed to use keys +composed of what both sides send, for example by using the +Diffie-Helman scheme. This is planned for tinc 2.0. + +> *- Provide message freshness guarantees (and, if possible, some form of PFS).* + +Currently only the UDP packets sent by tinc have PFS, but this is +not true for the TCP connections (the meta protocol). This will be +resolved in tinc 2.0. + +> *- Bind the identity of the principals to the authentication.* + +The authentication is done using RSA encryption, the RSA keys are +directly bound to the identities of the tinc daemons. + +> *- Don't use the same messages in both directions.* + +Tinc doesn't send the same messages, it sends the same *kinds* of +messages. + +> *- Don't act as an oracle for an attacker.* + +Apart from possibly being susceptible to a timing attack, we don't +believe, and Peter Gutmann has not convinced us, that tinc can be +used as any other kind of oracle. + +> *As it stands the handshake protocol only narrowly avoids a variety of basic attacks, making it quite brittle in that the most trivial change (or someone thinking about possible attacks a bit further :-) would probably kill it.* + +I think this holds for virtually all cryptographic handshake +protocols. + +### Thoughts + +> *These programs have been around for years (CIPE goes back to 1996 and vtun to 1998) and (apparently) have quite sizeable user communities without anyone having noticed (or caring, after flaws were pointed out) that they have security problems. I only heard of CIPE when a friend of mine mentioned it to me in passing, and came across vtun by coincidence when I was looking for more info on CIPE. Who knows how many more insecure Linux crypto-tunnel products there may be floating around out there.* + +Although security can only be proven by time and peer review, the +lack of some people noticing certain software applications does not +have a direct relation to their security. The fact that Peter +Gutmann only examined three specific Open Source VPN products does +not say anything about the security of other products. + +> *It's possible to create insecure "security" products just as readily with open-source as with closed-source software.* + +I don't think anyone disagrees with that. + +> *CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed. At least Microsoft eventually tries to fix their stuff, given sufficient public embarrassment and the odd hundred thousand or so computers being taken out by attackers.* + +Microsoft sells its products as being secure, and the people who +buy its products have expectations. But not everyone is out there +to make software that is as secure as possible, VTun even mentions +it is not intended to be secure, and CIPE focuses more on usability +than on security. + +> *For all of these VPN apps, the authors state that they were motivated to create them as a reaction to the perceived complexity of protocols like SSL, SSH, and IPsec. The means of reducing the complexity was to strip out all those nasty security features that made the protocols complex (and secure). Now if you're Bruce Schneier or Niels Ferguson, you're allowed to reinvent SSL ("Practical Cryptography", John Wiley & Sons, 2003). Unfortunately the people who created these programs are no Bruce or Niels. The results are predictable.* + +Development of CIPE, VTun and tinc has started in times when SSH, +SSL and IPsec were nowhere as popular as they are now. We certainly +never claimed we created tinc in reaction to those protocols. +Furthermore, SSL and SSH are reliable stream based protocols, +unsuitable for VPNs which work best with unreliable datagrams, +hence it wouldn't have been an obvious choice to use SSH or SSL in +the first place. Both SSL and SSH have had their security problems +in the past (and in the case of OpenSSH, even in the recent past), +emphasizing that even these widely used and scrutinised protocols +are not as perfect as Peter Gutmann would let us believe. +Apart from that, there is no reason why people shouldn't create new +protocols, which might in time become just as strong or even +stronger. Even great names as Ron Rivest didn't get it right the +first time. + +> *Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment.* + +A very professional and constructive argument. + +> *Replacing the SSL/SSH data channel is marginally justifiable, although usually just running SSL/SSH over UDP would be sufficient. Replacing the SSL/SSH control channel is never justifiable - even the WAP guys, with strong non-SSL/SSH requirements, simply adapted SSL rather than trying to invent their own protocol.* + +We have no obligation to justify anything we do. We also do not +believe SSL is the be-all, end-all of cryptography. diff --git a/sidebar.css b/sidebar.css new file mode 100644 index 0000000..0d6b582 --- /dev/null +++ b/sidebar.css @@ -0,0 +1,23 @@ +.pageheader { + margin-left: 260px; +} + +#content { + margin-left: 260px; +} + +#sidebar { + padding-bottom: 1em; + float: left; + text-align: center; + width: 250px; +} + +#sidebar > :first-child { + margin-top: 0; +} + +#sidebar ul { + padding: 0; + list-style-type: none; +} diff --git a/sidebar.mdwn b/sidebar.mdwn new file mode 100644 index 0000000..1b91e66 --- /dev/null +++ b/sidebar.mdwn @@ -0,0 +1,24 @@ +[[!img images/tinclogo.png alt=tinc link=/index]] + +Links: + +- [[Main screen|index]] +

+- [[Activities]] +- [[Contact]] +- [[Documentation|docs]] +- [[Download]] +- [[Examples]] +- [[FAQ]] +- [[Goals]] +- [[Mailing lists|mail]] +- [[News]] +- [[Search]] +- [[Security issues|security]] +- [[Repository]] +- [[Supported platforms|platforms]] +- [[VPN links|vpnlinks]] + +Hosted by: + +[[!img images/uvt.png alt=non-gnu link=http://non-gnu.uvt.nl/]] diff --git a/vpnlinks.mdwn b/vpnlinks.mdwn new file mode 100644 index 0000000..3cb21bf --- /dev/null +++ b/vpnlinks.mdwn @@ -0,0 +1,35 @@ +## VPN links + +If you wish to know more about VPNs, and perhaps want to try out +some other VPN solutions, you can find links to various resources +below. Of course, if you can think of any which are not yet listed +here, please [[tell us|contact]]. + +### FAQs, HOWTOs, and other information about VPNs + +- [The VPN HOWTO and related HOWTOs](http://www.tldp.org/HOWTO/HOWTO-INDEX/networking.html#NETVPN) +- [OpenVPN Forum, a german forum community about VPNs](http://www.vpnforum.de/) +- [VPNlabs, resources on network security](http://www.vpnlabs.com/) + +### VPN standardisation + +- [[!wikipedia IPsec]] +- [Virtual Private Network Consortium](http://www.vpnc.org/) + +### Other VPN solutions + +- [Amrita VPN](http://amvpn.sourceforge.net/) +- [CIPE](http://cipe-linux.sourceforge.net/) +- [CloudVPN](http://exa.czweb.org/?view=cloudvpn) +- [FreeS/WAN](http://www.freeswan.org/) +- [GVPE](http://savannah.gnu.org/projects/gvpe/) +- [l2tpd](http://sourceforge.net/projects/l2tpd) +- [Nest](http://www.targeted.org/nest/) +- [OpenS/WAN](http://www.openswan.org/) +- [OpenVPN](http://openvpn.sourceforge.net/) +- [Poptop](http://www.poptop.org/) +- [SocialVPN](http://socialvpn.wordpress.com/) +- [VPMN](http://code.google.com/p/vpmn/) +- [vpnd](http://sunsite.dk/vpnd/) +- [VTun](http://vtun.sourceforge.net/) +- [Yavipin](http://yavipin.sourceforge.net/) diff --git a/web.css b/web.css new file mode 100644 index 0000000..551bc92 --- /dev/null +++ b/web.css @@ -0,0 +1,136 @@ +body { + background: white; + color: black; + font-family: sans-serif; + font-size: 14px; + max-width: 1000px; + margin-left: auto; + margin-right: auto; + text-align: justify; +} + +.header { + margin: 0; + padding: 0; +} + +.actions { + margin: 0; + padding: 0; +} + +.actions ul { + margin: 0; + padding-left: 0; + padding-bottom: .5em; + list-style-type: none; + text-align: right; +} + +.pageheader .actions ul { + color: gray; + border-bottom: 1px solid black; +} + + +.header { + display: none; +} + +.actions li { + display: inline; + padding: .2em .4em; +} + +.searchform { + display: inline; +} + +.searchform form { + display: inline; +} + +input#searchbox { + background: url(wikiicons/search-bg.gif) no-repeat; + background-position: 100% 50%; + padding: 0; + padding-right: 1.2em; + width: 10em; +} + +.pagefooter { + color: gray; + border-top: 1px solid black; + clear: both; + padding-top: .5em; + text-align: right; +} + +#poweredby { + float: left; + width: 40%; + text-align: left; +} + +table { + border: 1px solid; + border-collapse: collapse; +} + +td { + border: 1px solid; + padding: 4px; +} + +th { + border: 1px solid; + padding: 4px; +} + +.inlinefooter { + clear: both; +} + +#content { + padding-top: 1em; + padding-bottom: 1em; + padding-right: 1em; +} + +#content > :first-child { + margin-top: 0; +} + +#backlinks { + display: none; +} + +#feedlink { + float: right; + width: 9em; + text-align: right; +} + +.feedbutton { + background: #ff6600; + color: white !important; + border-left: 1px solid #cc9966; + border-top: 1px solid #ccaa99; + border-right: 1px solid #993300; + border-bottom: 1px solid #331100; + padding: 0px 0.5em 0px 0.5em; + font-family: sans-serif; + font-weight: bold; + font-size: small; + text-decoration: none; + margin-top: 1em; +} + +.feedbutton:hover { + color: white !important; + background: #ff9900; +} + +img { + border: 0; +}