Recently we had an intermittent issue with remote OpenVPN. OpenVPN end user complains that they can’t connect to OpenVPN after works well for over a month.

In the system log, we see the below:

Sep 25 13:20:36 vy01 openvpn[25550]: pam_sss(vyatta-openvpn-vtun10.conf:auth): Request to sssd failed. Bad address
Sep 25 13:20:36 vy01 openvpn-vtun10[25557]: 20x.8x.x8.30:56383 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
Sep 25 13:20:36 vy01 openvpn-vtun10[25557]: 20x.8x.x8.30:56383 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-plugin-auth-pam.so
Sep 25 13:20:36 vy01 openvpn-vtun10[25557]: 20x.8x.x8.30:56383 TLS Auth Error: Auth Username/Password verification failed for peer 

From this log, we can see authentication failure related to SSSD.

We check the status of SSSD and found the service is still running:

vyatta@vy01:~$ sudo service sssd status
sssd is running.

We tried to restart the SSSD service. After restart, issue is fixed.

vyatta@y01:~$ sudo service sssd restart

SSSD stands for System Security Services Daemon. The System Security Services Daemon (SSSD) provides access to different identity and authentication providers.Most system authentication is configured locally, which means that services must check with a local user store to determine users and credentials. What SSSD does is allow a local service to check with a local cache in SSSD, but that cache may be taken from any variety of remote identity providers — an LDAP directory, an Identity Management domain, Active Directory, possibly even a Kerberos realm.SSSD also caches those users and credentials, so if the local system or the identity provider go offline, the user credentials are still available to services to verify.

We are checking with Brocade to verify if the SSSD issue is firmware bug or not. BTW, our Vyatta gateway version is 6.7R7.