GNOME Bugzilla – Bug 635179
additional options [e.g. hand-window to increase the TSL handshake window]
Last modified: 2020-11-12 14:28:28 UTC
The number of openvpn options supported by the GUI is currently very limited. This leads to a nice, simple and clean GUI, nevertheless, it would be very useful to be able to customize some connections a little more. E.g. I have to set the hand-window option to increase the time window for the TSL handshake in order to use openvpn on a very slow line. It would be nice to be able to pass additional parameters like hand-window to the openvpn command by adding an appropriate key to the gconf settings. Currently unknown keys lead to an error message like: <warn> VPN connection 'foo' failed to connect: 'property 'hand-window' invalid or not supported'. I propose to pass unknown keys to the openvpn command [prepend "--" to the key name and append the "--key value" sting to the openvpn args] instead of filtering them. This way the module gains a lot of flexibility with a limited effort.
What value do you have to increase the handshake window to? How slow is the line, out of curiosity?
my needs are quite "special purpose" and I wouldn't have filed a feature request just for the increased handshake window; but I really like the idea to set arbitrary openvpn options via gconf. This way the GUI is still easy to use but advanced users can play with whatever options they like and while using a highly customized openvpn connection still enjoy the advantages of NetworkManager. But to satisfy your curiosity: I need to connect to a cluster via microwave uplink; throughput and round trip time vary greatly depending on weather and the amount of traffic on the line. With good conditions the RTT is about 1 second and the default handshake window of 60s is usually sufficient. Unfortunately I have no real data for "bad conditions" as I have to wait for them to happen and can not perform extensive test runs [there is no backup line and the uplink is needed...]. Nevertheless, last time I managed to connect with a handshake window of 2 minutes, but I'm not sure if this is enough for bad weather conditions.
I have a similar situation as I need the "keysize" option. There is a workaround at https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/364101.
Created attachment 242638 [details] [review] Add the 'keysize' parameter to nm-openvpn Support for the keysize parameter. Tested by Danni, who also needs it for her work VPN.
(In reply to comment #0) > The number of openvpn options supported by the GUI is currently very limited. HA! Good one! :) OpenVPN has more options than all the other VPN plugins combined. (Did you not notice the "Advanced" sub-dialog?) We really need to come up with a long-term solution here, as I'm sure there are still dozens of OpenVPN options we don't support. (There are currently also more NM OpenVPN bugs open than there are of all other VPN plugins combined...) (I didn't look at Danni's patch yet... will do that later.)
(In reply to comment #5) > We really need to come up with a long-term solution here, as I'm sure there are > still dozens of OpenVPN options we don't support. (There are currently also > more NM OpenVPN bugs open than there are of all other VPN plugins combined...) Yeah, I considered refactoring to make it all really generic, but I'm also very lazy. I also considered just trying to use some kind of passthrough, so unknown options can still be added to the config file and would be passed through to OpenVPN, but again, really lazy.
Comment on attachment 242638 [details] [review] Add the 'keysize' parameter to nm-openvpn >@@ -399,12 +406,66 @@ config: fragment</property> > <object class="GtkSpinButton" id="fragment_spinbutton"> > <property name="visible">True</property> > <property name="can_focus">True</property> >+ <property name="tooltip_text" translatable="yes">Enable internal datagram fragmentation with this maximum size. >+config: fragment</property> unrelated, could go in a separate patch >+ <object class="GtkCheckButton" id="keysize_checkbutton"> ... >+ <property name="tooltip_markup" translatable="yes">Enable internal datagram fragmentation with this maximum size. >+config: fragment</property> >+ <property name="tooltip_text" translatable="yes">Enable internal datagram fragmentation with this maximum size. >+config: fragment</property> And the tooltip on the new checkbox and spinbutton need to be fixed to refer to the right option. (And there's no reason to define tooltip_markup on those since (a) we don't anywhere else, and (b) there's no markup in it. I'm sure that's glade's fault, and not anything you did intentionally, but please fix it up.) Also, it seems like keysize belongs on the "Security" page, not "General"?
(In reply to comment #7) > (From update of attachment 242638 [details] [review]) > >@@ -399,12 +406,66 @@ config: fragment</property> > > <object class="GtkSpinButton" id="fragment_spinbutton"> > > <property name="visible">True</property> > > <property name="can_focus">True</property> > >+ <property name="tooltip_text" translatable="yes">Enable internal datagram fragmentation with this maximum size. > >+config: fragment</property> > > unrelated, could go in a separate patch Hmm, I don't even remember writing this. Guess I did. > And the tooltip on the new checkbox and spinbutton need to be fixed to refer to > the right option. (And there's no reason to define tooltip_markup on those > since (a) we don't anywhere else, and (b) there's no markup in it. I'm sure > that's glade's fault, and not anything you did intentionally, but please fix it > up.) Right. Generally, I'm hella-busy between now and about August 31. So I'm happy for anyone else to fix these things up, because I'm not sure when I'll get to it.
Created attachment 248426 [details] [review] updated patch
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).