Bug #13116


OpenVPN client ``tls-client``/``client`` configuration directive not handled properly

Added by Jim Pingle about 2 months ago. Updated 29 days ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


There are a few problems with how we currently build a client configuration using the tls-client and client directives.

  • In current versions of OpenVPN client expands to tls-client and pull so it is redundant to have tls-client and client, but both end up in generated TLS client configurations
  • pull should not be used with peer-to-peer modes (SSL/TLS with /30 or smaller subnet for a single client, or shared key mode), but currently we put in client on both of those cases which is invalid. (Though due to a bug in the shared key test, it ends up correctly omitted)
  • OpenVPN complains if the configuration contains ifconfig and pull together, so pull should probably be omitted if there is any tunnel network defined. There may be other cases where it's valid (tap mode maybe?)

Static client addresses in client/server mode should be set in CSO entries on the server and not in client tunnel networks. If the user wants this behavior they could always add pull to custom options on their own. We could add a GUI option to force pull but that may be confusing since it should almost never be used.

Actions #1

Updated by Jim Pingle about 2 months ago

  • Description updated (diff)
Actions #2

Updated by Jim Pingle about 2 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Marcos Mendoza about 2 months ago

Does this need to take into account the `route-no-pull` option?

Actions #4

Updated by Jim Pingle about 2 months ago

The route-nopull option is harmless in this case. If it is present without pull it does nothing, doesn't even log an error.

Might be worth a note somewhere but if they check that they are telling it not to pull routes which it couldn't do anyhow, so it's still doing what they want just not how they expected it to happen.

Actions #5

Updated by Jim Pingle 29 days ago

  • Status changed from Feedback to Resolved

This appears to be correct and consistent now.


Also available in: Atom PDF