How to Fix a RemoteApp Connection That Fails on Home Wi-Fi but Works on a Hotspot

A RemoteApp connection that fails on home Wi-Fi but works on a hotspot can be confusing because the VPN often appears to connect successfully. In this case, the issue was not the laptop itself or the RemoteApp platform. The root cause was DNS resolution on the customer’s home internet after their ISP router upgrade.

A common sign of this issue is that the RemoteApp fails while connected to home Wi-Fi and VPN, but works when the same laptop is connected to a mobile hotspot while still using the VPN. That pattern strongly suggests a network or DNS issue on the home connection rather than a problem with the application itself.

For businesses relying on stable remote access, issues like this are exactly why structured IT support, secure remote access design, and proper network troubleshooting matter.

Quick Summary

• Issue: RemoteApp fails to open on home Wi-Fi while connected to VPN
• Symptom: Error 0x104 appears when launching the RemoteApp
• Important clue: The same laptop works when switched to a mobile hotspot and kept on VPN
• Root cause: DNS was not pointing to the correct internal RemoteApp DNS server first
• Fix: Set the primary DNS to the correct internal DNS server and use 8.8.8.8 as the alternate DNS if required

Direct Answer

If a RemoteApp only fails on a customer’s home Wi-Fi but works on a hotspot while still connected to VPN, the problem is often DNS. In this case, the fix was to point the preferred DNS server to the correct internal DNS server, then set the alternate DNS server to 8.8.8.8. Once the DNS order was corrected, the RemoteApp connection worked normally.

Common Signs of This Issue

You may be dealing with this issue if you notice any of the following:

• The VPN connects successfully
• The RemoteApp still fails with 0x104
• The RemoteApp host can be pinged by IP address
• The problem happens only on the customer’s home internet
• The same laptop works when changed to a mobile hotspot
• nslookup for the RemoteApp hostname fails or times out

These signs point away from a general VPN failure and more toward hostname resolution or DNS path problems.

Why This Happens

RemoteApp connections often rely on hostnames rather than direct IP addresses. Even if the laptop can reach the destination by IP and the VPN is connected, the application can still fail if the required hostname does not resolve correctly.

In this case, the home connection had been upgraded recently, including a new ISP router. After that change, DNS resolution was no longer working correctly for the RemoteApp path. Public DNS alone was not enough because the RemoteApp needed the correct internal or environment-specific DNS server to resolve properly.

Osmicro Resolution Process

Our standard process for this type of issue is:

1. Confirm whether the VPN connects successfully
2. Confirm whether the issue only happens on one internet connection
3. Test whether the RemoteApp host can be reached by IP
4. Test DNS resolution for the RemoteApp hostname
5. Review current DNS settings on the laptop
6. Set the correct internal DNS server as primary
7. Retest the RemoteApp connection

Step 1: Confirm the Pattern

Start by confirming whether the problem is specific to the customer’s home internet.

Check the following:

• On home Wi-Fi + VPN, the RemoteApp fails
• On mobile hotspot + VPN, the RemoteApp works

If the app works on hotspot but not home Wi-Fi, the issue is most likely tied to the home router, ISP path, or DNS configuration rather than the laptop itself.

Step 2: Confirm Basic Connectivity

Before focusing on DNS, confirm that the laptop can still reach the RemoteApp environment.

Useful checks include:

ping <RemoteAppHostIP>

If the host responds by IP, that tells you the VPN and basic routing are working. It does not confirm that DNS is working properly.

Step 3: Test DNS Resolution

Next, test whether the required hostname can be resolved.

Example:

nslookup <RemoteAppHostname>

If the result times out or cannot resolve the server, that is a strong sign the laptop is not using the correct DNS server for the RemoteApp environment.

This was the key clue in the troubleshooting process. The laptop could reach the host by IP, but it could not resolve the RemoteApp hostname properly.

Step 4: Review Current DNS Settings

Check the adapter configuration:

ipconfig /all

Review the following:

• DNS Servers
• Connection-specific DNS suffix
• Whether the Wi-Fi adapter is using public DNS only
• Whether the VPN or internal DNS server is being applied correctly

If the laptop is only using public DNS, internal RemoteApp hostnames may fail to resolve.

Step 5: Correct the DNS Order

Update the DNS configuration so that:

• Preferred DNS server: internal or RemoteApp DNS server
• Alternate DNS server: 8.8.8.8

This ensures internal names are resolved correctly first, while still allowing a fallback for public lookups if needed.

In this case, once the primary DNS was changed to the correct internal DNS server and the alternate was set to 8.8.8.8, the issue was resolved.

Step 6: Retest the RemoteApp

After updating DNS:

1. Disconnect and reconnect Wi-Fi if required
2. Reconnect the VPN
3. Launch the RemoteApp again

If the issue was caused by DNS, the RemoteApp should now connect successfully.

Important Notes

Reaching the server by IP does not rule out DNS

This is an important point. A successful ping to the RemoteApp host IP only proves routing is working. RemoteApp can still fail if the connection depends on a hostname that is not resolving correctly.

Public DNS should not be the primary DNS for internal app resolution

If the environment uses internal-only names, the internal DNS server should stay first. Public DNS can be used as a fallback, but it should not replace the correct internal DNS path.

ISP and Router Changes Can Trigger This Issue

If the problem begins right after a home internet upgrade or new modem installation, that is a strong clue that DNS behaviour has changed.

If the Fix Does Not Work

If the issue continues after correcting DNS, check the following:

• Whether the RemoteApp uses a short hostname instead of a full FQDN
• Whether the VPN is correctly pushing DNS suffixes
• Whether IPv6 is affecting DNS behaviour on the home connection
• Whether the router has security, filtering, or inspection features interfering with traffic
• Whether the RemoteApp is using an RD Gateway or additional hostname not yet tested

For businesses dealing with ongoing remote access issues, it is also worth reviewing the wider environment, including managed IT, IT infrastructure, and secure remote connectivity design.

Final Thoughts

This type of issue can look like a RemoteApp or VPN fault at first, but the actual cause is often DNS. In this case, the laptop could connect to VPN and reach the target by IP, but the RemoteApp still failed because the correct hostname was not being resolved on the home connection.

Once the primary DNS was set to the correct internal DNS server and the alternate DNS was set to 8.8.8.8, the RemoteApp started working again.

If your team depends on RemoteApp, VPN, or other business-critical remote access systems, getting the DNS path right is just as important as the VPN itself.