[Openvpn-devel] [ANNOUNCE] IPv6 payload patch
Hello everyone, up to now OpenVPN only supports transporting IPv6 data through a point-to-multipoint (tls-server/tls-client mode) using tap-interfaces, which emulate a virtual ethernet device. The preferred tun-mode does not support any IPv6, because the in-process routing engine does not understand IPv6 addressing. After planning to force a student to write this part of code (who unfortunately sensed our plot and ran for his life) Gert Doering finally yielded to our begging and promises of beer and wrote the code. So here we go. This patch implements pretty much everything you need for a decent IPv6 VPN-concentrator setup, including autoconfiguration of the client and routing of arbitrary subnets from the client to the server or from the server to the client. The patch (on stock upstream OpenVPN) and some rough documentation can be found at http://www.greenie.net/ipv6/openvpn.html . We are also maintaining the code in git to ease development. There are a public git-repository on my personal git server git://git.birkenwald.de/openvpn.git with the following branches: * upstream (fetched from http://github.com/jjo/openvpn-ipv6/ stock branch, which again comes from git-svn from the OpenVPN repository) * jjo-ipv6 (fetched again from jjo master branch, which is upstream with the additional patches for IPv6 _transport_ (not related to this project) * gert-ipv6 (upstream + gert's patches for IPv6 payload) There is also a jjo+gert branch which merges both branches. There was a small conflict in one function in mroute.c, but that is only cosmetical. We're working on getting that aligned. Additionally I have built Debian/Ubuntu binary packages (no guarantees whatsoever) which are available on my Launchpad PPA at https://launchpad.net/~berni/+archive/ipv6 . They say Ubuntu Intrepid/Karmic but run on Debian Lenny just fine. They are however based on the Debian OpenVPN package from testing (which also includes jjo's IPv6 transport patch), so they might introduce additional bugs not present in the stable series. Use at your own risk. The patched binaries have been tested on a number of OpenVPN installations, with a large number of different clients (mostly unpatched, some with IPv6 patches) connecting to patched servers, and we have not seen any instabilities yet. So we consider this "safe for more wider-scale testing and peer review". So what's left to do? Windows support for IPv6 is completely unimplemented at the moment, that part of the code would love to see someone familiar with the platform. Documentation (which is my primary responsibility, so I'd love to see patches from all of you :-) ) is pretty much missing. And of course, testing, testing, testing... We would love to hear your thoughts and results about it. Best Regards, Bernhard and Gert
Re: [Openvpn-devel] [PATCH] FQDN for routes should expand to all IPs
David Sommerseth wrote: > Unfortunately, it's running on a lot of different embedded systems. > OpenWRT and dd-wrt are just two of many firmwares which ships it. I > would not be surprised if somebody have made VoIP hardware phones which > includes OpenVPN. And these phones could in theory even be in the 4-8MB > segment. JFTR: http://wiki.snom.com/Networking/Virtual_Private_Network_%28VPN%29 They have 32MB RAM, but it is fairly packed already. Best Regards, Bernhard
Re: [Openvpn-devel] [PATCH] make ipv6_payload compile under windowze ( feat_ipv6_payload branch )
On Sun, Feb 21, 2010 at 08:00:27PM +0100, JuanJo Ciarlante☀ wrote: > This patch makes ipv6_payload successfully cross *compile* > (and just that :) under my mingw32msvc setup on Linux. > > Because same syshead.h changes are already included in > feat_ipv6_transport, it may merge-conflict applying it over > allmerged once the latter includes ipv6_transport. > > Patch follows > (also at > http://github.com/jjo/openvpn-ipv6/commit/b7e46bd5ebfd4b55146299129e8b9813fab91b5e > ): Thank you very much, applied to my gert-ipv6 branch (at least I hope so). David, please pull gert-ipv6 from git://git.birkenwald.de/openvpn.git to receive that change. Bernhard
Re: [Openvpn-devel] FreeBSD funny in the code
David Sommerseth wrote: Hi David, >> David, could you please pull my branch from Berni, and move that patch >> to wherever bugfixes/code cleanups go? It should merge easily into >> all branches. > > Pushed and pulled. I've only put your extra commit into the bugfix2.1 > branch (as a cherry-pick), and merged it into allmerged. > > At some point, you might consider to pull in the bugfix2.1 branch into > your feat_ipv6_payload branch, just to get in those bug fixes. Hm, I thought we (Gert :-) ) were supposed to develop on top of master? I don't have any preference either way, but as soon as we merge bugfix2.1 into feat_ipv6_payload all those commits are there. It doesn't make a difference at the moment (since the patch came from feat_ipv6_payload in the first place), but what's the general wish for the future? What to rebase on? Bernhard
Re: [Openvpn-devel] FreeBSD funny in the code
Hi David, It doesn't make a difference at the moment (since the patch came from feat_ipv6_payload in the first place), but what's the general wish for the future? What to rebase on? To be very honest, I'm very uncertain about what's best. Because it will a lot of changes in multiple branches. But as I'm able now to keep the bugfix2.1 branch pretty clean with only bugfixes, I begin to lean towards that you should consider to rebase on that branch. Could you please have a look at git://git.birkenwald.de/openvpn.git test-rebase branch? The history of gert-ipv6 was starting to look a bit weird (duplicate commits with the same content), to I rebased it on your bugfix2.1 branch (and dropped the duplicate commits in the process). No difference in the content whatsoever and the history looks much better, but I'm not exactly sure whether this is the right thing to do. Bernhard
Re: [Openvpn-devel] FreeBSD funny in the code
On 01.03.2010 22:59, David Sommerseth wrote: Could you please have a look at git://git.birkenwald.de/openvpn.git test-rebase branch? The history of gert-ipv6 was starting to look a bit weird (duplicate commits with the same content), to I rebased it on your bugfix2.1 branch (and dropped the duplicate commits in the process). No difference in the content whatsoever and the history looks much better, but I'm not exactly sure whether this is the right thing to do. I tried to both merge and rebase both your gert-ipv6 branch and the test-rebase branch from the allmerged branch. That was quite an interesting experience. The test-rebase branch gave most problems. Both rebase and merge got painful. While with the gert-ipv6 gave only (expected, though) issues with rebase. Merging in gert-ipv6 was more or less painless. Yeah ... I'm still having a hard time to wrap my head around the gory git details, but I think rebasing was a bad idea to begin with. Especially in the other direction (you rebasing on gerts tree) :-) As far as I understand it rebasing works by rolling back your local tree to the point you branched from the upstream tree (recording all changes in the progress), fast-forwarding to the HEAD of the upstream (at this point local = upstream) and then reapplying all your local changes. This fits perfectly in a model where you maintain a feature branch upstream has not yet seen. By doing that you guarantee that your feature branch is always a set of patches on top of the current upstream HEAD (guaranteed to merge without conflicts when pulled into upstream), thus making any conflicts that evolve during continued upstream development entirely the feature branch's problem to solve. When I rebased gert-ipv6 on bugfix2.1 I essentially dropped the old changesets and recreated new ones (with different ids). So when you try to merge that rebased tree your git sees new commits and tries to merge them on the tree already containing the changes. Which is something git can only detect (already applied and so on) if that part of the code has not been touched with subsequent changesets. As far as I can see it, the only point where rebasing would be useful is to rebase allmerged on bugfix2.1 and bugfix2.1 on master. But I don't know how much this will break. :-) Bernhard
[Openvpn-devel] Debian package of feat_allmerged
Hi, I have just restarted building Debian/Ubuntu OpenVPN packages for the feat_allmerged branch of openvpn-testing.git for my private use. If you want to test them, feel free to have a look at https://launchpad.net/~berni/+archive/ipv6 . There are up-to-date versions for Ubuntu Karmic and Ubuntu Lucid available. The lucid package works just fine on Debian Squeeze. I don't have binaries for older Ubuntu versions and for Debian Lenny at the moment, because my package relies on new features of dh7. It should be possible to create one with a bit of work if there is demand (I don't run OpenVPN on Lenny anywhere). I will try to automate rebuilding packages on git updates if someone is interested in them. Best Regards, Bernhard
Re: [Openvpn-devel] New maintainer(s) wanted for Debian's OpenVPN packages
Samuli Seppänen wrote:
Hi everyone,
> Alberto Gonzales Iniesta ("agi") is, after 15 years of excellent work,
> letting others take over maintainance of Debian's OpenVPN packages[1]:
>
>
>
> If you're interested in maintaining (or co-maintaining) OpenVPN packages
> on Debian, please comment in the above bug report.
Jörg Frings-Fürst and me have taken over maintainership of OpenVPN in
Debian. Thanks to Alberto for the maintainership in the last decade.
We will slowly wade through the open bugs. There are a couple of things
in the pipeline already (updated debian specific systemd units, build
against OpenSSL 1.1.0, ...), and we will try to keep up with new
upstream releases when they happen.
I'd like to remind here that Debian has a strict policy for updating
packages in stable. We will not ever update the upstream release within
stable, so Debian 9 (stretch) will stay on OpenVPN 2.4.0.
Security bugs will be fixed through applying individual patches from the
2.4-branch on top of 2.4.0.
We can fix major annoyances or usability issues in Debian stable point
releases (approx. every 2-4 months), if they can be fixed by backporting
commits from the git repo on top of 2.4.0. If you have something like
this feel free to drop us a note (or even better, file a bug in the
Debian BTS).
We'll have a look at Samuli's source package within the next weeks and
try to reduce the diff between Debian and his packages as much as
possible.
Best Regards,
Bernhard
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] openssl 1.1 tls version support
Hi,
in https://bugs.debian.org/873302 Kurt Roeckx (Debian OpenSSL
maintainer) submitted a patch for OpenVPN to properly set the minimum
and maximum TLS version. On Debian Buster (current development) OpenSSL
1.1 defaults to TLSv1.2+ only.
I'm unwilling to carry crypto specific patches in Debian. Can anyone
make some sense out of this and apply the patch if possible?
Please keep Kurt CCed and direct any questions to him.
Bernhard
--- src/openvpn/ssl_openssl.c.bak 2017-08-26 13:10:40.333428825 +0200
+++ src/openvpn/ssl_openssl.c 2017-08-26 13:12:05.143672978 +0200
@@ -215,6 +215,19 @@
#endif
}
+/* convert internal version number to openssl version number */
+static int
+openssl_tls_version(int ver)
+{
+if (ver == TLS_VER_1_0)
+return TLS1_VERSION;
+else if (ver == TLS_VER_1_1)
+return TLS1_1_VERSION;
+else if (ver == TLS_VER_1_2)
+return TLS1_2_VERSION;
+return 0;
+}
+
void
tls_ctx_set_options(struct tls_root_ctx *ctx, unsigned int ssl_flags)
{
@@ -232,6 +245,17 @@
tls_ver_max =
(ssl_flags >> SSLF_TLS_VERSION_MAX_SHIFT) & SSLF_TLS_VERSION_MAX_MASK;
+
+#if OPENSSL_VERSION_NUMBER >= 0x1010
+if (tls_ver_min <= TLS_VER_UNSPEC)
+{
+SSL_CTX_set_min_proto_version(ctx->ctx, openssl_tls_version(tls_ver_min));
+}
+if (tls_ver_max <= TLS_VER_UNSPEC)
+{
+SSL_CTX_set_max_proto_version(ctx->ctx, openssl_tls_version(tls_ver_max));
+}
+#else /* OPENSSL_VERSION_NUMBER >= 0x1010*/
if (tls_ver_max <= TLS_VER_UNSPEC)
{
tls_ver_max = tls_version_max();
@@ -253,6 +277,7 @@
sslopt |= SSL_OP_NO_TLSv1_2;
}
#endif
+#endif /* OPENSSL_VERSION_NUMBER */
#ifdef SSL_OP_NO_COMPRESSION
/* Disable compression - flag not available in OpenSSL 0.9.8 */
sslopt |= SSL_OP_NO_COMPRESSION;
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH 1/3] Fix --tls-version-min and --tls-version-max for OpenSSL 1.1+
In gmane.network.openvpn.devel, Steffan Karger wrote: Hi Steffan, > As described in <80e6b449-c536-dc87-7215-3693872bc...@birkenwald.de> on > the openvpn-devel mailing list, --tls-version-min no longer works with > OpenSSL 1.1. Kurt Roeckx posted in a debian bug report: > > "This is marked as important because if you switch to openssl 1.1.0 > the defaults minimum version in Debian is currently TLS 1.2 and > you can't override it with the options that you're currently using > (and are deprecated)." > > This patch is loosely based on the original patch by Kurt, but solves the > issue by adding functions to openssl-compat.h, like we also did for all > other openssl 1.1. breakage. This results in not having to add more ifdefs > in ssl_openssl.c and thus cleaner code. I have forwarded your patch to Kurt and asked for feedback. See attached mail. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873302#32 Bernhard --- Begin Message --- On Wed, Nov 29, 2017 at 03:36:14PM +0100, Bernhard Schmidt wrote: > Hi Kurt, > > Steffan has posted a patch for this that is losely based on yours. It is > not merged yet, comments welcome. > > https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/20171126141555.25930-1-steffan%40karger.me/#msg36136873 I have some comments: - It has: +/* TLS Version defines are new in OpenSSL 1.1 */ +#ifndef TLS1_0_VERSION +#define TLS1_0_VERSION 0x0301 +#endif +#ifndef TLS1_1_VERSION +#define TLS1_1_VERSION 0x0302 +#endif +#ifndef TLS1_2_VERSION +#define TLS1_2_VERSION 0x0303 +#endif It's TLS1_VERSION (not TLS1_0_VERSION) The defines all exist in at least 1.0.1, the version that added support for TLS 1.1 and 1.2 - It calls SSL_CTX_set_min_proto_version() unconditionally, overriding the library default. In the 1.0.2 case SSLv2 and SSLv3 are then disabled, in the 1.1 case it could enable SSLv3. - openssl_tls_version() should probably add SSL3_VERSION support. Kurt --- End Message --- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Re: OpenVPN 2.1-beta3 released
On 2005-10-16, James Yonan wrote: > * Merged --multihome patch. Any chance to merge the IPv6 patch of JuanJo Ciarlante in the current 2.1-series, too? http://www.irrigacion.gov.ar/juanjo/openvpn/ Regards, Bernhard
Re: [Openvpn-devel] IPv6 Feature Request
Joshua Rubin wrote: Hello, > However, my environment uses ifconfig-push so that I can maintain > central control over the assigned IPs. I would really like to be able to > push IPv6 address and redirect IPv6 routes in the same way. We are looking for the exact same thing (at my employer, which is a university computing center). We were thinking about offering an internship to cs students but we haven't found/selected a free and enthusiastic mentor so far (and haven't written up the requirements). Has anyone done more work in this place? I've read/heard this feature request at quite some places lately, I guess one could even find some funding for it. Key feature would be integration into the normal source tree as well, we run the UDP/IPv6 transport patch at some places and it is hard to keep current. Bernhard
Re: [Openvpn-devel] [PATCH] openvpn over ipv6 support -v0.4.6
JuanJo Ciarlante wrote:
Hello JuanJo,
> I'm(back) working on openvpn/ipv6 endpoint support, aka udp6/tcp6,
> please refer to README.ipv6[1] and TODO.ipv6[2] for more details.
>
> All snapshots are unittested for correct {udp,tcp}v{4,6} operation
> under GNU/Linux and win32 (the latter x-compiled under the former ;).
Thank you very much, your work is highly appreciated!
I've updated my Ubuntu PPA repository of IPv6-enabled OpenVPN with your
patch. It contains the Ubuntu Karmic 2.1~rc19-1ubuntu2 package patched
for IPv6 transport, compiled for Karmic and Intrepid. The Intrepid
version should work fine on Debian Lenny as well.
You can find those packages on
https://launchpad.net/~berni/+archive/ipv6/+packages . I have not
observed any problems in my easy usecase (static Point-to-point tunnel
over UDPv6), but no guarantees for anything.
Regards,
Bernhard
Re: [Openvpn-devel] Ubuntu 18.04 packages available for testing
Am 04.01.19 um 17:25 schrieb David Sommerseth: Hi everyone, > Okay, I was a bit unclear. The approach used with openvpn.service and > openvpn@.service are broken by (Debian) design. Quite many users have > reported that these service files does not work at all. But I'll admit, I'm > not really up-to-date if these service files have been updated by > distro-packagers later on. (One of the) Debian OpenVPN maintainer here. I'd like to get some input about the perceived brokenness of the openvpn@.service in Debian. Freeze is coming up, but we still have time to fix issues if they arise. I'm not aware of any major bugs reported for this. First of all, we ship both openvpn@.service (which is maintained in Debian) and openvpn-client@.service and openvpn-server@.service from the upstream sources. As a user of our package you are very much free (and encouraged) to work with OpenVPN in the officially documented way. openvpn@.service mostly comes from a compatibility layer. Since years in Debian you could drop a .conf into /etc/openvpn and had it executed at startup (controlled by a variable in /etc/default/openvpn). This is pretty much remodeled by the use of a custom generator, see https://sources.debian.org/src/openvpn/2.4.6-1/debian/openvpn-generator/ . openvpn.service just binds these instances together to allow for a service openvpn restart to work. And I currently don't see a compelling reason to drop this, since it allows upgrading users to keep working). Since the .conf files are not split between client and server we have to use one openvpn@.service that can accomodate both. But I really fail to see the problem here. openvpn@.service and openvpn-server@.service are not that much different. We do use systemd readyness notification, the capability bounding set is the same (for server), the ExecStart line is similar, we do restart on error. openvpn@.service ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid openvpn-server@.service ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf -client.service is a bit more restricted and uses --nobind and no status file, but that's about it. Bernhard ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Fwd: Bug#1012567: openvpn --mktun --dev-type tap --dev tap2 fails
Hi, I've received the following bug report for the dco-enabled OpenVPN 2.6 build currently sitting in Debian unstable. It looks like DCO is interfering with the CLI option to create a tap interface. Bernhard --- Package: openvpn Version: 2.6.0~git20220518+dco-2 Severity: important Since 2.6.0~git20220518+dco-2 the following command fails: openvpn --mktun --dev-type tap --dev tap2 with Assertion failed at dco_linux.c:442 (tt-type == DEV_TYPE_TUN) Exit due to fatal error I don't have dco support in the linux kernel. openvpn --disable-dco --mktun --dev-type tap --dev tap2 works as a workaround, but I think --mktun --dev-type tap should continue to work without it. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts --- ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
