Reach internal tools from home after the VPN is turned off

TL;DR — When the VPN is switched off, internal tools are usually reached through a browser-based access gateway protected by single sign-on (SSO, one login for multiple apps). The fastest fix is usually: open the app's new URL, sign in with your work account, and complete multi-factor authentication (MFA, a second proof like an authenticator code); if that fails, check that the app hostname points to the access gateway and that your account is in the allowed group. Reading time: ~5 min

Goal

When you finish, you will be able to open your internal tool from home in a web browser, sign in with your work account, pass MFA, and land on the tool without using the old VPN client.

Prerequisites

• Your work email address and password for your identity provider (IdP, the system that handles sign-in), such as Microsoft Entra ID, Google Workspace, or Okta
• Your MFA method ready: authenticator app, security key, or SMS if your organization still allows it
• The new internal tool URL, for example https://tool.company.example
• Access to your organization's password manager or onboarding email that lists internal tool links
• If you are an admin doing the fix for your team: access to your DNS provider dashboard and your access gateway dashboard
• A current browser: Chrome, Edge, Firefox, or Safari released in the last 12 months
• Optional, for command-line verification only: curl installed — check with:

curl --version

Steps

Step 1: Open the new tool URL in a private browser window

Use a private/incognito window first. This avoids stale cookies (saved sign-in data) from the old VPN-era setup.

Menu path:

• Chrome: ⋮ → New Incognito Window
• Edge: ⋮ → New InPrivate window
• Firefox: ☰ → New private window
• Safari: File → New Private Window

Then open the exact URL your team provided, for example:

https://tool.company.example

What you should see when this succeeds: a sign-in page from your company login system or an access page that says you need to authenticate.

Step 2: Sign in with your work account and complete MFA

On the sign-in page, enter your full work email address, then your password, then approve the MFA prompt.

Typical path in the browser:

• Enter email → Next → Enter password → Sign in → Approve MFA

If your company uses a launcher page, click the tile for the internal tool after sign-in.

What you should see when this succeeds: the browser returns to https://tool.company.example and the tool loads instead of the sign-in page.

Step 3: If you see "Access denied", confirm your account is in the allowed group

If you are the end user, send your admin this exact message:

Please check that my account is in the access group for https://tool.company.example and that the policy allows my email address.

If you are the admin, open your access provider dashboard and check the app policy. Vendor menus vary, but the path is usually:

• Access / Applications / Policies → tool.company.example → Allowed users or groups

Set the allowed identity to the exact group or user email already used by your organization, for example:

Allowed group: internal-tools-users
Allowed email domain: company.example

What you should see when this succeeds: after the user signs in again, the "Access denied" page is replaced by the app.

Step 4: If the page does not open at all, check the DNS record for the tool hostname

This is the most common admin-side issue after a VPN shutdown: the old internal-only DNS record still points to a private IP address instead of the access gateway.

In your DNS provider's dashboard (for example, in the DNS records area), open the zone for company.example and find the record for tool.

Use exactly one of these patterns, depending on your access provider's instructions:

Do not keep an old private-IP record like 10.x.x.x, 172.16.x.x to 172.31.x.x, or 192.168.x.x for a home-access URL.

What you should see when this succeeds: opening https://tool.company.example reaches a public sign-in page instead of timing out or trying to use the old VPN path.

Step 5: If the browser warns about the certificate, check that the hostname matches the app URL

A certificate warning usually means the browser reached the wrong service or an old origin server directly.

Admin dashboard path, usually:

• Access / Applications → tool.company.example → Public hostname
• Reverse proxy / Ingress / Routes → Hostname

Set the public hostname to the exact URL hostname:

tool.company.example

If your provider requires an origin target, set the internal origin exactly as documented by your team, for example:

http://internal-tool.service.local:8080

What you should see when this succeeds: the certificate warning disappears and the browser shows a normal lock icon for tool.company.example.

Step 6: Clear old browser state and retry once

If you used the old VPN recently, your browser may still hold cookies or cached redirects.

Use the browser's site-data controls for the exact hostname:

• Chrome/Edge: Settings → Privacy and security → Third-party cookies / See all site data and permissions → search for tool.company.example → Delete
• Firefox: Settings → Privacy & Security → Cookies and Site Data → Manage Data… → search for tool.company.example → Remove Selected
• Safari: Safari → Settings → Privacy → Manage Website Data… → search for tool.company.example → Remove

Then reopen a private window and go back to:

https://tool.company.example

What you should see when this succeeds: you get a fresh sign-in flow and then the tool opens.

[Home browser] ---- 1. GET tool.company.example ----> [Access gateway]
[Access gateway] ---- 2. redirect to sign-in ----> [Identity provider]
[Identity provider] ---- 3. password + MFA ----> [Home browser]
[Home browser] ---- 4. return with session ----> [Access gateway]
[Access gateway] ---- 5. proxy to app ----> [Internal tool]

Verify it works

End-user check:

• Open the tool URL in a normal browser window.
• Sign in.
• Confirm the page loads and you can click around without the VPN client running.

Admin checks:

curl -I https://tool.company.example

Expected result: one of these is normal before login:

HTTP/2 302
location: https://<your-idp-or-access-login-url>

or, if already signed in in that browser session:

HTTP/2 200

DNS check:

nslookup tool.company.example

Expected result: the answer is a public hostname or public IP, not a private IP like 10.x.x.x, 172.16-31.x.x, or 192.168.x.x.

Certificate check in the browser:

• Click the lock icon.
• The site identity should show tool.company.example with no certificate warning.

Common pitfalls

The DNS record still points to a private IP

Mistake: the hostname still resolves to an old internal address such as 10.0.0.25.

Symptom: from home, the page times out or never reaches a sign-in screen.

Fix: in your DNS provider, replace the old record with the public access-gateway target for tool.company.example.

The wrong DNS record type is used

Mistake: creating an A record when your access provider expects a CNAME, or vice versa.

Symptom: the hostname resolves, but the access gateway never serves the app correctly.

Fix: delete the wrong record and create the exact type your access provider specifies for that hostname.

The user is not in the allowed group

Mistake: the app policy only allows a group like internal-tools-users, but the user was never added.

Symptom: sign-in succeeds, then the user sees "Access denied".

Fix: add the user's account to the allowed group in the identity provider or access policy, then have them sign out and sign in again.

Cached cookies keep sending you to the wrong place

Mistake: reusing a browser session that still has old cookies from the VPN-era app or an old test hostname.

Symptom: redirect loops, repeated sign-in prompts, or landing on an error page after login.

Fix: delete site data for tool.company.example and retry in a private window.

The public hostname does not match the certificate

Mistake: publishing tool.company.example but routing it to a service that presents a certificate for a different name.

Symptom: the browser shows a certificate warning or privacy error.

Fix: set the application's public hostname to tool.company.example in the access gateway and wait for the certificate to finish issuing.

DNS changes were tested too quickly

Mistake: changing DNS and checking again immediately from the same network.

Symptom: one device works, another still fails, or results differ between browser and phone.

Fix: wait for the DNS TTL (cache lifetime) to expire, then retest in a private window or from mobile data.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.