Skip to main content
  • EN

In order to ensure the correct functioning of the Azure Virtual Desktop or Windows 365 machine when deploying the Netskope Agent on it we have to take care of some Steering Exceptions:




  1. MANDATORY: Destination Location Steering Exceptions for Azure Virtual Desktop RDGateways IPs (Remote Desktop Gateways service tags related IPs)




  2. OPTIONAL: Destination Location Steering Exceptions for Azure Virtual Desktop Monitoring IPs (Azure Monitor service tags related IPs)




  3. OPTIONAL: Application/Process (Certificate Pinned Application) Steering Exceptions for Azure Virtual Desktop agents running on the Virtual Desktop




Destination Location Steering Exceptions


Microsoft provides a Json file with all the Azure destinations at the address: https://www.microsoft.com/en-us/download/details.aspx?id=56519


Unfortunately though this list contains all the destinations used by the Azure infrastructure, divided by “Service Tags” (services). As we definitely don’t want to exclude all the Azure destination from the steering we must only take the destinations involved with the Virtual Desktop infrastructure.


The Service Tags we must consider for the steering exclusions are the following:




  1. The IP addresses of the Virtual Desktop Gateways that can be found under the “WindowsVirtualDesktop” Service Tag.




  2. To the above we must additionally add the traffic destined to the IPs 169.254.169.254/32 and 168.63.129.16/32 (these 2 addresses are common for AVD and Windows 365 deployments)




  3. The IP addresses of the monitoring traffic that can be found under the “AzureMonitor” Service Tag.




All the above Service Tags (and IPs) are mentioned on the article: https://docs.microsoft.com/en-us/azure/virtual-desktop/safe-url-list








Manually extracting the IPs from the Microsoft Service Tag document can be challenging, hence we’ve developed a Python script that will help in creating from the Microsoft Json file a simple CSV file that can be used to create the appropriate exceptions. Please find the python script attached to this blog.


















To use the Python script:




  1. Download the latest Json file from the Microsoft Website at the address: Azure IP Ranges and Service Tags – Public Cloud






  1. Place the Json file and the Python script under the same folder, and rename the Json file as “AzureIPs.json”




  2. Run the Python script from a privileged command prompt (tested both on MAC and Windows machines)




  3. Verify the content of the file “AzureWVD.csv” that should have been created on the same folder. It be a 2-lines file where the first line starts with "AzureWVD" and the second with "AzureMonitor"





Once we have the CSV, in order to create the desired steering exceptions with it do the following:




  1. On the Netskope UI select “Policies” - “Network Locations”




  2. Select “New Network Location” - “Multiple Objects”




  3. Upload the file “AzureWVD.csv”




  4. Verify the newly created “AzureWVD” and “AzureMonitor” network location to see if they contain the imported IPs




  5. Apply the changes clicking on “Apply changes”




  6. Open the Netskope Setting UI and navigate to “Security Cloud Platform” - “Steering Configuration”, select the Steering Configuration (by default the “Default tenant config”) and select the “EXCEPTIONS” tab




  7. Select “New Exception” - “Destination Location”




  8. Select the “AzureWVD” destination location.




  9. OPTIONALLY, if you want to exclude from steering the Virtual Desktop Agent traffic for monitoring purposes select the “AzureMonitor” destination location too. By default we don’t recommend to exclude this traffic to avoid excluding too many destinations that may be used or repurposed in the future for more activities that we would like to monitor.




  10. Select “Treat like local IP address” and provide a description like “Microsoft Azure VDI”




  11. Click “Save”




OPTIONAL - Application Steering Exceptions


Azure Virtual Desktops are installed with an Azure agent that runs several services performing many connections to different Azure services for different purposes. Excluding these agents from the traffic steering will ensure that the Azure communications performed by the agent won’t flow through Netskope. That said excluding the Azure agents traffic may lead to some loss of visibility as there can be some activities performed by the Azure agents we’d like to monitor. It’s not fully clear to us what potential activities the agents could perform, so we don’t recommend to exclude them from the steering, and we recommend to include the following exceptions only if the customer wants to send to Netskope the bare minimum of Azure traffic.


This optional second step is to configure a series of exclusions for specific Azure Virtual Desktop processes that run on the machine. Despite those are not properly Certificate Pinned Applications, as their traffic can technically be inspected, we can treat them as such to allow a bypass based on the service rather than sources/destinations.


The list of processes that we want optionally to exclude from steering is the following:



  1. WindowsAzureGuestAgent.exe: Azure VM Agent service

  2. WaAppAgent.exe: Azure RD Agent service

  3. WindowsAzureNetAgent.exe: Azure Network Agent service

  4. WindowsAzureTelemetryService.exe: Azure Telemetry Service

  5. metricsextension.native.exe: Azure Monitor Agent

  6. rdagentbootloader.exe: Azure Agent Bootloader


