On 12/04/14 19:55, Christoph Biedl wrote: [...snip...] Just filling out a few things extra, otherwise Gert's answer is fully valid.
> * 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. On the server side, --client-connect and --learn-address are the ones which can be used. IIRC, --client-connect can also be allowed to generate CCD entries in the script which is returned to the OpenVPN process. > * 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. Not sure what you mean with bizarre. Those settings not configured in DEFAULT is based upon whatever is found in the main config. And if not defined there, it's the default values in the OpenVPN binary. So if you dislike this values, modify them. > I have little understanding why the CCD files are *that* restricted. OpenVPN is a single-threaded process, which has it's own even event handler to tackle each client. That gives quite some restrictions. Further, OpenVPN is based on the wireprotocol found in OpenVPN 1.x and 2.x. And surprisngly often, mixed OpenVPN 2.x versions can work quite well. For OpenVPN 2.1 and newer, they all work fine. For 2.0 against 2.1 and newer, there are some restrictions, based on what features 2.0 does support. The next part is that OpenVPN doesn't negotiate any communication/wire protocol between client and servers. So what is declared in the main server config is what the client needs to obey to. OpenVPN also can't do any pre-authentication to adjust communication parameters based on which client it talks with. The OpenVPN server only knows which client it is when the wire-protocol is initiated between server and client, that's when the TLS protocol takes over and X.509 authentication can start. > 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? No, it cannot with the current implementation. This will require a massive re-work of most of the event process. In addition having a single process for each client won't that scale well. And, related to what I've already said, the OpenVPN server doesn't know who the client is until the basic connection is already initialised and the TLS protocol can be used. At that point, it's too late to modify the connection parameters. > So the big question is: I fail to believe I am the first person with > such requirements. What else? You might not be the first one. But you are definitely in a minority. It's several years since I heard anyone asking for features similar to yours. > 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. The server uses a single tun/tap device for all clients. Creating a new tun/tap device for each client would not scale well at all. > 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 Try using --server. It's a macro which can simplify the important parameters. It also needs a separate IP range for the VPN subnet (network between server and clients) which you use to route the traffic between LANs behind server and clients. For IPv6, there's a related --server-ipv6 option. When using --dev tun, OpenVPN will prepare tun0 if no other tun devices exists. If it does, it tries tun1, tun2, and so on. If you use --dev tun0, it will always try to only tun0 and fail to start if tun0 is already taken. The man page also document all these options fairly well. > --- Server, CCD file for "test-user" > > ifconfig-push 10.10.9.193 10.10.9.200/32 That looks fine. > --- 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 Likewise like on the server, I'd recommend to you use --client in the client config. It's a simple macro which results in --tls-client and --pull (currently). You're missing --pull, which is probably one of the reasons your client won't get any IP address too. Otherwise, I want to recommend you the OpenVPN 2 Cookbook by Jan Just Keijser (you'll see him responding from time to time on this ML). It provides many good starting points for configuration setups for many different scenarios, and also providing helpful info to understand the configuration options used even better. <http://www.packtpub.com/openvpn-2-cookbook/book> -- kind regards, David Sommerseth ------------------------------------------------------------------------------ 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
