Could not authenticate - after changing Host Name Resolution.

[rickandaj]

My openvpn client stopped working a few days ago because of an ISP DHCP change. Once I discovered the cause I attempted to use the DDNS name instead of the IP address in the Host Name Resolution section. Simple enough, but it didn't work! Same user, just an adjustment in the client export - That didn't work.

I checked the forums for some help but didn't find one specific to my issue - user 'xxxx' could not authenticate - after changing Host Name Resolution. I verified that the user was not locked out and the account was valid. I even created another client export with the interface IP address just to see if that would work. Still no-go. I then created a new user and tried with interface IP and DDNS name. Both worked??? What am I missing? Thanks in advance.

[viragomann]

@rickandaj
What does the client log tell you?

[rickandaj]

@viragomann I was unable to get a screen shot but a part from the cipher info etc it had the following minus the times

From Client Log

Verify OK: depth.....
handshake : peer certificate ..... and the rest
Session is active
Sending PUSH_REQUEST to server
Event:GET_CONFIG
Sending PUSH_REQUEST to server
AUTH_FAILED

I retyped the user credentials both in pfSense and the openvpn client. Still got the same error. Created a new user with the same password and got connected using a separate .opvn file for Interface IP and DDNS. That worked without issue. Maybe there was some type of DB corruption for that specific user.

Jan 22 01:50:40 openvpn 94057 user 'xxxx' could not authenticate.
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_BS64DL=1
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_SSO=webauth,openurl,crtext
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_GUI_VER=net.openvpn.connect.android_3.3.4-9290
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_PROTO=30
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_TCPNL=1
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_NCP=2
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_PLAT=android
Jan 22 01:50:40 openvpn 44222 107.87.138.164:30941 peer info: IV_VER=3.git::081bfebe:RelWithDebInfo
Jan 22 01:50:30 openvpn 44222 Initialization Sequence Completed
Jan 22 01:50:30 openvpn 44222 UDPv4 link remote: [AF_UNSPEC]
Jan 22 01:50:30 openvpn 44222 UDPv4 link local (bound): [AF_INET]142.197.176.149:23195
Jan 22 01:50:30 openvpn 44222 /usr/local/sbin/ovpn-linkup ovpns1 1500 0 172.16.167.1 255.255.255.0 init
Jan 22 01:50:30 openvpn 44222 /sbin/ifconfig ovpns1 172.16.167.1/24 mtu 1500 up
Jan 22 01:50:30 openvpn 44222 TUN/TAP device /dev/tun1 opened
Jan 22 01:50:30 openvpn 44222 TUN/TAP device ovpns1 exists previously, keep at program end
Jan 22 01:50:30 openvpn 44222 WARNING: experimental option --capath /var/etc/openvpn/server1/ca
Jan 22 01:50:30 openvpn 44222 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jan 22 01:50:30 openvpn 44222 WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Jan 22 01:50:30 openvpn 43941 DCO version: FreeBSD 14.0-CURRENT amd64 1400094 #1 plus-RELENG_23_09_1-n256200-3de1e293f3a: Wed Dec 6 21:00:32 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_09_1-main/obj/amd64/Obhu6gXB/var/jenkins/workspace/pfSense-Plus-snapshots-23_09_1
Jan 22 01:50:30 openvpn 43941 library versions: OpenSSL 3.0.12 24 Oct 2023, LZO 2.10
Jan 22 01:50:30 openvpn 43941 OpenVPN 2.6.8 amd64-portbld-freebsd14.0 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] [DCO]
Jan 22 01:50:30 openvpn 3311 SIGTERM[hard,] received, process exiting
Jan 22 01:50:30 openvpn 29096 Flushing states on OpenVPN interface ovpns1 (Link Down)
Jan 22 01:50:30 openvpn 3311 /usr/local/sbin/ovpn-linkdown ovpns1 1500 0 172.16.167.1 255.255.255.0 init
Jan 22 01:50:30 openvpn 3311 /sbin/ifconfig ovpns1 172.16.167.1 -alias

I just tried it with another user that was working prior to the ISP dhcp change and that worked with zero issue. So for sure, the issue is specific to that user account.

Any suggestions? Thanks.

[viragomann]

@rickandaj
Is the user in the same user database as the others?

Maybe something wrong with the certificate?

You can enhance the servers verbosity level to get more details in the log.

[rickandaj]

@viragomann Yes the same local database for all users. I guess this can be chalked up to "gremlins" in the system. All the other accounts using the openvpn are still working after the host name resolution change. I even considered the fat finger syndrome - :) - but that was eliminated with repeated copy/pastes. Still scratching my head on the cause? However, it in now not as critical, since I have a work around. I appreciate your help!!