OpenVPN disconnect removes active route to server IP, despite existing persistent route (On Windows)

[masoel00]

Describe the bug

When an OpenVPN client disconnects, persistent routes to the OpenVPN server IP remain in the routing table but the corresponding active route entry is removed. This causes the client to lose the active route to the server IP, breaking the ability to reconnect without manually refreshing the route or toggling the network interface. This behavior occurs even though the persistent route is still present, and it prevents seamless reconnection. The issue appears related to OpenVPN’s route cleanup logic on disconnect, which removes the active route to the OpenVPN Server IP that was used/added but does not restore or respect pre-existing active route to the OpenVPN Server IP.

To Reproduce (using Windows)

Configure an OpenVPN client on Windows with a persistent route to the OpenVPN server IP via a specific gateway/interface [not the default gateway].
Connect the OpenVPN client; the connection uses the persistent route correctly.
Disconnect the OpenVPN client.
Observe that the persistent route remains but the active route entry for the server IP is removed.
Attempt to reconnect; the connection fails because the active route to the server IP is missing.

Toggle the interface with a PS command (to restore the active route) Replace "Your_Interface_Name" with actual Interface Name:

Disable-NetAdapter -Name "Your_Interface_Name" -Confirm:$false; Start-Sleep -Seconds 5; Enable-NetAdapter -Name "Your_Interface_Name" -Confirm:$false

Expected behavior

On disconnect, OpenVPN should either:

Not remove the active route if a persistent route to the server IP already exists, or
Restore the active route from the persistent route after cleanup, ensuring connectivity to the server IP remains intact for reconnection.

Version information (2.7rc_6):

OS: Windows 11 (Only tested on Windows 64-bit version)
OpenVPN version: 2.7rc_6 (originally tested on 2.7rc_3, but also tested on the latest RC version)
Peer version: N/A (client-side issue)

Additional context

This issue is related to the previously reported and resolved issue #890, which addressed route management on Windows clients. However, the current behavior still causes disruption in environments where persistent routes are used to direct traffic to the OpenVPN server IP via a non-default gateway. A programmatic workaround involves toggling the network interface on disconnect to force Windows to reactivate persistent routes, but this is not ideal. A fix in OpenVPN’s route cleanup logic to respect existing persistent routes or avoid removing them unnecessarily would improve client stability and reconnection reliability.

[cron2]

Please provide a log that shows what you are doing.

This sounds as if you have a pre-existing host route to the VPN server, and OpenVPN is not respecting it and trampling on it (when it installs a new redirect host route)?

[masoel00]

Logs and Data

I have attached the logs and route table snapshots. (I've only sanitized the actual Public IP - replaced with A.B.C.D)

route_before.txt: Shows the persistent route to the server IP via gateway 10.45.1.2.
route_after_connect.txt: Shows OpenVPN active and managing the route.
route_after_disconnect.txt: Shows the persistent route is still listed at the bottom, but the 'Active Route' entry for the server IP has been deleted from the top section.
client0026-alt.txt (openvpn log): Client log with verb 6 showing the route deletion process.

Updated Log Reference:

[Line 771 - 772]
2026-01-29 10:57:00 us=531000 C:\windows\system32\route.exe ADD A.B.C.D MASK 255.255.255.255 10.45.1.2
2026-01-29 10:57:00 us=578000 Route addition via service failed because route exists

[Line 802] Active Route for A.B.C.D is removed: 2026-01-29 10:57:24 us=406000 C:\windows\system32\route.exe DELETE A.B.C.D MASK 255.255.255.255 10.45.1.2

Updated the Log Files (earlier logs was using the 10.45.1.2 as default gateway):

Persistent_Route_Client_updated.zip

[schwabe]

So you already had a special host route before connect:

	  A.B.C.D  255.255.255.255        10.45.1.2      10.45.1.100     21

but our logic looks up but the default route and creates a route for that as host route, deleting your special route in the process

In such a special case where you do that yourself, you might be better to not use redirect-gateway.

[masoel00]

Yes, it tries to create the route, but it fails to create the route; however, during clean-up it deletes the route that it failed to create.

Ideally, the clean-up would skip this address where it "failed" the route addition.

[Line 771 - 772]
2026-01-29 10:57:00 us=531000 C:\windows\system32\route.exe ADD A.B.C.D MASK 255.255.255.255 10.45.1.2
2026-01-29 10:57:00 us=578000 Route addition via service failed because route exists

[Line 802] Active Route for A.B.C.D is removed: 2026-01-29 10:57:24 us=406000 C:\windows\system32\route.exe DELETE A.B.C.D MASK 255.255.255.255 10.45.1.2

[cron2]

Right. The code should remember that it did not install the route, and then not try to remove it - this works on Linux (we had similar bugs), not sure why it does not work on Windows. Maybe it just does not work for the redirect host route, or the windows code does not properly signal it upwards.

So that would clearly be a bug.

Volunteers welcome to look into this...

[selvanair]

You can avoid openvpn adding the host route to the server by adding the local flag to redirect-gateway: that is, rediect-gateway def1 local bypass-dhcp in your case. I think the flag name local is a misnomer as what it does is to omit adding the direct route to the server[*]

[*] correct me if it does anything more than that.

[selvanair]

Right. The code should remember that it did not install the route, and then not try to remove it - this works on Linux (we had similar bugs), not sure why it does not work on Windows. Maybe it just does not work for the redirect host route, or the windows code does not properly signal it upwards.

So that would clearly be a bug.

Volunteers welcome to look into this...

See TODO in commit message below -- but I do not recall why this was a special case and not done at the time!

commit 00fac39
Author: Selva Nair selva.nair@gmail.com
Date: Sat Jan 21 14:42:26 2023 -0500

Fix one more 'existing route may get deleted' case

- Ensure net_route_v4/v6_add/del() functions using iproute2 return
  error when route addition fails. Return value follows the same logic
  as corresponding functions using netlink though all failure reasons
  get the same error code of -1.

TODO: Preserve any preexisting direct route to VPN and optionally the
IPv6 connected net route.

v2: Following review, removed the poorly coded RL_DID_LOCAL-related chunks.
That part needs a better fix.

Signed-off-by: Selva Nair <selva.nair@gmail.com>
Acked-by: Gert Doering <gert@greenie.muc.de>
Message-Id: <20230121194226.2081637-1-selva.nair@gmail.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26067.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>

[cron2]

Thanks for digging this up. I remembered "we fixed this" but forgot about that TODO item... maybe it wasn't really hurting, and more complex to fix...