General failure pinging a LAN address with the VPN client on
Windows says it cannot reach an adapter at all while the route table looks correct. Decide whether the block is routing, filtering or the client.
One host route, one address, and the ping fails immediately with General failure instead of the request timing out. That distinction is the whole diagnosis. A timeout means the packet left and something ignored it. General failure means Windows could not hand the packet to any interface in the first place.
So when the route table looks perfect and the error is still General failure, the block is happening below the routing decision, and the provider's client is the thing that operates there.
Read the error before the route table
Windows returns that error when it cannot find an interface to send on, and it says nothing about what the destination would have done with the packet. Reachability, firewalls at the far end and service availability are all downstream questions you have not reached yet.
The classic configuration for this case is a host route pointing a single LAN address at the physical gateway so it bypasses the tunnel. route add accepts it, route print displays it, and the ping still fails, because the filter driver has already decided the packet is not allowed out.
Before you accept that explanation, confirm the route is actually being selected: check the interface index and the metric, and make sure the entry is not stale after a reconnect. A route that points at an interface that no longer exists produces a similar error for a much less interesting reason.
Three layers, three different owners
The layer that wins is the one that runs last, and these three are not in the order most people assume.
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
The middle layer is why a route can be simultaneously correct and useless. Provider clients install a filter and firewall rules so that traffic outside the tunnel is dropped, which is the same mechanism that implements their kill switch. Nothing in the route table participates in that decision.
The third layer explains an odd report that arrives regularly: the local subnet is unreachable even after the client is disconnected. The service is still running and the filter is still installed, so not connected is not the same as not filtering. Exit the client rather than merely disconnecting it before you conclude anything.
What to try, in order
Start by removing the features that are cheap to remove and easy to restore. LAN discovery, sometimes called invisibility on the LAN, blocks traffic to private address ranges so the machine stays hidden from its neighbours. Printers, local file servers and the router itself all vanish behind that switch. Threat protection features that filter DNS install their own hooks and are reported to break local reachability in much the same way.
Turn both off, exit the client completely, then test the address. That sequence separates a feature that is blocking traffic from a tunnel that is routing it wrongly, and it takes two minutes rather than an afternoon of static routes.
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4If the address answers once the features are off, you have a policy decision rather than a fault: choose between leaving the feature off, adding an exception, or accepting that the machine stays invisible on the local network.
Use the client's exception path, narrowly
When a feature has to stay enabled, the client's own split tunnelling is the supported escape. Keep the exception as small as the requirement allows, which usually means one host address for one server or one prefix for a single segment. A rule covering an entire private range is a permanent hole that nobody will remember adding and nobody will dare remove.
Then verify by address first and by name second. If the address replies with a first hop on the physical gateway, the exception works. If the name still fails, you have moved to DNS, because the tunnel's resolver does not know the local zone and no routing change will teach it.
Keep the route or the exception, not both, plus a note about which one is doing the work. Two overlapping mechanisms hide each other, and the next person to debug this machine will remove one of them and see no change.
When the client is the obstacle
Some builds filter traffic in ways that neither a static route nor a client exception can defeat. When that is the finding, the honest options are to wait for the bypass feature or to connect with a plain OpenVPN client using the provider's own profile, which is what the vendor support response in the original report recommended.
Understand the trade before making that substitution. A plain profile behaves like any ordinary tunnel: it installs its routes and does not restructure the rest of the stack, so a narrow host route still behaves the way you expect. What you lose is everything the branded client implemented around the tunnel, including the kill switch and DNS filtering, and those have to be reproduced deliberately or accepted as absent.
Whatever you choose, record which layer owned the block. A packet that never left the machine is a filter result, and no routing change can repair a filter.