Routing, Firewall Policies, and Security Profiles

Akins IT • November 22, 2019
Connect with us

SECURING YOUR AZURE VIRTUAL NETWORK WITH A NEXT GENERATION FIREWALL


PART 4: ROUTING, FIREWALL POLICIES, AND SECURITY PROFILES


User Defined Routes (UDR)


By default, Azure networks automatically generate system routes for connectivity between subnets within a VNET. A default route of 0.0.0.0/0 also exists to forward traffic out to the internet for VM’s residing in that VNET. With that said, introducing an NGFW virtual appliance to the environment will require that these routes be updated to utilize the NGFW as its next hop. If not, Azure traffic will continue to route through the transparent system routes and will never touch the NGFW virtual appliance.


System routes can be overridden using User Defined Routes (UDR). The UDR can be deployed via the Azure Marketplace (known as Route Table). Within the Route Table object, new routes can be specified to route subnet and internet bound traffic through the NGFW. The Route Table object will also need to be associated to each subnet that require the use of UDR’s. If different subnets require different UDR’s, multiple Route Tables can be implemented to achieve this.


Firewall Policies and NGFW UTM Features


Once Azure traffic is routed through the NGFW virtual appliance, firewall policies must be in place to allow both subnet to subnet and inside to outside communication. The benefit now is that these policies can be built out and managed using a familiar NGFW GUI, and traffic can be inspected using UTM (Unified Threat Management) features such as Antivirus (AV), Intrusion Prevention System (IPS), Web and Application content filtering.


The FortiGate virtual appliance, for example, provides Botnet C&C blocking to known malicious IP’s and domains. Sandbox cloud AV detection can be enabled to provide protection against zero-day virus’, and advanced logging and traffic analytics will be available to assist with both traffic monitoring and troubleshooting.


Full SSL inspection (deep packet inspection) should also be implemented since it provides the highest accuracy when it comes to content filtering, IPS and AV. Considering that roughly 97% of all traffic is now encrypted, full SSL inspection is a must to ensure that your environment is secure. With full SSL inspection, the NGFW acts as a MITM (man in the middle) to decrypt encrypted traffic, inspect it, then re-encrypt it for transmission to its destination.


INTERESTED IN VIEWING THE WEBINAR VIDEO ON THIS TOPIC? FILL OUT THE FORM.


By Shawn Akins October 20, 2025
October 20, 2025 — Early today, Amazon Web Services experienced a major incident centered in its US‑EAST‑1 (N. Virginia) region. AWS reports the event began around 12:11 a.m. PT and tied back to DNS resolution affecting DynamoDB , with mitigation within a couple of hours and recovery continuing thereafter. As the outage rippled, popular services like Snapchat, Venmo, Ring, Roblox, Fortnite , and even some Amazon properties saw disruptions before recovering. If your apps or data are anchored to a single cloud, a morning like this can turn into a help‑desk fire drill. A multi‑cloud or cloud‑smart approach helps you ride through these moments with minimal end‑user impact. What happened (and why it matters) Single‑region fragility: US‑EAST‑1 is massive—and when it sneezes, the internet catches a cold. Incidents here have a history of wide blast radius. Shared dependencies: DNS issues to core services (like DynamoDB endpoints) can cascade across workloads that never directly “touch” that service. Multi‑cloud: practical resilience, not buzzwords For mid‑sized orgs, schools, and local government, multi‑cloud doesn’t have to mean “every app in every cloud.” It means thoughtful redundancy where it counts : Multi‑region or multi‑provider failover for critical apps Run active/standby across AWS and Azure (or another provider), or at least across two AWS regions with automated failover. Start with citizen‑facing portals, SIS/LMS access, emergency comms, and payment gateways. Portable platforms Use Kubernetes and containers, keep state externalized, and standardize infra with Terraform/Ansible so you can redeploy fast when a region (or a provider) wobbles. (Today’s DNS hiccup is exactly the kind of scenario this protects against.) Resilient data layers Replicate data asynchronously across clouds/regions; choose databases with cross‑region failover and test RPO/RTO quarterly. If you rely on a managed database tied to one region, design an escape hatch. Traffic and identity that float Use global traffic managers/DNS to shift users automatically; keep identity (MFA/SSO) highly available and not hard‑wired to a single provider’s control plane. Run the playbook Document health checks, automated cutover, and comms templates. Then practice —tabletops and live failovers. Many services today recovered within hours, but only teams with rehearsed playbooks avoided user‑visible downtime. The bottom line Cloud concentration risk is real. Outages will happen—what matters is whether your constituents, students, and staff feel it. A pragmatic multi‑cloud stance limits the blast radius and keeps your mission‑critical services online when one provider has a bad day. Need a resilience check? Akins IT can help you prioritize which systems should be multi‑cloud, design the right level of redundancy, and validate your failover plan—without overspending. Let’s start with a quick, 30‑minute review of your most critical services and RPO/RTO targets. (No slideware, just actionable next steps.)
By Shawn Akins October 13, 2025
How a Zero-Day in GoAnywhere MFT Sparked a Ransomware Wave—and What Mid-Sized IT Leaders Must Do Now
By Shawn Akins October 13, 2025
The clock is ticking: Learn your options for Windows 11 migration, Extended Security Updates, and cost‑smart strategies before support ends.
More Posts