Missing config setting with tls-auth option - feature request

DaywalkerGLXVR6

Hi

I have discovered a tiny problem with out openvpn setup.
We are omitting the optional 0/1 value at the end of the tls-auth parameter, but the openvpn (client) config gets created with the value "1" at the end. (as shown in the openvpn documentation: https://community.openvpn.net/openvpn/wiki/Hardening#Useof–tls-auth)

And it is impossible for us (in any short timespan) to touch all clients an change this parameter.

It would be nice to have a small check box like "omit client option for tls-auth" or something like that.

The problem you will get is just a bit shot of an explanation.

local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Local Options hash (VER=V4): '56f60c8f'
Expected Remote Options hash (VER=V4): 'e1494645'

And then the connection gets closed. Basically after a successful connection and authentication…

My workaround is to go into the /var/etc/openvpn directory, change the parameter by hand, an restart the service.
This is ok as a workaround, as I think, because the file just gets written after I change some config settings, witch should not happen very often :)

best regards
Daywalker

jimp

Why are you omitting that value when the documentation recommends it be set for increased security?

The optional direction parameter enables the use of 4 distinct
keys (HMAC-send, cipher-encrypt, HMAC-receive, cipher-decrypt),
so that each data flow direction has a different set of HMAC and
cipher keys. This has a number of desirable security properties
including eliminating certain kinds of DoS and message replay
attacks.

When the direction parameter is omitted, 2 keys are used bidi-
rectionally, one for HMAC and the other for encryption/decryp-
tion.

You're just hobbling the feature by omitting the direction. Seems it would be much simpler to add the direction on the server side like it wants.