You bring up so many different points, that it's hard to keep track of them. It would be better to discuss them individually or open Bugs for it.
I managed to also integrate it with the plasma applet thing for KDE 4, which is really nice in user interface terms for the largest part (after you realise the non-button-like tool icon is not decoration but a vital part of its configuration).
Which is not a NM issue but KDE, it is one of the least intuïtive ways to present a button and pretend to hope that the user will understand to click on it. The argument against the argument against was probably "well, he just has to hover over it, doesn't he"?. Anyway.
KDE/plasma-nm design decision. Please open a bug.
I happened to create a kind of forward shell script that added the option --cipher none to NM's openvpn invocation. This may be the cause of my current problems, in that NM constantly loses track of an existing openvpn connection/process.
From your wrapper script, do you invoke the openvpn binary with "exec", contrary to "call"? That seems important.
Symptoms I've seen were: * OpenVPN takes longer to connect due to an issue. When finally it connects (as it keeps running in the background) this happens: /usr/lib/nm-openvpn-service-openvpn-helper --tun -- tun0 1500 1528 10.8.0.6 10.8.0.5 init Could not send configuration information: The name org.freedesktop.NetworkManager.openvpn was not provided by any .service files".
your installation seems broken.
So basically what I see is that if OpenVPN disconnects, it notifies NM, but once it reconnects, NM doesn't know and the process becomes like a ghost process. And I have to manually shut it down each and every time. At least if I run my VPN manually I have NO ISSUES except for the one issue that NM will not allow me to remove the default route for its managed connection. So whatever way you frame it, NM is really my only issue ;-). OpenVPN itself works without a hitch. ============================== Then you have the problem that NM doesn't know about OpenVPN's "cipher none" mode. You cannot get it (I cannot get it) to pass that parameter to OpenVPN.
It's a UI bug only (https://git.gnome.org/browse/network-manager-openvp n/commit/?id=be63c404a146704e3e4840f050d5bdd63bc94826) You can still use the none cipher by configuring it either with nmcli or by editing the connection file under /etc/NetworkManager/system -connections/.
============================== The only benefit for NM for me at this point is its gui. Without the lock icon in the system tray, it is hard for me to know whether I am running VPN or not. And because of its interface it's easier to start and stop it. Using the console to do that is not fun. ============================== Sometimes my tunnel fails and since it is a simple SSH tunnel using /root/.ssh/config but with a custom startup script, I have to check on its status using the console. That is tiresome by itself, but OpenVPN is capable of just picking up where it left; it's just that NM mostly is not. ============================== I have a custom dispather.d script that sets another route on vpn-up. I need this for my tunnel host (which is also the VPN host). I think I can also do this using VPN options (extra routes) but my problem at this point is this: Is there a way to obtain the equivalent of OpenVPN variable "net_gateway"? _ net_gateway _ is a variable that indicates the OLD gateway address before VPN is activated. I know there is IP4_ROUTE_N and IP4_NUM_ROUTES. But at best this is a list of all routes. Do I have to manually search it for the route to 0.0.0.0? Same for VPN_, I don't know if it contains the new route or the old routes. Maybe both even.
IP4_GATEWAY environment variable. See `man NetworkManager` Or `nmcli -t -f IP4.GATEWAY connection show uuid $CONNECTION_UUID`
In OpenVPN the program gives me the required route target so I don't have to fix it in any script. With NM I have to write a custom script or add a route to the config that seems to have to be fixed????. ============================== When NM has a connection as managed, manual interference with IP address and such becomes impossible. I consider this a big problem. The problem does not arise with adding new IP addresses to any device.
What is your basis to claim "impossible". It is possible. What issues did you encounter?
============================== When manually using OpenVPN from/above/on top of a connection that is managed, I cannot remove the default route of the managed connection, whereas that is mostly 'necessary' for the main type of VPN use. NM should honour user decisions more instead of forcing correctness from its own model, which is (or very likely can be) incomplete. The fallacy is to think or consider that NM is always fully configured.
You can configure default-routes externally. NM should not interfere if you set "ipv4.never-default=yes".
Or even that it is feature complete. ============================== The issues with "forgetting" the OpenVPN process could be caused by my renaming openvpn to openvpn.real. But that would be rather odd because it would imply a dependency on the process NAME whereas it seems as though NM takes care of a 'callback' feature in OpenVPN.
Maybe it's "forgetting" the process, because your wrapper script spawns away. Did you use "exec"? Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part