OpenVPN “route addition failed” on Windows: routing fixes that actually work

Fast diagnosis playbook

If you’re on a bridge call and someone is saying “VPN is up but nothing works,” don’t wander. Do this in order. The goal is to find the bottleneck quickly: permissions, route conflicts, adapter selection, or policy controls.

1) Identify the exact failing route (don’t guess)

• OpenVPN GUI: open the log and search for route addition failed.
• Note the destination network and mask (or CIDR), and the gateway/interface it tried to use.
• If the log doesn’t show the route details, increase verbosity (verb 4 or verb 5) and reconnect.

2) Check whether Windows rejected the change due to privileges

• If you see “Access is denied” or error code 5, you’re not elevated or the service isn’t running with the needed rights.
• If you see “The object already exists” or error 183, you have a conflicting route already in the table.

3) Dump the routing table and look for conflicts and metrics

• Look for an existing route to the same destination network, especially with a lower metric.
• Look for multiple default routes (0.0.0.0/0) created by Wi-Fi, Ethernet, Hyper-V, WSL, or another VPN.

4) Validate the VPN adapter state and interface index

• If TAP/Wintun is disconnected, has no IP, or has a broken metric, route adds may fail or be ignored.
• If the server pushes routes for subnets you already have locally, Windows will “help” you into a black hole.

5) If it still looks sane, suspect security controls

• Windows Defender Firewall rules, WFP callouts from endpoint security, and “hardening” baselines can block route changes.
• Corporate “VPN posture” tools sometimes race OpenVPN and rewrite routes a second later.

That’s the triage. Now we’ll make it precise and repeatable.

What “route addition failed” really means on Windows

OpenVPN doesn’t “route packets.” It asks the OS to install routes. On Windows, that means calling into the IP Helper API (and friends), which then updates the routing table. If Windows refuses the route, OpenVPN logs the failure and proceeds—sometimes with partial connectivity that wastes hours.

A route addition can fail for a few unglamorous reasons:

• Privilege: adding routes requires administrative privileges. The OpenVPN GUI might be running as a normal user. The OpenVPN service might not be configured right. Or UAC is doing what UAC does.
• Conflict: the exact route (destination + mask + gateway/interface) already exists, or a more specific route exists that makes the new one pointless.
• Invalid gateway/interface: OpenVPN tries to add the route via an interface that isn’t up yet (timing), has no IP, or isn’t the adapter Windows thinks it is.
• Policy and filtering: endpoint security drivers can block route modification or reset it immediately after. This is “fun” because OpenVPN may log success while routes disappear later.
• Metric chaos: Windows chooses the “best” route using prefix length first, then metric. If metrics are auto-managed badly—or “optimized” by humans—you get split tunnel failures and hairpin traffic.

One important mental model: OpenVPN is just a route installer plus a tunnel. If Windows won’t accept the route, the tunnel is irrelevant. Your packets will keep taking the old path like nothing happened.

Joke #1: Windows routing is like office seating—everyone has a plan until the intern brings a new VPN client and takes the only chair labeled “default gateway.”

Facts and history that explain today’s pain

Some context helps because the weirdness you’re seeing is not random; it’s layered history.

1. Windows has long preferred “automatic metrics” to pick the “best” interface, and it often changes them after link events. Good for consumers, confusing for split tunneling.
2. OpenVPN’s original Windows integration relied heavily on TAP (layer-2-ish virtual Ethernet). Later, Wintun improved performance and reduced driver drama, but route logic remains OS-driven.
3. Older OpenVPN configs used route-method exe and literally called route.exe. Modern builds typically use IP Helper APIs, but logs and failure modes still reference “route add” semantics.
4. Windows routing decisions are “longest prefix match” first. Metrics are secondary. This is why a stale /24 route can override a shiny new default route, and you’ll swear the VPN “ignores” settings.
5. Split tunneling became mainstream with SaaS. Once companies stopped forcing all traffic through HQ, route tables got complicated fast, especially on laptops with multiple virtual adapters.
6. Endpoint security products often hook Windows Filtering Platform (WFP). They can allow the VPN tunnel but block route changes or specific subnets—so the tunnel is up, yet your internal CIDRs are dead.
7. OpenVPN’s pushed routes are “advisory”: the server pushes, the client attempts. The OS arbitrates. That’s why two clients on the same profile can behave differently if their local routes differ.
8. Corporate images frequently ship with Hyper-V, WSL, Docker, or virtual switch adapters. Each adds routes and can steal metrics or add overlapping RFC1918 ranges.

