Cisco Umbrella Interoperability with the Netskope Client in Three Steps!

  • 27 June 2021
  • 7 replies
  • 120 views

Badge +7

If you're currently using Cisco Umbrella in your organization, you might have experienced some issues when running Netskope and Cisco Umbrella together.  This guide will show you how to implement the steps to ensure smooth interoperability between the two solutions.

 

THIS DOCUMENTED WAS CREATED USING THE FOLLOWING COMPONENTS:

  • Netskope Client v.85.2.0.629

  • Umbrella Roaming Client v.2.2.580.0

  • Cisco AnyConnect (v.4.10.01075) w/Latest Umbrella Roaming Module as of 6/1/2021

#1 - Umbrella IP Bypass List

Regardless of the Netskope steering method (CASB or NG-SWG) or OS (Windows or Mac), create a Network Location and add the below ranges to it. This will prevent Netskope from intercepting the block page responses and the Intelligent Proxy redirect responses (if enabled in Umbrella), regardless of type (malware, malsite, content, etc) so those pages/redirects can be properly rendered.

<UI: Policies → Profiles → Network Location>

  • 67.215.64.0/19

  • 146.112.0.0/16

  • 155.190.0.0/18

  • 185.60.84.0/22

  • 204.194.232.0/21

  • 208.67.216.0/21

  • 208.69.32.0/21

When finished, the Network Location should look like this:

 

 

Next, create an exception like so:

<UI: Settings (bottom left on main screen) → Security Cloud Platform → Traffic Steering → Select Steering Config → Exceptions → New Exception → Destination Locations>

 

 

#2 - Bypass Umbrella Processes for Umbrella DNS-based protection

This step is done for Umbrella components running on the host, but even if the Umbrella user is just redirecting via virtual appliances while on-prem, it’s not a bad idea to have these bypasses in place. This will prevent Netskope from intercepting any traffic from the DNSCrypt component of Umbrella, as well as ensure that no traffic bound to the Umbrella dashboard (for things like updating status/operation) is intercepted by Netskope.

  • For Windows AND MacOS Umbrella RC, create a single Cert-Pinned App with the following listed as processes:

    • For the Umbrella DNScrypt process: “dnscrypt-proxy.exe”, soon to be “dnscryptproxy.exe” as of 2.3+ of the Umbrella Roaming Client

    • For the Umbrella RC process: “ercservice.exe”

    • For the Anyconnect with the Umbrella Roaming Module: “acumbrellaagent.exe”.

Watch this SHORT VIDEO to see how to create these exceptions (required MacOS processes are shown in video).

 

#3 - Enable “Perform SNI (Server Name Indication) check” (CASB mode ONLY!)

This was originally done by turning on “Ignore DNS Loopback” in the backend to ensure there was no “overlapping IP space” when one IP was used by several applications. When this occurred, Netskope would “map” that IP to all of those applications, and policy could overlap. Now that the SNI check option exists for steering, this option should not be needed.

To ensure SNI checking is enabled, follow these steps:

<UI → Settings → Security Cloud Platform → Netskope Client → Devices → Client Configurations (top right)>

  • Click on the existing tenant configuration. If there is more than one, click the one that will require Umbrella Roaming Client interop.

  • Ensure, under “Advanced”, that the “Perform SNI (Server Name Indication) check” is selected like so:

 

 

This will enable the ability to check the SNI to ensure there is no “confusion” as to what server name is being seen, hence removing the concern around overlapping IPs.

*** If you have SaaS applications that require IP Anchoring (the SaaS provider allows access by egress IP), SNI check will send this traffic to the proxy and thus break this IP anchoring (the egress IP will be the IP of the New Edge DC the client is connected to)***

FAQ

Question: I’ve done everything that was supposed to be done via this article, and they’re still not getting Umbrella block pages…things just seem to blow right through!!! What gives?

Answer: When this has happened, it generally has to do with the browser using Secure DNS, a.k.a. DNS over HTTPS. Umbrella cannot inspect the DNS requests when this is enabled, therefore the lack of any action taken by Umbrella. This has nothing to do with the Netskope Client or services and Umbrella support documentation mentions that this should be disabled.

Question: My customer uses Umbrella VAs (Virtual Appliances) onsite…is there anything I should be concerned about with that component?

Answer: No! The steps outlined here also take care of Virtual Appliances when in the network.

Question: What about tunnels? What if we’re not using the Netskope client, but an IPSec or GRE tunnel with the Umbrella Client or VAs…any concerns there?

Answer: No issues here, either…just follow the steps above!

Question: Ok…how about Cloud Explicit Proxy, or EPoT (Explicit Proxy over Tunnel) instead of the Netskope client with Umbrella Roaming client? Surely there are some problems here…

Answer: YES…there is, since an explicit proxy call uses a CONNECT that doesn’t call for a host-level DNS request, and therefore doesn’t produce anything the Umbrella roaming client/VAs can inspect. This will render the Umbrella solution completely inoperable, an effect brought on by use of an explicit proxy configuration, not specific to Netskope.


7 replies

Badge +7

For those that come across this article, I'm working on getting the video linked as well as getting that 3rd picture to render...but the directions can still lead you to what you need!  Thanks for your patience!

Badge +4

Thank you, exactly what I was looking for

Badge +7

Glad it was useful, @davidlan !  Please do let me know if you experience anything anomalous based on these steps!  Cheers!

Badge +6

Thanks for the article! So the SNI check is not needed when running NG-SWG in addition to CASB?

Badge +7

Hey @eblackburn , that's correct...in NG-SWG mode, you're already steering all traffic (with the exception of the things you're bypassing), so there's generally no need to check some traffic as you're seeing all at the proxy...the mechanisms are a bit different 🙂

Userlevel 3
Badge +12

It is critical to note, that Item #3 has consideration for interoperability with services behind ACLs.

 

If you plan to steer applications with IP-based controls, this functionality will break the flow as the initial packets of the TCP handshake happen outside the tunnel to validate the SNI prior to steering. This will result in these services denying the connection. Prior to enabling this feature, ensure you have validated that you aren't or don't intend to steer these services.

Userlevel 3
Badge +12

If you are actively leveraging the loopback interface, ensure your TSM/SE disables Loopback Bypass for the client hardening of we will break the loopback interface for the Umbrella roaming client.

Reply