Re: vpn and stuff

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

I managed to also integrate it with the plasma applet thing for KDE
which is really nice in user interface terms for the largest part
you realise the non-button-like tool icon is not decoration but a
part of its configuration).

Which is not a NM issue but KDE, it is one of the least intuïtive
to present a button and pretend to hope that the user will understand
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
of my current problems, in that NM constantly loses track of an
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 init

Could not send configuration information: The name 
org.freedesktop.NetworkManager.openvpn was not provided by any

your installation seems broken.

So basically what I see is that if OpenVPN disconnects, it notifies
but once it reconnects, NM doesn't know and the process becomes like
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
none" mode. You cannot get it (I cannot get it) to pass that
to OpenVPN.

It's a UI bug only (
You can still use the none cipher by configuring it either with nmcli
or by editing the connection file under /etc/NetworkManager/system


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
its status using the console. That is tiresome by itself, but OpenVPN
capable of just picking up where it left; it's just that NM mostly is


I have a custom dispather.d script that sets another route on vpn-up.
need this for my tunnel host (which is also the VPN host). I think I
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
IP4_NUM_ROUTES. But at best this is a list of all routes. Do I have
manually search it for the route to Same for VPN_, I don't
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
add a route to the config that seems to have to be fixed????.


When NM has a connection as managed, manual interference with IP
and such becomes impossible. I consider this a big problem. The
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
its own model, which is (or very likely can be) incomplete.

The fallacy is to think or consider that NM is always fully

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
renaming openvpn to openvpn.real. But that would be rather odd
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"?


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]