Issue with Openvpn 2.7 not releasing IP's from adaptors

[MINC-bot]

Describe the bug
Since upgrading to openvpn 2.7 we have an issue where systems are unable to correctly bind the IP address to an adaptor intermittently. We issue the same ip's to clients and have two remotes issuing separate subnets.

2026-03-06 08:53:11 us=390000 ovpn-dco device [OpenVPN Data Channel Offload #2] opened
2026-03-06 08:53:11 us=390000 do_ifconfig, ipv4=1, ipv6=0
2026-03-06 08:53:11 us=390000 INET address service: add 192.168.203.122/23
2026-03-06 08:53:11 us=390000 TUN: adding address failed using service: The object already exists.   [status=5010 if_index=18]
2026-03-06 08:53:11 us=390000 Setting IPv4 dns servers on 'OpenVPN Data Channel Offload #2' (if_index = 18) using service
2026-03-06 08:53:11 us=421000 IPv4 dns servers set using service

Windows IP Configuration

Unknown adapter OpenVPN Data Channel Offload #2:

   Connection-specific DNS Suffix  . : acme.com
   Description . . . . . . . . . . . : OpenVPN Data Channel Offload #2
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Autoconfiguration IPv4 Address. . : 169.254.18.175(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.1.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                       acme.com
                                       

Get-NetIPAddress | Where-Object {$_.IPAddress -like "192.168.*"}


IPAddress         : 192.168.203.122
InterfaceIndex    : 8
InterfaceAlias    : OpenVPN Data Channel Offload
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 23
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Tentative
ValidLifetime     :
PreferredLifetime :
SkipAsSource      : False
PolicyStore       : ActiveStore

So as it has no ip, no routes get added either

2026-03-06 08:53:11 us=687000 C:\WINDOWS\system32\route.exe ADD 10.0.0.1 MASK 255.255.255.255 192.168.202.1 METRIC 200
2026-03-06 08:53:11 us=687000 Warning: route gateway is not reachable on any active network adapters: 192.168.202.1

To Reproduce
It's intermittent but seems to be particularly bad coming out of sleep

Expected behavior
Tunnel to bind IP to virtual adaptor, routes to get added, traffic to route.

Version information (please complete the following information):

• OS: W11
• OpenVPN version: 2.7

[schwabe]

Please double check that the IP address is not on the old TAP Adapter on or some other adapter

[MINC-bot]

it's not you can see it in my log above, it's still on the "OpenVPN Data Channel Offload" which it should have removed, when coming up it's added a OpenVPN Data Channel Offload #2 and is trying to bind to that.

[cron2]

The bug would be "failing to remove it from OpenVPN Adapter 1" on disconnect (and it would be good to have evidence of this happening).

If you're already in that state, by whatever way things happened, OpenVPN will not be able to fix it - remove the IP address manually from adapter 1, and then OpenVPN should be fine configuring it on whatever interface it will use.

[MINC-bot]

I can manually fix it but it's happening frequently across hundreds of users, what evidence can I gather for you?

Is there a way for force re-use of the same adaptor in client config, we have no use for these dynamically created adaptors.
We use ipp to allocate the same IP's, which i've also commented out currently to hope a user gets another IP address and therefore doesn't fail to come up.

[cron2]

If it's happening frequently, you/we need to figure out why the IP address is stuck to one adaptor, and OpenVPN wants to use a different one (which usually means "something is still busy"). So are there crashes involved? Is the IP address sticking around after OpenVPN ends normally (it should fully clean up on program end, always).

[selvanair]

I can manually fix it but it's happening frequently across hundreds of users, what evidence can I gather for you?

A full verb=4 log that spans the connection before sleep and the one after where the adapter changes would help.