The Cisco Umbrella roaming client works with most VPN software, but there are instances when extra action is required to have both types of software work as expected.
This document provides technical information and additional context for specific VPN clients which may require further configurations.
For a list of known incompatible VPN software, see the Incompatible VPNs section of this article.
Table of Contents
- Client incompatibilities
- Cisco AnyConnect
- Viscosity VPN
- Lightspeed Rocket
Introduction – How the Umbrella Roaming Client works with VPN Clients
The Umbrella roaming client binds to all network adapters and changes DNS settings on the computer to 127.0.0.1 (localhost). This allows the Umbrella roaming client to forward all DNS queries directly to Umbrella while allowing resolution of local domains through the Internal Domains feature.
Upon establishing a connection to a VPN server, the Umbrella roaming client detects a new network connection in the system and changes the connection's DNS settings to point toward the Umbrella roaming client. The Umbrella roaming client relies on being able to perform DNS lookups to Umbrella's AnyCast DNS IP addresses (188.8.131.52/184.108.40.206).
If you are connecting to a VPN, the firewall associated with the VPN should allow access to Umbrella.
Umbrella roaming client incompatibilties
The Umbrella roaming client today is composed of two primary functions: DNS and IP layer enforcement. The DNS layer is the primary function of the roaming client, applying DNS-based security policies on any network. The IP Layer is optionally enabled by policy, and provides direct-to-ip connection protection as well. Both functions of the roaming client experience known software incompatibilities as follows:
The DNS Layer of the Umbrella roaming client is incompatible with the following clients:
- Avaya VPN √∂
- VPNs "apps" built on top of the Windows Universal Platform. These apps must utilize a Microsoft connection API that requires DNS be sent to the local NIC, not 127.0.0.1 and therefore will display an error that it cannot connect. Example apps: Pulse Secure app version, SonicWall MobileConnect app, and Windows 8+ built in VPN app. ∂
- OpenVPN Connect (OSX)≈, the DNS resolution zones (optional split DNS mode) feature
- Palo Alto GlobalProtect VPN ^ (version 2.x and below)(Windows, Select Modes)
- F5 VPN ¥ (Split-dns mode and DNS-based split tunneling incompatible due to DNS proxy) F5 may not be used with DNS names defined with the roaming client (see ¥ section below). To use split tunneling with F5 and the roaming client at this time, use IP-based split tunneling rather than DNS based split tunneling. Contact Support for information on a legacy version and proposed resolution that works with F5 and to assist us in bringing back F5 support.
- Checkpoint VPN ∂ (MacOS Only, Split-tunnel mode only)
- VPNs running in a split-dns mode (where DNS is split between the tunnel and the local network) are not supported by the roaming client. Split tunneling is generally supported unless noted otherwise. The roaming client effectively creates a split-dns scenario where only domains on the internal domains list configured on the dashboard reach the VPN-configured local DNS servers while all other DNS goes straight to Umbrella resolvers.
- Partial incompatibility with SonicWall NetExtender and similar *
- Pulse Secure Name-based split tunneling (standalone roaming client only, AnyConnect module not affected). Impact: On disconnect, saved local DNS may remain VPN values rather than WiFi/Ethernet values due to Pulse modification during VPN connection.
- Zscaler VPN. Zscaler makes use of ZPS which acts as a DNS proxy, which conflicts with our own DNS encryption proxy software
∂ Does not impact the AnyConnect Umbrella Roaming Security Module edition of the roaming client built into AnyConnect (even if AnyConnect is not used for VPN).
√ Avaya VPN, in addition to the above, is thought to prevent connectivity to the VPN's LAN once the Umbrella roaming client is enabled.
≈ To disable the DNS resolution zones split DNS feature, log into the admin console of the access server and go to VPN Settings. Ensure there are no domains entered in the DNS Resolution Zones (optional) section.
^ Palo Alto GlobalProtect VPN (Windows only) cannot be set to start and connect on boot while using the roaming client. Currently, there is a workaround available: Delay the start of the roaming client or GlobalProtect boot process in system services or utilize a tool to delay the start of the roaming client. As long as the roaming client starts after GlobalProtect, issues do not occur. Version 3.1.3 was found to not have this issue.
*The Umbrella roaming client is partially incompatible with VPN clients which monitor and force local DNS settings to remain the VPN-set values; for example, SonicWall NETEXTENDER. To maintain connectivity over the VPN, the Umbrella roaming client will cease to reset that adapter's DNS settings to the 127.0.0.1 value after repeated overrides. Umbrella protection would be maintained over the VPN by the network level protection enabled on the VPN's DNS server (which is strongly recommended to be configured). This only applies to VPN clients which forcibly set DNS to their desired values and do not allow the Umbrella roaming client to set 127.0.0.1 into the DNS server settings. This may be avoided by using the AnyConnect Umbrella Roaming Security module.
¥ F5 VPN Split Tunneling with split-dns appears in the form of the "DNS Address Space" setting. When active, this spins up F5's own DNS proxy which conflicts with the roaming client. The symptom is a failure to resolve A-records while the VPN is active. See the following image for a working configuration. The most common breaking setting is "*". For more information on this feature, see https://support.f5.com/csp/article/K9694.
This feature is most commonly used for DNS-based split tunneling. At this time, DNS-based split tunneling with F5 is incompatible with the Umbrella roaming client and the configuration noted here is required to not launch the F5 DNS Proxy.
A permanent solution is in the works to allow this to be used - contact support to ask about it's progress.
The IP Layer Enforcement feature of the roaming client is incompatible with:
- Built-in OS X VPN client
- F5 VPN
- Fortinet FortiClient
- SonicWALL VPN (some environments)
- Checkpoint VPN
Users with these clients should disable the IP Layer Enforcement feature. Users with a VA and using the VA over the VPN may selectively disable IP Layer Enforcement for on network policies while keeping it enabled for the Umbrella roaming client off network policy.
IP Layer Enforcement is known to be compatible with the following VPN Clients only. IP Layer Enforcement will disable when these VPNs become active, and re-activate automatically when the VPN disconnects. If it is not on this list, and you are experiencing an issue, disable IP Layer Enforcement and confirm if the issue persists.
- AnyConnect VPN
- Pulse Secure VPN
Special Consideration for AnyConnect with IP Layer Enforcement: Select Settings prevents VPN Connection
Currently, 220.127.116.11 is blocked by IP Layer Enforcement. In some AnyConnect deployments, 18.104.22.168 is used as the DHCP server for the AnyConnect tunnel. Since this address would be used as the VPN connects, it would be blocked before IP Layer Enforcement can disable. To resolve this issue, add 22.214.171.124 to your Global Allow List to prevent this block from occurring.
The Umbrella roaming client behaves differently when connected to a network that utilizes the Umbrella Virtual Appliances (VA) or the Protected Networks feature. This is true whether you're connected to the network locally or through a VPN.
Special Considerations When Using AnyConnect and the Standalone Roaming Client
The following applies to the standalone Umbrella roaming client. The following does not apply to the AnyConnect-integrated Umbrella roaming client. Looking for an easy plugin install? Then Umbrella Roaming integrated into AnyConnect is for you! How does this module differ from the standalone Umbrella roaming client?
The Cisco AnyConnect VPN software provides options for how DNS should be handled by the system when a VPN connection is established. Cisco has published a complete article with this information: Behavioral Differences Regarding DNS Queries and Domain Name Resolution in Different OSs
The following information is based on our experience with using AnyConnect and the Umbrella roaming client. Your experience may differ, and we recommended testing the Umbrella roaming client with Cisco AnyConnect VPN enabled to ensure that internal and external DNS resolution work according to your expectations.
We strongly recommend that you use the Umbrella Roaming AnyConnect module if you are also using AnyConnect 4.4+ for maximum compatibility. The following steps are for the non-integrated roaming client only if required. These steps are not required for the AnyConnect roaming module. Read more: standalone client vs AnyConnect module.
In both full and split tunnel mode, special instructions are required to allow the roaming client to work while AnyConnect is connected. This is required in order to allow DNS to flow to the roaming client rather than being overridden by AnyConnect's kernel driver. For full tunnel, the symptom will be that the client will be forced to disable. For split tunneling, the symptom is a loss of internal DNS while connected to the VPN.
Currently, there is a limited set of users on Windows 10 which encounter a specific issue where the local LAN will bind above the VPN NIC for DNS. In this event, local DNS on the internal domains list for the roaming client will fail to resolve while public DNS will work without issue. This affects version 2.0.338 and 2.0.341 (by default) and above. The issue also did not occur on version 2.0.255.
To confirm if this is indeed the issue, run our diagnostic test and click to the results for resolv.confs. If your VPN adapter is listed first, you are not impacted. If your VPN adapter is listed second, you may be impacted. Example:
Results for: resolv.confs
If you're using a Full Tunnel, you'll need to ensure that the following appliance-side and client-side attributes are set accordingly. Without this setting, all DNS is forced to the AnyConnect-set DNS servers and no DNS arrives at the roaming client.
If the Umbrella roaming client eventually transitions to Unprotected/Unencrypted even after changing these settings, please copy/paste the VPN settings portion of show running-config output.
|On the client side, check Allow local (LAN) access when using VPN (if configured).|
|Create an access list that excludes an IP to release AnyConnect's control over all DNS and allow the roaming client to operate.||
ASA 4.2+ (Sends Roaming Client Encrypted DNS over tunnel). Why 126.96.36.199? The AnyConnect client in full tunnel mode takes full control of DNS which prevents DNS from reaching the roaming client at 127.0.0.1. To allow DNS to the Umbrella roaming client and release the AC client's full control on DNS, an IP must be split-excluded. We've chosen an IP not likely to be routed to as one to exclude from the tunnel. You may use any IP you like!
access-list ExcludeIP standard permit host 188.8.131.52
ASA below 4.2 (Will exclude Roaming Client Encrypted DNS from Tunnel). Must exclude this due to ASA issue below 4.2 which prevents DNS from being sent to any server not configured in the ASA.
access-list ExcludeIP standard permit host 184.108.40.206
|Add it to your group policy attributes for your VPN.||
|Ensure that split-tunnel-all-dns is NOT in the configuration.||
All DNS queries go through the DNS servers defined by the Adaptive Security Appliance (ASA) and, in the case of a negative response, might also go to the DNS servers configured on the physical adapter.
Only DNS traffic to the DNS servers defined on the ASA is allowed. This setting is configured in the group policy. Delay after connection to connectivity is about six seconds.
Split-DNS—DNS queries that match the domain names configured on the Cisco ASA go through the tunnel, for example, to the DNS servers defined on the ASA, and others do not.
With tunnel-all-dns or split-dns enabled, local DNS will fail because AnyConnect is managing VPN vs non-VPN DNS server by kernel driver. The effect is the roaming client sees all DNS going over the local non-VPN network, causing local VPN domains to not resolve.
*Tunnel-all-DNS is partially supported. Tunnel-all-DNS does not allow the Umbrella roaming client to communicate with Umbrella from a DNS perspective. In order for Tunnel-all-DNS to work immediately, you must utilize Virtual Appliances (VAs) as the VPN connection's DNS servers. If you use Tunnel-all-DNS without VAs, DNS connectivity will be unavailable for about six seconds until the Umbrella roaming client transitions to the "Open" state. The Umbrella roaming client will not protect your computer and protection will need to be configured on the network level through the AnyConnect-defined local DNS servers. The Umbrella roaming client will be disabled as long as AnyConnect remains connected. If a six-second delay isn't a concern and the VPN network is already protected by Umbrella, you may use this deployment method.
**Split-DNS is unsupported. Split-DNS does not allow the Umbrella roaming client to communicate with Umbrella from a DNS perspective. If you use Split-DNS, DNS connectivity will be unavailable for six seconds until the Umbrella roaming client transitions to the "Open" state. The Umbrella roaming client will not protect your computer.
Why? In short, due to the way that split-DNS works in AnyConnect, it sends all DNS to the local NIC (the Umbrella roaming client sees this and attempts to send all local DNS list traffic to the local non-AnyConnect adapter, hence the symptom is that local DNS stops working). The AnyConnect client then grabs any split-local DNS and redirects it to the VPN adapter at the kernel level.
**Need Tunnel-all-DNS or Split-DNS, see the header of this section for more information on Umbrella Roaming—built into AnyConnect as a plugin!
In order to ensure the Umbrella roaming client will work, you have to remove any Split-DNS names in the Split Tunneling configuration.
via ASDM interface
Navigate to the Group Policy settings for your group, then from the Advanced > Split Tunneling menu, uncheck the "DNS Names (Inherit)" option and remove any DNS names entered in the text field. Next write your changes to the running config.
Log into the CLI and run the following commands, replacing "GroupName" with the specific group policy name.
hostname# conf t
hostname(config)# group-policy GroupName attributes
hostname(config-group-policy)# no split-dns
You'll find more information about Cisco's Split-DNS configuration options here: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/71704-dns-doctoring-2zones.html#splitdns
The following is a snippet from Cisco's documentation, which provides some worthwhile notes on the methodology that the AnyConnect client uses.
Note: Avoid using NSLookup when you test the name resolution on the client. Instead, rely on a browser or use ping. This is because NSLookup does not rely on the operating system (OS) DNS resolver, and therefore, AnyConnect does not force the DNS request via a certain interface. It only allows it or rejects it, according to the split-DNS configuration. In order to force the DNS resolver to try an acceptable DNS server for that request, it is important that split-DNS testing is only performed with applications that rely on the native DNS resolver for domain name resolution. For example, all applications except NSLookup, Dig, and similar applications, which handle DNS resolution by themselves.
Viscosity VPN requires a change in the settings to work with the Umbrella roaming client. If this change is not made, Viscosity's default behavior mimics that of other Incompatible VPNs. This change tells Viscosity that it will use the DNS settings pushed via the Umbrella server for all domains in the search domain and 127.0.0.1 will still be used for any other requests.
In Viscosity, navigate to Preferences > Connections > <your connection> (site specific) > Networking > DNS Settings and select Automatic (Default).
Tunnelblick requires two changes in order to:
- allow changing of the DNS servers for the adaptor
- apply DNS settings after the tunnel has been established.
By ensuring the following settings in the "Advanced" menu, Tunnelblick will work with the Umbrella roaming client:
In the Connecting and Disconnecting tab, ensure the following two settings are enabled:
- Flush DNS cache after connecting or disconnecting (default)
- Set DNS after routes are set instead of before routes are set
In the While Connected tab, change the following to "Ignore".
DNS: Servers > When changes to pre-VPN value, When changes to anything else.
Tunnelblick VPN Disconnect Issues
With some tunnelblick versions the Roaming Client is unable to properly identify the correct Internal DNS servers following a VPN Disconnect. We recommend the following steps if you encounter problems with "Internal Domains" following a Disconnect of the VPN.
The following change causes Tunnelblick to bring the primary network interface down/up after VPN disconnect. This is managed on the Settings tab of Tunnelblicks configuration panel:
In older versions of Tunnelblick (prior to 3.7.5beta03), use the "Reset the primary interface after disconnecting" checkbox
On newer versions of Tunnelblick, 3.7.5beta03 and higher), set both the "On expected disconnect" and the "On unexpected disconnect" settings to "Reset Primary Interface".
Lightspeed Rocket has select features which are not compatible with the roaming client. Specifically, the DNS modification for "No SSL Search" and "SafeSearch" CNAME redirection of www.google.com -> nosslsearch.google.com and forcesafesearch.com respectively causes all www.google.com DNS resolution to fail as long as Lightspeed Rocket's DNS redirection is enabled.