Basically I need to connect my server to a vpn provider, openvpn compatible. Ive tried setting up a client with the server address, port, my username and password and client cert. That did not work so I added the private key to the cert since it was part of the openvpn config file. I cannot import a opvn config file directly. I tried editing the etc/openvpv/VPN.conf file and the auth file and added a cert file and a new key file but it still doesnt want to connect. What am I doing wrong? Thanks! Ill keep messing with it, maybe im in the wrong place.
Ok I tried adding a ovpn file to /etc/openvpn as well as a conf file and I can manually start through ssh openvpn -config /etc/openvpn/VPN.conf/ovpn but I lose internet and a server reboot is the only thing that fixes it.
The latest update to OpenVPN keeps the server and client configs in different directories in /etc/openvpn, although NS hasn’t migrated to this scheme (yet) for the RoadWarrior service.
All I did, was to put the client VPN configuration file in /etc/openvpn/clients directory and then start the service with:
systemctl start openvpn-client@<Name of openvpn config file, without .conf extension>
You can check the status with the “systemctl status” command, using the same parameter.
Perhaps post your conf file and/or the log from the start-up for someone to check.
This is my standard config file, used for my pc and phone, I will try generating a config with the GUI client page and editing that possibly…when I try to load this I get a failed to start error, failed to open vpn.conf when I input systemctl start openvpn-client@vpn
And the vpn.conf is in the /etc/openvpn/client directory. (Sorry, I said clients above).
The one issue I see with the config (assuming that the board software stripped the tags on KEY and CERT, based on the blank lines) is the format for remote is: host SPACE port.
Oops yea I had it that way haha just an old habit when writing ip:port. And I have been working in the client folder, ill keep at it, maybe my vpn provider just isnt playing nice.
WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
openvpn[27416]: Error: private key password verification failed
openvpn[27416]: Exiting due to fatal error
systemd[1]: openvpn-client@vpn.service: main process exited, code=exited, status=1/FAILURE
systemd[1]: Unit openvpn-client@vpn.service entered failed state.
systemd[1]: openvpn-client@vpn.service failed.
Issue is I do have a key file as well as an auth file and cert…I literally created the file in the GUI just to make sure it was proper code and it didnt work so I edited it so that it uses the key file and it still doesnt work. Anyone actually connected to a client vpn or is it broken? I am used to openvpn, used it a bunch but I dont know why this isnt working.
Yes the dev tunvpn is correct thats how the nethserver wants it…This is exactly how nethserver creates the file except I added cipher and a key file, as well as a couple other variables, wasnt working before and that didnt break or fix it still getting that error.
Edit: I do try and create a tunnel from the nethserver gui but it fails of course and when I manually start it thats the same error I get. I wonder if its just broken or there is a syntax error Im not seeing.
Yes, I can connect to ExpressVPN from my NS server without any problem.
The client is completely outside of NS, unless you are trying to VPN between 2 NS instances. I just created the relevant conf file and start it with systemctl. If it helps, here is my conf:
dev tun
fast-io
persist-key
persist-tun
nobind
remote <some server at>.expressnetw.com 1195
remote-random
pull
comp-lzo
tls-client
verify-x509-name Server name-prefix
ns-cert-type server
key-direction 1
route-method exe
route-delay 2
tun-mtu 1500
fragment 1300
mssfix 1450
verb 3
cipher AES-256-CBC
keysize 256
auth SHA512
sndbuf 524288
rcvbuf 524288
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
log-append /var/log/openvpn/UK-VPN.log
status /var/log/openvpn/status-UK-VPN.log
# Don't let them mess up my routing.
route-nopull
# Let's try some scripts
script-security 2
#up-restart
up /etc/openvpn/tunup.sh
down /etc/openvpn/tundown.sh
# See if our queue is too short
txqueuelen 250
<cert>
-----BEGIN CERTIFICATE-----
--snip--
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
--snip--
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
--snip--
-----END OpenVPN Static key V1-----
</tls-auth>
<ca>
-----BEGIN CERTIFICATE-----
--snip--
-----END CERTIFICATE-----
</ca>
Ill bet its torguard then…So i tinkered with the script a bit annnnd i can connect but no internet outside of the gateway…ill update when I try your script and ill post my updated faulty one. Much appreciated its been bugging me
Normally the server will send down a route to force all the traffic out via the VPN. That’s why I added this to my configuration, because I wanted to control what goes out via the VPN or the WAN:
# Don't let them mess up my routing.
route-nopull
You also need to “nat” the new interface, so that internal machines can connect through correctly.
That’s what I do in the “up” and “down” scripts:
Normally, most VPNs push down a route command to force all the outgoing traffic out via the VPN. I don’t know if that really works or not with the NS/Shorewall setup as I use the “route-nopull” to stop this behaviour.
In order to do split routing, when certain traffic is routed via the VPN and the rest via the “normal” WAN, the scripts I use create override files in /etc/e-smith/templates-custom/etc/shorewall directory to add to the Shorewall configuration created by NS. I don’t set any of these rules in NS because the client VPN is outside of NS.
still getting that error.