Hi @wilson ,

We've seen issues in the past with users utilizing the native WebEx application on Big Sur. The Netskope Client on Big Sur heavily relies on making steering decisions based on the SNI (Server Name Indication) seen in the Client Hello packet of a SSL negotiation. This SNI field within the SSL negotiation provides the destination/receiver more information about who the source/sender wants to speak to, but this is not a required field and sometimes not utilized by some native applications. The native WebEx client was seen as not adding/filling out this SNI field in its negotiation and therefore traffic steering and communication broke. 
To allow communication, we need to add Webex IP addresses to the destination IP exception in the respective Steering configuration.
You can find the list of IPs here:
https://help.webex.com/en-us/WBX264/How-Do-I-Allow-Webex-Meetings-Traffic-on-My-Network#id_135011

I have not come across any issues with Github on Bigsur specifically, except that the CLI access breaks with the NS Client. 
You can follow the below article to configure Github to work with the NS Client:

https://support.netskope.com/hc/en-us/articles/360023228553-Configuring-CLI-based-tools-and-development-frameworks-to-work-with-Netskope-SSL-Interception

you mentioned GitHub is the internal site - but also mention AWS.  Does it have an RFC1918 IP or does it have a public IP?  How is the user supposed to reach the GitHub application?

We have seen an increase in the amount of applications that we've had to explicitly put in exceptions due to some traffic not containing SNI.  I've watched a process have different communication that Netskope is detecting as URL and/or IP addresses.  We've had to add a few applications to the whitelist.  
A few to note that I would assume are causing others harm:

Apple Software Update:  (com.apple.mobilesoftwareupdate.updatebrainservice & softwareupdated)
Mac App Store:  (appstored)

Following up on the thread.  I'm starting to see process bypasses are not always bypassing all traffic from the process.  We have seen IP addresses still being tunneled for processes that are on a bypass, which the only other workaround is IP address whitelist (not scalable for most applications).  

I do have a ticket opened with Netskope but curious if others are experiencing the same challenges.  

Are you running the latest Netskope client?  Feel free to DM me your case number and I can take a look as well.  Process bypass should work.

Also curious to understand why destination IP bypass is not a scalable solution as an alternative to process-based bypass - and what kind of processes are you trying to bypass - perhaps we can think of a better solution.

Hello, sent you a DM with some details.  But process bypass definitely is not working all of the time as I see IP addresses getting tunneled to Netskope for the process in bypass list.  IP address bypass is generally acceptable if the IPs are known and documented and specific, however, in this case for us... Apple Software updates are behind Akamai CDN and Apple IPs as well.  So it would be an extremely large range to exclude that would most likely exclude other type of unknown traffic.  

Hi @ddrake ,

If you have 'Enhanced Cert-Pinned App' enabled (this is enabled by default for all tenants), you will need to add the domains that you wish the process to bypass.
If you decide to bypass all traffic from that specific process, you can simply add * in the domains list. PFA screenshot.

@sooraj  - I do not have a custom app domains listed like in your screenshot, I assume that Enhanced Cert-Pinned apps are not enabled in my tenant.  If that is the case, generally what I have seen is all domains are bypassed when I add a process bypass.  

@ddrake that is correct. If the Enhanced Cert-Pinned app feature is disabled, all traffic from that process should be bypassed. If you see that some traffic from a process that is added to the cert-pinned app list, is still being tunnelled by the Netskope Client, I recommend that you open a Support ticket to investigate the same. 

I wasn't clear on how what the problem was at the time, just that there was a problem proven by disabling the client software.  The user had a script on his Macintosh for a Docker on his machine that LDAPed over to GITHUB using AWS authentication.  That was hanging.   Trying a solution now.