What causes error 0x800704CF?

A routing conflict: when a VPN is connected, its adapter often captures traffic meant for the local network, so Windows sends your file-share request into the tunnel where the share is not reachable. The share looks "gone" even though the machine is on the same desk.

How do I fix 0x800704CF when using a VPN?

Preferred: enable split tunnelling in the VPN client so local-subnet traffic bypasses the tunnel. Alternative: add a static route for your LAN subnet with a lower metric ("route add" with the local gateway). Or disconnect the VPN when you need LAN shares.

Can I avoid VPN routing problems for office file transfers?

Yes — transfer over an app that talks directly between machines on the LAN instead of through Windows shares. Oxolan discovers peers on the local network and moves files over its own encrypted channel, which does not collide with VPN routing the way SMB paths do.

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