Bug #13116
closed
OpenVPN client ``tls-client``/``client`` configuration directive not handled properly
100%
Description
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
clientexpands totls-clientandpullso it is redundant to havetls-clientandclient, 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 inclienton 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
ifconfigandpulltogether, sopullshould 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 over 2 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 7656940124d108194df34ec0793ac1263aaabf23.
Updated by Marcos M over 2 years ago
Does this need to take into account the `route-no-pull` option?
Updated by Jim Pingle over 2 years 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.
Updated by Jim Pingle over 2 years ago
- Status changed from Feedback to Resolved
This appears to be correct and consistent now.