vpn and stuff


It's not that I ever really liked NM, but.

After I set up my VPN with dispatcher.d scripts (it seems my SuSE install doesn't automatically call any ifup.d scripts but then it doesn't have /etc/network/ either. ;-)).

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.

VPN seems to work but it is very fallible.

It can really break at any junction.

I have noticed these things:

- it may happen that the existing openvpn instance is not closed but since it occupies localhost:1194 any new start will fail - it may happen and maybe this is the result of some 'tweak' I made (as well as the previous item).... that openvpn takes a longer time to connect and NM will lose its knowledge of that process - it may happen that cute girls arive and then your wifi stops working, but that's another story.

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.

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 .service files".

I have to kill my OpenVPN process to enable NM to use it again.

After that this happens instead:

<info> (tun0): new Tun device (driver: 'unknown' ifindex: 6)
<info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/5

And it connects successfully.

* My tunnel unexpectedly closes, this causes the OpenVPN to disconnect, the process keeps running and retrying, apparently NM gets notified that the connection is lost, but once OpenVPN reconnects NM doesn't update the routing table and I have an ineffective or inoperational VPN

I have to kill OpenVPN and restart it using NM.

All this is extremely arduous as it happens all the time.

NM doesn't really live up to its ideal of (check website).

It's not fuss-free at all.

Whenever my link fails I know it is 80% certain to be NM instead of a problem with my actual link.

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.

Another problem, and an inconfigurability.


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 Same for VPN_, I don't know if it contains the new route or the old routes. Maybe both even.

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.


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.

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.


Requesting OpenVPN listens at port 1194 for the management console might not be the most rad choice as a user may want to use that port for tunneling to a remote OpenVPN server. So you get a conflict between the tunnel listening socket and OpenVPN opening a port there to receive commands. It seems wrong to use the same port number for both. Right now I'm having to put my tunnel at 1193 (for example) just so OpenVPN (nonconfigurable? --) runs at 1194. This is a parameter choice of NM:

--management 1194


Seriously I would suggest to get rid of the CamelCase name. It breaks compatibility or congruency with a lot of other things and as a user you are constantly wondering what the name is going to be. NetworkManager? networkmanager? network-manager? It changes from situation to situation. There is no reason for NetworkManager to be capitalized (least of all the binary) because this is no user-friendly system where NM sits inside some sort of pretty application catalogue. Linux packages are always lowercased. Most Linux directories are lowercased (and they should be). You have to follow convention. This only creates problems. This is not Microsoft Windows where each program sits in C:\Programs or C:\Program Files and where filenames are CASE INSENSITIVE. Even the KDE convention to name the "Documents" and "Pictures" folders with upper cases creates issue because of the case sensitivity, which means that "cd documents" won't work. If you want this in Linux, you have to ensure that the actual names are lower case, but that you create a representation in the GUI (!!!) that is capitalized. I know other packages do this as well, notably PackageKit and UPower, but it is bad habit and bad choice and makes it harder for everyone, because most of what you do in Linux is still done using the COMMAND LINE.


So I guess these are my issues till now.

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