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.
1. Auth or No-Auth?
(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:
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:
In order to view this content, you will need to sign in to your account. Simply click the "Sign In" button belowSign In