vpn and stuff

[Xen <list xenhideout nl>]

Hi,

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

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 0.0.0.0? 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 127.0.0.1 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.