One quote worth keeping on a sticky note, because it applies perfectly to routing: “Hope is not a strategy.” — General Gordon R. Sullivan.

Common failure modes: access denied, file exists, not found

“ROUTE: route addition failed” + “Access is denied”

This is the classic. You are not elevated, or OpenVPN is not running in a context that can modify the route table. Sometimes it’s intermittent because the first route add fails, but later ones succeed when the adapter comes up and triggers different code paths. Don’t accept intermittent. Fix the privilege model.

“ROUTE: route addition failed” + “The object already exists”

Windows already has a route for that destination. Maybe from another VPN, maybe from a past OpenVPN session with persistent routes, maybe from an “optimization” script. OpenVPN tries to add, Windows says “already there,” and OpenVPN logs it as a failure even though the existing route might be correct—or disastrously wrong.

“ROUTE: route addition failed” + “The network path was not found” / bad gateway

This is usually an interface selection issue: OpenVPN is trying to add a route via a gateway that doesn’t exist yet, or through the wrong interface index. Timing matters on Windows. The adapter may be “connected” but not fully initialized with an IP, DNS, and routing parameters.

“Route added successfully” but traffic still goes wrong

This is metric or prefix behavior, not a route add failure. A more specific route (or lower metric) wins and sends traffic somewhere else. Or your traffic hits the VPN, but return routing or firewall rules block it. Your “fix” is to stop staring at the OpenVPN log and start interrogating the OS route selection.

Practical tasks: commands, outputs, and decisions

You want tasks you can run, outputs you can interpret, and decisions you can make without turning into a part-time network archaeologist. Here they are. Run them on the Windows client. Use an elevated PowerShell or CMD when needed.

Task 1: Confirm you’re actually elevated (yes, really)

cr0x@server:~$ whoami /groups | findstr /i "S-1-5-32-544"
BUILTIN\Administrators Alias S-1-5-32-544 Enabled group, Enabled by default, Group owner

What it means: If you don’t see the Administrators group enabled, you are not elevated. OpenVPN GUI launched normally is often non-elevated, even if your user is “an admin.”

Decision: Relaunch OpenVPN GUI “Run as administrator” or use the OpenVPN service with proper privileges.

Task 2: Capture the failing route from the OpenVPN log

cr0x@server:~$ type "C:\Program Files\OpenVPN\log\client.log" | findstr /i "route addition failed"
2025-12-27 09:11:54 ROUTE: route addition failed using CreateIpForwardEntry: Access is denied.   [status=5 if_index=23]

What it means: Status 5 is privilege. The if_index is the interface Windows tried to use.

Decision: Fix privilege first. If already elevated, suspect endpoint controls blocking route modifications.

Task 3: Dump routing table and look for the target subnet

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.50     35
        10.20.0.0    255.255.0.0         On-link       10.8.0.2      5
        10.20.0.0    255.255.0.0      192.168.1.1    192.168.1.50     25
===========================================================================

What it means: Two routes to 10.20.0.0/16. The VPN “On-link” route has a better metric (5), so it should win. If the worse one wins, you’re probably dealing with a more specific prefix elsewhere or policy routes.

Decision: If the “wrong” route has the better metric, delete it or adjust metrics. If both exist, decide which interface should own that subnet and enforce it.

Task 4: Confirm interface indexes and names match the OpenVPN log

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 11          25        1500  connected     Wi-Fi
 23           5        1500  connected     OpenVPN Wintun

What it means: Idx 23 matches the log. Good. If the log references an index that doesn’t exist anymore, you have a stale adapter or driver churn.

Decision: If index mismatch: remove stale TAP/Wintun adapters and reinstall cleanly, or update the OpenVPN profile to use the correct device type.

Task 5: Verify the VPN adapter has an IP and the expected gateway behavior

