Hi @MetgatzNK , thank you for posting your question.

Good afternoon,

This ultimately depends on the exact remote access VPN that is installed and how it intercepts traffic. In broader cases where the app is defined by hostname, NPA usually intercepts first by replying with a stub IP address that the client automatically intercepts. In your specific case, since it's defined by IP address, it's going to depend on how the VPN client operates and the operating system (driver level, proxy, system extension, etc). One other note, while it is supported to run the Netskope client with Private Access enabled at the same time as a VPN client, most enterprises end up replacing their traditional VPN client with Netskope Private Access. I hope this helps but if there's a specific client for VPN you are interested in understanding the interoperability, I'd be happy to do some additional digging.

@sshiflett

Hello, good afternoon, thank you very much for your prompt response and support.

If precisely the applications are only accessible via IP, not with FQDN or Hostname, they are somewhat legacy applications.

Yes, I understand that once NPA Private Access is used, I understand that normally the traditional VPN client should no longer be used, however, under a "transition" period, both solutions may operate, and both may be useful for operational continuity.

Now with respect to the mode, client and vendor, it would be the following scheme.

Palo Alto Networks Global Protect Client Version 5.2.
and Fortinet FortiClient version 6.4.X.
Both in split tunnel mode, where only passes through the VPN tunnel the traffic destined for internal resources, networks and in this case the app discussed in the beginning of the post, the traffic to the Internet, goes directly from the client/endpoint and its connection to local internet, cafe, home, public, home, etc, etc .... Not through the VPN concentrator and then to the Internet, but direct to the Internet, the VPN only for access to local networks and internal resources.

Thank you very much for your support

I remain very attentive to your comments.

Best regards

@MetgatzNK 

I will see if we have anything specific to those solutions.  If not, it's something I could likely setup in a lab and test.  

Hello @sshiflett , good evening.

Thanks for the support and collaboration.

Please let me know how you did with your lab and testing with respect to the VPN clients mentioned in the post.

Thank you, I remain attentive

Best regards

Good morning @MetgatzNK,

My apologies for the delay.  After some additional research, Netskope doesn't support running a remote access VPN client at the same time as Netskope Private Access.  This is because the respective drivers/services will likely fight over traffic depending on the specific VPN client.  If there's a specific use case you're looking to solve for, please let me know.  Keep in mind, there is a feature in Netskope Private Access to allow users to enable and disable the tunnel from the client:

https://docs.netskope.com/en/allow-users-to-disable-private-apps-access-on-the-netskope-client.html

This would allow you to alternate between the remote access VPN and Netskope Private Access as needed. 

Hello @sshiflett Good afternoon

A ok, thank you for your answer and for confirming it.

Now thinking in an environment, in an implementation that requires "transition" stages from VPN client access to private access then to Netskope Private access, how do you handle it or how have you handled it in that case ?

Since if you do not support VPN client, in parallel, it means is a complete cutover from VPN access and then via Netskope Private Access Apps.

There is no middle ground then that Netskope can offer thinking that I am connected with my VPN client to access certain services, while in parallel I have Netskope Client to test and validate access to certain private applications via Private Access ZTNA.

I remain attentive

Best regards