Theory — Next-Generation Firewalls (NGFW)
Theory — Next-Generation Firewalls (NGFW)
Network Security Groups give you IP/port-level rules.
A Next-Generation Firewall goes further.
What a traditional firewall does
A traditional firewall filters traffic based on:
source IP
destination IP
port
protocol (TCP / UDP)It answers the question: is this connection allowed?
What an NGFW adds
An NGFW can inspect the actual content of the traffic, not just the connection metadata.
| Capability | Traditional Firewall | NGFW |
|---|---|---|
| IP / port rules | Yes | Yes |
| Stateful connection tracking | Yes | Yes |
| Application identification (Layer 7) | No | Yes |
| TLS inspection | No | Yes (with cert) |
| Intrusion detection / prevention (IDS/IPS) | No | Yes |
| URL / domain filtering | No | Yes |
| Threat intelligence integration | No | Yes |
| User identity awareness | No | Yes (with directory integration) |
Layer 7 inspection
Traditional firewalls operate at Layer 3 (IP) and Layer 4 (TCP/UDP).
An NGFW operates at Layer 7 — the application layer.
This means an NGFW can:
- allow HTTP but block specific URLs
- allow HTTPS but block traffic to known malicious domains
- allow traffic from a specific user even if their IP changes
- detect an exploit pattern inside a valid TCP session
NGFW in Azure: Azure Firewall Premium
Azure offers a managed NGFW called Azure Firewall.
The Premium tier adds NGFW capabilities:
TLS inspection
IDPS (Intrusion Detection and Prevention System)
URL filtering
Web categoriesAzure Firewall sits in a dedicated subnet (typically called AzureFirewallSubnet) and all traffic in the VNet is routed through it using User Defined Routes (UDR).
NGFW vs NSG
These are complementary, not alternatives.
| NSG | ASG | Azure Firewall (NGFW) | |
|---|---|---|---|
| Scope | Subnet or NIC | Logical group of NICs | Entire VNet (hub) |
| Rules | IP / port | Used in NSG rules | Application, FQDN, IDPS, URL |
| Applies to | Any resource with NIC | VMs only | All traffic routed through it |
| Managed service | Yes | Yes | Yes |
| Stateful | Yes | N/A (not a filter) | Yes |
| TLS inspection | No | No | Yes (Premium) |
| Cost | Free | Free | Significant hourly cost |
A common pattern is both NSG and Firewall:
- NSGs enforce subnet-level allow/deny rules
- Azure Firewall enforces application-level and threat-intelligence rules centrally
ASGs (Application Security Groups) are not a separate security layer — they're logical labels you assign to VMs to simplify NSG rule management. Instead of writing NSG rules like "allow 10.0.1.10, 10.0.1.11, 10.0.1.12", you write "allow ASG web-tier". Covered in NSG theory (Lab 2.6).
Hub-and-spoke with NGFW
In larger environments, a hub-and-spoke topology centralises the firewall.
All traffic between spokes — and all traffic to/from the internet — passes through the firewall.
This gives a single point of inspection and policy enforcement.
Bring Your Own Firewall (BYOF)
Azure Firewall is not the only option. You can deploy a third-party network virtual appliance (NVA) from the Azure Marketplace — a VM running a commercial firewall product — and route traffic through it instead.
Common NVAs include Palo Alto VM-Series, Fortinet FortiGate, Check Point CloudGuard, and Cisco FTD. These are the same firewall products used on-premises, packaged as Azure VMs.
| Azure Firewall | Third-party NVA (BYOF) | |
|---|---|---|
| Management | Azure Portal / Firewall Policy | Vendor console (Panorama, FortiManager, etc.) |
| Feature set | Azure-defined | Full vendor feature set |
| Integration | Native Azure (RBAC, Monitor, Sentinel) | Vendor-specific; Azure Monitor via syslog |
| Existing licence | Not applicable | Bring existing enterprise licence (BYOL) |
| Operational model | Fully managed PaaS | You manage the VM, HA, patching |
| Typical use case | Azure-native teams | Regulated orgs with existing vendor standardisation |
The NVA sits in its own subnet in the hub VNet. Traffic is routed through it using the same UDR mechanism as Azure Firewall.
Info
BYOF is common in organisations that have standardised on a specific vendor on-premises and want consistent policy and tooling across both environments. The firewall rules, threat signatures, and reporting all come from the same place.
User Defined Routes and forcing traffic through a firewall
By default, Azure routes traffic between subnets in a VNet automatically using system routes. These routes are implicit — you do not see them, and you cannot delete them.
The problem: system routes do not send traffic through your firewall. Traffic between two subnets goes directly, bypassing any NVA or Azure Firewall you have deployed.
A User Defined Route (UDR) overrides a system route. You create a route table, add a route that says "for this destination, send traffic to this next hop", and associate the route table with a subnet.
Destination: 0.0.0.0/0 (all traffic)
Next hop type: Virtual appliance
Next hop address: 10.0.0.4 (firewall private IP)When this route table is associated with a subnet, all outbound traffic from that subnet — including internet-bound traffic — is sent to the firewall first.
Common UDR patterns
| Route | Next hop | Effect |
|---|---|---|
0.0.0.0/0 → firewall | Virtual appliance | All internet-bound traffic inspected |
10.0.0.0/8 → firewall | Virtual appliance | All inter-spoke traffic inspected |
0.0.0.0/0 → internet | Internet | Bypass firewall for a specific subnet |
Routing asymmetry
UDRs must be symmetric. If traffic from subnet A to subnet B goes through the firewall, return traffic from B to A must also go through the firewall — otherwise the firewall's stateful connection tracking breaks and drops the return packets.
In a hub-and-spoke topology this means route tables on both subnets, or a design where all traffic enters and exits through the hub.
UDRs and private endpoints
Private endpoint subnets need careful route table design. If you send all traffic to the firewall (0.0.0.0/0), the firewall must have a rule allowing traffic to the private endpoint IPs — otherwise your app loses access to Cosmos DB or Key Vault even though the private endpoint is correctly configured.
A common approach is to exclude the private endpoint subnet CIDR from the forced-routing rule:
10.0.2.0/24 → VirtualNetworkGateway (or none) ← private endpoint subnet, bypass firewall
0.0.0.0/0 → Virtual appliance (firewall) ← everything elseWhen to use an NGFW
| Scenario | Recommendation |
|---|---|
| Internal lab / learning environment | NSG is sufficient |
| Production workload, internet-facing | Consider Azure Firewall Standard |
| Regulated environment (PCI, ISO 27001) | Azure Firewall Premium + IDPS |
| Multi-team, multi-VNet organisation | Hub-and-spoke with Azure Firewall |
| Outbound traffic filtering (egress control) | Azure Firewall with FQDN rules |
Key takeaway
An NSG says: this port is open or closed.
An NGFW says: this traffic is allowed, inspected, and verified against threat intelligence.
Both are tools. The threat model determines which is appropriate.
Course scope
In this course, we use NSGs and App Service access restrictions.
Azure Firewall is not deployed in the labs because of cost.
But understanding what it adds — and when you need it — is part of designing a production-grade architecture.