Skip to main content
  • EN

This post is mainly centered around - How to handle traffic averse to 'SSL Decryption'. Here are some best practices around deploying tunnels and managing SSL decryption exceptions.

 

One of the reasons why you are considering upgrading to Netskope SWG is "ubiquitous growth", mix of managed and unmanaged, shared and dedicated systems. Some hosts that can install agent and others that can't take agents. Or you want to do application instance based granular policies that your on-prem proxies are blind to.

 

As part of this deployment generally after installing  Netskope clients you are now considering network tunnels to steer traffic to Netskope on certain systems i.e. to apply inline controls to servers, IOT devices, medical devices or kiosks.

 

When deploying IPSEC or GRE tunnels to steer traffic to Netskope New Edge  network here are certain best practices that can be followed. 

 

Design Considerations:

1. Auth or No-Auth?

IPSEC/GRE tunnel originated traffic typically won't have user ID available. You can definitely add auth - either have a Netskope client on those machines or enable SAML forward proxy auth and redirect user to your IDP such as Azure AD or Okta.   The later method is is browser based redirection and not my favorite auth method.
 
2. Client over Tunnels or Direct to Internet?
.Netskope Client behind these network tunnels can be either in disabled or enabled state depending upon how you are routing 'achecker.goskope.com'.  Another design decision you need to make before deploying the network tunnels: What about the systems that have clients installed? Let Netskope client traffic go over IPSEC / GRE tunnels or keep them separate?
-If there is a client installed, my recommendation is to let Netskope client traffic go straight via your internet pipe to the Netskope New Edge network instead of piggybacking via your GRE/IPsec tunnel. This will require proper ordering of the Netskope destined traffic on your egress firewalls. Major advantages of this approach
  • You save GRE / IPSEC bandwidth by keeping client separate
  • You don't have single point of failure. Netskope Client continues to cater when the network tunnels are down.

(essentially these are the reasons why you moved to cloud: to avoid expensive and clogged network tunnels 😳)

 

Key best practices / points to note when it comes deploying network tunnels:

  • Leverage "SSL do not decrypt" policies for the key apps we will call these DND policies. You can add SSL DND policies by source/user-ip/domain or categories. Having specific SSL DND policies will make it easier to troubleshoot when issues arise. Having tunnel specific exceptions in one place will minimize jumping around steering configurations (yes some of my customers have tens of these. Keep it short and simple where possible.
  • Any bypasses in the default steering exceptions (i.e. the bottom most catch-all steering policy which is not associated to a group or OU) will also be applicable to traffic steered via tunnels. (Group specific steering won't apply again due to the same user-id constraint mentioned above)
  • Move exceptions from default steering to group specific steering. As clarified in the last bullet default steering applies to all traffic. This will limit the number of exceptions the traffic behind tunnel will subconsciously fall through. This is a brilliant approach one of my customers came up with.
  • Leverage "Network Locations" (Netskope's address book objects for those familiar with firewall terminology) Keep SSL DND policies well segmented using individual Network Locations. Network locations can be ranges or single IP's. The idea is to use proper subnetting to distinguish critical apps.
  • Keep in mind that SSL DND policies currently apply to all steering methods.  In future we may have ability to apply "Access Method" filter to these policies. 
  • In-line policies with "any" user or "user-ip" as source criterion will be applicable to traffic behind tunnels where there is no user-id present
  • If there is no Netskope Client on these machines  behind network tunnels keep in mind that Cert Pinned App exceptions that have domains associated will need to be added to the SSL DND policies. Client does a better job at identifying processes + domains. Key benefit of using Netskope client!
  • Leverage URL web categories: You can use default or custom URL web categories as a filter to SSL DND policies.
  • Move category based steering exceptions that are factory default to SSL DND policies. That way you have the visibility to this traffic as the client will steer this traffic but cloud proxy will not decrypt it (e.g. finance or health that you may be excluding due to PII reasons)
  • Enable "Logging" of bypassed traffic. (Located at Settings > Steering Configuration; blue box in the pic attached)
  • Netskope client smartly disables itself when behind Network Tunnels. Will continue to provide user-id and pop-up notifications / coaching messages. You can get around this by having client go DIRECT to offer full functionality.
  • If the destination server / SaaS provider has IP restrictions you need to steer this traffic out of GRE/IPSEC tunnels or clients tunnels to retain your egress IP (talk to your sales contact regarding dedicated egress IP feature)

Tips 🔵 🔵 🔵  

-SSL DND policies are applied after steering exceptions and before inline real time protection policies.

-SSL DND policies are located under inline "Policies" as the top level policies (not under settings; unlike 'steering exceptions')

-We will soon have support for multiple AD groups or OU in a single steering configuration. I don't have exact ETA but keep an eye on the release notes. Here is how to subscribe to release notes: 

 

Be the first to reply!

Reply


Terms & ConditionsCookie settings