About this Case Study:
One common scenario on Azure is finding organisations using Azure Firewall that wants to connect to Netskope NewEdge without disrupting or changing the current architecture too much.
Another common scenario is that companies are obligated to use Azure Firewall for compliance purposes or because it is part of the service provided under management for their providers.
This Case Study aims to provide the essential information to deploy and troubleshoot the Cloud Security Connector for Azure when connecting Servers and Virtual Desktops to NewEdge and using Azure Firewall.
Customer requirements:
The customer is an organization with the following traffic steering requirements:
1. Http/s only traffic to NewEdge because the customer has no Cloud Firewall license.
2. Non-Http/s traffic goes directly to the Internet.
3. All traffic must traverse via an Azure Firewall for compliance with local regulators.
4. Authentication exemption for traffic arriving from Server Subnets.
5. The Source IP of the Servers must be visible at NewEdge.
6. Traffic from Servers Subnets will reach NewEdge via IPsec Tunnels at 1 Gbps or more.
7. Virtual Desktops will have the Netskope Client installed and reach NewEdge directly to the Internet and not via the IPsec tunnels.
8. Some Http/s destinations must go direct to the Internet via local Public IP, and not via NewEdge. (i.e. to apply MSFT Conditional Access)
Network Diagram:
How the solution works:
Important note: The Azure FW has severe limitations on the Source NAT configuration and cannot split traffic to the Internet Source NATed or not Source NATed per Source IP. In this case, we need the Servers' private source IP visible at the Cloud level (no source NAT) and the VDI direct to the Internet (Source Nat applied). The Azure FW is not capable of doing this. For this reason, we send all traffic via the CSC, which has no limitations in this regard. |
This chapter shows how to achieve the customer's requirements, one by one.
Http/s only traffic to NewEdge because the customer has no Cloud Firewall license.
After passing via the Azure Firewall, the CSC splits the traffic, sending Http/s from Server Subnets via the IPsec Tunnels and the traffic from VDI Subnets direct to NewEdge Nodes.
Non-Http/s traffic goes directly to the Internet.
After passing via the Azure Firewall, the CSC sends all Non-Https/s traffic direct to the Internet.
All traffic must traverse via an Azure Firewall for compliance with local regulators.
The default route to the Internet (0.0.0.0/0) for all internal Subnets is the Azure Firewall GW IP.
Authentication exemption for traffic arriving from Server Subnets.
On the Netskope console, configure Bypass Settings -> SOURCE IP ADDRESS BYPASS.
The Source IP of the Servers must be visible at NewEdge.
The CSC provides full visibility of internal devices IPs at Cloud Level.
Traffic from Servers Subnets will reach NewEdge via IPsec Tunnels at 1 Gbps or more.
The CSC Mux 4 aggregates 4 x IPsec tunnels (1 Gbps), and the CSC Mux 8 aggregates 8 x IPsec (2 Gbps)
Virtual Desktops will have the Netskope Client installed and reach NewEdge directly to the Internet and not via the IPsec tunnels.
The CSC can split traffic per Source IPs, Destination IPs, Protocol and Port. Therefore, we will create a "routed bypass rule" for the VDI Subnets going to NewEdge Nodes on port 433. This "routed bypass rule" will send the traffic directly via Internet Gateway and not via the IPsec Tunnels.
Some Http/s destinations must go direct to the Internet via local Public IP, and not via NewEdge.
Similar than before, we will create a "routed bypass rule" to reach some Http/s destinations directly via the Internet.
| Please, see the attached PDF file for a detailed configuration of each component of the solution: Azure Firewall, Cloud Security Connector, Subnets, Route Tables, Security Groups, etc. |