OpenVPN Server Service not working after system reboot

[ccman32]

Hey everyone,

after I finally managed to get my own OpenVPN Server up and running on TrueNAS, I keep running into problems after restarting the TrueNAS device. While it looks like the OpenVPN Server Service started just fine after the system reboot, I cannot connect to the VPN server from any client device. Only after manually stopping the service and then starting it again via the web UI, it starts working again.

While checking the OpenVPN Server logs, I found the error "CRL is not yet valid" being logged when a client attempts to connect before I manually restarted the service:

I'm not a TrueNAS, FreeBSD or OpenVPN expert by any means but this seems to me like the OpenVPN server is being started so early that the system time or whatever time is used for the certificate validation is not yet initialized. To "fix" this, I tried to uncheck the option to start the OpenVPN Server Service automatically and instead I created a post init task which runs "service openvpn_server onestart". Unfortunately, even after adding a 20 seconds sleep before this command, the OpenVPN server keeps logging the same error on startup.

Does anyone know a solution for this problem or is there already a fix being worked on?

Thanks a lot in advance!

 

[homer27081990]

The is not yet valid error makes me think about certificates and date/time... Could your server have a messed-up date set? Sometimes a bad CMOS battery or a faulty NTP - timezone setting can cause this. If your server thinks it is yesterday and you issued a certificate today (but before the restart that set the date to yesterday), it is going to throw such an error.

 

[ccman32]

The is not yet valid error makes me think about certificates and date/time... Could your server have a messed-up date set? Sometimes a bad CMOS battery or a faulty NTP - timezone setting can cause this. If your server thinks it is yesterday and you issued a certificate today (but before the restart that set the date to yesterday), it is going to throw such an error.

As I said, this problem only happens when the OpenVPN Server Service is started automatically directly after a reboot. If I uncheck the option to start it automatically and just start it manually instead, it works absolutely fine. The only problem is that I won't be able to do this when the reboot happens while I am not at home / connected to my LAN.

If the problem would happen all the time and not just after a reboot, I would agree that it is a problem with the system time, but my timezone settings are correct and the system time matches my current local time, so this cannot be the problem.

My guess is that this could be caused by the OpenVPN Server Service being started too early, but in that case it seems strange to me how this problem hasn't been noticed and fixed already.

 

[ccman32]

Update: I still could not find a solution for this. Whenever I restart my TrueNAS system, the OpenVPN server stops working until I manually stop and then start it again.

 

[homer27081990]

Update: I still could not find a solution for this. Whenever I restart my TrueNAS system, the OpenVPN server stops working until I manually stop and then start it again.

CAUTION: Late reply:
Most likely the timezone is handled by the middleware after OpenVPN, or OpenVPN doesn't have awareness of the middleware and its handling of timedate settings, or most possibly both. I would try finding a way to insert a startup delay (~30s should do) to OpenVPN startup on boot. To be honest, I did a cursory search and didn't turn up with any way to achieve that. Sadly, I do not have the free time required to research the issue . (Also, bumping this up)

 

[homer27081990]

You could also try setting the time in BIOS to side-step the need for timezone adjustments at boot.

 

[ccman32]

You could also try setting the time in BIOS to side-step the need for timezone adjustments at boot.

Sorry for the late response. I tried this now but the BIOS time was already correctly configured. As I wrote earlier, I already tried to start the service with some delay via a post init task but that didn't help either. Do you have any other suggestions or is there some way to escalate or report this problem elsewhere so it can get investigated further?

 

[ccman32]

Strangely, the problem disappeared today after I migrated from SMR to WD Red Plus WD40EFZX CMR drives. I basically just replicated my main pool to the new drives and removed the old drives. Now, whenever I restart the system I can instantly connect just fine via VPN after the boot process finished. I still don't know what was the problem, but at least its gone now

 

[homer27081990]

Strangely, the problem disappeared today after I migrated from SMR to WD Red Plus WD40EFZX CMR drives. I basically just replicated my main pool to the new drives and removed the old drives. Now, whenever I restart the system I can instantly connect just fine via VPN after the boot process finished. I still don't know what was the problem, but at least its gone now

Perhaps the loading time for certain services was affected? I honestly don't know and it doesn't matter. Goodbye and have fun with the system now working.