Error 0x800704CF — The Remote Device or Resource Won't Accept the Connection (Fix)

What This Error Means

Windows cannot access \OFFICEMACHINE\Share Error code: 0x800704CF The remote device or resource won't accept the connection.

Or on mapped drives after connecting a VPN:

\OFFICEMACHINE\Share is not accessible. 0x800704CF

This error almost exclusively appears when a VPN is connected. The exact cause is a routing conflict: Windows is trying to send traffic to the local network machine through the VPN tunnel, which routes it to the wrong destination — typically the VPN exit server rather than your local network.

The Root Cause: VPN Routing Conflict

When most VPN clients connect, they insert a default route that sends all traffic through the VPN tunnel. This is called full-tunnel mode. In full-tunnel mode:

Traffic to 192.168.1.45 (your office NAS) goes through the VPN
The VPN exit server has no idea what 192.168.1.45 is
The connection fails with 0x800704CF

Machines on your local LAN that you could access before the VPN connected become unreachable.

Fix 1 — Enable Split Tunnelling on the VPN (Recommended)

Split tunnelling tells the VPN client: "route traffic for my local network directly, not through the tunnel."

The configuration location varies by VPN client:

Windows built-in VPN:

Control Panel → Network Connections → right-click your VPN connection → Properties
Networking tab → Internet Protocol Version 4 (TCP/IPv4) → Properties → Advanced
Uncheck "Use default gateway on remote network"
Reconnect the VPN

This is split tunnelling for the Windows built-in VPN. Local network traffic now goes directly; VPN traffic goes through the tunnel.

OpenVPN: Add to the client config file (.ovpn):

route-nopull
route 0.0.0.0 0.0.0.0 vpn_gateway

Or set specific routes via the OpenVPN management interface.

Cisco AnyConnect, Palo Alto GlobalProtect, Fortinet FortiClient: Split tunnelling on these clients is configured server-side by your network administrator — the client policy must be updated to exclude local subnets. Contact your network admin to enable split tunnel with local LAN access.

WireGuard: In the [Peer] section of the client config, set AllowedIPs to only the remote subnets rather than 0.0.0.0/0:

AllowedIPs = 10.8.0.0/24   # Only VPN subnet, not your local network

Fix 2 — Add a Static Route for the Local Network

If you cannot change the VPN split tunnel configuration, add a persistent static route that forces local network traffic to bypass the VPN:

Find the IP address of your default LAN gateway (your router's IP — typically 192.168.1.1):
```
Get-NetIPConfiguration | Select-Object -ExpandProperty IPv4DefaultGateway
```
Find the interface index of your LAN adapter (not the VPN adapter):
```
Get-NetAdapter | Select-Object Name, InterfaceIndex
```

Add the static route (replace values with your actual subnet and interface):

New-NetRoute -DestinationPrefix "192.168.1.0/24" -InterfaceIndex [LAN_INDEX] -NextHop 192.168.1.1

This ensures traffic to your local network goes through the LAN adapter rather than the VPN. This route persists until the VPN disconnects.

Fix 3 — Verify the Office File Server Is Accessible Through the VPN

If the VPN is designed for remote access back to your office network, the file server should be accessible through the VPN — not separately. In this case:

The VPN should give you an IP address in the office subnet (e.g., 192.168.1.x)
You connect to the file server using its LAN IP through the VPN tunnel
No local LAN access is involved — you are connecting as if you were in the office

If this is your setup and it is not working: the issue is with the VPN server configuration, not the client. Check with your network administrator that the VPN server is advertising routes to the file server subnet.

Home/Remote Worker Scenario

If you are a home worker trying to access your office file share:

The correct setup is: VPN that connects to the office network → access file server through VPN (not direct local access to the office server from your home network).

Once your home machine VPN connects and receives an office-range IP, you should be able to type \\192.168.1.45\Share and connect through the tunnel.

If you are getting 0x800704CF in this scenario, the VPN connection itself is the problem — either it is not connecting fully or the server is not routing that subnet. Check the VPN connection status and that you are receiving a valid IP in the office range.

Done troubleshooting Windows?

Oxolan transfers files within the office without VPN conflicts. Installs in 2 minutes.

Get Oxolan for Windows

Frequently Asked Questions

The error disappears when I disconnect the VPN. Is that normal? Yes — that confirms the VPN routing conflict is the cause. With VPN disconnected, local network traffic routes normally. Apply Fix 1 (split tunnelling) to have both working simultaneously.

My IT department manages the VPN and will not enable split tunnelling. Any alternatives? The static route (Fix 2) works without VPN server changes. Add the static route each time you connect the VPN, or create a script that does it automatically.

This error appears for some colleagues on VPN but not others. Why? Different VPN client versions or different VPN profiles (different connection policies). The affected users likely have full-tunnel VPN configs while the unaffected users have split tunnel. Check the VPN client configuration differences.

Can Macs get this error? macOS does not use error code 0x800704CF but can have the same underlying VPN routing conflict. When a Mac with full-tunnel VPN cannot reach a local network share, the same split tunnelling fix applies in the VPN client settings.