Doh....
I can't believe I missed/forgot about this...
Yeah, the solution may be fairly simple. This is most likely an issue of time. Specifically, there is no real time clock (RTC) to keep persistent time on most routers. This means that when you restart the router, the current time gets cleared and the time must sync with an NTP server. IIRC, OpenWrt does set the time to the value of the most recently written file, thus making it not-as-far-off as if it just didn't have any time reference at all (think the beginning of the unix epoch - Jan 1, 1970, midnight UTC). Here is a thread discussing the time issues.
Anyway, I think that OpenVPN will not connect properly if the time isn't right. I know this to be true for Wireguard, but I think it matters for OpenVPN as well, although the time tolerance may be bigger.
I'd recommend trying to either delay the OpenVPN initialization until after NTP has successfully sync'd, or to bounce it after the NTP sync. This thread deals with the issue for Wireguard, as an example.
If the OpenVPN init upon reboot results in the router itself not having connectivity, the router obviously won't be able to sync time until you stop OpenVPN. However, if the time can sync properly, you can just restart the tunnel.
There are probably a bunch of ways to test this theory (do these individually, not combined)...
- add a delay (maybe 10-60 seconds) in the OpenWrt init sequence
- push OpenVPN's init sequence number to 99, with the hopes that the time has sync'd by the time OpenVPN is started (this is not guaranteed to work, though)
- disable the OpenVPN service on boot and then use the hot plug scripts described in the WG thread to start OpenVPN when NTP has sync'd
- leave OpenVPN enabled on-boot, add the hot plug script to restart OpenVPN after NTP success.
Whichever of these options seems resonate with you as a reasonable solution is probably worth trying.... try other options if it doesn't resolve the issue.