Configuring AnyConnect (with Umbrella)
The Roaming Client (aka Umbrella Roaming Client) is a legacy technology from Cisco and has been replaced by AnyConnect with Umbrella Module.
Customers can upgrade from the Roaming Client to AnyConnect with Umbrella Module free of charge.
Cisco has not yet retired the Roaming Client but new developments are made to AnyConnect only.
Upon startup, the Roaming Client (R.C.) reads the list of DNS Resolvers from the Operating System, stores it in an internal configuration file and then replaces the first Resolver to become the loopback address
When the R.C. receives a DNS request, it uses its internal DNS Proxy (via
127.0.0.1) and forwards it to the Server Side of Umbrella which then makes a determination whether to block or allow traffic for the requested domain.
If traffic is allowed, the list of known resolvers from the R.C.’s internal configuration file is used to resolve it instead.
It is important to note that the R.C. does not poll the Operating System for changes to the Resolver list: Once the R.C. has started, it will keep a static list of resolvers, even if the actual list of Resolvers changes (at Operating System level).
Roaming Client and Twingate Client are not compatible
As a consequence, the Twingate Client cannot work alongside Cisco’s Umbrella Roaming Client.
It intercepts DNS traffic by using a kernel module and looking at all outgoing traffic on port 53 (Default DNS Port).
Because it works at Kernel level, it does not require the addition of anything to the Resolver list on the Operating System nor does it require copying the list of Resolvers into an internal configuration file at any point (this is different from the Roaming Client as mentioned above).
Once the kernel module intercepts DNS traffic, it sends it to the AnyConnect stack (local to the Operating System) to make a decision on what to do with it:
If the traffic corresponds to a list of Internal Domains (see below) specified in the Admin Console of AnyConnect, the AnyConnect Client puts the request back on the network stack (to be processed by the Operating System as if it never went through AnyConnect at all),
If it does not correspond to an known Internal Domain, the Client forwards it to the Umbrella server backend instead for processing (which then makes a decision on whether to block traffic or not).
For Internal Domains: Once AnyConnect makes a determination that a specific destination corresponds to an Internal Domain, the AnyConnect client adds an internal tag marking the destination of the request as “do not intercept” (this is done in memory and remains valid until the AnyConnect Client restarts).
AnyConnect Compatibility with Twingate
AnyConnect (with Umbrella Module) is fully compatible with Twingate. Read on for instructions on what needs to be configured on the AnyConnect side.
In order for AnyConnect not to wrongly drop or intercept traffic away from the Twingate Client, a bit of configuration needs to be done on the AnyConnect Umbrella side:
For the purpose of illustration, let’s assume we need the Twingate Client to be able to access Twingate Resources on
In the Cisco Umbrella Management Console, go to Deployments → Configuration → Domain Management:
Under Internal Domains, add the corresponding domains, in this case, add:
Publicly Resolvable Domains
If the resources you are protecting being Twingate are publicly resolvable, you will need to add them to the Internal Domains list in order for Twingate to be able to resolve them.
Important Note: AnyConnect does not support midfield wildcards (
bla.*.example.com is not a valid Domain for Umbrella) but it does support left hand wildcards which are also implied (
example.com on the list of Bypass Domains is therefore the same as
More information on Domain Management in Umbrella is available at https://docs.umbrella.com/deployment-umbrella/docs/domain-management
Last updated 2 months ago