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?
- 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: