Second VPN Client Broke the First One: Find the Shared Resource

Yesterday the original client worked. Today the newcomer claims a connection while the older profile stops at a stage it used to clear without complaint. Credentials are rarely involved, and the gateway is usually innocent. What changed is that two VPN stacks now want the same exclusive resource, and the repair depends on naming it. Walk the layers instead of reinstalling both.

Walk the four layers in order

A VPN product needs four resources that can collide: a background service that often refuses to run twice, a fixed port, a virtual adapter or kernel filter that sees traffic before the routing table does, and the right to install routes ahead of the default. Knowing which one gave way turns a vague conflict into a single question with a testable answer.

Map the symptom to a layer before touching anything. A client that will not start points at the service; one that starts and never negotiates points at the port; one that connects while the other loses all connectivity points at the filter or at the default route. Write that mapping down, because it saves an hour of reinstalling applications in hope.

Start at the service that will not run twice

On Windows a corporate client is usually more than a tunnel, because it installs a service, a filter driver and sometimes a credential provider alongside the profile. Record which services run before the change and again after it, then compare the two lists instead of rebooting until something works. Services can also exclude each other through dependencies, where starting one stops another, and the same pattern appears on macOS with launchd jobs and a shared daemon. A client that starts and exits within seconds is reporting ownership rather than configuration.

Read the service state and its log before you read the profile. A service that started and stopped inside the same minute is the pattern to look for, and its own event log names the dependency that displaced it. A profile cannot repair a process that is not running, and time spent editing one is time not spent on the actual conflict.

Then ask who owns the port

Port ownership is the clearest evidence you will get, because a bind failure names the conflict outright. Two IKE implementations cannot both answer on the same local address and UDP port, and no amount of retrying changes that.

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

Whichever line matches your platform, the answer you want is a process and the service that parented it. If the listener is the built-in IKE service, the second client is the intruder; if it is a vendor agent, the built-in client is. Decide which one may start at login and disable the other's autostart rather than killing it every session.

The filter driver sits below your routes

A network filter driver intercepts traffic between the adapter and the protocol stack, so it can rewrite or block packets no matter what the routing table says. That is how a route that looks correct gets ignored, and why a successful ping can sit beside a browser that cannot load anything.

Vendor components also bind to specific connections. A legacy filter bound to one adapter can stop an otherwise correct profile from finishing its handshake, and unbinding that component from the adapter's properties is narrower and more reversible than removing the product entirely. Because the binding is per connection, compare the adapters rather than the whole stack.

Decide which product owns boot, then record it

Coexistence is realistic only when the two clients occupy different layers by design, such as an IPsec stack beside a proxy that handles application traffic alone. Where both want the same port, the same filter layer or the right to publish a default route, they will keep taking turns and each failure will look like a new fault.

Pick the owner deliberately. Shapes that survive a reboot include running the second client inside a virtual machine, keeping it on dedicated hardware, or standardising on one client that speaks both protocols. Disabling the loser's autostart and service is a smaller change than rebuilding the routing table after every start, and it reverses in one settings edit.