So i have interesting news. I reread the manuals
man openvpn
and
zless /usr/share/doc/openvpn/management-notes.txt.gz
more carefully and experimented a bit.
I was suprised to find out that sometimes the client-pf rules defined in the management interface seem to be successfull created:
SUCCESS: client-pf command succeeded
and sometimes they don't:
ERROR: client-pf command failed
I could not really determine a case for that until i found the following:
The CID which is stated in the documentation
client-pf {CID}
line_1
line_2
...
line_n
END
is *
NOT* the common-name (CN) of the client!
It is a sequential number assigned to a client based on the connection order. So the first client which connects to the OpenVPN-Server gets the CID 1, the second gets 2, the third gets 3 and so on. They wrap over at (2^32)-1 according to the manual.
CID -- Client ID, numerical ID for each connecting client, sequence = 0,1,2,...
In the unlikely scenario of an extremely long-running OpenVPN server,
CID and KID should be assumed to recycle to 0 after (2^32)-1, however this
recycling behavior is guaranteed to be collision-free.
Turning on the logging (verb 6) and keeping an eye on the management interface helps
a lot! I was now able to see a client connection in the management interface console, and therefor able to catch the right CID of the client. You can see the various environment variables and so i know which client is connecting looking at the CN in the certificate.
>CLIENT:CONNECT,5,0
>CLIENT:ENV,n_clients=0
>CLIENT:ENV,IV_VER=2.3.2
>CLIENT:ENV,IV_PLAT=linux
>CLIENT:ENV,untrusted_port=63062
>CLIENT:ENV,untrusted_ip=w.x.y.z
>CLIENT:ENV,common_name=client_two
>CLIENT:ENV,password=
>CLIENT:ENV,username=
>CLIENT:ENV,tls_serial_0=14211
>CLIENT:ENV,tls_digest_0=17:a6:1d:15:a4:00:93:50:c7:80:93:78:80:5c:45:12:f0:04:9d:75
>CLIENT:ENV,tls_id_0=C=DE, ST=foo, O=bar, OU=batz, CN=client_two
>CLIENT:ENV,X509_0_CN=client_two
>CLIENT:ENV,X509_0_OU=batz
>CLIENT:ENV,X509_0_O=bar
>CLIENT:ENV,X509_0_ST=foo
>CLIENT:ENV,X509_0_C=DE
>CLIENT:ENV,tls_serial_1=11315633920557459494
>CLIENT:ENV,tls_digest_1=e8:4a:2f:73:60:d5:72:66:37:f9:e2:49:ec:d8:ec:60:b7:c6:27:5e
>CLIENT:ENV,tls_id_1=CN=Root, emailAddress=info@foo.de, C=DE, ST=foo, O=bar, OU=baz
>CLIENT:ENV,X509_1_OU=baz
>CLIENT:ENV,X509_1_O=bar
>CLIENT:ENV,X509_1_ST=foo
>CLIENT:ENV,X509_1_C=DE
>CLIENT:ENV,X509_1_emailAddress=
>CLIENT:ENV,X509_1_CN=Root
>CLIENT:ENV,remote_port_1=444
>CLIENT:ENV,local_port_1=444
>CLIENT:ENV,local_1=192.6.1.21
>CLIENT:ENV,proto_1=udp
>CLIENT:ENV,daemon_pid=16687
>CLIENT:ENV,daemon_start_time=1420443210
>CLIENT:ENV,daemon_log_redirect=1
>CLIENT:ENV,daemon=1
>CLIENT:ENV,verb=6
>CLIENT:ENV,config=/etc/openvpn/server.conf
>CLIENT:ENV,ifconfig_local=10.2.2.1
>CLIENT:ENV,ifconfig_netmask=255.255.255.0
>CLIENT:ENV,ifconfig_broadcast=10.2.2.255
>CLIENT:ENV,script_context=init
>CLIENT:ENV,tun_mtu=1500
>CLIENT:ENV,link_mtu=1590
>CLIENT:ENV,dev=tap0
>CLIENT:ENV,dev_type=tap
>CLIENT:ENV,script_type=up
>CLIENT:ENV,redirect_gateway=0
>CLIENT:ENV,END
Now i am able to create the right client-pf rules in the management interface. Lets assume i know that "client_one" would connect next and "client_two" afterwards. So the CID of "client_one" will be 6 and the CID of "client_two" will be 7.
A rule to allow "client_one" to speak to "client_two" and everybody else (hence the CLIENTS ACCEPT) would look like this:
client-pf 6
[CLIENTS ACCEPT]
+client_two
[SUBNETS ACCEPT]
[END]
END
SUCCESS: client-pf command succeeded
Problem is, the management interface only accepts these rules if a client with the right CID already connected or is connecting at the moment. So i have to be very quick to setup the rules. They do not seem to work though and still no client is able to connect...
The client is still complaining about it, maybe i am just to late with my client-pf rules? But how am i supposed to know which client connects next and how to setup the rules "just in time"?
I am a little confused that the common-names are not used for defining the pf-rules. :?
Mon Jan 5 12:56:06 2015 [OpenVPN-Server] Peer Connection Initiated with [AF_INET]88.79.183.84:444
Mon Jan 5 12:56:08 2015 SENT CONTROL [OpenVPN-Server]: 'PUSH_REQUEST' (status=1)
Mon Jan 5 12:56:13 2015 SENT CONTROL [OpenVPN-Server]: 'PUSH_REQUEST' (status=1)
Mon Jan 5 12:56:18 2015 SENT CONTROL [OpenVPN-Server]: 'PUSH_REQUEST' (status=1)
Mon Jan 5 12:56:23 2015 SENT CONTROL [OpenVPN-Server]: 'PUSH_REQUEST' (status=1)
