FortiClient VPN Connected but Cannot Access Internal Network

FortiClient says Connected, but the intranet still will not load. Start with one internal application, its expected IP address, and its real service port. Compare Windows routing and DNS with what FortiGate sees for that same connection. This guide focuses on Windows 11 and FortiGate dial-up IPsec remote access.

1. Test the application by IP and name

The example uses 10.20.30.40 for an HTTPS application and payroll.corp.example for its name. Replace both with values from your own network. Record the FortiClient version, assigned VPN address, exact test time and time zone, and whether another user on the same profile can reproduce the symptom.

Test-NetConnection -ComputerName 10.20.30.40 -Port 443 -InformationLevel Detailed
Resolve-DnsName -Name payroll.corp.example -Type A -DnsOnly
Test-NetConnection -ComputerName payroll.corp.example -Port 443 -InformationLevel Detailed

Read TcpTestSucceeded and RemoteAddress. If TCP works by IP but the name fails or resolves to an unexpected address, investigate DNS first. If both TCP tests fail, check the selected route and firewall path. If both TCP tests succeed and the browser still fails, inspect the application response, TLS certificate, proxy settings, and authentication. A TCP test can succeed even when the application rejects the request.

2. Confirm Windows selects the VPN route

Find-NetRoute -RemoteIPAddress 10.20.30.40
Get-NetIPConfiguration

Check the selected interface, source address, and destination prefix. If the route goes through Wi-Fi or Ethernet, verify that the split-tunnel configuration includes the exact internal prefix and that the endpoint received it. Compare the selected route with a working client. A local network can advertise an overlapping prefix, and a more-specific route can take precedence over the VPN route. Retest from an approved network with a different address range to isolate overlap.

If the client did not receive an expected VPN address, review the assigned address pool and client logs before changing access rules. A 169.254.x.x address on an unexpected adapter can suggest an address assignment issue. Check the VPN adapter and actual source address used by the test.

3. Check split DNS and resolver reachability

Get-DnsClientServerAddress -AddressFamily IPv4
Find-NetRoute -RemoteIPAddress 10.20.0.53
Resolve-DnsName -Name payroll.corp.example -Server 10.20.0.53 -Type A -DnsOnly

The example resolver is 10.20.0.53. If the direct query returns the expected address and the default lookup fails, check the VPN DNS assignment and split DNS domain matching. If the direct query times out, verify the route and access policy between the VPN address pool and the DNS server. If the server answers with an unexpected record, validate the record and the resolver view. Repeat for AAAA if the application publishes IPv6 records.

4. Match the test connection to FortiGate logs

In FortiGate forward traffic logs, filter by the assigned VPN address, destination, service, and test timestamp. Check the action, matched policy, egress interface, and any source translation. For a deny, review whether the approved VPN group or pool, destination object, and service match the intended policy. If no log appears, check logging and the source address you actually used before assuming traffic never reached the firewall.

If FortiGate accepts the request but the client receives no reply, confirm the service is listening and check the return route from the destination network toward the VPN address pool. If source NAT is in use, trace the address seen by the destination. Compare the relevant tunnel counters before and after the test. Rising TX with flat RX narrows the investigation to the missing inbound traffic. Counters may also include unrelated sessions, so correlate them with the traffic log.

Worked example: The application works by IP but not by name

A Windows client reaches 10.20.30.40 on TCP 443. The system lookup for payroll.corp.example fails, but an explicit query to 10.20.0.53 returns 10.20.30.40. The network path and resolver can handle this test. Review the split DNS settings for corp.example and verify that the client receives the corrected profile. Reconnect, repeat the default lookup, then open the application by its intended hostname and confirm that the certificate and sign-in work.

Related guides and references

For the VPN configuration, see our FortiGate IKEv2 remote access CLI guide. See also Fortinet’s IPsec split DNS guide and Microsoft’s Test-NetConnection reference.