OpenVPN client ``tls-client``/``client`` configuration directive not handled properly
There are a few problems with how we currently build a client configuration using the
- In current versions of OpenVPN
pullso it is redundant to have
client, but both end up in generated TLS client configurations
pullshould 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
clienton 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
pullshould 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.
Updated by Jim Pingle about 2 months ago
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.