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. Synchronization from the roaming client to Umbrella is required to enter protected mode. 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
   • TCP 443 to sync.hydra.opendns.com
   • TCP 80 to crl3.digicert.com, crl4.digicert.com, and ocsp.digicert.com
   Without these connections, the roaming client cannot 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 compatibility 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 following:
   • MacOS: /var/lib/data/opendns/resolv_orig.conf
   • 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. 
   • All local DNS servers must be using Umbrella
   • All local DNS server-based policies must be higher in policy priority than the roaming client
   • 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. Requirements: ability to create a subdomain with an A-record within the local RFC-1918 IP range. Prerequisites for trusted network domain:
   
   • Create a subdomain which only resolves locally
   • 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
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 in the enterprise. While most work great with Umbrella, some VPN clients may need tweaks or may not function well with the roaming client. Review the list below to determine the compatibility of your VPN software. 

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 sends and receives DNS traffic using one of two modes: encrypted or transparent. Encrypted mode encrypts and encapsulates the roaming client's DNS network traffic. Transparent mode packets are standard DNS packets (with Umbrella-specific EDNS information added).

The most common reason the client remains in the unencrypted state is a firewall rule or ACL blocking the needed destinations and/or ports. Transparent mode works over the standard DNS port, UDP 53 (with failover to TCP 53). Encrypted mode uses UDP port 443 (failover to TCP port 443). On networks where UDP 53 is allowed to 208.67.220.220 and 208.67.222.222, but UDP 443 is blocked, the client will remain in a "protected, unencrypted" state. Allow the roaming client to access 208.67.220.220 and 208.67.222.222 on UDP port 443 to move to the "protected, encrypted" state.

If the previous information does not produce the desired results, 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.