Opened 8 years ago

Closed 7 weeks ago

#264 closed Feature Wish (wontfix)

[PATCH] IPv6 p2p issues

Reported by: leres Owned by: Gert Döring
Priority: minor Milestone: release 2.5
Component: IPv6 Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: IPv6 p2p
Cc: openvpn13@…

Description

I had a couple problems adding IPv6 to an existing IPv6 p2p tunnel configuration. I want to use:

# server
 ifconfig-ipv6 2620:83:8000:3088::101/128 2620:83:3000:8088::445
# client
ifconfig-ipv6 2620:83:8000:3088::445/128 2620:83:3000:8088::101

First I ran into:

ifconfig-ipv6: /netbits must be between 64 and 124, not /128

Once I "fixed" that the ifconfig command issued was missing the remote end:

# server
openvpn_test[57456]: /sbin/ifconfig tun6 inet6 2620:83:3000:8088::101/128

Attached are patches for both changes I needed.

Attachments (3)

patch-srcopenvpnoptions.c (591 bytes) - added by leres 8 years ago.
patch-src_openvpn_options.c (591 bytes) - added by leres 8 years ago.
patch-src_openvpn_tun.c (718 bytes) - added by leres 8 years ago.

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by leres

Changed 8 years ago by leres

Attachment: patch-src_openvpn_options.c added

Changed 8 years ago by leres

Attachment: patch-src_openvpn_tun.c added

comment:1 Changed 8 years ago by Gert Döring

This is not the way it is supposed to work - we run the tun interface as a network, not as a /128 with independent addresses on the left and right end (because that is not working on all supported platforms).

Just assign a /124 to the tun, and give both sides an address out of it

side A:

ifconfig-ipv6 2620:83:8000:3088::10a/124

sideB:

ifconfig-ipv6 2620:83:8000:3088::10b/124

you have enough IPv6 addresses so you can afford "wasting" a /124 there.

comment:2 Changed 8 years ago by Gert Döring

Owner: set to Gert Döring
Priority: majorminor
Status: newaccepted
Type: Bug / DefectFeature Wish

comment:3 Changed 7 years ago by Samuli Seppänen

cron2: do we want to implement this feature at some point, or should we just close this ticket?

comment:4 Changed 5 years ago by Gert Döring

Milestone: release 2.4
Version: 2.3.0git master branch

We're not changing this for 2.3, but I might be tempted to work on this (read: ensure that it actually works on all supported platforms!) for 2.4 - for example, most if the BSDs would need an extra route for the remote address, not just an extra ifconfig parameter (if that is valid at all).

But maybe not. The IPv6 code really wants a subnet.

comment:5 Changed 4 years ago by jankratochvil

Using such setup with custom 'up' script calling IP6 ifconfig/route/ip commands and it works fine. I do not understand why I should create subnets for openvpn when they are not needed using the ip commands.

comment:6 in reply to:  1 Changed 12 months ago by netravnen

Replying to Gert Döring:

This is not the way it is supposed to work - we run the tun interface as a network, not as a /128 with independent addresses on the left and right end (because that is not working on all supported platforms).
Just assign a /124 to the tun, and give both sides an address out of it
you have enough IPv6 addresses so you can afford "wasting" a /124 there.

I prefer if the upper-limit is increased from /124 to /127.

Sep 18 20:37:28 vm372 ovpn-tun0[17491]: Options error: ifconfig-ipv6: /netbits must be between 64 and 124, not '/127'
Sep 18 20:37:28 vm372 ovpn-tun0[17491]: Use --help for more information.
Sep 18 20:37:28 vm372 systemd[1]: openvpn@tun0.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- An ExecStart= process belonging to unit openvpn@tun0.service has exited.
$ dpkg -s openvpn 
Package: openvpn
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 1140
Maintainer: Bernhard Schmidt <berni@debian.org>
Architecture: amd64
Version: 2.4.7-1
Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.15), liblz4-1 (>= 0.0~r130), liblzo2-2, libpam0g (>= 0.99.7.1), libpkcs11-helper1 (>= 1.11), libssl1.1 (>= 1.1.1), libsystemd0, iproute2, lsb-base (>= 3.0-6)
Recommends: easy-rsa
Suggests: openssl, resolvconf, openvpn-systemd-resolved
Conffiles:
 /etc/default/openvpn 3c4d9d1b3f89320396784cc21a142a22
 /etc/init.d/openvpn cf1bc30e71de3b3e4a2f05dc8bf095e4
 /etc/network/if-down.d/openvpn 33ce4a4608a2f2e129c1feb05daa2f97
 /etc/network/if-up.d/openvpn 5c1e39845a263f512b81ee62c1f37b92
 /etc/openvpn/update-resolv-conf b75b20ba3fd750b33e47dd81e2c427a8
Description: virtual private network daemon
 OpenVPN is an application to securely tunnel IP networks over a
 single UDP or TCP port. It can be used to access remote sites, make
 secure point-to-point connections, enhance wireless security, etc.
 .
 OpenVPN uses all of the encryption, authentication, and certification
 features provided by the OpenSSL library (any cipher, key size, or
 HMAC digest).
 .
 OpenVPN may use static, pre-shared keys or TLS-based dynamic key exchange. It
 also supports VPNs with dynamic endpoints (DHCP or dial-up clients), tunnels
 over NAT or connection-oriented stateful firewalls (such as Linux's iptables).
Homepage: https://openvpn.net/
Last edited 12 months ago by netravnen (previous) (diff)

comment:7 Changed 11 months ago by Gert Döring

Milestone: release 2.4release 2.5

We missed 2.4 release by a wide margin. Maybe I can find time to look into this again (across all platforms!) for 2.5.

"Just because it works on Linux with the 'ip' command" is not sufficiently good for an upstream change -- it either needs to work on all supported platforms or be documented appropriately.

comment:8 Changed 7 weeks ago by Gert Döring

Resolution: wontfix
Status: acceptedclosed

I am closing this now with "wontfix".

The IPv6 handling code "for all platforms" assumes subnets, and using a /124 for a p2p link is a perfectly fine way to do so.

Yes, it works on Linux with /128s and p2p addressing.

Maybe it works on Windows, FreeBSD, NetBSD, OpenBSD, MacOS, OpenSolaris? and AIX. Maybe not. Someone needs to test this initially, and keep testing this to ensure we do not accidentially break it with some refactoring.

This is lots of work, and I do not see anyone interested in doing this (for *all* platforms). There is still bugs in the existing IPv6 code for some of the oddball configurations, so it's not good for the overall code quality and project maintenance to introduce yet another variant.

Subnets it is, if you want OpenVPN to handle IPv6 address configuration for you.

If you want something else, and that works on your platform, --up is the tool for you.

(As a side note: /127 does not work on all platforms either. /124 is "it works always" safe land)

Note: See TracTickets for help on using tickets.