cr0x@server:~$ ipconfig /all
Ethernet adapter OpenVPN Wintun:
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : OpenVPN Wintun
   Physical Address. . . . . . . . . : 00-FF-12-34-56-78
   DHCP Enabled. . . . . . . . . . . : No
   IPv4 Address. . . . . . . . . . . : 10.8.0.2(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 

What it means: Many OpenVPN setups use a /32 on the tunnel interface and don’t set a default gateway there. That’s normal. Routing should still work via on-link routes.

Decision: If there is no IP at all, your tunnel isn’t actually configured; fix that before chasing routes.

Task 6: Check for overlapping RFC1918 routes from local networks

cr0x@server:~$ route print | findstr /r "10\. 172\.16\. 192\.168\."
        10.0.0.0        255.0.0.0      192.168.1.1    192.168.1.50     25
      192.168.0.0    255.255.0.0         On-link     192.168.1.50    281

What it means: If your local network already routes 10.0.0.0/8 via your home/office gateway, and the VPN also wants parts of 10/8, you’re in “overlap country.” Windows will use the most specific prefix, but the broad local route can still break less-specific VPN routes.

Decision: Prefer non-overlapping internal addressing if you control it. If you don’t, push more specific routes from OpenVPN (e.g., /16 or /24 instead of /8) and remove broad local routes where feasible.

Task 7: Delete a conflicting route (surgical, not scorched-earth)

cr0x@server:~$ route delete 10.20.0.0 mask 255.255.0.0 192.168.1.1
 OK!

What it means: You removed the route that was stealing traffic from the VPN.

Decision: Reconnect the VPN and verify OpenVPN can add the intended route. If the conflicting route reappears, something (a service, another VPN, a script, group policy) is reinstalling it—hunt that actor, not the symptom.

Task 8: Add a route manually to prove the OS will accept it

cr0x@server:~$ route add 10.20.0.0 mask 255.255.0.0 10.8.0.1 metric 5
 OK!

What it means: Windows accepted the route. If OpenVPN still can’t add it, you likely have a privilege/context issue (GUI vs service) or timing problem.

Decision: If manual add works only in elevated shells, OpenVPN must run elevated or as a service. If manual add fails even elevated, suspect WFP/security policy or an invalid gateway.

Task 9: Confirm actual route selection for a target IP

cr0x@server:~$ powershell -Command "Get-NetRoute -DestinationPrefix 10.20.5.10/32 | Sort-Object -Property RouteMetric | Format-Table -AutoSize"
DestinationPrefix NextHop     InterfaceAlias  RouteMetric PolicyStore
----------------- -------     --------------  ----------- -----------
10.20.5.10/32     10.8.0.1    OpenVPN Wintun  5           ActiveStore

What it means: This shows which route Windows will use for that specific destination (or at least the candidates). A /32 host route is decisive.

Decision: If the route points to Wi-Fi/Ethernet instead of the VPN, you have a prefix/metric conflict. Fix the conflicting route or add a more specific route via VPN.

Task 10: Check whether Windows is auto-managing interface metrics poorly

cr0x@server:~$ powershell -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -AutoSize"
ifIndex InterfaceAlias        NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState
------- --------------        ------------ --------------- ----     ---------------
23      OpenVPN Wintun        1500         5               Disabled Connected
11      Wi-Fi                 1500         25              Enabled  Connected

What it means: Lower metric wins when prefix lengths tie. VPN metric lower than Wi-Fi is usually what you want for full-tunnel, and often what you want for split-tunnel if you rely on route metrics for defaults.

Decision: If the VPN metric is higher than Wi-Fi and you expect default traffic through VPN, set a lower metric on the VPN interface or push a default route through VPN explicitly.

Task 11: Disable automatic metrics on a specific interface (controlled change)

cr0x@server:~$ powershell -Command "Set-NetIPInterface -InterfaceAlias 'OpenVPN Wintun' -AutomaticMetric Disabled -InterfaceMetric 5"

What it means: You pinned the metric. This removes one source of “it worked yesterday” randomness.

Decision: Do this only if you own the laptop baseline or you’re writing a support playbook. Metrics as a per-user tweak are fragile; they’ll drift with adapter renames and rebuilds.

Task 12: Confirm the OpenVPN process context (GUI vs service)

cr0x@server:~$ sc query OpenVPNService
SERVICE_NAME: OpenVPNService
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING

What it means: If the service is running, routes may be installed by the service even if the GUI is not elevated (depends on your build/config). If it’s stopped, the GUI must be elevated to add routes.

Decision: Standardize: either run as a service for consistency, or mandate “Run as administrator” for GUI. Mixing both is where tickets breed.

Task 13: Verify DNS behavior when routes are fine but apps still fail

cr0x@server:~$ nslookup internal-app.corp
Server:  UnKnown
Address:  192.168.1.1

*** internal-app.corp can't find internal-app.corp: Non-existent domain

What it means: You’re querying your local DNS (home router) instead of the corporate DNS. Routing might be perfect; name resolution is sabotaging you.

Decision: Fix pushed DNS options, use block-outside-dns where appropriate, or set interface DNS for the VPN adapter via policy.

Task 14: Detect whether another VPN client is also installed and interfering

cr0x@server:~$ powershell -Command "Get-NetAdapter | Select-Object Name,InterfaceDescription,Status | Format-Table -AutoSize"
Name             InterfaceDescription                      Status
----             --------------------                      ------
Wi-Fi            Intel(R) Wi-Fi 6 AX200 160MHz             Up
OpenVPN Wintun   OpenVPN Wintun                            Up
CorpVPN          Acme SecureConnect Virtual Adapter        Up

What it means: Two VPN adapters up at once is not “extra secure.” It’s route roulette.

Decision: Pick one VPN. Disable or disconnect the other before connecting OpenVPN, unless you explicitly support chained tunnels (most orgs don’t, and Windows really doesn’t).

Task 15: Prove packet path with traceroute (when routing lies to you)

cr0x@server:~$ tracert -d 10.20.5.10

Tracing route to 10.20.5.10 over a maximum of 30 hops

  1     2 ms     1 ms     2 ms  10.8.0.1
  2    15 ms    14 ms    15 ms  10.20.0.1
  3    18 ms    17 ms    18 ms  10.20.5.10

Trace complete.

What it means: If hop 1 is your home router (192.168.1.1) instead of the VPN gateway (often 10.8.0.1 or similar), your traffic is not entering the tunnel.

Decision: Fix route selection. If traceroute enters VPN but dies later, the issue is server-side routing/firewall, not Windows route add.

Task 16: Check Windows event logs for driver or filter issues (route changes blocked)

cr0x@server:~$ powershell -Command "Get-WinEvent -LogName System -MaxEvents 30 | Where-Object {$_.Message -match 'Wintun|TAP|filter|WFP'} | Select-Object TimeCreated,Id,ProviderName,Message | Format-List"
TimeCreated : 12/27/2025 9:12:10 AM
Id          : 5007
ProviderName: Microsoft-Windows-Windows Firewall With Advanced Security
Message     : Windows Firewall settings were changed.

What it means: Not a smoking gun by itself, but changes at connect time can correlate with route failures or traffic drops. Security agents often toggle firewall profiles when a VPN comes up.

Decision: If you see consistent events on connect, coordinate with security tooling owners. Your “network problem” may be a policy engine doing its job badly.

Common mistakes: symptom → root cause → fix

Symptom: “route addition failed: Access is denied”

Root cause: OpenVPN GUI not elevated; service not running; UAC tokens; or endpoint security blocking route writes.

Fix: Run OpenVPN GUI as administrator or run OpenVPN as a Windows service with proper permissions. If already elevated, test manual route add; if that also fails, escalate to endpoint security/WFP policy.

Symptom: “route addition failed: The object already exists”

Root cause: Existing route to same prefix from another VPN, persistent route, or a virtual adapter network (Hyper-V/WSL/Docker) using overlapping ranges.

Fix: Delete the conflicting route; stop the actor that re-adds it; avoid overlapping internal subnets; push more specific routes; disable the second VPN adapter.

Symptom: VPN connects, but only some internal subnets work

Root cause: Split tunneling conflicts. A subset of routes failed to install, often those overlapping with local networks or those pushed before the adapter stabilized.

Fix: Increase log verbosity to see which specific prefixes failed. Add a route-delay or ensure the adapter is ready. Remove overlapping local routes or change pushed prefixes.

Symptom: Route is present, but traffic still goes out Wi‑Fi

Root cause: Metric and prefix rules: a more specific route exists elsewhere, or policy-based routing from other software is winning.

Fix: Use Get-NetRoute for the exact destination IP, not just the subnet. Remove the more specific conflicting route, or add an explicit /32 host route via VPN for critical endpoints.

Symptom: Internal names don’t resolve, but ping by IP works

Root cause: DNS not pushed or not applied. Windows keeps using local DNS servers; split-DNS policies missing.

Fix: Push DNS server and domain options from the VPN; apply block-outside-dns where supported; validate DNS server selection with nslookup.

Symptom: Everything works for 30–90 seconds, then breaks

Root cause: Another agent rewrites routes after the VPN connects: “network optimization,” posture checking, Wi-Fi roaming software, or another VPN client auto-repairing its own routes.

Fix: Watch the route table over time; identify the process/service; disable the competing agent or set a deterministic route policy (service-owned routes, pinned metrics).

Symptom: “Cannot find device” / interface index errors in log

Root cause: Stale TAP/Wintun adapters, driver reinstall, Windows update shuffling interface indexes.

Fix: Remove unused adapters, reinstall the correct driver, and standardize on Wintun where possible to reduce legacy TAP drift.

Joke #2: If you “fixed” routing by disabling every adapter until it worked, congratulations—you’ve reinvented change management, but with more panic.

Three corporate mini-stories from production life

Mini-story 1: The incident caused by a wrong assumption

The company had a tidy story: “OpenVPN pushes routes; clients obey; done.” That assumption held on developer laptops and broke on executive laptops—the ones with a security agent that ran with kernel hooks and a love for “protective defaults.”

The symptom was classic: VPN connected, a few internal apps worked, anything in one particular subnet timed out. The on-call engineer (who had seen enough VPN tickets to age a decade) went straight to the route table and found the pushed /16 route was missing. OpenVPN logged route addition failed with status 5 on those machines.

The wrong assumption: “Status 5 means the user didn’t run as admin.” They were admins. They were elevated. Manual route add still failed. That’s when the team stopped blaming the humans and started blaming the platform.

They correlated connect-time route failures with security agent policy updates and found a rule that prevented modifying routes to “private ranges not explicitly approved.” The policy was meant to prevent malware from re-routing local traffic. It also prevented VPN clients from doing their job unless they registered their routes in a vendor-specific allowlist.

The resolution was boring: coordinate with security, add the VPN subnets to the allowlist, and document that OpenVPN needs route-write capability. The lesson wasn’t “security is bad.” The lesson was that Windows routing is not a private playground—other tenants live there.

Mini-story 2: The optimization that backfired

A network team wanted faster Internet on VPN. They switched from full-tunnel to split-tunnel and pushed only a handful of internal routes. Then they got ambitious and “cleaned up” by pushing a broad route: 10.0.0.0/8. “One route is easier than twenty,” they said. They weren’t wrong. They were also not right.

Users started complaining that when they worked from certain hotels, nothing internal worked. At home it was fine. In the office it was fine. In the hotel: dead. The VPN logs showed route add failures for 10/8. Windows said the route already existed.

The missing detail: those hotel networks also used 10/8 internally. The local Wi‑Fi gateway installed a 10/8 route, and Windows treated it like any other. The OpenVPN-pushed 10/8 collided. Sometimes Windows kept the local one. Sometimes it accepted the VPN one but metrics favored the wrong path. Either way, split tunneling turned into a coin flip.

The fix was a reversal of the “optimization”: stop pushing 10/8. Push only the actual corporate prefixes (more specific /16s and /24s). Yes, it’s more routes. It’s also what you meant in the first place. They also added a check in onboarding docs: if your local network overlaps, expect pain—and don’t pretend that’s the user’s fault.

Mini-story 3: The boring but correct practice that saved the day

Another org had a dull policy: all Windows VPN clients run as services, not user-mode GUI processes. Everyone grumbled because it felt “enterprise-y.” Then a Windows feature update rolled through and changed how UAC tokens behaved for a subset of devices with certain hardening baselines.

Teams that relied on “Run as administrator” started seeing route add failures. Their SOPs were suddenly wrong. People did the usual dance: reinstall OpenVPN, reset the network stack, reboot, swear at the laptop, repeat.

The org with service-based VPN barely noticed. The OpenVPN service ran with consistent privileges and installed routes deterministically. Their incident was a non-event: a handful of users had adapter driver issues, but route add failures weren’t one of them.

The saving practice wasn’t glamorous. It was standardization: one installation method, one execution context, consistent logs, and predictable privilege. When Windows changes under you—and it will—you want fewer moving parts, not more folklore.

Checklists / step-by-step plan

Step-by-step: Fix route addition failures on a single Windows machine

1. Get the exact failing route from the OpenVPN log (destination, mask, gateway, interface index, and status code).
2. Confirm elevation (whoami /groups). If not elevated, stop and fix execution context.
3. Confirm adapter index/name with netsh interface ipv4 show interfaces. If the log references a dead index, clean stale adapters.
4. Dump routes (route print) and find conflicts for that prefix. Decide which route should own it.
5. Delete conflicting routes surgically. Reconnect VPN. Verify the route appears and stays.
6. Verify real route selection for a specific internal IP using Get-NetRoute or tracert.
7. Validate DNS with nslookup to ensure you’re using the intended resolver.
8. Watch for route churn (route table changes after connect). If routes revert, identify the competing service/software.

Checklist: What to standardize across the fleet (so this stops recurring)

• Execution model: pick service-based OpenVPN or elevated GUI; don’t mix casually.
• Adapter strategy: standardize on Wintun where supported; remove legacy TAP clutter.
• Address plan: avoid pushing broad private ranges that collide with home/hotel networks.
• Route policy: push explicit, specific routes; avoid “one big route” unless you own the client environment tightly.
• Metrics: define what wins (VPN vs LAN) and enforce metrics where necessary; document why.
• Security coordination: ensure endpoint controls allow route installation for your VPN subnets.
• Logging: store client logs in a known location; set verbosity high enough for troubleshooting without turning logs into novels.

Step-by-step: When the problem is actually server-side

1. If traceroute shows hop 1 is the VPN gateway but traffic dies later, stop changing Windows routes.
2. Confirm the server is pushing the correct routes and that the server routes return traffic back into the tunnel.
3. Check firewall rules on the VPN concentrator and internal routers for the VPN client pool.
4. Validate that internal networks know how to reach the VPN client subnet (or that NAT is configured intentionally).

FAQ

1) Why does OpenVPN say “route addition failed” but the VPN still connects?

