Hello, good evening, to reinforce what the colleague commented, this is extremely important to find out.

I understand that there is the On-Premise Detection, but what happens when you have NPA ? and you want, despite being in the corporate offices, continue using the SWG/CASB, but when you are in the internal corporate offices, stop using NPA, and only use SWG/CASB, is there any option for this ? the colleague comments that continues tunneling traffic via NPA/ZTNA, despite being in the corporate network.

Thank you, we remain attentive to your comments

Best regards

Hello - Please refer to this article on Netskope support portal.

https://support.netskope.com/s/article/NPA-Gateway-IP-Address-for-VPN-Interoperability

For customers using Netskope Private Access (NPA) in conjunction with a VPN service, it is often desirable to disable NPA while end-users have VPNs tunnels enabled. This is to prevent potential issues when connecting to private applications via NPA within a VPN tunnel.

The following list of IP addresses can be used to optimize NPA access while VPN tunnels are enabled by either:

Blocking via on-premises firewalls
List of those NPA Gateway IPs can be found on the above support article.

Hope I was able to help.

Thanks

Hello @ark007 Thank you for your time, your comment and your collaboration.

But if you read the initial post of the colleague @jdavila and then my comment, it is not commenting

on access in conjunction with VPN Client, but the following specific case:

I have Netskope client, we have CASB/SWG and NPA, when that endpoint and works outside the coporate, all good, all OK, CASB/SWG, APPs are reached via NPA... but what happens when.... When the user with the Netskope client, goes to his corporate, and you want to continue operating the "CASB/SWG of Netskope", but not the NPA/ZTNA, but the access, when he is in the offices, is directly to the internal applications, but it happens, as the colleague says, that the traffic continues going to the NPA, and not directly when he is in the corporate.

Please support us with this point and detail, what to do in these use cases.

Thanks

We remain attentive

Best regards

Hello - To disable NPA tunnel when you are at your corporate office then  you will need to block/deny NPA gateway connections via on-premise firewalls as per the article I shared. This will help users to get to the private apps directly with NPA tunnel disabled.

The KB article states VPN, it might be confusing but this also applies to on-premise site-site vpn firewall appliance. We recently applied this configuration as per the Netskope TAM recommendation.

Hope this helps.

Thanks

What you want to do is configure dynamic steering in Netskope. This enabled the On/Off a premises detection. When Netskope detects “On Premise” it can disable the NPA but keep the SWG/CASB in place. 

there is little reason to block NPA at the firewalls if using on/off prem detection since you can configure the NPA to be disabled right within the product. Maybe that wasn’t the case long ago for some of the comments above but it’s built into the tech today. 

Hmm, interesting. Thank you, will explore into this option but our TAM did not suggest this configuration. I will check with them.

Thanks

Yes check with them. It’s simple to do, we do it. There are a couple caveats though - with onprem exceptikns they are done proxy side (Netskope cloud) and not at the client. This can pose a problem if you have certain cloud applications that have to originate from your office IP. They will be changing this around R106/107 with the ability to let customers choice if exceptions should be done at the client or cloud for BOTH on and off prem. Im currently alpha testing this in our dev tenant and it works perfectly. 

Hello @ark007 Thank you for your time, your comment and your collaboration.

I cannot enter the link since I do not have credentials for that page (Support Portal).  

Maybe you can export the content, or share it in another way.

thank 

Best Regards

Hello @nduda , reviewing all the comments.

Have you tested it ? does it work well ? does it work as expected and with the target in mind ?

So the best practice is to use dynamic steering, check the documentation and it is something very native to the netskope client, it is a recent feature, as I see that not all Tenant have it enabled.

As far as I see it is the best option, leaving as a second option, blocking access to the NPA gateway, from the corporate firewalls.

What do you think about it? @ark007 @jdavila 

Best regards

@MetgatzNK - Yes we tested it. We use it in Production today. It works perfectly. There is a slight delay when switching from Off Prem to On Prem (VPN) where the tunnel gets disabled but nothing crazy. Here is a screenshot of what it looks like in the current GA release. Again, there is a change coming that further allows more granular control over exemptions with dynamic steering. You can see in the screenshot for On-Prem the NPA is disabled.

Thank you @nduda . This information is helpful and will keep in my mind when I configure dynamic steering.

Thanks you

You can also block the NPA Gateway IP's at your firewall and then you don't have to use the on-prem / off-prem and dynamic steering. This tends to work better if you dont have a good grasp on how the exceptions work when using these options.  Then you dont have to implement this as it gives another option thats really better at the end of the day given the way it works, food for though for anyone moving forward.

For VPN, those that split tunnel, you would need to split tunnel the IP's for NPA to go over the vpn tunnel. 

@nduda Could you explain little bit more on split tunneling IPs for NPA on VPN?

Organizations that have VPN's for employees configure either it for Full tunnel or Split tunnel. With full tunnel, all traffic is routed over the VPN and sits behind company firewalls. With split tunnel, the firewall admin configures only specific IP's (usually internal CIDR ranges) and FQDN (for internal web apps) to route over the VPN while leaving all other traffic going out the devices normal internet. So in the event of a company using split tunnel, it's highly unlikely the IP's or FQDN for NPA are routed over the split tunnel. This makes blocking at the firewall not work. With split tunnel those NPA IP's and FQDN need to be configured to route over the VPN and then blocked at the firewall.

Just another reason why the built in On/Off Prem detection of NSClient is more attractive.

Hi @nduda 

We are observing this problem. With on-prem detection enabled, exception are done on the cloud proxy side instead of the client. We are now on R117.0.2.136. Are you aware of any update regarding allowing customers to choose if exceptions should be done at the client or cloud for BOTH on and off prem?

Regards,

Simon