My roaming client will not activate and ... [My roaming client series]

Overview

Welcome to the "my roaming client" series of knowledge base article. This series provides an interactive series of questions in response to common roaming client challenges.

This article is targeted at the scenario where the roaming client is unprotected or an undesired mode. This includes failure to register, failure to protect, or failure to enter a protected network mode. Just looking for a primer of what to expect with the roaming client, click here?

The "My Roaming Client Series" Index:

1. My roaming client will not activate and....
2. My roaming client says "Protected" but....

Explore the possibilities in each subsection below, by filling in the blank of "My roaming client will not ___________":

Register, it remains "unknown, unknown"

When the roaming client fails to register, the GUI state will remain "unknown" with a red status. There are several causes of this, all of which have solutions as follows:

1. A proxy server is in place, but not defined for the SYSTEM user. The roaming client connects as the SYSTEM user, so if a proxy is required but not defined here, the client will fail to register. See our "Using the roaming client with a proxy" guide. 
2. No proxy server is defined, but a proxy server remains configured from an old configuration to the SYSTEM user. This will need to be cleared for the client to register successfully. See our "Using the roaming client with a proxy" guide. 
3. No SYSTEM proxy server is configured, but there is an old proxy configured (see netsh winhttp show proxy). The roaming client utilizes the .NET framework, and HTTPS calls pull certificates with the .NET Crypto API v2, which will check many possible locations for a proxy server, and use that first! See our "Using the roaming client with a proxy" guide. 
4. Our registration server is not accessible. Please ensure that api.opendns.com is accessible over TCP port 443 for registration. See our roaming client prerequisites page for details.
5. You are missing the registration data. Ensure that the registration details passed during installation are correct. Where do I find this registration data?
6. The firewall restricts unauthenticated accounts (like the SYSTEM account) from accessing the necessary sites. Since the roaming client calls out registration from the SYSTEM user account, this must be opened up for our prerequisites for registration. 
7. None of the above or unsure? Contact our support team at umbrella-support@cisco.com and we'd be happy to help. Be sure to include a copy of the roaming client diagnostic report in your case. 

Enter "Protected" mode, and remains "Unprotected, Unencrypted"

The roaming client has installed successfully, but is not providing any protection. Help! 

1. Check your network prerequisites and firewall settings (network and software). Specifically UDP 53 and 443 to 208.67.220.220 and 208.67.222.222 and TCP 443 to sync.hydra.opendns.com, crl3.digicert.com, crl4.digicert.com, and ocsp.digicert.com. Without these connections, we are unable to go protected. Sync is required to enter protected mode. 
2. All of the proxy possibilities under "Register, it remains "unknown, unknown" above. If the client has registered from a network without a proxy, then returns to a network with a proxy and boots there, this will be the state the client remains in. See our "Using the roaming client with a proxy" guide. 
3. Ensure that the roaming client is not blocked by antivirus or program management. See which folders we use here.
4. Using Netskope? There is a known compatibilty issue preventing the client from syncing in certain configurations. See our article on this Netskope issue here. 
5. Check for incompatibilities with other software here. 
6. Using the AnyConnect Roaming Security Module? The standalone roaming client must not also be installed at the same time! If both ERCService.exe and acumbrellaagent.exe are running concurrently, this indicates both are installed. Uninstall the standalone Umbrella roaming client, and ensure no software management tools are reinstalling it. 
7. None of the above or unsure? Contact our support team at umbrella-support@cisco.com and we'd be happy to help. Be sure to include a copy of the roaming client diagnostic report in your case. 

Enter "Protected by VA" mode

The scenario where roaming client remains active on a network with a VA is possible when:

