Answer
Check whether the environment's public hostname is actually resolving to a public IP address rather than the private IP reachable through the VPN — if so, traffic from the desktop tool may be routing over the public internet instead of through the VPN tunnel, even while the VPN connection itself shows as active, and a public-internet route can be rejected or fail differently than a check made over the tunnel. Adding a manual hosts-file entry on the connecting machine, mapping the environment's hostname directly to its private IP, forces traffic through the VPN tunnel as intended and has resolved this exact class of confusing authorization error in split-DNS VPN setups.