Overview
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. This document serves as general guidance and does not serve as an official list of supported software.
Cisco Umbrella does not test, validate, or certify functionality with any 3rd party software or VPN client.
For a list of known incompatible VPN software, see the Incompatible VPNs section of this article.
Table of Contents
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 (208.67.222.222/208.67.220.220).
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:
DNS Layer Incompatibilities
The DNS Layer of the Umbrella roaming client is incompatible with the following clients based on support team testing. These clients are not verified or tested by Cisco Umbrella engineering and all entries are subject to review.
- Avaya VPN ö
- Windows VPN, notably always on VPN. May result in local DNS failing to resolve to the internal answer despite the DNS hostnames being on the internal domains list.
- Workaround: Modify the metric of the VPN interface to be lower than that of the Ethernet/WiFi network interface. For some third party examples of success, see this article.
- VPNs "apps" built on top of the Windows Universal Platform.
- Does not affect AnyConnect module. 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 is not compatible
- Palo Alto GlobalProtect VPN ^ (version 2.x and below)(Windows, Select Modes)
- F5 VPN ¥ (as of version 2.2+) (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. Additionally, some configurations and versions may result in Umbrella being overridden despite showing green.
- 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, split dns (standalone roaming client only, AnyConnect module not affected). For more details see Pulse Secure and Umbrella Roaming
- Impact: On disconnect, saved local DNS may remain VPN values rather than WiFi/Ethernet values due to Pulse modification during VPN connection.
- Solution: Do not use name-based split tunneling.
- Support may be added in the future - contact us to log a feature request.
- Zscaler VPN.
- Zscaler makes use of ZPA which acts as a DNS proxy, which conflicts with our own DNS encryption proxy software. DNS may fail to resolve including local DNS or may resolve to completely different IPs such as 100.x.x.x ZScaler IPs.
- SentinelOne firewall.
- Confirmed to conflict with the AnyConnect Umbrella Roaming Security Module and prevent coverage from applying after the next reboot after installation. No known workarounds. Contact SentinelOne to see if DNS control may be disabled. This is slated for resolution in a future SentinelOne version to be confirmed.
- Akamai endpoint protection (ETPclient)
- This is a DNS redirection proxy software which will also bind to 127.0.0.1:53. We are not compatible with this competing product.
- NordVPN
- Two options exist for adding compatibility. Firstly, use the OpenVPN connection method as outlined at https://nordvpn.com/tutorials/windows-10/openvpn/. Second, allow custom DNS under Advanced settings©©. Set DNS to 208.67.220.220 and 208.67.222.222.
- Azure VPN
∂ 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.
© NordVPN Advanced settings screen. 
|
¥ 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. Today, a permanent solution may exist in the form of the AnyConnect roaming security module (requires additional license). In the long term, we aim to add support for these additional DNS modes; however, due to the use of a F5 DNS proxy - support may remain limited. |
|
|
| In some cases, this manifests with a F5 DNS proxy where DNS flows to F5 despite the roaming client showing protected and encrypted. Test pages to welcome.umbrella.com would fail (unless on-network uses Umbrella) and the roaming client would not be used for DNS due to interception. The roaming client is fully functional and would report a protected state, but not receive DNS from the system. |
IP Layer Enforcement Incompatibilities
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
- DirectAccess (some deployments). May cause failure to maintain connections to DA.
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
Special Consideration for AnyConnect with IP Layer Enforcement: Select Settings prevents VPN Connection
Currently, 1.1.1.1 may be blocked by IP Layer Enforcement. In some AnyConnect deployments, 1.1.1.1 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 1.1.1.1 to your Global Allow List to prevent this block from occurring.
Virtual Appliances and Protected Networks
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.
For more information, see Roaming Client and Virtual Appliances and/or Protected Networks.
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.
VPNs (including AnyConnect) + Standalone Roaming Client + Windows 10: DNS Binding Order VPN compatibility mode:
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.
Sophos VPN
|
Results for: resolv.confs C:\ProgramData\OpenDNS\ERC\Resolver1-76F52CE47B124D9FB05591D162777829-resolv.conf nameserver 192.168.2.1 |
|
C:\ProgramData\OpenDNS\ERC\Resolver1-76F52CE47B124D9FB05591D162777829-resolv.conf nameserver 10.1.1.27 |
Always on VPN
The standalone roaming client is incompatible with the AnyConnect Always On VPN setting when Trusted DNS servers are defined. When running, the standalone roaming client will always set DNS to 127.0.0.1 when active, eliminating all trusted DNS servers from the NIC settings. The roaming client may be disabled on network to restore DHCP settings; however, all roaming client related protections will shut off when configured. Contact Umbrella support to learn more about disabling the client on a trusted network.
Solutions:
- The AnyConnect Roaming Security Module (roaming client for AnyConnect) is not affected and will work great with an Automatic VPN policy
- Add 127.0.0.1 to the trusted DNS servers list.
- Ensure that alternate methods of trusted detection are defined - DNS names and servers to avoid all networks from being declared trusted.
- Ensure that alternate methods of trusted detection are defined - DNS names and servers to avoid all networks from being declared trusted.
AnyConnect + Standalone Roaming Client + Full Tunneling
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 208.67.222.123? 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! We chose 208.67.222.123 because it is one of our alternate resolvers that the roaming client uses, so it would never be actually used - but serves the purpose of permitting our traffic. access-list ExcludeIP standard permit host 208.67.222.123 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 208.67.222.222 |
| Add it to your group policy attributes for your VPN. |
split-tunnel-policy excludespecified |
| Ensure that split-tunnel-all-dns is NOT in the configuration. |
|
AnyConnect + Standalone Roaming Client + Split Tunneling
|
DNS Setting |
Status |
Description |
| Standard DNS | Supported |
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. |
| *Tunnel-all-DNS | Partially Supported |
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 | Unsupported |
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.
via CLI
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
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).
When using an OpenVPN server, be sure that "persist-tun" is not enabled server-side to ensure that network changes are triggered on disconnect/reconnect.
Tunnelblick
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.
When using an OpenVPN server, be sure that "persist-tun" is not enabled server-side to ensure that network changes are triggered on disconnect/reconnect.
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
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.
Comments
0 comments
Article is closed for comments.