[Resolved] Dynamic OpenVPN Server Configuration

tmartins

Hello!

I'm looking for a more dynamic OpenVPN "site to multi-site" solution, currently, it works but, it's very static and requires server restart often (which is really bad).

The whole solution is based on Ubuntu 18.04 and default OpenVPN packages from it.

Let me try to explain it... The network prototype that I'm building today, have 1 OpenVPN Access Server, plus 1~50 remote offices/labs.

Main OpenVPN Server Site 1: 10.101.0.0/16
Site 2: 10.102.0.0/16
Site 3: 10.103.0.0/16
...
Site 50: 10.150.0.0/16

I can deploy the OpenVPN Server site and, let's say, 2 remote sites. They all talk to each other!

According to the OpenVPN docs, at the server side, the remote site subnet must be declared twice, as follows:

Site 1 (server):

---
# cat /etc/openvpn/ccd/site2
iroute 10.102.0.0 255.255.0.0
-
# grep 102 /etc/openvpn/server.conf
route 10.102.0.0 255.255.0.0
---

So, the problem that I'm facing is that to add a new site (that doesn't exist yet), I need to change the "/etc/openvpn/server.conf" and then, restart the server!! It kills everybody.

I want to be able to add/remove remote sites without restarting the main server, is it possible?

Worth to mention that, on Ubuntu, the command `systemctl reload openvpn@server.service` fails, error:

Jul 29 19:56:55 ovpn-s2s-1 kill[25844]: kill: (25826): Operation not permitted

Maybe this is the source of my problem?

Thanks!
Thiago

tmartins

Running OpenVPN as root fixes the "systemctl reload openvpn" issue!

About to test the reload while monitoring the other sites... =P

tmartins

Well, reload now works but it kills the connection anyway... Or I don't know how to do it, or OpenVPN doesn't support a reload without killing the client's connections?

Pippin

# grep 102 /etc/openvpn/server.conf
route 10.102.0.0 255.255.0.0
---

You can do

route 10.0.0.0 255.0.0.0

TinCanTech

Pippin wrote

# grep 102 /etc/openvpn/server.conf
route 10.102.0.0 255.255.0.0
---

You can do

route 10.0.0.0 255.0.0.0

but probably should not do this ..

tmartins wrote OpenVPN doesn't support a reload without killing the client's connections?

That is correct because systemd kills then starts the process.

Pippin

but probably should not do this ..

Yes, probably not and not without firewalling.
If the client subnets would start at 10.128.0.0 instead of 10.100.0.0 he could half that 10.0.0.0/8 to be 10.128.0.0/9.

Unless there is another solution...

tmartins

Pippin wrote

# grep 102 /etc/openvpn/server.conf
route 10.102.0.0 255.255.0.0
---

You can do

route 10.0.0.0 255.0.0.0

Oh, nice!!! Thank you!

tmartins

TinCanTech wrote
Pippin wrote ....
tmartins wrote OpenVPN doesn't support a reload without killing the client's connections?
That is correct because systemd kills then starts the process.
So, is this a systemd limitation or bad configuration (unit files?) for OpenVPN, or an OpenVPN limitation?

If OpenVPN supports reloading its config files without killing all the connections, how to do it? `kill -1 openvpn` ?

tmartins

Pippin wrote
but probably should not do this ..
Yes, probably not and not without firewalling.
If the client subnets would start at 10.128.0.0 instead of 10.100.0.0 he could half that 10.0.0.0/8 to be 10.128.0.0/9.

Unless there is another solution...

Sure! This is just a lab anyway, I'm planning to take slices of 10/8 later on.

TinCanTech

tmartins wrote If OpenVPN supports reloading its config files without killing all the connections, how to do it?

Openvpn does not support reloading the config file without restarting the process and thereby disconnecting all users.

tmartins

TinCanTech wrote
tmartins wrote If OpenVPN supports reloading its config files without killing all the connections, how to do it?
Openvpn does not support reloading the config file without restarting the process and thereby disconnecting all users.

Ok, thanks!

What about the ccd subdir files? Do I need to restart openvpn to reload the files under, let's say, /etc/openvpn/ccd/* ?

Pippin

Nope, those will be read every time a client connects.

tmartins

Perfect, thank you!

😃

TinCanTech

This appears to be "Solved" ? :geek:

tmartins

Yes, definitely "solved". lol

^_^

TinCanTech

You are ok that this was moved to "Doh!" .. Like a badge of honour :ugeek:

tmartins

Of course, no problem at all... It was really a Doh! problem anyway... lol