2.6.14 "--auth-user-pass requiring --pull"???

[agowa]

IMPORTANT NOTE Bugs about OpenVPN Access Server, OpenVPN Connect or any other product by OpenVPN Inc. should be directly reported to OpenVPN Inc. at https://support.openvpn.net

Describe the bug Either a config file parsing bug or a documentation issue.

Edit: Looks like this is related to (at least) these lines of the code: https://github.com/OpenVPN/openvpn/blob/88f8edbf7545dc7913d031ea12c4bae5250bb766/src/openvpn/options.c#L2813-L2848

To Reproduce

1. Setup a small example deployment with one server and client, fitting the below client config.
2. Try to connect to the server (should work without additional properties, except filling in ca and tls-auth).
3. Now replace client and with tls-client and pull. Docs say this is all that client does Link.
4. Now add pull-filter ignore "" (Config should still work and connect properly). Docs don't mention that anything is except from getting filtered neither at --pull nor --pull-filter args.
5. Next try to remove the pull entirely as the pull-filter ignore "" should render it entirely useless anyway. The docs for --pull even state:

so you should not use --pull or --client in situations where you don't trust the server to have control over the client's routing table

But once these two lines are removed parsing the configuration file fails for undocumented reasons with:

Options error: You must define certificate file (--cert) or PKCS#12 file (--pkcs12) Use --help for more information.

Then one may think "just point it towards the CA file or /dev/null". When --cert /dev/null is added a similar message but with --key instead of --cert is shown. Trying to set that one to /dev/null as well results in another error message without any documentation (Setting --pkcs12 /dev/null instead behaves exactly like --cert /dev/null --key /dev/null in this regard):

Options error: --auth-user-pass requires --pull Use --help for more information.

--auth-user-pass within the docs doesn't mention anything about this requirement.

Also even if this is intended for whatever reason the fact that it doesn't work when pull is missing but does when pull-filter ignore "" definitely needs further elaboration. Same for why cert/key or pkcs12 suddenly becomes required when a client doesn't pull options from the server (esp. when looking at what options get logged as having been sent by the server. See below)

6. Out of desperation try to add all of the options the server (supposedly according to the logs) sent directly into the config file => Same parsing error as above.

Working client config before above steps to start with:

client

dev tun
proto udp
remote example.invalid 1194
auth-user-pass 
link-mtu 1500
mtu-test
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
key-direction 1

<ca>
-----BEGIN CERTIFICATE-----
(...)
-----END CERTIFICATE-----
</ca>

remote-cert-tls server

<tls-auth>
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
(...)
-----END OpenVPN Static key V1-----
</tls-auth>

data-ciphers AES-256-CBC
data-ciphers-fallback AES-256-CBC
verb 5

Even though the mentioned error is while parsing the client configuration before any connection is attempted here are the options the server would be pushing (as logged by the pull-filter option):

# What the server would push:
#route 10.0.0.0 255.255.0.0
#route 192.168.0.0 255.255.255.0
#dhcp-option DNS 10.0.0.11
#dhcp-option DNS 10.0.0.12
#route-gateway 172.16.0.1
#topology subnet
#ping 10
#ping-restart 120
#ifconfig 172.16.0.20 255.255.255.0
#peer-id 4
#cipher AES-256-CBC

Expected behavior Either documentation stating what side effects or hidden configuration options get set/unset when comparing: a) pull being omitted with pull and pull-filter ignore "" (what is different, why, and where to find it in the logs?) b) The configuration with all of the pulled (and logged) options being included in the config (instead of using pull) with one that only contains pull

The expected behaviour would be consistent behaviour. As both in a should behave exactly the same as should the two in b.

And/Or documentation needs to be expanded to state that what's different and why.

Also in case there is some technical reason for why pull is demanded here, a less intrusive option should be provided that only gets the minimal required properties (or add the pull-filter ignore ""-trick to the docs as the "official" solution for these situations together with an explanation what it modifies).

Version information (please complete the following information):

• OS: MacOS 15.6.1
• OpenVPN version: OpenVPN 2.6.14 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD]
• library versions: OpenSSL 3.0.16 11 Feb 2025, LZO 2.10

Additional context I'm connecting to a openvpn server of a 3rd party company to access some specific systems only. I do not want them to fuck up my network configuration or being considered authoritative or trusted for pushing ANY configuration including e.g. DNS or full-tunnel (esp. because some of the routes they push overlay with other networks I need to access). I'll manually configure the routes I want to have and everything else is undesired here too.

[cron2]

Additional context I'm connecting to a openvpn server of a 3rd party company to access some specific systems only. I do not want them to fuck up my network configuration or being considered authoritative or trusted for pushing ANY configuration including e.g. DNS or full-tunnel (esp. because some of the routes they push overlay with other networks I need to access). I'll manually configure the routes I want to have and everything else is undesired here too.

So pull-filter ignore "" is exactly what you want to use.

If you remove pull, you are basically changing a client-to-server config into a point-to-point config (with TLS). In that scenario there is no user/password authentication (as this is only available in a pull to mode server config), so auth-user-pass is not available anymore.

Inside OpenVPN a "client" and a "tls-client" are really the same in a large number of respects, but the main difference is really "user/password", "options negotiations" and sending of PULL_REQUEST. It will actually do honour PULL_REPLY even if that is not documented and more an undocumented feature.

Suggestions for a manpage update are welcome.

[cron2]

... basically what the manpage needs, in case it does not have it yet, is a description of the differences between --client aka --pull + --tls-client and point-to-point mode.

[schwabe]

Technically auth-user-pass could work without --pull but realistically that is such a corner case that I don't want to to support and test that.

You might want to look into route-nopull that should address your concern.

[agowa]

@schwabe Stil gives the remote more control than I like. Probably will end up just throwing it into a VM instead them. Hoped to avoid that. But if such a change is not wanted...

[ordex]

@agowa the ratio is not "you have to use --pull if you want to use --auth-user-pass", but rather "--auth-user-pass is expected to be used in client/server mode only". And "--pull" is what is often used to distinguish the p2p (both peers are equal) from the client/server mode (one peer is the server, the others are clients).

So it's not about giving one peer more power, but rather "we don't envision --auth-user-pass" being something people should/want to use in p2p mode.

If you need to use --auth-user-pass, I feel you know that one of those peers is a server (as it handles authentication for the connecting nodes). Or are you using --auth-user-poass on both peers? (that'd be interesting, if possible at all)

[cron2]

@ordex: my understanding of the scenario is "someone provided a .ovpn profile to give access to some VPN-protected resource" (which would be a typical client-to-server profile, with --client and --auth-user-pass) but @agowa does not trust this server to not install unwanted routes (= steal traffic), so wants to disable --pull - which currently has the unexpected (and undocumented) side effect of conflicting with --auth-user-pass. For us, this is somewhat expected ("p2p" vs. "client" mode pretending to be the same, but only halfway), for normal users, it's not.

--route-nopull exists, and if that is still seen as "too much control", --pull-filter ignore can be used as well...

[ordex]

--route-nopull exists, and if that is still seen as "too much control", --pull-filter ignore can be used as well...

@agowa if what @cron2 described is the actual scenario, then I agree with his proposed solution: you cannot just change the layout of the deployment. But you can definitely control what you accept and what you do not.

--pull-filter is there for this exact reason.

[cron2]

--pull-filter ignore "" actually works, though I've never tested the "ignore all!" variant before :-) - it does break most modern configs, though, so depending on what the server pushes something like

pull-filter accept cipher
pull-filter accept peer-id
pull-filter accept key-derivation
pull-filter accept ping
pull-filter ignore ""

will be needed.