Netskope Client steering traffic

Hello @farhan,

A few items on your questions  are below.

• I need to understand that how the Netskope traffic steer there traffic without any proxy setting on the machine
  • This varies by operating system but in short, Netskope intercepts traffic using OS functions (for example network extensions on Mac) to select what traffic to steer and then routes it over the TLS or DTLS tunnel the client has established.  This usually operates lower in the operating system or network stack so proxy settings are not required for the client to work.   There's some additional intricacies around how the client works with the DNS queries and responses on the machine to ensure more accurate traffic steering but that's a longer discussion.
• any additional certificate please let me know its create an SSL tunnel through Data plane for HTTP/HTTPS traffic
  • The client uses a Netskope provided certificate on a pinned tunnel to establish the client to Netskope TLS/DTLS tunnel. 
  • For SSL inspection, the client also includes the Netskope Root and Intermediate certificates as part of the install on most operating systems.  For the operating systems that don't install by default the certs are provided from the Netskope tenant for administrators to push via MDM. 
• Also please let me know how  Netskope validate the user is correct.
  • There is a bit of nuance here but the client can operate in different ways for different use cases and deployments.  This includes UPN, IDP, and email modes.  Email mode (which you reference) hard codes the client to be tied to a user.  It should ideally only be used in testing and cases where other identity methods aren't available.  To your point, it ties the client to that user so if James installs an email invite client for John on his laptop then user attribution will be incorrect.  Instead you should use UPN and IDP methods as those validate the user based on their Active Directory or Identity Provider login.  In any case, there are mitigating factors you can take such as requiring periodic reauthentication for private app access which would ask the user to log into your IDP on specific intervals or at logon.    If the device is AD integrated then you should absolutely be leveraging UPN or IDP modes. 

The Netskope client builds an SSL tunnel to the closest Netskope datacenter. The client then sends any 80/443 traffic (other ports can be added) through that tunnel for processing of SWG, DLP, and CASB rules, it then exits out of their datacenter with a Netskope public IP (can be static customer IPs if purchased). So the exiting traffic will have their Public IP stamped on it and not your perimeter IPs. You are free to offload apps/URLs/IPs from the client, so it will be handled through your normal routing methods. We have our internal network offloaded so internal traffic is not sent through the SSL tunnel which is standard.

Non-netskope clients can also have their traffic forwarded to Netskope via a VPN tunnel to the nearest gateway on your perimeter firewall. You can change this VPN tunnel to whatever datacenter you feel is fastest.