SC-500 Network Security: NSGs, Virtual Network Manager, VPN, Private Link and Azure Firewall

A network security group (NSG) is a stateful, priority-ordered list of allow and deny rules that Azure applies to traffic entering or leaving a subnet or a network interface (NIC). Each rule has a priority from 100 to 4096; Azure evaluates rules from the lowest number upward and stops at the first rule that matches the flow's source, destination, port and protocol. A later rule never gets a say, even if it is more specific or has the opposite action, so an exception must sit at a lower number than the broad rule it carves out of.

Because NSGs are stateful, you write rules only for the direction a connection starts in: an allowed inbound HTTPS session gets its return traffic automatically, and an outbound rule on the server does nothing for inbound reachability.

Default rules

Every NSG carries default rules that you can't delete but can override with lower-numbered custom rules:

Two consequences matter in practice. First, a brand-new NSG with no custom rules still lets peered and connected networks in through AllowVnetInBound, because the VirtualNetwork tag includes peered address spaces. (A peering's Allow forwarded traffic setting is a different thing: it covers traffic that originates outside the peered network, such as flows forwarded through an appliance there.) Second, a custom "deny all" rule placed above the defaults also hides AllowAzureLoadBalancerInBound, so health probes fail and backends are marked unhealthy; re-allow the AzureLoadBalancer tag at a lower number than your deny.

Subnet NSG plus NIC NSG

You can associate one NSG with a subnet and another with a NIC in it. Both are gates on the same path: inbound traffic is evaluated by the subnet NSG and then by the NIC NSG, outbound traffic by the NIC NSG and then by the subnet NSG, and the flow passes only if both allow it. A NIC NSG holding only default rules blocks internet traffic that the subnet NSG allows, so either add the allow to the NIC NSG or remove the redundant association.

Application security groups

An application security group (ASG) is a named group of NICs that you use as the source or destination of an NSG rule instead of IP addresses. You write "web tier to database tier on TCP 1433" once, then add each new VM's NIC to the right ASG; the rule follows automatically, with no rule edits and no IP lists. ASGs are not Azure resource tags, which NSG rules can't reference. All NICs in an ASG must be in the same virtual network, and a rule that uses ASGs as both source and destination needs them in the same virtual network. Across a peering, describe the remote side with its address prefix and keep the ASG for the local side; the broad VirtualNetwork tag would admit far more than the one tier.

Azure Virtual Network Manager (AVNM) lets a central team enforce network access policy across many virtual networks, subscriptions and management groups with security admin rules, which Azure evaluates before any NSG. Application teams keep managing their own NSGs; the admin rules sit above them and decide whether the NSGs are even consulted.

Admin rules have their own priorities (1 to 4096, lowest first), evaluated before NSGs, and the first matching admin rule wins. To exempt a jump-host range from an organisation-wide Deny on RDP, the exception must have a lower priority number than the Deny, and it must be Always Allow if team NSGs must not be able to block it. Use Deny for "must never be reachable, whatever a team opens" policies such as inbound RDP or SMB from anywhere.

Network groups, configurations and deployment

• Network groups define which virtual networks a configuration targets. Static membership lists networks by hand; dynamic membership uses an Azure Policy condition (for example a tag such as Environment=Production or a name pattern), so new matching networks join automatically.
• A security admin configuration holds one or more rule collections; each collection contains rules and is associated with network groups.
• Nothing takes effect until you deploy the configuration to the target regions. Creating the configuration and its rules changes no traffic.
• Deployments follow a goal state model: what you commit to a region replaces what was there. Only one security admin configuration from a network manager can be deployed to a region at a time, so deploying a second configuration on its own removes the first. To enforce several teams' rule sets in one region, put them in the same configuration as separate rule collections and redeploy it. (Connectivity configurations, by contrast, can be deployed side by side.)
• Once a configuration is deployed, a virtual network that joins a targeted group in that region picks it up without another deployment.

Connectivity configurations (hub-and-spoke or mesh peering) are a separate configuration type; they connect networks and enforce no traffic rules.

You secure Azure Virtual WAN by deploying Azure Firewall (or a supported security appliance) inside the virtual hub and configuring routing intent, which tells the hub to send traffic through that firewall. Routing intent has two independent routing policies:

• Configure only the policy you need. If internet egress must stay on an on-premises proxy, use only Private Traffic so that branch-to-spoke and spoke-to-spoke traffic is inspected without a new default route.
• Inter-hub inspection needs routing intent on every hub involved. Hand-built custom route tables with static routes to the firewall are the older method and can't be combined with routing intent, so remove them and configure routing intent on each hub to get symmetric inspection.
• Internet egress is hub-local. A default route learned in one hub doesn't propagate to another hub, so spokes on a hub without a firewall never learn the other hub's 0.0.0.0/0. Each hub that needs inspected internet egress needs its own firewall and Internet Traffic policy.
• Each hub connection has a Propagate default route setting. Turning it off for one connection keeps that virtual network from learning the hub's default route, so it can keep using its own approved egress while every other spoke uses the hub firewall.

NSGs on spoke subnets still filter traffic, but they don't change where the hub routes it; inspection in a Virtual WAN is a routing decision.

VPN Gateway security comes down to two choices: how point-to-site (P2S) users authenticate, and which IPsec/IKE cryptography a site-to-site (S2S) tunnel uses.

Point-to-site authentication

Disabling a user in Entra ID doesn't stop a certificate-authenticated tunnel, because the gateway never asks Entra ID; the certificate itself must be revoked. Tunnel types IKEv2 and SSTP can't carry Entra ID authentication; OpenVPN works on Windows, macOS and Linux clients.

Site-to-site cryptography

By default a gateway offers a set of standard IKE/IPsec proposals. To meet a compliance requirement such as AES256, SHA256 and a specific Diffie-Hellman group, apply a custom IPsec/IKE policy to the connection resource. The policy is per connection, so other tunnels on the same gateway keep their settings; the local network gateway only describes the remote site's public IP and address prefixes. A route-based gateway can also connect to a branch device that supports only policy-based tunnels: apply a custom IPsec/IKE policy and enable policy-based traffic selectors on the connection, and configure the branch device with a traffic selector for each combination of on-premises and Azure prefixes. Recreating the gateway as policy-based would break its other connections.

Microsoft Entra Private Access is the Zero Trust network access part of Microsoft's Global Secure Access service: it gives users identity-checked access to private apps on-premises or in Azure without a VPN. Three components make it work:

• The Global Secure Access client on the user's device captures traffic for configured private resources and sends it to the service.
• The Microsoft Entra private network connector, installed on a Windows Server that can reach the apps, carries traffic from the service to them over outbound connections only; connectors are organised in connector groups.
• The Private Access traffic forwarding profile must be enabled, and users or groups assigned to it, for the client to acquire private traffic.

Quick Access versus per-app access

When a per-app segment overlaps a Quick Access segment, traffic that matches the more specific per-app segment is handled by that enterprise app, so users who aren't assigned to it lose access to that destination even though Quick Access still lists the wider range.

For name resolution of internal short names, enable private DNS on Quick Access and add the internal DNS suffixes (for example ad.contoso.com); the client then sends queries for those suffixes to be resolved by the DNS servers the connectors use. The lookup happens on the connector side of the network, which is why it works for a device that is nowhere near Azure.

Microsoft Entra application proxy publishes web apps over HTTP/HTTPS; Private Access handles any TCP/UDP app such as SMB, RDP or SSH.

A private endpoint is a read-only network interface with a private IP address from your subnet that connects to one specific Private Link resource (for example one storage account's blob service or one Azure SQL logical server). A service endpoint instead extends a subnet's identity to a whole Azure service over the Microsoft backbone, while the service keeps its public IP address.

For the strongest isolation, use private endpoints, disable public network access on the resource, and don't enable service endpoints on the client subnet. A storage account needs a separate private endpoint for each sub-resource it serves (blob, file, queue, table, dfs, web).

DNS for private endpoints

Clients keep using the resource's normal name (account.blob.core.windows.net); public DNS answers with a CNAME into a privatelink zone. The private endpoint is used only if that name resolves to its private IP, so:

• Create the matching privatelink private DNS zone (for blob, privatelink.blob.core.windows.net) and link it to every virtual network whose clients use Azure-provided DNS. Without it, clients resolve the public IP, and with public access disabled they get 403 or connection errors. Don't create a zone for the public name itself; it would answer for every account in that namespace.
• On-premises DNS servers can't query Azure DNS (168.63.129.16 is reachable only from inside Azure). Deploy Azure DNS Private Resolver with an inbound endpoint in the virtual network linked to the zones, and add a conditional forwarder for the public zone (for example blob.core.windows.net) on the on-premises servers that points at the inbound endpoint's IP. Outbound endpoints and forwarding rulesets solve the opposite direction: Azure resolving on-premises names.

Private endpoint network policies decide whether NSGs and user-defined routes (UDRs) apply to private endpoints in a subnet, and they are disabled by default. Until you enable them, an NSG on the subnet doesn't filter traffic to the private endpoints, even though it filters every other resource in that subnet. You enable support per subnet for network security groups, for route tables, or for both; you can't associate an NSG with the endpoint's own read-only NIC.

Forcing traffic to a private endpoint through Azure Firewall takes two things:

1. Enable network policies for route tables on the subnet that hosts the private endpoints.
2. On the client subnet's route table, add a UDR whose prefix is equal to or more specific than the virtual network's address space (for example the private endpoint subnet's prefix) with the firewall as next hop.

The reason is longest-prefix-match routing. A 0.0.0.0/0 route, or a /8 that is broader than the virtual network's own /16, loses to the virtual network's system route and never catches traffic to an endpoint in the same network. Route tables on the private endpoint subnet itself don't steer the clients' traffic. Microsoft recommends that the firewall SNAT traffic bound for private endpoints so return traffic is symmetric.

The portal doesn't display effective routes or effective security rules for a private endpoint's NIC, so validate these paths from the client side.

Azure Private Link service lets a provider publish its own TCP/UDP service so that consumers reach it through private endpoints in their own virtual networks, across subscriptions and Microsoft Entra tenants, with no peering, no overlapping-address problems and no public IPs. The generally available design places the service behind the frontend IP configuration of an internal Standard Load Balancer (Microsoft has also previewed a variant that targets private IP addresses directly). Consumer traffic is source-NATed to NAT IP addresses taken from a subnet in the provider's network, which is why backends see a few provider-side addresses rather than consumer IPs.

Requests that aren't auto-approved arrive Pending until the provider approves or rejects them, and only Approved connections pass traffic.

Azure Firewall is a managed, stateful network firewall, configured through a firewall policy, that filters traffic at layers 3 to 7 and comes in three SKUs with increasing capability.

Basic targets small environments with lower throughput; choose Standard when you must block known-malicious addresses or need DNS proxy, and Premium only when traffic must be decrypted, matched against IDPS signatures or filtered by URL path.

How rules are processed

• Threat intelligence is evaluated before rules. Then rule types run in a fixed order: DNAT, then network, then application rules.
• Inside a policy, rule collection groups are processed by priority (lowest number first) and collections within them by their priority, but the rule-type order still applies across all of them. A matching network rule is terminating: once a broad network rule allows TCP 443, application rules are never consulted, whatever their priority numbers. To filter HTTPS by FQDN, allow it with application rules instead of a broad network rule.
• With a parent (base) policy, the parent's rule collection groups always take precedence over the child's, regardless of priority numbers. An exception to a central deny therefore has to go into the parent policy, ahead of the deny.

DNS proxy and FQDN filtering in network rules

Network rules can use FQDNs only when the firewall resolves names the same way as the clients. Enable DNS proxy in the policy's DNS settings (the firewall then listens on port 53 and forwards to Azure DNS or your custom servers), and set the virtual network's DNS servers to the firewall's private IP. Application rules don't need this, because the firewall reads the FQDN from the HTTP Host header or the TLS SNI.

TLS inspection (Premium)

TLS inspection decrypts traffic, inspects it and re-encrypts it with certificates that the firewall issues from an intermediate CA certificate you provide. Store it as a password-less PFX in Azure Key Vault and give the firewall policy a user-assigned managed identity with Get and List permissions on secrets (the PFX is read as a secret). The firewall mints each site's certificate itself from that intermediate CA, and clients must trust the issuing CA chain.

Inbound web traffic

Azure Firewall application rules and URL filtering are for outbound and east-west traffic. To inspect inbound HTTP requests for attacks such as SQL injection, put Application Gateway with a WAF policy (Prevention mode blocks, Detection only logs) in front of the app. Firewall IDPS signatures aren't a substitute for a WAF.

Azure Network Watcher diagnostics show which rules and routes actually apply to a flow, so you can prove why traffic is allowed or blocked instead of reading NSGs one by one. Pick the tool by the question you're asking:

Next hop tells you which route won, and the winner follows one rule: Azure picks the route with the longest prefix match, and when two routes have the same prefix, a user-defined route beats a BGP-learned route, which beats a system route. So when traffic takes an unexpected path, read the next hop type and route type in the output, then fix the route table associated with the source subnet: a user-defined route for an equal or more specific prefix overrides whatever route it currently uses. NSGs only allow or deny; they never change where a packet goes. Gateway route propagation is a setting on the route table associated with a client subnet and controls whether that subnet learns the gateway's BGP and VPN routes; it isn't configured on the GatewaySubnet.