GNOME Bugzilla – Bug 731620
No GUI option for IPv6
Last modified: 2017-11-23 21:38:35 UTC
As OpenVPN introduces IPv6, there should also be the possibility to setup IPv6 within the Network Manager Gui, or it should switch autocratically. To get this done, only the protocol needs to be changed within the OpenVPN config (from udp -> upd6, tcp -> tcp6). Introducing a automatic switch would be a convenient solution.
Are you referring to the configuration --remote host [port] [proto] with [proto] being udp6 or tcp6? or do you mean: --proto p "Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server." Manual pages don't mention udp6/tcp6. https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage Some more details would be advised.
Hello Thomas. Yes, I am referring to --remote host [port] [proto] There is currently no option in the Network Manager GUI to use IPv6 addresses (for remote hosts).
The manual page makes no mention about --remote accepting udp6/tcp6. Can you provide a link? Why would openvpn ask for such a configuration? You configure the remote host (which either resolves to IPv4 or IPv6, so what's the point of explicitly specifying that?)
Same problem. OpenVPN manpage needs updating. It mentions 'udp6/tcp6' but not at the option '--proto'. '--proto udp6/tcp6' is need for connecting to an OpenVPN server with an IPv6 address. Otherwise, if use '--proto udp/tcp', openvpn will fails to resolve the IPv6 address of server. https://github.com/OpenVPN/openvpn/blob/master/README.IPv6 The only documentation about this problem provided by OpenVPN which I can find is the one embedded in its source code archive.
I can confirm the issue. On a network with only IPv6 available (FOSDEM conference default wifi, for instance), it is not possible to use an openVPN VPN configured with NetworkManager, because it only tries udp (which means udpv4 for openVPN) and there is no way to either force udpv6 or, even better, have both tried options tried if the first fails.
Looking at bug#682620, this issue should have been fixed. And it seems to require openVPN 2.4 to make it work.
Created attachment 357689 [details] [review] Allow IPv6 remote address in gateway entry while editing an openvpn connection I'm working on the IPv6 support in NM-openvpn recently. And this is the first patch which allows IPv6 remote address in gateway entry while editing an openvpn conneciton. I've made some progress in parsing IPv6 remote address. That patch will be attached soon.
(In reply to Jonathan Kang from comment #7) > Created attachment 357689 [details] [review] [review] > Allow IPv6 remote address in gateway entry while editing an openvpn > connection > > I'm working on the IPv6 support in NM-openvpn recently. And this is the first > patch which allows IPv6 remote address in gateway entry while editing an > openvpn conneciton. > > I've made some progress in parsing IPv6 remote address. That patch will be > attached soon. Hi Jonathan, the change in check_gateway_entry() seems not correct to me. Does Openvpn even support specifying an IPv6 remote address with [::] notation? I think we could just search from the colon from the right end, so one could specify 2001:dead:beef::1:1194:udp or just 2001:dead:beef::1:: also, the parsing of this line is currently duplicated at 3 places. It should be moved to one function.
Created attachment 357891 [details] [review] add support for IP address family specifier for remote protocol Add support for udp4/udp6/tcp4/tcp6 and the tcp*-client specifiers. - refactor parsing of host:port:proto for --remote into a function nmovpn_remote_parse(). Also, search for the ':' delimiter from the right side. That way, one could use colons in the host like using an IPv6 address "aa:bb::1:1194:udp" (or just "aa:bb::1::"). - during export, also consider '\t' as delimiter for mulitple remotes. - during export, if port is unspecified but proto is given (a very unusual case), export port as "1194" instead of "443" for TCP. That is what server also does in case port is missing, and also is 1194 the default port for OpenVPN.
(In reply to Thomas Haller from comment #8) > (In reply to Jonathan Kang from comment #7) > > Created attachment 357689 [details] [review] [review] [review] > > Allow IPv6 remote address in gateway entry while editing an openvpn > > connection > > > > I'm working on the IPv6 support in NM-openvpn recently. And this is the first > > patch which allows IPv6 remote address in gateway entry while editing an > > openvpn conneciton. > > > > I've made some progress in parsing IPv6 remote address. That patch will be > > attached soon. > > Hi Jonathan, > > the change in check_gateway_entry() seems not correct to me. Does Openvpn > even support specifying an IPv6 remote address with [::] notation? Emm. I checked wikipedia[1] and found out this rule, but I'm not sure if it's used in openvpn. > > I think we could just search from the colon from the right end, so one could > specify > 2001:dead:beef::1:1194:udp > or just > 2001:dead:beef::1:: I suppose we'll have to add two ':' after the ipv6 address even if we don't want to specify the port and proto. Inputing "2001:dead:beef::1" lead to an invalid config. *[1]https://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_network_resource_identifiers
(In reply to Jonathan Kang from comment #10) > (In reply to Thomas Haller from comment #8) > > (In reply to Jonathan Kang from comment #7) > > > Created attachment 357689 [details] [review] [review] [review] [review] > > > Allow IPv6 remote address in gateway entry while editing an openvpn > > > connection > > > > > > I'm working on the IPv6 support in NM-openvpn recently. And this is the first > > > patch which allows IPv6 remote address in gateway entry while editing an > > > openvpn conneciton. > > > > > > I've made some progress in parsing IPv6 remote address. That patch will be > > > attached soon. > > > > Hi Jonathan, > > > > the change in check_gateway_entry() seems not correct to me. Does Openvpn > > even support specifying an IPv6 remote address with [::] notation? > > Emm. I checked wikipedia[1] and found out this rule, but I'm not sure if > it's used > in openvpn. This [::] notation is mostly used in URLs. It's not clear that openvpn supports that . > > > > I think we could just search from the colon from the right end, so one could > > specify > > 2001:dead:beef::1:1194:udp > > or just > > 2001:dead:beef::1:: > > I suppose we'll have to add two ':' after the ipv6 address even if we don't > want > to specify the port and proto. Inputing "2001:dead:beef::1" lead to an > invalid > config. > > *[1]https://en.wikipedia.org/wiki/ > IPv6_address#Literal_IPv6_addresses_in_network_resource_identifiers correct.
(In reply to Thomas Haller from comment #11) > (In reply to Jonathan Kang from comment #10) > > (In reply to Thomas Haller from comment #8) > > > > I think we could just search from the colon from the right end, so one could > > > specify > > > 2001:dead:beef::1:1194:udp > > > or just > > > 2001:dead:beef::1:: > > > > I suppose we'll have to add two ':' after the ipv6 address even if we don't > > want > > to specify the port and proto. Inputing "2001:dead:beef::1" lead to an > > invalid > > config. > > > > *[1]https://en.wikipedia.org/wiki/ > > IPv6_address#Literal_IPv6_addresses_in_network_resource_identifiers > > correct. we could try to guess that the first part already is IPv6 address, and that the colon shall not be treated as separator. But that complicates the rules how to interpret the string. That is not hard to implement, but hard to document/understand for the user. Given how unlikely it is that somebody enters there a plain IPv6 address, the current notation seems simpler and suitable. Dunno.
(In reply to Thomas Haller from comment #12) > > we could try to guess that the first part already is IPv6 address, and that > the colon shall not be treated as separator. But that complicates the rules > how to interpret the string. That is not hard to implement, but hard to > document/understand for the user. > > Given how unlikely it is that somebody enters there a plain IPv6 address, > the current notation seems simpler and suitable. Dunno. Fair enough. It makes sense to me. Thanks.
Thinking some more... guessing makes it hard to understand what means "2001:dead:beef::1:1194" Maybe the plugin could allow the [::] notation (even if openvpn itself wouldn't support it). But that seems unexpected to the user as well (we either would need to document to use "[]" or "::"). The problem is that we use colon as separator. We cannot change that now, so plain IPv6 addresses are problematic either way. The workaround is to append :: to an IPv6 address, which seems acceptable (but still ugly).
To make it simpler for users, without the need to consult the documentation, we could accept all the following: IPv6 IPv6:port:proto [IPv6] [IPv6]:port [IPv6]:port:proto Also, a tooltip in the GUI could show what the valid syntax is.
Ok, after discussion, I merged https://git.gnome.org/browse/network-manager-openvpn/commit/?id=3c5c7efba75ffd121be3b0ac179c36ca9aa772b0 Now, IPv6 addresses can both be escaped with square brackets and are taken verbatim. That is, parsing them as IPv6 address has highest priority, for that reason "aa:bb::1:1194:udp" is an invalid confguration (because it looks like the port is "udp"). The workaround is "[aa:bb::1]:1194:udp". Another outcome is that --remote a: cannot be expressed in NM configuration, because - "a:" would be treated as "a" - "a::" would be treated as "a::" - "a:::" would be treated as "a::" You can also not do --remote a: 1194 because - "a::1194" would be treated as "a::1194" - "a::1194:" would be treated as "a::1194" Basically, certain hostnames with colon (but not IPv6 addresses) cannot be supported with this syntax.
*** Bug 784461 has been marked as a duplicate of this bug. ***
*** Bug 790769 has been marked as a duplicate of this bug. ***