On VyOS 1.5 Q2-2025 stream, I have ~20 OpenVPN site-to-site tunnels with similar configuration. On nearly every reboot, a random subset of these tunnels fails to apply and appears uncommitted in the config.

Tunnels use the following structure (only differing in addresses and ports):

+ openvpn vtun13 {
+     description "my-mega-tunnel"
+     local-address 10.0.1.87 {
+     }
+     local-host "8.1.2.3"
+     local-port "13020"
+     mode "site-to-site"
+     openvpn-option "--data-ciphers-fallback AES-128-CBC"
+     remote-address "10.0.1.88"
+     remote-host "3.4.5.6"
+     remote-port "13001"
+     tls {
+         ca-certificate "vyos-ca"
+         certificate "vpngw-my01_signed"
+         role "passive"
+     }
+ }

After boot, some tunnels fail with a Network is unreachable error, and load reveals them as uncommitted. Running commit manually after boot resolves the issue and brings all tunnels up successfully.

Root cause:
OpenVPN services are started before a valid default route is established. As seen in the logs:

net_route_v4_best_gw result: via 0.0.0.0 dev
...
write UDPv4 []: Network is unreachable (fd=6,code=101)
...
SIGUSR1[soft,network-unreachable] received, process restarting

Eventually, once the default route appears (via 8.1.2.6 dev eth0), the tunnel comes up successfully — but only if manually restarted or re-committed.

Expected behavior:
All OpenVPN tunnels should start reliably after boot, once the system has a valid default route and interfaces are ready.

Actual behavior:
Tunnels start too early and fail to establish due to missing routes. The failed tunnels are left in an uncommitted state and do not recover automatically.

Steps to reproduce:

Define 15–20 OpenVPN site-to-site tunnels with static remote-hosts and local-host IPs
Reboot VyOS 1.5
Observe that some tunnels fail with network unreachable, and config is partially unapplied
Run commit manually → all tunnels apply successfully

write UDPv4 []: Network is unreachable (fd=6,code=101)
SIGUSR1[soft,network-unreachable] received, process restarting
...
net_route_v4_best_gw result: via 0.0.0.0 dev
...
net_route_v4_best_gw result: via 8.1.2.6 dev eth0

Suggestion:
Delay OpenVPN service startup until a valid default route is present, or implement dependency logic (e.g., via systemd unit After=network-online.target). Alternatively, queue/retry config commit automatically after boot finishes.