Greetings,
for many years, I've been running a multi-client openvpn setup. This
was implemented using multiple openvpn instances, one per client. To
give you an idea of *how* many years: This is a remainder of a
CIPE-based VPN setup that, when Peter Gutmann smashed it, was later
migrated to OpenVPN
The heardbleed desaster finally gave the reason for a major overhaul,
including switching to --client-config-dir (aka "CCD"). Major goal was
to simplify the packet filter setup since there would be just a single
listening port then.
However, the outcome so far was extremely frustrating. Search engines
were not helpful at all, they are filled up with the trivial basics.
>From my experience in such situations, there's an very small piece of
information I am missing, it's obvious to everybody else, so nobody
bothered to write it down. Now, before eventually returning to the
previous setup in anger, I at least wanted to ask whether it could be
what I am seeing here.
The essentials for my setup:
* For each client, the tunnel interface must have a fixed name
This is required for accounting and/or client-specific packet filter
rules.
Status: "dev tun123" or similar is not allowed in a CCD file.
There's not even a trace whether tun device creation is controlable.
Well, for the they don't get created at all, see below.
* For each client, I need an individual startup file
Status: "up" and friends are not allowed in a CCD file.
There might be a workaround using a global setting and using a
switch driven by environment variables, I haven't checked yet since
I failed to get *any* CCD setup running, see below.
* For some clients, I need individual settings for some of the
gazillion of {link,tun,whatever}-mtu, and preferibly for "comp-lzo",
too
Status: You guess it
"comp-lzo" does not trigger a "cannot be used in this context" warning,
whatever that means.
* For an unknown client, the server must reject the connection
Status: DEFAULT is tried, and even if missing/unreadable/invalid, some
bizarre configuration values are used instead.
I have little understanding why the CCD files are *that* restricted.
I'd prefer a setup where the master process does x509-based
authentication, then forks a child with a full (modulo TLS
credentials) configuration, passing the existing connection. That
would solve all my problems, can this be done in openvpn?
So the big question is: I fail to believe I am the first person with
such requirements. What else?
At the moment, I even fail to get the trivial setup running,
stripped-down config files below. The client 'test-user' connects,
is authenticated, both sides report successful initialization. BUT:
The server neither creates a tun interface (or is tun0 supposed to
be re-used?) nor assigns the configured addresses. The client does
create the tun interface but leaves it unconfigured, so either the
push command doesn't get through or it is not executed.
Both sides are Debian Linux, openvpn version 2.2.1 as provided in the
Wheezy release.
Christoph</rant>
--- Server, main configuration
mode server
tls-server
key-method 2
local <redacted>
port 1194
proto udp
tls-auth /etc/openvpn/tls-auth
client-config-dir /etc/openvpn/client.d/
link-mtu 1464
dev tun # also tried tun0
keepalive 60 190
ping-timer-rem
tun-ipv6
comp-lzo
dh /etc/openvpn/dh1024.pem # also tried 2048, 4096
ca /etc/openvpn/iptunnelCA.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
writepid /var/run/openvpn.master.pid
--- Server, CCD file for "test-user"
ifconfig-push 10.10.9.193 10.10.9.200/32
--- Client "test-user"
tls-client
key-method 2
remote <redacted>
port 1194
proto udp
link-mtu 1464
ping 60
ping-restart 122
tls-auth /etc/openvpn/tls-auth
dev tun200
tun-ipv6
comp-lzo
passtos
ca /etc/openvpn/iptunnelCA.crt
cert /etc/openvpn/test-user.crt
key /etc/openvpn/test-user.key
verb 3
writepid /var/run/openvpn.pid
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