In order to create the Steering Exceptions



  1. On the Netskope Settings UI navigate to “Security Cloud Platform” - “Steering Configuration”, select the Steering Configuration (by default the “Default tenant config”) and select the “EXCEPTIONS” tab

  2. Click on “New Exception” and select “Certificate Pinned Application”

  3. Click on the field “Certificate Pinned App = None” and select the “+” button to add the Application

  4. On the “New Certificate Pinned Application” window select “Windows” as “PLATFORM” and starting from the first application from the list above fill the “DEFINITION” field with the service name and the “APPLICATION NAME” field on top with the description and click “Save”

  5. At this point select the newly created application on the “Certificate Pinned App” field and write “*” (star) as “Custom Apps Domains” to include all the traffic that the application would generate, then optionally provide a description like “Microsoft Azure VDI”, and lastly click “Save”

  6. Repeat the steps above for all the 6 processes listed above







Maintenance of the Network Destination lists


Microsoft will change/update the list of destinations in their Service Tags file and publish a new version of it. This update is quite frequent, in the other of weeks.

It is our experience with tests and working with customers that the IP addresses of the Remote Desktop Gateways don’t almost change, or they may change very infrequently. For this reason we’d recommend to update the list of exclusions only if the customer’s experiencing disconnections from the Virtual Desktop upon login, which may indicate that the connection to the RD Gateway is not being excluded, possibly because Microsoft has added or modified the list of RD Gateways IPs.





Please also note that this procedure effectively removes the current steering bypass and a new one must be created !


In order to update the “AzureWVD” and “AzureMonitor” Network Destination lists do the following:




  1. Download the latest Json file from the Microsoft Website at the address:Azure IP Ranges and Service Tags – Public Cloud






  1. Place the Json file and the Python script under the same folder, and rename the Json file as “AzureIPs.json”




  2. Run the Python script from a privileged command prompt (tested both on MAC and Windows machines)



  3. Verify the content of the file “AzureWVD.csv” that should have been created on the same folder. It be a 2-lines file where the first line starts with "AzureWVD" and the second with "AzureMonitor"


Once we have the CSV, in order to create the desired steering exceptions with it do the following:




  1. In the Netskope UI select “Policies” - “Network Locations”




  2. Select “New Network Location” - “Multiple Objects”




  3. Upload the file “AzureWVD.csv”. You’ll notice that the UI seems to indicate there are duplicated entries for “AzureVWD” and “AzureMonitor”. This is ok, the new ones will actually overwrite the old ones upon Applying the config !




  4. Verify the newly created “AzureWVD” and “AzureMonitor” network location to see if they contain the newly imported IPs




  5. Apply the changes clicking on “Apply changes”. You will notice that the duplicated entries will disappear as the new lists will overwrite the old ones




  6. We must re-create the Steering Exceptions as the previous ones would be deleted upon the destination Location overwrite !




  7. Open the Netskope Setting UI and navigate to “Security Cloud Platform” - “Steering Configuration”, select the Steering Configuration (by default the “Default tenant config”) and select the “EXCEPTIONS” tab




  8. Select “New Exception” - “Destination Location”




  9. Select the “AzureWVD” destination location.




  10. OPTIONALLY, if you want to exclude from steering the Virtual Desktop Agent traffic for monitoring purposes select the “AzureMonitor” destination location too. By default we don’t recommend to exclude this traffic to avoid excluding too many destinations that may be used or repurposed in the future for more activities that we would like to monitor.




  11. Select “Treat like local IP address” and provide a description like “Microsoft Azure VDI”




  12. Click “Save”



Hi team,

 

Everything is fine however I am not able to find the Python Script attachment anywhere.

 

Can someone help me to get it.

 

Thank you.

 

Regards,

KC

Hi KC,


aren't you able to download the file "AzureWVD.zip" at the bottom of the article ?


 


Regards,


Stefano Artioli

i cannot download the python file can you help

Apparently the download doesn't work. Here is the Python script:


import json
import csv

f = open('AzureIPs.json')
data = json.load(f)
f.close()

def solve(key, val, lis):
return next((i for i, d in enumerate(lis) if d[key] == val), None)

WVD_index=solve('id', 'WindowsVirtualDesktop', data['values'])
MNT_index=solve('id', 'AzureMonitor', data['values'])
print(WVD_index)
print(MNT_index)

with open('AzureWVD.csv', mode='w+') as csv_file:
f = csv.writer(csv_file, delimiter=',', lineterminator='
')
WVD = data["values"][WVD_index]["properties"]["addressPrefixes"]
MNT = data["values"][MNT_index]["properties"]["addressPrefixes"]
WVD_Full = ["AzureWVD","168.63.129.16/32","169.254.169.254/32"]
WVD_Full.extend(WVD)
f.writerow(WVD_Full)
MNT_Full = ["AzureMonitor"]
MNT_Full.extend(MNT)
f.writerow(MNT_Full)

Hi 

 

We have Netskope agent install into AVD and perform the above steps

 

however when user launch AVD, the screen seem to be frozen and the session is disconnected which mean the agent seem to initialize and switch to ZTNA network which cause the AVD session host server to disconnect to AVD control plane 

 

I do believe the article above will configure the exception so that traffic from AVD session host to AVD controlplane wont use ZTNA network but rather going direct using AVD backbone?

This article was HUGELY helpful. Thank you for such an excellent and very detailed write-up on this issue!

Many thanks, 🙏

BH

Reply


Terms & ConditionsCookie settings