Community Forum

Resolved
0 votes
Lately our OpenVPN connections are dropping, and when the users go to reconnect they can't get past the login prompt.
We have the Active Directory Connector installed and connected to the main DC.

To resolve the issue, I have to open "System > Accounts > Users" and "System > Accounts > Groups" and wait for the list to populate, then Stop and Restart OpenVPN. Then the users can authenticate.

Has anyone else had this issue?

MICHAEL TATE
YouDecide | IT


====== Software Version ======
2.2.0-1


====== Message Logs ======
=== User logs in ===
Mar 2 07:17:44 VPNSERVER openvpn[1183]: 66.138.xxx.92:63xx4 TLS: Username/Password authentication succeeded for username 'REMOTEUSER'

=== Begin error (nothing in log for prior 45 minutes) ==
Mar 2 08:00:47 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 TLS: soft reset sec=1017 bytes=69159716/67108864 pkts=106513/0
Mar 2 08:00:47 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 VERIFY OK: depth=1, C=US, L=Duluth, O=ClearOS, OU=DUL, CN=ca.xxxx.youdecide.com, emailAddress=xxxxxx@xxxx.youdecide.com, O=YouDecide, ST=GA
Mar 2 08:00:47 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 VERIFY OK: depth=0, C=US, ST=GA, L=Duluth, O=ClearOS, O=YouDecide, OU=DUL, CN=REMOTEUSER, emailAddress=REMOTEUSER@youdecide.com
Mar 2 08:00:49 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 PLUGIN_CALL: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
Mar 2 08:00:49 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so
Mar 2 08:00:49 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 TLS Auth Error: Auth Username/Password verification failed for peer
Mar 2 08:00:49 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mar 2 08:01:47 VPNSERVER openvpn[1183]: REMOTEUSER/66.138.xxx.92:63xx4 TLS Error: local/remote TLS keys are out of sync: [AF_INET]66.138.xxx.92:63xx4 (via [AF_INET]172.xxx.xxx.250%enp5s0) [1]

=== Clicking on Users & Groups to ennumerate the lists===
Mar 2 08:06:59 VPNSERVER systemd: Starting Cleanup of Temporary Directories...
Mar 2 08:06:59 VPNSERVER systemd: Started Cleanup of Temporary Directories.
Mar 2 08:07:06 VPNSERVER clearsyncd[707]: System Events: Socket hang-up: 29
Mar 2 08:07:06 VPNSERVER clearsyncd[707]: System Events: Socket hang-up: 29
Mar 2 08:07:08 VPNSERVER webconfig: Redirecting to /bin/systemctl stop winbind.service
Mar 2 08:07:08 VPNSERVER systemd: Stopping Samba Winbind Daemon...
Mar 2 08:07:08 VPNSERVER systemd: Stopped Samba Winbind Daemon.
Mar 2 08:07:08 VPNSERVER webconfig: Redirecting to /bin/systemctl start winbind.service
Mar 2 08:07:08 VPNSERVER systemd: Cannot add dependency job for unit microcode.service, ignoring: Unit is not loaded properly: Invalid argument.
Mar 2 08:07:08 VPNSERVER systemd: Starting Samba Winbind Daemon...
Mar 2 08:07:08 VPNSERVER systemd: winbind.service: Supervising process 21616 which is not our child. We'll most likely not notice when it exits.
Mar 2 08:07:08 VPNSERVER systemd: Started Samba Winbind Daemon.

=== Restrarting OpenVPN ===
Mar 2 08:07:40 VPNSERVER systemd: Stopping OpenVPN Robust And Highly Flexible Tunneling Application On clients/tcp...
Mar 2 08:07:40 VPNSERVER systemd: Stopped OpenVPN Robust And Highly Flexible Tunneling Application On clients.
Mar 2 08:07:44 VPNSERVER systemd: Starting OpenVPN Robust And Highly Flexible Tunneling Application On clients/tcp...

=== User logs back in ===
Mar 2 08:07:46 VPNSERVER openvpn[22173]: 66.138.xxx.92:63xx8 TLS: Username/Password authentication succeeded for username 'REMOTEUSER'
In OpenVPN
Thursday, March 02 2017, 03:58 PM
Share this post:

Accepted Answer

