A remote employee sees “VPN connected,” but the company portal, file server, or ticketing tool will not open. The tunnel indicator confirms that the client established a VPN session; it does not prove that the right internal routes, DNS settings, identity permissions, or application services are available.
Remote access adds layers that office users may not encounter. The VPN may install routes, assign DNS servers, apply device posture checks, and place the user into a policy group. Split tunneling can also send some traffic through the home internet connection while other traffic enters the corporate network. A successful tunnel can therefore coexist with a failed application path.
Record the user, device, VPN gateway, connection time, application name, and exact error. Test whether other internal apps work and whether coworkers on the same VPN are affected. If an app works by address but not by name, DNS becomes a strong lead. If no internal destinations work, check routes, client configuration, and identity or posture policy.
After the cause is corrected, test the same application by its normal hostname from the affected VPN session. Confirm the expected internal resources are reachable, unrelated traffic still follows the intended split-tunnel policy, and a second authorized user can connect if the fix was shared.
The status indicates that a tunnel was negotiated with a gateway. It may also show that the user passed an initial authentication step. It does not confirm that every internal subnet is routed to the client, that DNS uses the right resolver, or that the application’s access policy allows this identity and endpoint.
Include the VPN gateway, assigned address, DNS servers, relevant routes, device posture result, user group, application name, and exact time. This lets the access team compare the failing session with a working one without asking the user to reconnect repeatedly.
Keep VPN client versions, address pools, DNS behavior, split-tunnel routes, and access groups documented. Include internal app checks in remote-access monitoring and test key services after gateway or policy changes. Give users a short checklist for capturing the VPN status, application error, and time of failure.
Start by separating what the VPN client reports from what the user can reach. A successful tunnel usually confirms that authentication and at least part of the secure session setup completed. It does not prove that the client received the intended routes, that the application name resolves to the right address, or that policy permits the flow. Record the client’s assigned address, the application’s resolved address, the route selected for that destination, and the time of a failed test. These details make the remote path reproducible.
Compare the route table before and after connecting, using the client’s supported diagnostic tools. If the application subnet is absent, the issue may involve route distribution or split-tunnel policy. If a route exists but points through the wrong interface, look for overlapping home and corporate address ranges. A home router using the same subnet as the company can make a destination appear local, so packets never enter the tunnel. Avoid changing routes manually unless your organization’s support procedure allows it.
If the address is reachable but the service is not, test the required port and protocol from the remote client and compare the result with an office test. Check whether the VPN policy, internal firewall, or application access list expects a different source range for remote users. Also verify that the VPN assigns the right DNS servers and search suffixes. A browser may fail by name while a direct address test works, or a cached record may send the user to a retired server.
Work through the application’s dependencies as well as its main server. Sign-in may rely on identity services, databases, licensing systems, or a cloud endpoint that is not included in the tunnel routes. Ask whether the problem affects one application, one subnet, or all internal services, then compare a successful remote user on the same VPN gateway. Retest after any policy change from a fresh VPN session, and confirm both name resolution and the full user workflow rather than relying only on a ping.
The most useful comparison is often between two users on the same VPN gateway. If one can reach the service and one cannot, compare their assigned address pools, group policies, device posture, and routes. If both fail, compare the gateway’s reachability to the application subnet and check for a shared route or firewall change. Make sure the successful user is opening the same host and port; applications may have several front ends that make a casual comparison misleading.
Keep the scope narrow when troubleshooting a remote-access policy. A temporary broad route or permissive rule may make the test pass while exposing traffic that should remain outside the tunnel. Ask the VPN or security owner to confirm the intended access design, then compare policy logs with the exact source and destination. If a test requires a policy exception, document it, limit its scope, and remove it after verification unless it is approved as a permanent change.
For a durable resolution, test after disconnecting and reconnecting so the client receives fresh routes and resolver settings. Confirm that the service works by the expected internal name, that related sign-in dependencies are reachable, and that general internet browsing still follows the intended tunnel or split-tunnel policy. A short follow-up with the user can reveal failures that do not appear in a technician’s command-line checks.
Treat the VPN indicator as one piece of evidence. Follow the application’s DNS, route, access policy, and return path, and compare with a working remote session before changing shared settings.
Does “VPN connected” mean all company applications should work?
No. It confirms that the VPN session is established. DNS, routes, identity permissions, device posture, firewall policy, and the application itself can still prevent access.
Why does an internal app work by IP address but not by name over VPN?
The VPN client may not be using the internal DNS server or search suffix. Check the resolver assigned to the session and whether split DNS is configured for that internal domain.
Could my home network cause the problem?
Yes, especially if the home network uses the same IP subnet as the company network. The client may route internal traffic locally instead of through the VPN. Compare routes and subnet ranges before changing them.
What is the safest first comparison?
Compare the failing session with a known-good VPN user on the same gateway. Check the assigned address, routes, DNS servers, client version, identity group, and posture result.
Join the discussion: What would you check first: DNS, routes, or access policy?
For hands-on practice with real network troubleshooting, explore training with Atmic Networks.
SEO title: VPN Connected. Internal Apps Unreachable. Where Do You Start?
Meta description: VPN connected but internal apps will not load? Follow practical checks for DNS, VPN routes, split tunneling, access policy, and application availability.
Focus keywords: VPN troubleshooting, VPN connected but no access, internal applications, split tunnel
URL slug: vpn-connected-internal-apps-unreachable
