Client On-Premise Detection options

  • 8 November 2022
  • 4 replies
  • 278 views
MetgatzNK
Rank
Badge +11

First of all, thank you very much for your time and collaboration.

 

I have the following doubts:

I understand that for the matter of detecting whether or not the client is on-premise, there is such a configuration for the client to detect it:

 

-Whether it is resolving an internal DNS domain, for example, and with that it concludes, if there is a correct resolution, it determines that it is on-premise, in corporate offices and seek, let's say, skip the use of Netskope, so that the filtering does it the firewall and/or Proxies or devices within the corporate network.

 

But here the doubt, what happens in cases where I have a VPN client, typical and traditional VPN client (whatever the vendor is, for example Forticlient, Global protect, anyconnect?

 

Example I connect with my VPN client, from one of the known vendors, and if I manage, being outside the dependencies, to have connectivity to the DNS and resolve said domain that defines that it is on-premise or not, but in reality it is not , the machine is outside the company premises and is only connected by vpn, it has access to said networks and services by vpn, splitunnel type, therefore only the internal resources go through the vpn client, the rest of the traffic, example Internet, goes through the home connection, local, coffee, 4G, etc. If the user has access to resolve dns of said domain, then in that case, as the Netskope client would understand that condition, that, if it is outside the company's premises, connected by VPN, if I manage to resolve the domain of check- on-premise, but I want all user browsing through the services in Netskope to be filtered.

 

How, in the scenario described above, Netskope manages to discriminate these 3 conditions and/or scenarios, especially the third one ?:

1.- User outside the company (off-premise) – At this point it is using On-Premises Detection
2.- User within the company (on-premise) – At this point it is using On-Premises Detection
3.- User outside the company, with VPN client and Netskope client, connected by VPN, which, if it reaches the internal dns, to resolve this domain, and navigation, that is, all Internet access, Netskope must apply it your filters.

 

How does Netskope resolve and/or recommend settings in this case? I understand that it is something quite normal that can occur as part of implementations and use cases.

 

Thanks for your time

 

Stay tuned

 

Best regards

4 replies

Zulkifal
Userlevel 3
Badge +12

Split DNS is a feature available on several VPN clients, including GlobalProtect. You can choose which domains should be resolved by the local DNS servers or the VPN-assigned DNS servers. The DNS record added for Netskope On-premise detection can be added on the firewall split DNS domain field. 

 

https://docs.paloaltonetworks.com/globalprotect/5-2/globalprotect-app-new-features/new-features-released-in-gp-app/split-dns

 

https://docs.paloaltonetworks.com/globalprotect/10-0/globalprotect-admin/globalprotect-gateways/split-tunnel-traffic-on-globalprotect-gateways/configure-a-split-tunnel-based-on-the-domain-and-application#id0687b049-664-4054-96dc-ba880f8c92c9

 

Looking for further recommendations from the Netskope community 🙂

Zulkifal
MetgatzNK
Rank
Badge +11

Hello @Zulkifal  thank you for your comment.

 

Currently in Palo Alto firewall, the use of Split VPN using domains and/or applications, is by adding an additional subscription. As a base and without subscription you can use split without problems, but if you approach it as Split with DNS domains and / or applications is an additional subscription and clearly is not the idea to acquire it... 

 

https://docs.paloaltonetworks.com/globalprotect/10-1/globalprotect-admin/globalprotect-gateways/split-tunnel-traffic-on-globalprotect-gateways/configure-a-split-tunnel-based-on-the-domain-and-application#:~:text=With%20a%20GlobalProtect%20license%2C%20you%20can%20enforce%20or%20apply%20split%20tunnel%20rules%20based%20on%20the%20destination%20domain%20and%20application%20to%20Windows%20and%20macOS%20endpoints.

 

 

Now the question of the 3 scenarios and how they have solved this issue is still not completely resolved, since there is usually an issue that Zero Trust seeks to attack, mitigate and eradicate. VPNs currently provide access that is too broad and cannot be completely delimited by applications (although with Palo Alto you can achieve this, not 100% but to a large extent). Many must connect by VPN, by resolving DNS, to the internal dns, to be able to resolve and connect to internal corporate sites, which are not exposed to the Internet.


Now from what I saw, for on-premise discovery, there is the option of DNS ( FQDN ) or HTTP. This option is interesting, because we could set the IP of a network printer for example (of course not accessible through the VPN), the IP of a communications device, a server, etc.) and block access through the VPN and thus determine when it is on-premise, off-premise and off-premise-connected to the VPN.

With Palo Alto for VPN you can use DNS proxy and send to a sinkhole the FQDN for detection, so that the netskope client validates that it is connected to VPN, but is not on-premise.

 

Best regards

M
Rank
Userlevel 4
Badge +14

The solution to this dilemma(as in, number 3) is to set on-premises detection to be based on the HTTP call rather than simple DNS name resolution, and block traffic to the on-prem detection beacon either on the VPN device or on the firewall between VPN and the destination.

The beacon service in that case has to be something that is completely non-essential to the user, so if there is something that exists already, great, if not, then it will need to be created to service this purpose.

N
Userlevel 4
Badge +12

I consider a device that connects to our VPN as On-prem. It has (for the most part) the same direct access to internal resources that the user would get if in the physical office. We use on-prem detections to disable NPA when a user connects to the VPN. The bigger issue is on-prem exemptions and that they are proxy side, not client side. This wrecks havoc on saas appliances that we configure to require come from our office IP's. Adding in netskope IP's is not an option since those IP's are shared with all netskope customers and their dedicated IP option is $$$. I think client side exemptions are coming in Q1 2023 but this should have been addressed long ago.

Reply


Terms & ConditionsCookie settings