Opened 5 years ago
Closed 4 years ago
#1191 closed User question (invalid)
--push-remove and --push-reset do not remove auth-token from PUSH data
Reported by: | tct | Owned by: | tct |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Documentation | Version: | |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
If a server is configured with --auth-gen-token
then there is no way to selectively use the token.
IE. A CCD file like so:
push-reset push-remove auth-token ifconfig-push 10.8.0.5 10.8.0.6 iroute 10.201.101.0 255.255.255.0 ... other necessary directives
will still push an auth-token
Server log excerpts:
(Full log as attachment)
Thu May 30 21:26:18 2019 us=729924 OpenVPN 2.5_git [git:master/07290dc292ed3a7c] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [ AEAD] built on May 29 2019 Thu May 30 21:26:18 2019 us=729936 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.08 Thu May 30 21:26:18 2019 us=732114 /sbin/ifconfig tuns108 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 Thu May 30 21:26:18 2019 us=734876 /sbin/ifconfig tuns108 add 12fc:1918::10:8:0:1/112 mtu 1500 up Thu May 30 21:26:18 2019 us=736795 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 Thu May 30 21:26:18 2019 us=738146 Initialization Sequence Completed Thu May 30 21:26:48 2019 us=685057 MULTI: multi_create_instance called Thu May 30 21:26:48 2019 us=726062 defaultc03/92.10.33.200:3828 OPTIONS IMPORT: reading client specific options from: defaults/ccd_net30/defaultc03 Thu May 30 21:26:48 2019 us=726132 defaultc03/92.10.33.200:3828 PUSH_REMOVE 'auth-token' Thu May 30 21:26:48 2019 us=726249 defaultc03/92.10.33.200:3828 MULTI_sva: push_ifconfig_ipv6 12fc:1918::10:8:0:226/112 Thu May 30 21:26:48 2019 us=726337 defaultc03/92.10.33.200:3828 MULTI: Learn: 10.8.0.226 -> defaultc03/92.10.33.200:3828 Thu May 30 21:26:48 2019 us=726354 defaultc03/92.10.33.200:3828 MULTI: primary virtual IP for defaultc03/92.10.33.200:3828: 10.8.0.226 Thu May 30 21:26:48 2019 us=726372 defaultc03/92.10.33.200:3828 MULTI: Learn: 12fc:1918::10:8:0:226 -> defaultc03/92.10.33.200:3828 Thu May 30 21:26:48 2019 us=726388 defaultc03/92.10.33.200:3828 MULTI: primary virtual IPv6 for defaultc03/92.10.33.200:3828: 12fc:1918::10:8:0:226 Thu May 30 21:26:49 2019 us=947927 defaultc03/92.10.33.200:3828 PUSH: Received control message: 'PUSH_REQUEST' Thu May 30 21:26:49 2019 us=948171 defaultc03/92.10.33.200:3828 SENT CONTROL [defaultc03]: 'PUSH_REPLY,topology net30,route 10.8.0.0 255.255.255.0,route-ipv6 12fc:1918::10:8:0:0/112,ifconfig-ipv6 12fc:1918::10:8:0:226/112 12fc:1918::10:8:0:1,ifconfig 10.8.0.226 10.8.0.225,peer-id 0,auth-token' (status=1) Thu May 30 21:29:48 2019 us=393400 defaultc03/92.10.33.200:3828 TLS: Username/auth-token authentication succeeded for username 'arch'
Client log excerpts:
(Full log as attachment)
Thu May 30 21:26:41 2019 us=911081 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018 Thu May 30 21:26:41 2019 us=911537 library versions: OpenSSL 1.1.1a 20 Nov 2018, LZO 2.10 Enter Auth Username: arch Enter Auth Password: **** Thu May 30 21:26:49 2019 us=945491 SENT CONTROL [defaults]: 'PUSH_REQUEST' (status=1) Thu May 30 21:26:49 2019 us=950783 PUSH: Received control message: 'PUSH_REPLY,topology net30,route 10.8.0.0 255.255.255.0,route-ipv6 12fc:1918::10:8:0:0/112,ifconfig-ipv6 12fc:1918::10:8:0:226/112 12fc:1918::10:8:0:1,ifconfig 10.8.0.226 10.8.0.225,peer-id 0,auth-token' Thu May 30 21:26:49 2019 us=991890 Initialization Sequence Completed Thu May 30 21:29:48 2019 us=362267 TLS: soft reset sec=0 bytes=1168/-1 pkts=14/0 etc
Attachments (2)
Change History (8)
Changed 5 years ago by
Changed 5 years ago by
comment:1 follow-up: 3 Changed 5 years ago by
comment:2 Changed 5 years ago by
Owner: | set to David Sommerseth |
---|---|
Status: | new → assigned |
what I already wrote to IRC yesterday
20:31 <@cron2> push.c, prepare_push_reply() puts it onto the push_list
20:34 <@cron2> yeah, and that's the problem - these are the "special things that are not normal pushed options"
20:34 <@cron2> so if you have a *plugin* set auth-token, it might be removeable, but *these* auth-tokens are the server-generated ones
20:35 <@cron2> /* If server uses --auth-gen-token and we have an auth token
20:35 <@cron2> * to send to the client
20:35 <@cron2> push_option_fmt(gc, push_list, M_USAGE,
20:35 <@cron2> "auth-token %s", tls_multi->auth_token);
20:36 <@cron2> (and indeed, everything that is added here cannot be push-remove'd - NCP-negotiated cipher cannot be either). Which I can understand (because it's not trivially visible at this place whether or not some option has been removed, without storing that somewhere - order is sensitive!
20:37 <@cron2> but still not satisfying
...
20:43 <@cron2> "fixing" this will not be straightforward given the way push-remove works internally, so documenting this as "shortcoming: push-remove can not remove <this, that, ...>" will be acceptable for me. It's a debugging tool, a *useful* debugging tool, but if it complicates the code very much, there are tradeoffs to decided
background: when push-remove
is encountered, it will act instantaneously at this specific moment in the processing of options. So you can do push-remove route
and then later push route <new route>
and push-remove
will only remove everything that ended up in the push list up to this point. This is a feature :-)
Things that get put onto the push list by other means than push
need to be handled specially - for ifconfig/ifconfig-ipv6 we set a flag "ifconfig has been push-removed". But these are special anyway as ifconfig-push
does more than "just push ifconfig".
So, the --auth-gen-token
generated auth-tokens can not be push-removed today.
@dazo: if this is what it is (because changing it would not lead to nice code), we should just document it.
comment:3 Changed 5 years ago by
Replying to tincantech:
The user question: Should
--push-reset
and--push-remove
be constrained to only what seems arbitrarily acceptable or should they take priority and do what they are documented to do?
--push-reset
Don't inherit the global push list for a specific client instance. Specify this option in a client-specific context such as with a --client-config-dir configuration file. This option will ignore --push options at the global config file level.
--push-remove
selectively remove all --push options matching "opt" from the option list for a client. (etc)
Technically both very clearly do what they are documented to do (since you're so insistent on this). Your auth-token
config has not been set up by a --push
command - and that's all these two commands talk about. If it had been set up manually with --push auth-token
(ccd/ file or plugin), removing it with --push-remove
would work.
comment:4 Changed 5 years ago by
Replying to tincantech:
If a server is configured with
--auth-gen-token
then there is no way to selectively use the token.
The problem is cause by --auth-gen-token
Other weird behaviour is also observed but not documented.
comment:5 Changed 4 years ago by
Component: | Generic / unclassified → Documentation |
---|---|
Owner: | changed from David Sommerseth to tct |
Giving this ticket back to @tincantech: please send a .rst man page fix so we can get this documented, and closed.
comment:6 Changed 4 years ago by
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
When I raised this I did not understand that Auth-Tokens were not really Production ready (A comment made by Selva pointed this out to me).
I'm closing this because I don't know enough about Auth-Token to be able to document it sufficiently accurately for an official man page.
The user question: Should
--push-reset
and--push-remove
be constrained to only what seems arbitrarily acceptable or should they take priority and do what they are documented to do?--push-reset
--push-remove