Yet another VPN issue (for me at least)

NethServer 7.9.2009
OpenVPN 1.7.2

HI all,

Client with the above system. One NIC only. OpenVPN roadwarrior username and passwd only.

Downloaded profile to windows PC, trying to connect, but fails authentication.
I added a system user, but no joy.

Tried with certificate, username and password, but the self signed certificate needs a password which is unknown…
I am at a loss.
Tried to follow the setup guide (which is a tad old), but no joy there either.
Any help appreciated
Thanks and kind regards

Is this arrangement

working for other username/password and/or other computer running openvpn client?

HI Michael,

nope, this is a new server, all updates done…Tried other computers, no go…

IMVHO this arrangement of NICs (one only) should not work.
At least two NICs should be present (even a dummy one) for make OpenVPN happen.

But i don’t know how this could be duck-taped for allowing Nethserver to be a pure VPN Endpoint.

I can install another nic, and try… I have to go to the client this week anyway… Will report back…
Thanks again

Scrub the forum. If i’m not wrong, someone already achieved something similar with the dummy NIC (necessary into hosting scenarios).

OK… dummy NIC with a whatever IP/mask/GW without connecting any cables?



If using a real local server or local VM, this is valid:

With NethServer (Not running as your firewall, only one NIC) you can easily create a OpenVPN (Routed, not bridged, as is suggested nowadays!)…

You must have a port-forwarding rule created on whatever box you’re using as your default gateway (Provider box, Internet box, other router…). This must be for whatever Port you’re using for OpenVPN (usually 1194) and forwarding to the LAN IP of your NethServer.

Additionally, you must create a route on that box for the OpenVPN used Network, eg (or, whatever you’re using) and point this again to the NethServers LAN IP (as the Gateway for this rule…)

In plain english, a route can be considered as follows:

“Pass any traffic to the via this special gateway (IP of your NethServer)”…

I have this working for several clients, here is one.


If you have a “hosted” server, you do need the “dummy” NIC.

I also have this working in a couple of cases…

You should have valid LetsEncrypt certs on this server…
This is independant from the cert OpenVPN provides for security/encryption.

My 2 cents


The setup is as follows:

internet → modem/router → Nethserver

So, basically say; → →

On the router, UDP port 1194 is forwarded to the nethserver. On other systems that’s all that is needed.

If I introduce a second NIC, I’d have to change the LAN IP address of the router to be say: and the 2nd NIC to have

Then forward port 1194 to

Configure OpenVPN to listen to the interface…

Yet all documents don’t mention anything like that, just create a roadwarrior, username and password and Download the config file onto the client, and off you go…

Not complaining, just saying that the documentation should be revised and updated. I’d gladly help.



A second NIC is absolutely NOT needed in your Setup!

As said above, in your setup you’re missing the route on your modem/router pointing to your OpenVPN network.

You should be using NethServers Account Provider to create a user, not just do an adduser for a simple linux user. If NethServer doesn’t “know” about the user, the correct attributes will not be generated.

I’d also suggest reviewing the security options under advanced - the standard seems rather low.
I’d suggest as follows:

I’ld also suggest using a certificate - just for additional security. On other systems like OPNsense, I also use the certificcate and a “revoked” list to be able to revoke dead, missing or stolen devices, without changing or removing the user / vpn.

The certificate is included in the file for import in any client. I use Viscosity on Windows and Mac for my clients, and OpenVPN for Linux.

My 2 cents

See also here:

OK Andy,
thanks for the reply…

I will that a go,

Thanks again

Good Luck!

I can also confirm that the OpenVPN is rock solid, a client recently made international tests 4 weeks ago! Fast, solid access to the Server / Network - from anywhere including Germany, Austria, Guatamala…

Give feedback, and don’t hesitate to ask questions, if any turn up.
After all, our motto here is: The only dumb questions are the ones not asked… :slight_smile:

My 2 cents

HI Andy and all,

OK, managed to get it sorted. Only forward port 1196 as per your pic from the router to the Nethserver box.

Added a system user, downloaded the config file and imported into the OpenVPN client, connected.

What we are missing is that the username needs to be “” and not only “user”.

That connected straight away with no trouble at all…

I will go onto the certificates when I have some time, but at least now the clients can log into their system remotely…

Thanks again and best regards to all

1 Like


Depending on your click-rate, we’re talking about max 3 minutes here!!!

Should be no issue to implement that and spend 3 well worth minutes doing this. No real effort needed at all, neither on client or server side - just click it through…!

Why wait?

My 2 cents

Busy transferring domains to a new registrar at the moment… Don’t I need access to the domain for the API key used by let’s encrypt?

No, as the OpenVPN uses it’s own self created SSL cert, and because the client imports this cert, it’s accepted (Not like browsers).
Here the main purpose is additional security, encryption, authentification - and the option for revocation of any individual VPN connection.

For Lets Encrypt generally for your NethServer, it is enough if the NethServer is reachable by it’s FQDN (Has to be entered in external DNS hoster).

You can use aliases, for other purposes, like I’m using at home.

See for yourself for some ideas…

Try the PI-Hole. It’s a seperate VM (actually LXC on Proxmox) with a internal fqdn of: The PI-Hole does NO SSL - all is handled by NethServer and a reverse Proxy… :slight_smile:

PS: also try using the IP (It’s dynamic…), but a nslookup will help…

My 2 cents

Cool Thanks…

Let’s encrytp needs (For HTTP verification):

  • An external DNS entry
  • Accessible from the Internet on Port 80 (443 is not tested…) Port forwarding on your firewall…

If planing on using Webmail, Nextcloud, or other web based services, you’ll need also port 443.

Don’t forget to set the newly aquired LE cert as standard!