It is often necessary to disable private app steering when a user is on premises. This can be accomplished by using Dynamic steering as documented https://docs.netskope.com/en/dynamic-steering.html
On-premises detection is required for Dynamic steering and the Netskope client can detect that it is on-premises either by resolving a DNS A record to IP address or by probing an HTTP server.
NOTE: The host probed by on-premises detection should never be steered through Netskope Private access neither explicitly or by wildcard. This will result in unwanted behaviour.
In this article I will explain how you can use nginx to host a service which can be probed for on-prem check. As per the Netskope documentation for HTTP, the HTTP server must return 200 OK response code to determine if the device is on-premises.
nginx is an open source highly performant and scalable HTTP and reverse proxy server which can easily be used to perform this function. There are many great articles available on the internet covering installing nginx so I will not cover that here.
What is interesting is that with nginx you can use the client source ip address to either return a 200 status or 403 status depending on the source ip address of the http request. This is useful for instance where you want to ensure users on one internal vlan(like the guest vlan) is detected as remote while other users are detected to be on-premises. Another use case might be direct internet breakout from all branches and the customer might only have cloud infrastructure so DNS is not an option. In this case hosting nginx on a cloud service and then using the branch router public ip addresses will allow us to detect when users are on-prem and return the required HTTP status code.
On ubuntu the nginx default site configuration can be edited using the following command.
$ sudo nano /etc/nginx/sites-enabled/default
Let's say we want to detect any user as local when their IP address is in 10.0.0.0/8 or 192.168.0.0/16 and when users come from all other IP addresses they should be treated as remote. We can add the following to the location statement in the nginx configuration.
allow 192.168.0.0/16; # Allow source ips in range 192.168.0.0/16
allow 10.0.0.0/8; # Allow source ips in range 10.0.0.0/8
deny all; # Return 403 status code for all other ip addresses
In order to return the required HTTP status code, we can use the allow and deny statements in the required location as shown below.
server {
listen 80;
listen [::]:80;
root /var/www/html;
server_name _;
location / {
allow 192.168.0.0/16;
allow 10.0.0.0/8;
deny all;
try_files $uri $uri/ =404;
}
}
Test the configuration changes to ensure the syntax of the config file is correct.
$ sudo nginx -t
Restart the nginx service in order for the configuration to take effect.
$ sudo systemctl restart nginx
You can test access and response code using your web browser by visiting the nginx web server using your browser.
Browser page when user is remote.
Browser test when user is on premises
Once you have validated that the nginx server is responding with the correct status code based on the client device source ip address you can enable On-Premises detection from the Client Configuration policy
Netskope device steering configuration example
The nginx access log offers good insight into the requests and responses being served.
$ tail -f /var/log/nginx/access.log
192.168.25.60 - - [15/Mar/2022:08:06:21 +0000] "GET / HTTP/1.1" 200 612 "-" "Mac OSX 12.2.1;Netskope ST Agent 91.0.6.812;testclient"
105.245.102.164 - - [15/Mar/2022:08:10:49 +0000] "GET / HTTP/1.1" 403 162 "-" "Mac OSX 12.2.1;Netskope ST Agent 91.0.6.812;testclient"
192.168.25.60 - - [15/Mar/2022:08:13:21 +0000] "GET / HTTP/1.1" 200 612 "-" "Mac OSX 12.2.1;Netskope ST Agent 91.0.6.812;testclient"
The log offers insight into the HTTP response code for each GET request. When the request comes from client with IP 192.168.25.60 there is a response code 200 return while when the request is received from 105.254.102.164 a response code 403 is returned.
What do you think, is this useful?
Any other use cases where you think this can be used or do you have a better way of performing on-premises?