OpenVPN Support Forum

My wish is that all client options for the client configuration can be pushed in thru the server configuration so that it is easier to implement client options from the server configuration.

I also wish that there is a clear sequence order of how the server and client options be placed in the configuration option.

I also wish that there would be a comprehension example other than that presented on the man page. Like the setenv option, it is not very clear how to use it in the client configuration.

it will never be possible to specify ALL client options on the server side, but the list can surely be made longer. If you can specify exactly which options you'd like to see "pushable" then please list them here.

As for the order of the options: to a large scale it does not matter, but there are a few caveats: some options can be specified multiple times (e.g. 'remote') , in which case openvpn tries them in order. Other options can be specified only once, in which case the LAST instance "wins".

more elaborate examples, as well as more details on these options, can be found in my book

Janjust,

It came to my mind that since a client configuration has already been supplied to a client and later on new options can be made available to these clients if a newer version of openvpn is released, like from version 2.0 to 2.2.

Enabling the server to push some these new client options can be immediate than providing them new client configuration or telling them to add new line for client option.

Or Enabling the server to push client options when the need to adjust the options for the clients.

The existing client options that can be pushed now in 2.2 are:

--route, --route-gateway, --route-delay, --redirect-gateway, --ip-win32, --dhcp-option, --inactive, --ping, --ping-exit, --ping-restart, --setenv, --persist-key, --persist-tun, --echo, --comp-lzo, --socket-flags, --sndbuf, --rcvbuf

I would like to request as my WISH the following:

--connect-retry n
--connect-retry-max n
--bind
--nobind
--tun-ipv6
--allow-pull-fqdn
--tun-mtu n
--persist-local-ip
--persist-remote-ip
--auth alg
--cipher alg
--keysize n
--prng alg [nsl]
--tls-auth file [direction]
--auth-nocache
--ns-cert-type client|server
-win-sys path|'env'
--ip-win32 method
--route-method m
--register-dns
--allow-nonadmin [TAP-adapter]

if not all can be requested to be pushed in my WISH.

I'm sorry, but most of these options in your wishlist makes no sense of pushing - due to that they change the established communication channel between client and server.

However, I believe --register-dns is pushable already.

The options which probably are possible to change after the connection is established are:

--connect-retry n
--connect-retry-max n
--allow-pull-fqdn (will most likely only have effect on pushed routes)
--tun-mtu n (uncertain if really doable, but shouldn't be impossible - unless it requires re-creating the TUN device)
--auth-nocache (probably tricky to implement, due to username/password might already be in memory)

The rest are most likely not possible to push. Reasons follows:

--bind
--nobind
--persist-local-ip
--persist-remote-ip
The UDP/TCP connection is already established, and you would need to tear-down the connection and re-establish it with these options. Which, IMO, would really be more like a hack than a real life solution.

--auth alg
--cipher alg
--keysize n
--ns-cert-type client|server
This is related to the SSL layer. The PUSH_REQUEST and the response is sent over an encrypted channel. Which means that to re-negotiate the cipher algorithms, the SSL connection must be re-establish. And for --ns-cert-type, it makes no sense to change this after the SSL connection is already established. Checking cert-type is done as part of the certificate validation process, IIRC, before the SSL connection is fully established.

--prng alg [nsl]
This is related to the SSL stuff above, plus that it might be that a certain prng engine is not available on the client which you want to use.

--tls-auth file [direction]
This options adds an extra layer of authentication, on top of the SSL packets. How will you be able to establish a connection to the server to start with if you can't pass this authentication? Further, how will you tackle the static key which this option require?

--tun-ipv6
--allow-nonadmin [TAP-adapter]
I believe the TUN device is already created when the PUSH _REQUEST message is sent to the server. This will most likely require to recreate the TUN device. However, the --tun-ipv6 option might become obsolete in a later version. It depends on if this option is needed at all in OpenVPN 2.3 which will contain full IPv6 support.

-win-sys path|'env'
--ip-win32 method
--route-method m
I understand the wish for these ones, but they will come too late to make any sense. And route options might already have been parsed. This probably needs to be activated in OpenVPN before the TUN/TAP device is created and the initial IP addresses and routes are set up.

Thank you very much for the replies. Somehow I am enlightened.

And what about '--explicit-exit-notify' option? Can it be "pushable"?