Cisco Secure Remote Worker Architecture for Azure

Today companies are investing in empowering their workforce to have a secure connection to the resources hosted in the Cloud. Cisco provides a secure remote worker solution that uses the Cisco AnyConnect Secure Mobility Client, Cisco Duo, Cisco Umbrella, and Cisco Advanced Malware Protection (AMP) for Endpoints.

◉ Cisco AnyConnect Secure Mobility Client: Cisco AnyConnect Secure Mobility Client empowers remote workers with frictionless, highly secure access to the enterprise network from any device, at any time, in any location while protecting the organization. It provides a consistent user experience across devices, both on and off-premises, without creating a headache for your IT teams. Simplify management with a single agent.

◉ Cisco Duo: Cisco Duo is a user-friendly, scalable way to keep business ahead of ever-changing security threats by implementing the Zero Trust security model. Multi-factor authentication from Duo protects the network by using a second source of validation, like a phone or token, to verify user identity before granting access. Cisco Duo is engineered to provide a simple, streamlined login experience for every remote user. As a cloud-based solution, it integrates easily with your existing technology and provides administrative, visibility, and monitoring.

◉ Cisco Umbrella Roaming Security Module: Cisco Umbrella Roaming Security module for Cisco AnyConnect provides always-on security on any network, anywhere, any time — both on and off your corporate VPN. The Roaming Security module enforces security at the DNS layer to block malware, phishing, and command and control callbacks over any port. Umbrella provides real-time visibility into all internet activity per hostname both on and off your network or VPN.

◉ Cisco Advanced Malware Protection (AMP) Enabler: Cisco AnyConnect AMP Enabler module is used as a medium for deploying Advanced Malware Protection (AMP) for Endpoints. It pushes the AMP for Endpoints software to a subset of endpoints from a server hosted locally within the enterprise and installs AMP services to its existing user base. This approach provides AnyConnect user base administrators with an additional security agent that detects potential malware threats in the network, removes those threats, and protects the enterprise from compromise. It saves bandwidth and time taken to download, requires no changes on the portal side, and can be done without authentication credentials being sent to the endpoint. AnyConnect AMP Enabler protects the user both on and off the network or VPN.

Figure 1 – Components of the Cisco secure remote worker solution

Cisco Secure Remote Worker Architecture for Azure

Today organizations are consuming services, workloads, and applications hosted in Azure (Public Cloud). Azure provides a wide range of services that offer ease of usability, orchestration, and management. Customers are embracing these services, but this resource consumption model opens another attack surface. Using Cisco Security controls, customers can provide a secure connection to the Azure cloud infrastructure. This remote access VPN architecture protects multi-VNet, multi-AZ (availability zone) by extending the Cisco Secure Remote Worker solution. This Architecture brings together Cisco Security and Azure Infrastructure-as-a-service (IaaS) and extends remote access VPN capabilities with Duo, Umbrella, and AMP Enabler.

Figure 2 – Secure Remote Worker architecture for multi-VNet, multi-AZ

The above network design has the following components and services:

◉ Cisco ASAv or Cisco NGFWv for Remote access VPN termination (TLS or DTLS)

◉ Cisco Secure AnyConnect Mobility Client on the endpoints

◉ Microsoft Windows 2019 Active Directory for LDAP

◉ Cisco Duo for Multi-Factor Authentication

◉ Umbrella Security Roaming Module for DNS Layer Security

◉ AMP Enabler for protection against Malware

This Architecture is designed on the bases of the Hub and Spoke model, the hub-vnet has firewalls for VPN termination. The Hub-VNet is connected to spoke-VNets using VNet peering. VNet peering uses the Azure backbone network and the Azure backbone network provides higher throughput.

◉ Remote Access VPN sessions are load balanced by Azure Traffic Manager

◉ Azure Internal Load Balancer (Standard) is used for non-VPN traffic load balancing (East/West)

◉ Azure External/Public Load Balancer is used for non-VPN traffic load balancing (North/South)

Traffic Flow 

Remote Access VPN: Azure blocks layer-2 visibility required for native HA and VPN load balancing to work. To enable resiliency and VPN load balancing, one must rely on the native cloud services such as Azure Traffic Manager (ATM), DNS, and UDR. In this architecture, VPN users send VPN traffic to the Azure Traffic Manager. ATM tracks all the firewalls using probes, and it load-balances VPN connection endpoints (Cisco Firewalls).

◉ Each Firewall has a separate VPN pool

◉ Azure User Defined Route (UDR) forwards traffic back to the correct firewall

◉ Azure Traffic Manager load balances the RAVPN traffic

Figure 3 – Secure Remote Worker architecture for multi-VNet, multi-AZ (RA VPN Traffic Flow)

Non-VPN (East/West): Firewalls in the HubvNET inspects east-west traffic, each subnet in the spoke VNet has a route-table that has a user-defined route (UDR) pointing to Azure ILB “virtual-IP address”. Traffic lands on ILB and ILB forward it to the firewall. The firewall inspects the traffic; if traffic is allowed, it is sent to the destination VNet using VNet peer. Return traffic is forwarded back to the ILB because of the similar UDR is applied on destination VNet also. ILB maintains the state and sends traffic back to the same firewall that processed the initial packet flow.

Figure 4 – Non-VPN East/West Traffic Flow

Non-VPN (North/South)

◉ Outbound Traffic Flow: Each spoke subnet has a route-table associated with it. UDR controls traffic routing, and it has a default route that points to ILB’s virtual IP (VIP). HubvNET has ILB, and ILB points to firewalls for internet connectivity. Internet traffic is load-balanced on the perimeter firewall, and traffic is SNATed to the outside interface IP address. Outbound traffic does not hit the external load balancer because a public IP mapped to the outside interface of the firewall and UDR on the outside subnet used 10.82.1.1 as a default gateway. Azure ILB used in this architecture is a standard SKU that requires explicit Azure NSG to allow traffic on firewalls (backend devices). There is an azure NSG applied to inside and outside interfaces of firewalls; this NSG has allow-all rule applied, but you can restrict traffic according to your Infosec policy.

Figure 5 – Non-VPN North/South (Outbound Traffic Flow)

◉ Inbound Traffic Flow: External users would access frontend IP on the Azure public load balancer (ELB), ELB has external interfaces in the backend pool. ELB is responsible for load balancing incoming non-VPN traffic, ELB sends traffic to the firewall if allowed traffic is SNATed to inside interface to maintain traffic symmetry.

Figure 6 – Non-VPN North/South (Inbound Traffic Flow)