1. All local DNS on the workstation is not pointed at a VA. If any are not pointed to the VA, the client will not stay in "Protected by VA" mode. To validate what we're checking, see the follwing:
   1. MacOS: /var/lib/data/opendns/resolv_orig.conf
   2. Windows: C:\ProgramData\OpenDNS\ERC\Resolver1-Wireless Network Connection 5-resolv.conf (where the name of the NIC is the prefix to the file, note that each NIC will have it's own file) 
2. Firewall or network issue. We must get back an answer from the VA with it's identity using the query debug.opendns.com (TXT). If this doesn't return, we will not enter a "behind VA" mode. 
3. The IP given to the VA is also present elsewhere on the network, thereby causing some packets to not reach the VA. Ensure that the VA IP is unique on your network. 
4. The VA may not be completely able to send DNS. The VA will also use DNS encryption, which may be flagged by a firewall especially on port 53. This will be inconsistent. See our document on VAs and packet inspection. 
5. None of the above or unsure? Contact our support team at umbrella-support@cisco.com and we'd be happy to help. Be sure to include a copy of the roaming client diagnostic report in your case. 

Disable behind protected or trusted network

The roaming client possesses several ways to disable in desired scenarios. One of these is to disable on protected network. For a background on this feature, see this article. 

1. Most commonly, the cause is not meeting the strict prerequisites detailed here. 
   1. All local DNS servers must be using Umbrella
   2. All local DNS server-based policies must be higher in policy priority than the roaming client
   3. The DNS egress of the workstation directly to Umbrella must be the same registered network ID as the DNS egress through each local DNS server. In many cases, this is not possible for enterprise networks. See below for alternative. 
    
   This feature works only for single-egress-registration between the workstation egress and the local DNS server egress.
   Looking for a "trusted network" feature which disables based on a trusted DNS record rather than specific egress rules? Contact our support team to learn about an awesome new "Umbrella trusted network domain" feature, currently in LA. Requirements: ability to create a subdomain with an A-record within the local RFC-1918 IP range. Provide this subdomain to Umbrella support. Prerequisites for trusted network domain
   1. Create or provide a subdomain which only resolves locally
   2. Create A-record for the domain pointing to any RFC-1918 internal IP (i.e. 10.0.4.1). The IP does not need to exist or be reachable
   3. Provide this subdomain to Umbrella support to be added to your configuration. Soon, this will be available directly on the dashboard. 
2. The local network is not using Umbrella. All local DNS must forward to Umbrella to use protected networks. 
3. None of the above or unsure? Contact our support team at umbrella-support@cisco.com and we'd be happy to help. Be sure to include a copy of the roaming client diagnostic report in your case. 

Stay protected behind my VPN

VPNs are common software in the enterprise. While most work great with Umbrella, some VPN clients may need tweaks or may not function well with the roaming client. Read below to learn where your VPN stands. 

1. Is your VPN on the incompatible list? See this article for VPN compatibility details. Compatibility issues include failure to resolve local DNS or failure to stay connected to VPN. 
2. Using AnyConnect and experiencing issues with local DNS? If you are using 4.3 MR4 or higher, we have a solution! See our AnyConnect Roaming Security Module, built right into AnyConnect. Adds support for all modes including split-dns and tunnel-all-dns! What is the difference between the AnyConnect and standalone client?
3. Compatibility workaround: Use our protected network or trusted network (see the subsection "Disable behind protected or trusted network" above) feature to disable the client's DNS encryption while on VPN. 
4. None of the above or unsure? Contact our support team at umbrella-support@cisco.com and we'd be happy to help. Be sure to include a copy of the roaming client diagnostic report in your case. 

Go encrypted, and it remains "Protected, unencrypted"

The roaming client protects your DNS over two modes, encrypted and transparent. Encrypted mode encapsulates your DNS over the network and transparent provides the same policy application and protection, but the packets are standard DNS with EDNS information added. Here are the most common reasons the client remains in unencrypted mode:

1. Firewall. Transparent mode works over the DNS standard UDP 53 (failover to TCP 53) while encrypted mode works over UDP 443 (failover TCP 443). On networks where UDP 53 is allowed but UDP 443 is blocked to 208.67.220.220 and 208.67.222.222, the client will remain in a "protected, unencrypted" mode. This is expected under those network conditions. 
2. None of the above or unsure? Contact our support team at umbrella-support@cisco.com and we'd be happy to help. Be sure to include a copy of the roaming client diagnostic report in your case.