Because tunnel establishment and route installation are separate steps. TLS can succeed, the adapter can come up, and route adds can still fail. The UI says “connected,” your packets disagree.

2) Is “The object already exists” actually a problem?

Sometimes yes, sometimes no. If the existing route points to the correct interface/gateway, you might be fine. If it points to Wi‑Fi or another VPN, you get partial or total failure. Always check the existing route’s interface and metric.

3) Do I need TAP or Wintun?

Most modern Windows deployments should prefer Wintun unless you have a specific legacy requirement. TAP has more historical baggage. But switching drivers won’t magically fix route conflicts or privilege problems; it just reduces driver-related instability.

4) Why do routes fail only on some Wi‑Fi networks?

Overlapping private IP space and “helpful” local routes. Hotels, cafes, and some enterprise guest networks love broad 10/8 usage. If your VPN pushes broad ranges, you collide and Windows chooses a winner you didn’t vote for.

5) How do I know which interface Windows will use for an internal IP?

Don’t eyeball the route table and guess. Query the specific destination using Get-NetRoute for that IP (or use tracert and see hop 1). That tells you the actual path selection.

6) Can endpoint security really block route additions?

Yes. WFP callouts and hardening policies can deny or revert route changes. The symptom looks like “OpenVPN broken,” but the root cause is “route writes not allowed” or “routes rewritten after connect.”

