As per the title, how would I go about using an openvpn connection without using networkmanager?
I can use the connection with kde’s networkmanager using the password method but I want one machine to continue using the openvpn connection when logged out of the desktop
Is there a way to do this? Everything I’ve been able to find in searches seems to be about networkmanager
Yes,
You can invoke your VPN during system boot.
Should be in the MAN pages.
Remember that a VPN is not possible until <after> your regular network connection is fully established.
BTW - If you’re already using Network Manager, this can be configured NM also.
HTH,
TSU
Thanks for the reply there tsu2, though I was kinda hoping for some sort of a clue to help me get started rather than advice to RTFM
BTW - The question is how to do it without networkmanager as I want to use openvpn when not logged into any DE as stated, so I’m not really sure what you meant by ‘if I’m already using networkmanager then I can also configure it with networkmanager’. I can only guess that you meant if I’m using NM for ethernet/wireless I can also use it for openvpn, though I already said I can use the openvpn connection with NM but want to connect without having to use NM at all
Usually I use ifup with all machines other than anything portable that isn’t always going to use the same connection which in my case is quite a rarity, but it’s only very recently I started making use of openvpn so it’s pretty much unchartered territory for me
The openvpn docs have this to say about starting openvpn at boot which doesn’t really go into any detail:
Configuring OpenVPN to run automatically on system startup
The lack of standards in this area means that most OSes have a different way of configuring daemons/services for autostart on boot. The best way to have this functionality configured by default is to install OpenVPN as a package, such as via RPM on Linux or using the Windows installer.
Linux
If you install OpenVPN via an RPM package on Linux, the installer will set up an initscript. When executed, the initscript will scan for .conf configuration files in /etc/openvpn, and if found, will start up a separate OpenVPN daemon for each file.
No info on how to go about constructing a client conf file, but I did manage to find a sample file in a different location to that stated by the openvpn docs, the conf requires information I don’t have so I’m waiting to hear back from my provider on that
With regards to the ethernet connection needing to be up and running first I’ve already planned on calling openvpn from the /etc/init.d/after.local file which should take care of that issue
OK,
Here are some places to start…
One of the first things I generally do is look for openSUSE documentation already installed on my machine as part of the package, I found this
# cat /usr/share/doc/packages/openvpn/README.SUSE
Notes about the OpenVPN package
In a fresh installation, you will find an empty directory /etc/openvpn.
The directory is meant to contain *.conf files -- the openvpn init script
will automatically look for them there, so you can start/stop all tunnels with
"rcopenvpn (start|stop)", as well as start tham at boot time.
That is consistent with the official community “how to” documentation at openvpn which is referenced in the MAN pages
OpenVPN HOWTO - System Startup
So, although I haven’t tested because I prefer to manually start my VPNs, it seems that if you place your connection profile(s) in that location, you should be good to go.
I would advise against placing in an init.d subdirectory because I understand that method will be deprecated over time (although should work today).
HTH,
TSU
I use NM for activating and de-activating my PPTP VPN, so can only point you at reference material for controlling your openVPN connectivity. I assume you’ll want to be able to manually control the connection…
https://wiki.archlinux.org/index.php/OpenVPN#Manual_startup
http://fedoraproject.org/wiki/Openvpn#Working_with_systemd
There is also some useful info concerning systemd configuration.
That’s interesting. If the info in that link is true then both openSUSE and the OpenVPN wiki may incorrect and need to be updated.
But should be a simple matter to test simply placing a config file in /etc/openvpn and if the VPN isn’t automatically activated with the next boot to make the entry in sysctl.
TSU
I made it work by placing a client.conf file in /etc/openvpn and calling /etc/init.d/openvpn from boot.local, starting/stopping the connection’s a simple matter of running the same openvpn init script
Here’s the contents of my client.conf file in case anyone’s interested, the main pieces of info the sample file didn’t provide is [obviously] the server host, and it gave no indication of how to pass my username/password:
client
dev tun
proto udp
remote [server's host goes here] 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
ns-cert-type server
comp-lzo
verb 3
auth-user-pass login.info
auth-nocache
The auth-user-pass directive tells it to look in the file you specify which needs the username on the first line and password on the second, I called my file login.info, don’t know if it’s possible to use encryption, more reading required
auth-nocache I picked up on from a look at /var/log/messages after starting the openvpn client where I found an entry stating the ‘current configuration could result in the password being cached in ram’ and the auth-nocache directive was suggested as a method of avoiding this
I didn’t need any username.key & crt files as give in the fedora project btw, the ca.crt file from my account provider was sufficient
Thanks for the update Ecky. I’m glad you got it working as you like. This will be a useful thread for others who come searching. 
Hopefully so mate, most of the info out there seemed aimed at people connecting their clients to their own server whereas I was looking to connect to an openvpn provider
Murphy’s law struck though, the machine I was trying on this on is quite old and the memory just went bad in it … oh well it’ll be a good consistency test putting the same setup on another machine