Remote Employee unable to connect organization internal network via VPN

Remote Employee Unable to Connect to VPN: Solving Network Overlap Issues

The Problem:

A few weeks ago, I had a remote employee unable to connect to our organization's VPN. She could establish the VPN tunnel successfully, but once connected, she couldn't access any internal resources. From her perspective, the VPN was "working" but nothing on the corporate network was reachable.

This is one of those frustrating issues where the technology appears to be functioning correctly on the surface, but application-level connectivity just doesn't work.

Initial Investigation:

I gathered the basic information from the user and started checking her home network configuration. That's when I discovered the root cause: her home network was using the same IP address range as our organization's internal network.

The Issue: Network overlap created routing ambiguity. Her computer didn't know whether to send traffic to her local home network or through the VPN tunnel to reach the corporate network.

Why This Happens:

Many home routers default to common private IP ranges like 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. If your organization uses the same range internally, you create an overlap scenario.

What the Computer Sees:

Home Network: 10.0.0.0/8 (Local Interface)
Corporate Network: 10.0.0.0/8 (VPN Interface)

Destination: 10.1.1.128
Question: Which interface should I use?

Answer: Without specific routing, the computer chooses
based on administrative distance and existing routes,
often selecting the wrong interface.

The computer had no clear way of knowing where to send traffic. Administrative distance and routing tables provided conflicting information, resulting in traffic being sent to the local network instead of through the VPN tunnel.

The Solution:

Rather than asking the user to reconfigure her entire home network (which would affect all her devices), I created a persistent static route on her Windows machine that:

1. Was only active when the VPN interface was connected
2. Had a lower administrative distance than the default route
3. Pointed specifically to the corporate resource she needed
4. Routed through the VPN gateway

The Command:

On her Windows machine, I ran:

route -p ADD 10.1.1.128 MASK 255.255.255.255 10.10.254.254 METRIC 1 IF 38

Command Breakdown:

• route -p → Creates a persistent route (survives reboots)
• ADD 10.1.1.128 → The destination IP address (corporate resource)
• MASK 255.255.255.255 → Host-specific route (/32, only this one IP)
• 10.10.254.254 → Gateway (VPN endpoint on her side)
• METRIC 1 → Low metric = higher priority than default routes
• IF 38 → Interface index (VPN interface ID)

Finding the Interface ID: You can find the interface index by running:

route print

This displays all interfaces with their corresponding index numbers.

Additional Configuration:

I also disabled the "Use default gateway on remote network" option in her VPN client settings. This prevented all of her traffic from being routed through the VPN (split tunneling), which would have:

• Slowed down her internet browsing
• Increased load on our corporate network
• Created unnecessary bandwidth consumption

By disabling this option and using a specific route, only traffic destined for 10.1.1.128 goes through the VPN, while all other traffic uses her regular internet connection.

Result:

• ✓ Employee successfully connected to the required corporate resource
• ✓ VPN tunnel remained stable
• ✓ No need to reconfigure home network
• ✓ Other home devices unaffected
• ✓ Regular internet traffic unimpacted

Alternative Solutions:

If you encounter this issue frequently, consider these approaches:

1. Change Home Network Addressing:

# If corporate uses 10.0.0.0/8
# Configure home router to use 192.168.x.x instead

This requires reconfiguring the home router and all static IP assignments

2. Use VPN Client Auto-Routes:

Many enterprise VPN clients (Cisco AnyConnect, Palo Alto GlobalProtect, etc.) support automatic route injection for specific subnets.

3. Corporate Network Redesign:

If possible, use less common private address space for corporate networks to minimize overlap risk:

• Instead of 10.0.0.0/8, use 10.200.0.0/16
• Instead of 192.168.0.0/24, use 192.168.200.0/24

Verifying the Route:

After adding the persistent route, verify it's working:

# Display routing table
route print

# Test connectivity to the specific host
ping 10.1.1.128

# Trace the route to confirm it's using VPN
tracert 10.1.1.128

Removing the Route (If Needed):

If you need to remove the persistent route later:

route DELETE 10.1.1.128

Common Scenarios Where This Occurs:

• Remote work from home (home router defaults conflict with corporate)
• Hotel or public WiFi (guest networks using common ranges)
• Coffee shops (business WiFi using 10.0.0.0/8)
• Mergers & acquisitions (two companies with overlapping IP schemes)
• Branch office VPN (branch office and HQ using same private range)

Key Takeaway:

When VPN connects but resources are unreachable, check for network overlap first. Overlapping IP address ranges between local and remote networks create routing ambiguity that prevents proper connectivity.

A targeted static route with a lower metric can solve the problem immediately without requiring network reconfiguration on either end.

Prevention Tips:

1. Use unique address space for corporate networks (avoid common defaults)
2. Document your IP scheme and communicate it to remote workers
3. Provide VPN client configuration guides that include routing instructions
4. Implement automatic route injection in your VPN solution where possible
5. Test from various network types (home, hotel, coffee shop) before deployment

Related Topics: VPN Troubleshooting, Network Routing, Windows Networking, Remote Access, IP Addressing, Split Tunneling