Host VPN or a client inside Genymotion: decide which owns it

A desktop VPN affects Genymotion in two places, and fixing one proves nothing about the other. The first is the connection the desktop app uses to control the virtual device; the second is the virtual Android app's path to a private service. Decide which of those you are actually changing before you touch an adapter, then record the Genymotion Desktop version, the host OS and the hypervisor, because guidance written for a VirtualBox host-only adapter does not transfer to a QEMU device or to a cloud-hosted session.

Two paths on one machine

The control path runs from the Genymotion desktop application to the virtual device, often over a host-only network. The application path runs from inside Android out to whatever the app talks to. A host VPN can carry the second and break the first, which is why a working browser on the desktop means very little. One tunnel can serve both paths or only one of them, and that arrangement is a decision rather than an accident.

Write down which path you are troubleshooting. Most of the wasted hours in this area come from changing private-app DNS when the device never launched, or from relaxing the host VPN when the app simply had the wrong resolver.

Keep the control connection alive

Genymotion's own Desktop support note documents a VirtualBox case: once a host VPN is up, Desktop can no longer see the virtual device, and the exception that matters is the real host-only adapter listed in VirtualBox's network manager. Enumerate those adapters instead of guessing a range:

VBoxManage list hostonlyifs

A default range printed in documentation is no excuse for a blanket private-network bypass across every machine. Add the smallest exception that covers the adapter in use, and get the VPN administrator to approve it, since a managed client may block the local network on purpose. Write the exception down with the adapter name and the approval date. Six months later that note is the only thing that explains why the rule exists.

The same note says the QEMU combination is untested with a VPN. Treat that as a compatibility limitation rather than a hint that switching to bridged networking will repair it; changing the adapter changes the failure, it does not resolve the untested combination.

Option A: let the host carry the traffic

With this choice the guest's packets must arrive at an interface the VPN both permits and encrypts. That is a routing question, not a status-light question: the guest's packets need to arrive at an interface the VPN will encrypt, and the replies need to find their way back.

A browser on the host proves the host's path and nothing about whether a virtual-device source is accepted. Some VPN clients treat forwarded or translated traffic differently from locally generated traffic, so test from inside Android before concluding the tunnel works. Android's resolver is not the host's resolver either. If names resolve on the desktop and fail in the app, read the guest's resolver configuration before you touch the VPN profile.

Option B: run a supported client inside Android

Here the guest holds its own profile, credentials, routes and resolver policy. The ordinary Android VPN APIs need no root access, so a standard client installs and connects inside the virtual device. Approval is the part people skip. The organisation must permit that client and that virtual-device environment, and a clean import does not by itself meet device-enrollment or posture checks. Ask before you build a workflow around it.

The two choices can also stack: a tunnel inside Android may reach its server through a tunnel already running on the host. That arrangement needs a reachable endpoint and forwarding you actually permitted, not two green lights that happen to be on together.

Verify from the app and write down the arrangement

Use the same Android app for every test and read what it reports: whether the address answers, whether the private name resolves, and what the application returns. Three observations separate a routing failure from a resolver failure from a policy rejection.

When the device fails to launch, or Desktop loses it, treat that as a control-path fault rather than a DNS fault. That symptom belongs to the first path, and the fix is on the host, not inside Android. Finish by recording four facts: Genymotion Desktop version, hypervisor, which side owns the tunnel, and the exact host-only exception if one was added. Choose a documented arrangement the network owner supports, and do not treat disabling an enterprise VPN or weakening posture checks as neutral troubleshooting when the private service relies on them.