As the digital landscape continues to evolve, businesses are becoming more reliant on interconnected systems and networks to streamline operations and maximize efficiency. With this increasing dependence on interconnectedness, securing the flow of data within an organization has become a paramount concern. Firewalls, the primary gatekeepers of network security, play a crucial role in protecting sensitive information from unauthorized access. However, filtering east-west traffic, or lateral traffic, poses unique challenges for these guardians of the cyber realm.
Traditionally, firewalls have excelled at filtering traffic flowing from the outside world (north-south traffic) to internal networks and vice versa. This approach ensured that external threats were kept at bay, preventing malicious actors from gaining unauthorized access to sensitive data and systems. Unfortunately, this security paradigm falls short in the face of east-west traffic, which involves communication between different devices and servers within the internal network itself.
When it comes to Cloud networking architecture, most of the enterprises opt for Hub-Spoke model, which provide flexibility of scaling and ease of management for future growth.
Typical scenario of most small to medium enterprises networking architecture is shown below.
In the aforementioned architecture, the Azure firewall primarily resides within the Hub subscription, and the routing for all the spokes is centrally managed through the Hub. Users define routes, and firewall networking rules are utilized to regulate this capability. While this configuration may initially appear straightforward, as with many implementations, there are certain caveats to consider.
During a recent deployment for one of our customers, we encountered several challenges, which are outlined below:
Challenge #1 On-prem to Azure Traffic Filtration:
The client’s specific requirement entailed inspecting traffic originating from the on-premises data center and destined for the data center through a firewall. To accomplish this, our approach involved designing User-Defined Routes (UDRs) to be attached to the gateway subnet for downstream traffic and to the spoke subnets for upstream traffic.
Upon investigation, we identified the presence of over 100 routes propagated to Azure via Border Gateway Protocol (BGP) from the on-premises infrastructure. Manually configuring all these routes in the UDRs to direct traffic through the firewall proved to be an impractical and non-scalable solution for future needs. To address these challenges effectively, we devised a solution involving route summarization on the on-premises router. By broadcasting a reduced number of routes through the use of super subsets of CIDR routes before advertising to the Azure environment, we can achieve efficient traffic management and ensure a more sustainable and future-proof resolution to the issue.
Challenge #2 Hub to Spoke Azure Traffic Filtration:
One of the secondary challenges encountered during the inspection of downstream traffic from Azure Hub to Azure Spokes pertains to certain Azure PaaS services that do not support User-Defined Route (UDR) configuration or fail to adhere to the UDR settings when attached to the respective subnets. A prominent example of such a service is Bastion, which is typically recommended by Microsoft to reside in the Hub and be accessed across multiple spokes environments. Unfortunately, Azure Bastion directs traffic towards the VM IP with a /32 prefix, rendering it impossible to establish a UDR to override this route priority.
To address this issue, the only viable solution is to exclude the Bastion subnet from the UDRs, necessitating a shift in the upstream traffic strategy from Vnet CIDR to Subnet CIDR range to mitigate this challenge. However, this approach introduces a new predicament as the management of such UDRs becomes arduous and complex. Any addition of a single subnet to the Hub would require modifications across the UDRs in all spokes, compounding the maintenance overhead.
An improved approach to filtering EAST-West traffic involves the utilization of Network Security Groups (NSGs) at the subnet level in conjunction with Firewall networking rules until the Azure Core services fully support User-Defined Routes (UDRs). While alternative solutions exist, such as relocating certain architecture components from the Hub to Spokes, it is essential to acknowledge the potential drawback of increased costs due to the necessity of duplicating these components across multiple spokes.