Case 4: VPN Connects But No Internal Routing

During a remote triage session, an engineering contractor reported that their corporate VPN interface showed an active Connected status with an assigned virtual IP address. Despite the verified transport tunnel, every attempt to reach internal development repositories, staging clusters, and intranet dashboards failed immediately with request timed out and destination host unreachable errors. The previous technician had simply cycled the local virtual adapter and reinstalled the client package without recording the underlying route table state.

Detailed diagnostic inspection revealed that while the virtual TAP adapter received an IP within the 10.240.12.0/24 subnet, the client operating system failed to inject the required classless static routes for the corporate 172.16.0.0/12 data center subnets. Furthermore, a local home router subnet on 192.168.1.0/24 conflicted directly with a secondary lab subnet, causing outbound enterprise traffic to drop silently into the local home gateway default route.

Examining the local route table through route print output exposed two distinct anomalies operating in tandem. The client workstation had assigned an interface metric of 45 to the VPN virtual TAP device, while the local wireless interface held a metric of 25. Because split tunneling was configured without overriding the default gateway, traffic bound for private corporate subnets evaluated the higher-priority physical gateway path instead of routing through the tunnel.

In addition, the tunnel gateway profile lacked DHCP Option 121 classless static route instructions for auxiliary subnets. Once the client configuration profile was updated on the gateway and the local routing table re-evaluated, internal hosts became instantly reachable with an average ping latency of 18ms. Recording both the initial route dump and the final metric script prevented incoming shift technicians from repeating unneeded client reinstallations.