Monday, May 01 2017, 04:16 PM - #Permalink
Resolved
0 votes
Ok, stayed up over the weekend with these changes. (with 4k keys, but still fail audit since clearos/openvpn doesn't use at least 256bit cipher -- another separate security issue)

#!/bin/bash
#Fix samba
FILE=/etc/samba/smb.conf
sed -i '/winbind offline logon/c\winbind offline logon = yes' $FILE

FILE=/etc/cron.d/get-active-directory
echo '*/5 * * * * root /usr/bin/gentent passwd && /usr/bin/getent group' > $FILE
chmod +x $FILE


Also, had put this in a cron script in "/etc/cron.d/fix-clearos" to rewrite the edit every 7 mins (don't forget to chmod +x the file)
*/7 * * * * root sed -i '/winbind offline logon/c\winbind offline logon = yes' /etc/samba/smb.conf
The reply is currently minimized Show
Responses (8)
  • Accepted Answer

    Thursday, May 18 2017, 05:39 PM - #Permalink
    Resolved
    0 votes
    UPDATE:
    After following Mr McShane's advice and making the following change to "/etc/samba/smb.conf":
    winbind offline logon = yes
    I haven't had a single VPN connection drop, nor have I had to bump the SMB Cache to restore service.
    I'm recommending his solution, and will mark this as resolved in 2 more weeks if all holds fast.
    Michael Tate
    The reply is currently minimized Show
  • Accepted Answer

    Monday, May 01 2017, 08:13 PM - #Permalink
    Resolved
    0 votes
    You can upgrade to OpenVPN 2.4.1 from clearos-epel. This will automatically negotiate stronger encryption if your clients support it. OpenVPN Connect on both Android and iPad iOS do. In Windows you need to update to the latest client. With all three clients and the server no further adjustments were necessary.

    As I am also running OpenVPN on a Pi (Raspbian) which is not directly upgradable to 2.4.1 from its repos, I had to manually force the encryption on the Pi and also add "ncp-ciphers AES-256-GCM:AES-256-CBC:BF-CBC" to /etc/openvpn/clients.conf.

    In this configuration, the Pi uses AES-256-CBC and the other clients use AES-256-GCM. I should be able to drop the BF-CBC from the above string as I now have no client using it.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 27 2017, 05:11 AM - #Permalink
    Resolved
    0 votes
    John Colin McShane wrote:

    Just wanted to confirm we are seeing this on our 7.3.0 fresh install.

    Environment
    <ul>
    ClearOS 7.3.0 fresh install
    Active Directory Connector
    Windows Server 2016
    OpenVPN
    </ul>

    Symptoms
    <ul>
    OpenVPN user connections die
    OpenVPN users recieve password authentication failed
    Only reload cache via the WebGUI-> Accounts or Groups allows logins
    Cronjob specified above does not work
    </ul>


    Same here. Exact setup. :(
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, April 20 2017, 06:41 PM - #Permalink
    Resolved
    0 votes
    Bump.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 04 2017, 08:37 PM - #Permalink
    Resolved
    1 votes
    Just wanted to confirm we are seeing this on our 7.3.0 fresh install.

    Environment

    ClearOS 7.3.0 fresh install
    Active Directory Connector
    Windows Server 2016
    OpenVPN


    Symptoms

    OpenVPN user connections die
    OpenVPN users recieve password authentication failed
    Only reload cache via the WebGUI-> Accounts or Groups allows logins
    Cronjob specified above does not work
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, March 22 2017, 01:54 PM - #Permalink
    Resolved
    0 votes
    Before replying to this thread, I tried setting a "tab refresh" in Firefox to refresh the accounts page in the WebGUI, but that also failed

    So I modified the cron job to clear cache first:
    */5 * * * * /usr/sbin/nscd -i passwd && /usr/bin/getent passwd && /usr/sbin/nscd -i group && /usr/bin/getent group
    But that didn't help; my users still got kicked off. I even ran it manually when we got disconnected, but that didn't allow us to authenticate.

    It wasn't until I logged into the WebGUI and forced a cache refresh that users were allowed to authenticate.


    MICHAEL TATE
    YouDecide | IT
    The reply is currently minimized Show
  • Accepted Answer

    Monday, March 20 2017, 05:26 PM - #Permalink
    Resolved
    0 votes
    I'm afraid that didn't resolve the issue. Even running it manually generates output from AD, but doesn't permit OpenVPN authentication from AD.

    I have found that I have to refresh the cache on the WebGUI lets the AD Connector resume authentication.Could the nscd be involved in my issue?

    MICHAEL TATE
    YouDecide | IT
    The reply is currently minimized Show
  • Accepted Answer

    Monday, March 06 2017, 02:52 AM - #Permalink
    Resolved
    0 votes
    Does this workaround mitigate the problem?

    Edit crontab with:

    crontab -e

    Go to the last line by hitting:

    G

    Open a new line with:

    o

    Input the following:

    */5   *   *   *   *   /usr/bin/getent passwd && /usr/bin/getent group


    Let me know if that workaround makes the issue go away, if so. There are some other things we can check. If not, then we can look at some other things.
    The reply is currently minimized Show
Your Reply