how to automatically disable agent npa tunnel, when endpoints are in company internal network?.
It is necessary that when the endpoints are in the internal network of the company, and the endpoint needs to connect to the internal web applications, these are not encapsulated and the traffic is not sent to the netskope cloud. If not, the traffic must go directly through the internal network.
How does netskope manage to do this, because it has been tested and found that the netskope agent for https always tunnels traffic to the cloud, so for intra-enterprise web applications you will never be able to access it directly.
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.
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.
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.
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.
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.
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.
@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.
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.
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.