Route to VPN server is bound to wrong interface

Describe the bug
When openvpn adds a route to the VPN server, it is bound to the wrong interface. I have a wireless interface wlp1s0 and a wireguard interface wg on my machine. When connecting using sudo openvpn config.ovpn, openvpn successfully connects to the VPN server (8.8.8.8 for example), and adds a route to the VPN server to the routing table to prevent traffic to the VPN server from going through the tunnel. The openvpn client correctly determines the gateway for this route, but the route gets bound to the wg interface:

8.8.8.8 via 192.168.178.1 dev wg 

As the VPN server is not reachable from the wireguard interface, the connection to the VPN server stops working as soon as the tunnel is established, resulting in No route to host errors from the openvpn client:

user@host:~$ sudo openvpn config.ovpn 
2026-01-29 12:45:14 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations. 
2026-01-29 12:45:14 OpenVPN 2.6.17 [git:makepkg/fa20154d58ca609b+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Nov 28 2025
2026-01-29 12:45:14 library versions: OpenSSL 3.6.0 1 Oct 2025, LZO 2.10
2026-01-29 12:45:14 DCO version: N/A
Enter Auth Username: user
Enter Auth Password: 
2026-01-29 12:45:19 TCP/UDP: Preserving recently used remote address: [AF_INET]8.8.8.8:1194
2026-01-29 12:45:19 Attempting to establish TCP connection with [AF_INET]8.8.8.8:1194
2026-01-29 12:45:19 TCP connection established with [AF_INET]8.8.8.8:1194
2026-01-29 12:45:19 TCPv4_CLIENT link local: (not bound)
2026-01-29 12:45:19 TCPv4_CLIENT link remote: [AF_INET]8.8.8.8:1194
2026-01-29 12:45:19 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2026-01-29 12:45:19 [vpn.hhu.de] Peer Connection Initiated with [AF_INET]8.8.8.8:1194
2026-01-29 12:45:20 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:4c78e03e-cfaf-4ec5-8315-35a7ccd4b0b9:bHVyb3MxMDEuemlt:Enter TOTP-Pin.  Then press OK here.
2026-01-29 12:45:20 SIGUSR1[soft,auth-failure] received, process restarting
CHALLENGE: Enter TOTP-Pin.  Then press OK here. 123456
2026-01-29 12:45:25 TCP/UDP: Preserving recently used remote address: [AF_INET]8.8.8.8:1194
2026-01-29 12:45:25 Attempting to establish TCP connection with [AF_INET]8.8.8.8:1194
2026-01-29 12:45:25 TCP connection established with [AF_INET]8.8.8.8:1194
2026-01-29 12:45:25 TCPv4_CLIENT link local: (not bound)
2026-01-29 12:45:25 TCPv4_CLIENT link remote: [AF_INET]8.8.8.8:1194
2026-01-29 12:45:26 [vpn.hhu.de] Peer Connection Initiated with [AF_INET]8.8.8.8:1194
2026-01-29 12:45:27 TUN/TAP device tun0 opened
2026-01-29 12:45:27 net_iface_mtu_set: mtu 1500 for tun0
2026-01-29 12:45:27 net_iface_up: set tun0 up
2026-01-29 12:45:27 net_addr_v4_add: 10.99.16.199/25 dev tun0
2026-01-29 12:45:27 Initialization Sequence Completed
2026-01-29 12:45:56 read TCPv4_CLIENT []: No route to host (fd=3,code=113)
2026-01-29 12:45:56 read TCPv4_CLIENT []: No route to host (fd=3,code=113)
2026-01-29 12:45:56 read TCPv4_CLIENT []: No route to host (fd=3,code=113)
2026-01-29 12:45:57 read TCPv4_CLIENT []: No route to host (fd=3,code=113)
^C2026-01-29 12:46:47 event_wait : Interrupted system call (fd=-1,code=4)
2026-01-29 12:46:47 sitnl_send: rtnl: generic error (-3): No such process
2026-01-29 12:46:47 ERROR: Linux route delete command failed
2026-01-29 12:46:47 net_addr_v4_del: 10.99.16.199 dev tun0
2026-01-29 12:46:47 SIGINT[hard,] received, process exiting

When the wireguard connection is not active, the openvpn client adds the route to the wireless device:

134.99.2.254 via 192.168.178.1 dev wlp1s0 

To Reproduce

1. Connect to an OpenVPN network with a wireguard connection already active
2. Observe a non working tunnel, No route to host errors from the openvpn client and an incorrect route
3. Disconnect from the OpenVPN network and the wireguard network
4. Establish OpenVPN tunnel again, observe a correct route and working VPN tunnel

Expected behavior
The openvpn client should add routes to the correct interface (or without interface specification at all) regardless of which network connections are present.

Version information (please complete the following information):

• OS: Arch Linux
• OpenVPN version: 2.6.17

Additional context
The config file looks like this:

client
nobind
mssfix 1432
dev tun
remote 8.8.8.8 1194
proto tcp

#auth-nocache
auth-retry interact
persist-key
persist-tun

auth-user-pass
cipher AES-128-CBC
auth SHA256
#pull
keepalive 10 120
#route-method exe
#route-delay 2
verify-x509-name "C=DE, ..."

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

Start by reproducing the route selection with an active WireGuard interface using the supplied OpenVPN configuration and route outputs. Trace the Linux route setup that produces the VPN-server route, then verify that the route uses the reachable wireless interface or omits the interface and that the tunnel remains connected.