Opened 7 years ago

Closed 6 years ago

#279 closed Bug / Defect (wontfix)

tun-ipv6 warning found when connecting to a v2.2 server from a v2.3 client

Reported by: David Sommerseth Owned by: Gert Döring
Priority: trivial Milestone: release 2.3.7
Component: Configuration Version: OpenVPN 2.3.1 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:


See Red Hat bugzilla 952940 for more info.

Change History (6)

comment:1 Changed 7 years ago by JoshC

I'm not sure we really want to do anything about this since the 2.2.x series never officially "had" IPv6 support. While some downstream vendors (Debian/Ubuntu?, Redhat, maybe others) used the development patches, having it generate warnings on clients hardly seems an issue we should fix, much less attempt to support a feature never in an actual release (pre-2.3 IPv6 interaction.)

If I've missed something from the referenced downstream bugreport, feel free to add it. Otherwise, I'm inclined to file this 'wontfix.'

Last edited 7 years ago by JoshC (previous) (diff)

comment:2 Changed 7 years ago by David Sommerseth

I can understand that, kind of. And I even agree to some degree too.

But there are OpenVPN service providers who might not be ready to upgrade their servers to a 2.3 code base yet. However, many Linux distros updated to the a 2.3 code base.

IPv6 was also possible earlier too on Linux (the --tun-ipv6 option is an old option, going back to at least commit 6fbf66fad3367b24) - but it required quite some manual configuration to make it work. But in OpenVPN 2.3, some code paths and options checks were modified. And this is now causing 2.3 clients to complain if the server uses --tun-ipv6. This is most likely caused by an oversight when comparing options between remote and local configs.

I vaguely remember we did some updates improving the situation for some options, in this remote/local comparison check. I don't remember now if we fixed tun-ipv6 or if it was some other options as well. But it might be worth digging into this further. If my memory serves me right, it was cron2 who provided the patch.

comment:3 Changed 6 years ago by Gert Döring

Milestone: release 2.3.5

Reading through the original bug report makes me wonder a bit - it says AUTH_FAILED, so it *might* be more than a warning, but triggering a --opt-verify disconnect on the server.

OTOH "upgrade to 2.3.x" is good advice in any case.

The warning will still be there if the client relies on the server pushing --tun-ipv6 (so it will not be in the client config before the server pushes it, triggering the warning) but *that* is purely cosmetic...

Need to find time to think about it. It's an old wart, maybe we should really get rid of the non-helpful warning in 2.3.5/2.4

comment:4 Changed 6 years ago by Samuli Seppänen

Owner: set to Gert Döring
Status: newassigned

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

Milestone: release 2.3.5release 2.3.7

comment:6 Changed 6 years ago by Gert Döring

Resolution: wontfix
Status: assignedclosed

OK, coming back to this. I think we should just close the issue, and tell people that are connecting to a 2.2/2.1 server to remove "tun-ipv6" from their configs.

The underlying issue is that we're not considering tun-ipv6 for OCC checking *in 2.3.*:

commit f21410729e68b553f391dc036c0372fd3690714e
Author: Gert Doering <gert@…>

"tun-ipv6" is only sent in option string if running in point-to-point
mode (= not --server and not --client or --pull), because in those
scenarios it's usually pushed by the server, and the client does not
yet have it when comparing options -> needless warning.

(which went into 2.3_rc2)

If talking to an unmodified 2.2 point-to-multipoint server, the server will not have IPv6 support, even if it knows the option --tun-ivp6 (it was there for p2p support forever, but didn't work in p2mp setup). So that server should just remove --tun-ipv6 from its config, and no OCC warning will occur - and no functionality is lost, as it doesn't do IPv6 anyway.

The problem case that remains is the combination of a 2.2 server with the IPv6 payload patch and OCC consistency checking and --tun-ipv6 enabled, talking to a 2.3 client. In that case, the 2.3 client will not send the --tun-ipv6 option, but the server expects it, OCC-checks it, and kicks out the client due to option mismatch. For this case, I'd strongly argue to upgrade the server to 2.3.x (which will not include --tun-ipv6 in the OCC string), or to patch the (2.2+ipv6) code with the referenced commit (same result). Or just disable --opt-verify...

Besides having some sort of extra-special "yes, really put tun-ipv6 into OCC!" option (no way!) or a new release of 2.2 with that commit backported, I do not see a way to fix this. Even doing a new 2.2 release would require getting "whatever distribution is used on the server side" to pick it up...

Closing! David, if you disagree and have a better idea to move forward, feel free to reopen.

Note: See TracTickets for help on using tickets.