7) Should I use persistent routes to make it stable?

Only if you control the endpoint and you know why you need it. Persistent routes can outlive VPN sessions and cause weird “why is traffic going into a dead tunnel” failures later. Prefer deterministic connect-time routes managed by the VPN service.

8) My route exists, but internal apps still fail. What next?

Check DNS first, then firewall. If you can ping by IP but not by name, it’s DNS. If you can resolve names but TCP fails, look at firewall rules and return routing on the server side. Routing is necessary, not sufficient.

9) Is changing interface metrics a good long-term fix?

It can be, but it’s sharp. Pinning metrics works best when deployed via policy and validated across hardware models. As a one-off user tweak, it’s fragile—adapter names and indices change, and your “fix” becomes a ghost story.

Conclusion: next steps that stick

“Route addition failed” is not a mysterious OpenVPN bug. It’s Windows refusing a route change for a reason: privilege, conflict, interface readiness, or policy. The fix that works is the fix that matches the failure mode.

Do this next:

1. Capture the exact failing route and the Windows status code from the OpenVPN log.
2. Prove route selection for one broken internal IP using Get-NetRoute or tracert.
3. Eliminate conflicts (overlapping routes, dual VPN adapters, stale persistent routes).
4. Standardize the privilege model: service-based VPN is dull and correct, and dull is underrated in production.
5. Coordinate with security tooling if manual route adds fail even when elevated.

If you adopt just one habit: stop treating “connected” as a success signal. Treat the route table as the source of truth. It’s not glamorous, but neither is spending your morning on a VPN ticket you could have closed in five minutes.