#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)
Change History (12)
Changed 12 years ago by
Attachment: | patch-srcopenvpnoptions.c added |
---|
Changed 12 years ago by
Attachment: | patch-src_openvpn_options.c added |
---|
Changed 12 years ago by
Attachment: | patch-src_openvpn_tun.c added |
---|
comment:1 follow-up: 6 Changed 12 years ago by
comment:2 Changed 12 years ago by
Owner: | set to Gert Döring |
---|---|
Priority: | major → minor |
Status: | new → accepted |
Type: | Bug / Defect → Feature Wish |
comment:3 Changed 11 years ago by
cron2: do we want to implement this feature at some point, or should we just close this ticket?
comment:4 Changed 9 years ago by
Milestone: | → release 2.4 |
---|---|
Version: | 2.3.0 → git 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 8 years ago by
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 Changed 5 years ago by
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/
comment:7 Changed 5 years ago by
Milestone: | release 2.4 → release 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 4 years ago by
Resolution: | → wontfix |
---|---|
Status: | accepted → closed |
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)
comment:9 Changed 13 months ago by
Gert, any reason why /124 was chosen and not /126 for example? I expect /126 to be fully compatible with every OS/implementation.
By the way, ifconfig-ipv6 is inconsistent on server and client: ifconfig-ipv6-push allows pushing 0-128 bits, while the client only accepts 64-124 bits.
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:
sideB:
you have enough IPv6 addresses so you can afford "wasting" a /124 there.