[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

Code: Select all

route 10.0.0.0 255.0.0.0

[TinCanTech]

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

You can do

Code: Select all

route 10.0.0.0 255.0.0.0

but probably should not do this ..

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]

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

You can do

Code: Select all

route 10.0.0.0 255.0.0.0

Oh, nice!!! Thank you!

[tmartins]

....

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]

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]

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]

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

[tmartins]

Yes, definitely "solved". lol

^_^

[TinCanTech]

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

[tmartins]

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