Some progress: A credentials file is needed and by the convention of the OVPN-hoster that really needs to contain the application token as password in combination with some organisation ID as username. After providing that credentials file login succeeds, even though at first some AUTH errors have been logged by MANAGEMENT, but establishing the tunnel succeeded anyway. After manually closing and starting things again, MANAGEMENT didn't log any AUTH errors anymore. Things work on Linux now as well.
What I don't understand is that even though everything seems to work now, the following line is still logged on Windows:
Enter Management Password:
But there shouldn't be any MANAGEMENT-related problem, because that is used to do some things and properly logs:
2020-11-23 11:57:48 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2020-11-23 11:57:48 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2020-11-23 11:57:48 Windows version 10.0 (Windows 10 or greater) 64bit
2020-11-23 11:57:48 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10
Enter Management Password:
2020-11-23 11:57:48 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25351
2020-11-23 11:57:48 Need hold release from management interface, waiting...
2020-11-23 11:57:49 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25351
2020-11-23 11:57:49 MANAGEMENT: CMD 'state on'
2020-11-23 11:57:49 MANAGEMENT: CMD 'log all on'
2020-11-23 11:57:49 MANAGEMENT: CMD 'echo all on'
2020-11-23 11:57:49 MANAGEMENT: CMD 'bytecount 5'
2020-11-23 11:57:49 MANAGEMENT: CMD 'hold off'
2020-11-23 11:57:49 MANAGEMENT: CMD 'hold release'
2020-11-23 11:57:49 MANAGEMENT: >STATE:1606129069,RESOLVE,,,,,,
2020-11-23 11:57:49 TCP/UDP: Preserving recently used remote address: [AF_INET]52.209.29.183:1194
2020-11-23 11:57:49 Socket Buffers: R=[65536->65536] S=[65536->65536]
2020-11-23 11:57:49 UDP link local: (not bound)
2020-11-23 11:57:49 UDP link remote: [AF_INET]52.209.29.183:1194
2020-11-23 11:57:49 MANAGEMENT: >STATE:1606129069,WAIT,,,,,,
2020-11-23 11:57:49 MANAGEMENT: >STATE:1606129069,AUTH,,,,,,
2020-11-23 11:57:49 TLS: Initial packet from [AF_INET]52.209.29.183:1194, sid=0bfe4a88 4b8029f7
2020-11-23 11:57:49 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-11-23 11:57:50 VERIFY KU OK
2020-11-23 11:57:50 Validating certificate extended key usage
2020-11-23 11:57:50 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2020-11-23 11:57:50 VERIFY EKU OK
2020-11-23 11:57:50 VERIFY OK: depth=0, C=de, ST=Bavaria, L=Wuerzburg, O=EMnify, OU=EMnify Operations, CN=openvpn.emnify.net, name=EMnify, emailAddress=
support@emnify.com
2020-11-23 11:57:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2020-11-23 11:57:50 [openvpn.emnify.net] Peer Connection Initiated with [AF_INET]52.209.29.183:1194
2020-11-23 11:57:51 MANAGEMENT: >STATE:1606129071,GET_CONFIG,,,,,,
2020-11-23 11:57:51 SENT CONTROL [openvpn.emnify.net]: 'PUSH_REQUEST' (status=1)
2020-11-23 11:57:51 PUSH: Received control message: 'PUSH_REPLY,sndbuf 393216,rcvbuf 393216,route 10.64.0.1,topology net30,ping 10,ping-restart 60,route 100.119.4.0 255.255.252.0,ifconfig 10.64.55.165 10.64.55.166,peer-id 204,cipher AES-256-GCM'
2020-11-23 11:57:51 OPTIONS IMPORT: timers and/or timeouts modified
2020-11-23 11:57:51 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
2020-11-23 11:57:51 Socket Buffers: R=[65536->393216] S=[65536->393216]
2020-11-23 11:57:51 OPTIONS IMPORT: --ifconfig/up options modified
2020-11-23 11:57:51 OPTIONS IMPORT: route options modified
2020-11-23 11:57:51 OPTIONS IMPORT: peer-id set
2020-11-23 11:57:51 OPTIONS IMPORT: adjusting link_mtu to 1624
2020-11-23 11:57:51 OPTIONS IMPORT: data channel crypto options modified
2020-11-23 11:57:51 Data Channel: using negotiated cipher 'AES-256-GCM'
2020-11-23 11:57:51 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2020-11-23 11:57:51 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2020-11-23 11:57:51 interactive service msg_channel=864
2020-11-23 11:57:51 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 I=30 HWADDR=fc:f8:ae:b6:e4:7d
2020-11-23 11:57:51 open_tun
2020-11-23 11:57:51 tap-windows6 device [OpenVPN net.emnify.openvpn.eu-west-1] opened
2020-11-23 11:57:51 TAP-Windows Driver Version 9.24
2020-11-23 11:57:51 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.64.55.165/255.255.255.252 on interface {0DBEC9F5-8D47-4232-9847-4233711E5931} [DHCP-serv: 10.64.55.166, lease-time: 31536000]
2020-11-23 11:57:51 Successful ARP Flush on interface [9] {0DBEC9F5-8D47-4232-9847-4233711E5931}
2020-11-23 11:57:51 MANAGEMENT: >STATE:1606129071,ASSIGN_IP,,10.64.55.165,,,,
2020-11-23 11:57:51 IPv4 MTU set to 1500 on interface 9 using service
2020-11-23 11:57:56 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
2020-11-23 11:57:56 MANAGEMENT: >STATE:1606129076,ADD_ROUTES,,,,,,
2020-11-23 11:57:56 C:\WINDOWS\system32\route.exe ADD 10.64.0.1 MASK 255.255.255.255 10.64.55.166
2020-11-23 11:57:56 Route addition via service succeeded
2020-11-23 11:57:56 C:\WINDOWS\system32\route.exe ADD 100.119.4.0 MASK 255.255.252.0 10.64.55.166
2020-11-23 11:57:56 Route addition via service succeeded
2020-11-23 11:57:56 Initialization Sequence Completed
2020-11-23 11:57:56 MANAGEMENT: >STATE:1606129076,CONNECTED,SUCCESS,10.64.55.165,52.209.29.183,1194,,
2020-11-23 11:59:37 SIGTERM received, sending exit notification to peer
2020-11-23 11:59:40 C:\WINDOWS\system32\route.exe DELETE 10.64.0.1 MASK 255.255.255.255 10.64.55.166
2020-11-23 11:59:40 Route deletion via service succeeded
2020-11-23 11:59:40 C:\WINDOWS\system32\route.exe DELETE 100.119.4.0 MASK 255.255.252.0 10.64.55.166
2020-11-23 11:59:40 Route deletion via service succeeded
2020-11-23 11:59:40 Closing TUN/TAP interface
2020-11-23 11:59:40 TAP: DHCP address released
2020-11-23 11:59:40 SIGTERM[soft,exit-with-notification] received, process exiting
2020-11-23 11:59:40 MANAGEMENT: >STATE:1606129180,EXITING,exit-with-notification,,,,,
Under which additional circumstances does "Enter Management Password:" occur?
Still not sure.
How likely is it that whatever triggers "Enter Management Password:" on my Windows is the same root cause for not establishing the tunnel on Linux?
Unlikely, on Windows I only needed to create the correct credentials file and could successfully establish the tunnel.
Does a special device needs to be created on Linux?
No, OVPN creates tun0 in my case automatically. Without the tunnel, executing "ip link" DOES NOT show that device, while after creating the tunnel it DOES exist.
ROUTE_GATEWAY 164.138.208.10/255.255.252.0 IFACE=eth0 HWADDR=00:16:3e:5b:29:9d
TUN/TAP device tun0 opened
TUN/TAP TX queue length set to 100
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
/sbin/ip link set dev tun0 up mtu 1500
/sbin/ip addr add dev tun0 local 10.64.55.165 peer 10.64.55.166
/sbin/ip route add 10.64.0.1/32 via 10.64.55.166
/sbin/ip route add 100.119.4.0/22 via 10.64.55.166
Is the option "auth-user-pass" related to encrypted keys/certificates/...?
No, I didn't change anything related the keys/certs and they seem to be decrypted anyway. "auth-user-pass" really was only necessary because the OVPN-hoster requires additional authentication.
