openvpn: client access policies

Question

I'm trying to setup client access policies, akin to what is described in openvpn documentation. The configuration will use tun device

in the above example, it seems the only thing restricting employees and contractors is an ifconfig command being pushed from the server. What happens if the client just comments the pull directive, the client will simply not connect?

I've read this FAQ, and makes me a bit nervous that a unauthorized client could access off-limits networks by fiddling locally with ifconfig. Is it secure to rely on this sort of client configuration?

if the answer is that is not that secure, what would be the best way to secure network access policies for different clients?

thanks!

Answer 1

I've seen OpenVPN check the validity of IP addresses of the connected clients (ingress filtering) on other occasions, so I would reckon this has been done for client access policies as well, although I never checked.

In the olden days, when there was no client policy feature, we used to implement similar requirements by simply setting up more than one openvpn configuration - one for each security zone (in the example case there would be three configs - one for administrators, one for employees and one for contractors) - and setting up packet filters.

what sort of conflicts can i expect from running multiple instances of openvpn in the same server? i mean, besides files conflicts, that are easily solved by setting different current dir and chroot folders. Should i worry about ports?

Nothing much would conflict there. You obviously would create different ports, you may create different CAs and different server certificates, although this is not mandatory as you can restrict the connection authorization by the client's TLS name using --tls-remote or --tls-verify options.

Ports are not an issue, you are not bound to the default 1194/udp but can select an arbitrary unused port on your host using the --port option.

There is no need of setting a different current dir and chrooting, although you might choose to do so for security reasons