Missing config setting with tls-auth option - feature request
DaywalkerGLXVR6 last edited by
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 :)
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
When the direction parameter is omitted, 2 keys are used bidi-
rectionally, one for HMAC and the other for encryption/decryp-
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.