OpenVPN adapter flapping on Windows? Check for a duplicate IP

On Windows, an OpenVPN adapter that takes an address, drops it, and repeats every few seconds usually is not a DHCP bug. The adapter is being told to use an address that something else already answers for, so Windows marks it unusable and the client starts over. The client log stays quiet because the conflict is resolved below it, inside the operating system's own network stack.

That distinction matters, because every troubleshooting step aimed at the tunnel configuration will miss a duplicate address on the server side.

Start with the Windows event log, not the client log

Windows records address conflicts in the System log, with event IDs 4198 and 4199. The first reports a conflict detected for an address, the second reports that an interface could not use the address it was configured with. Neither mentions OpenVPN, which is exactly why they are easy to overlook.

Pull the recent events and compare their timestamps with the adapter's renew cycle: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. A conflict every fifteen seconds matches a client retrying the same address against an owner that keeps answering for it. A single conflict at connect time points at a one-off collision instead. Either way, the next question is who else holds the address.

Three arrangements put two hosts on one address

Ask the server who it thinks holds the address, then ask the network who answers for it. grep -H ifconfig-push /etc/openvpn/ccd/* lists every pinned tunnel address and the certificate it belongs to. ip -4 neigh show dev tap0 shows what the bridge has learned at layer two. Comparing those two lists finds most duplicates in under a minute.

Three arrangements account for nearly all of them: a client-config-dir entry pins one address for two certificates, a bridged tap segment hands a machine an address another host already has statically, or a stale lease file returns an address that a still-connected client believes it owns. The third case is the sneakiest, because ifconfig-pool-persist deliberately reuses addresses for known clients.

Make the address unique instead of racing for it

Boot order only decides who wins today, so treat any fix based on restart sequence as temporary. Give each client its own ifconfig-push line, or allocate static addresses from a range no bridge or server interface touches. Audit the client list for duplicate common names as well, since duplicate-cn lets two sessions share one identity and therefore one pinned address. If a bridged device truly needs a fixed address, move it to its own subnet or reserve it from the pool in a place the server records.

Delete the persist file only after you know which leases it holds, or the next reconnect will hand out the same addresses again.

Restart in the right order and confirm one owner per address

Apply the change on the server first, then reconnect the clients, so every participant registers against the corrected pool. Restarting clients first leaves them holding addresses the server still believes are taken. After the restart, read the status file and confirm each common name appears once with one address. Two entries for one name mean an old session never closed, not that the pool is broken.

If a client still cannot keep its address, check whether a bridge interface on the same host carries it. A bridge that inherited an address from a vendor device will answer ARP for it even when the VPN server has handed that address to a client.

Watch past a full renewal cycle before closing the ticket

One clean reading proves nothing. Watch the adapter for at least ten minutes and force a reconnect in the middle: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. The address should survive the reconnect and stay in a preferred state.

Then re-run the event query from the first step and confirm it returns nothing new. A quiet log across a reconnect is the evidence that the conflict is gone, while a quiet log after a single connect only means the race has not happened yet. Finally, test the resource the tunnel exists for, because a bridge that lost its address can break a vendor path while the VPN itself looks healthy.

Record the pool range, each pinned address and the host that owns it in the server notes. The next collision then takes minutes to spot instead of an afternoon to rediscover.