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.