TL;DR
NSX to Azure segmentation is an architectural translation problem, not a firewall-rule conversion exercise. Preserve the application relationships, workload membership, enforcement scope, default-deny behavior, and operational evidence behind the source policy. Azure network security groups, application security groups, centralized firewalls, private endpoints, and hybrid controls perform different responsibilities and must be combined deliberately. Use a phased migration process that validates required connections, prohibited connections, changing membership, and recovery paths before retiring the source controls.
Introduction
A firewall export is useful migration evidence. It is not a target security architecture.
In an NSX environment, a rule can depend on group membership, service definitions, enforcement scope, policy ordering, and the network path available to the workload. Moving the virtual machine does not explain how those relationships should behave after the application enters Azure.
Consider a production application with web, API, and database tiers. The migration team recreates the expected application connections, confirms that transactions complete, and receives application-owner approval. That proves an important part of the migration, but it leaves another question unanswered: can an unrelated workload now reach the database?
This is where network policy translation becomes more demanding than connectivity validation. The target must preserve the required communication while preventing access that the original design intentionally excluded.
The practical objective is to translate each important security requirement into an identified target control, an enforcement location, an accountable owner, and a repeatable acceptance test. Rule names and object counts can support traceability, but neither demonstrates that the boundary survived.
Scope and Assumptions
This article focuses on applications moving from NSX-protected virtual machines into native Azure virtual machines, including a coexistence period in which dependencies remain on-premises. Private endpoints are included where a dependency moves to a managed Azure service.
Azure VMware Solution is a separate destination decision. Microsoft documents that its private clouds retain VMware components, including NSX. That path requires an NSX-aware preservation and integration assessment rather than an automatic rewrite into native Azure controls.
The examples assume an established Azure landing zone, controlled workload deployment, identified application owners, and an approved hybrid connectivity design. Azure Local SDN and Kubernetes network policy require their own platform-specific translation and are outside the worked example.
The configurations below illustrate design decisions. They are not a complete deployable ruleset or a claim of lab-validated equivalence.
Current State and Target State
Start by separating the responsibilities that the source environment may present through a smaller number of integrated objects.
Broadcom’s NSX API documentation distinguishes group definitions from firewall rules and their enforcement scope. Microsoft’s Azure documentation similarly separates workload grouping, network filtering, routed inspection, and centrally managed network rules.
| Source responsibility | Azure or hybrid implementation | What the translation must preserve |
|---|---|---|
| Identify application members | Application security groups for eligible Azure VM interfaces, plus controlled endpoint inventories where needed | The membership condition, not only the group name |
| Restrict workload communication | NSGs at the selected subnet or network-interface boundary | Approved source, destination, protocol, port, and initiation direction |
| Enforce policy at a particular location | NSG associations and explicitly designed transit enforcement | Coverage of every relevant communication path |
| Inspect traffic crossing a routed boundary | Azure Firewall or an approved network virtual appliance | Required inspection without an unexamined bypass |
| Apply central network guardrails | Azure Virtual Network Manager security admin rules, where supported | Central restrictions without accidentally overriding workload controls |
| Reach a managed service privately | Private endpoints, DNS integration, applicable network policies, and service authorization | Access to the intended service instance through the approved path |
This is a responsibility map, not a feature-equivalence table.
An application may need several target controls to preserve one source requirement. Another source rule may be unnecessary because the dependency has been retired. Both are legitimate outcomes when the decision is documented and approved.
The migration should preserve required security outcomes, not reproduce every historical exception.
Translate the Security Requirement Before Selecting the Control
Capture More Than the Rule Row
For each policy in scope, retain its identifiers, source and destination definitions, resolved services, action, direction, enforcement scope, ordering context, and logging configuration.
Broadcom’s distributed firewall rule documentation makes an important distinction: source and destination fields describe matching traffic, while scope identifies where the rule is enforced. Copying the matching fields while changing the enforcement location can therefore change the protection.
Group evidence needs similar care. Preserve both the membership expression and a timestamped view of the members it currently selects. The expression explains how future workloads should qualify; the snapshot explains what the policy protected when the migration assessment occurred.
Neither should replace the other.
A list of current addresses loses the lifecycle behavior of a dynamic group. A membership expression without resolved members makes it harder to discover unexpected inclusions, stale classifications, or application dependencies.
Separate Approved Intent from Observed Traffic
Traffic discovery helps identify dependencies, but observed communication is not automatically approved communication.
A maintenance session, temporary troubleshooting rule, or obsolete integration may appear in the evidence. Conversely, a quarterly batch process or recovery dependency may be absent from a short observation window.
Use discovery to ask better questions. Have the application owner confirm the business requirement and the security owner confirm the boundary. Record temporary migration access separately from steady-state application access.
For the example application, the approved requirement might be:
Production Orders API instances may initiate database connections to the production Orders database. Web-tier instances, development systems, unrelated applications, and unclassified workloads may not.
That statement is more useful than “allow TCP 1433.” It identifies the permitted relationship and the access that must remain excluded.
Treat Membership as Part of Deployment
Microsoft’s application security group documentation limits ASG membership to interfaces within the same VNet. When an NSG rule uses ASGs as both source and destination, those groups must also belong to the same VNet.
An ASG is therefore not a portable enterprise application identity spanning Azure VNets and on-premises systems.
For eligible Azure VM workloads, make membership an explicit deployment responsibility. The deployment process should establish the correct classification, associate the intended controls, and validate the resulting access before admitting the instance into service.
For cross-VNet or on-premises communication, use a representation that the selected control can evaluate, such as an approved address inventory. Replacing a small application group with an entire subnet is an access expansion unless every workload in that subnet is intentionally authorized.
Worked Example: Translating a Three-Tier Application
Assume the Orders application will ultimately run in one Azure VNet, with separate web, API, and database subnets. The application uses TCP 8443 between web and API, and a deliberately configured TCP 1433 database listener.
These ports are example requirements, not a general prescription.
The diagram shows approved initiation relationships, not physical routing. The denied path is as important as the permitted paths.
Create role-specific ASGs and place their membership under deployment control. For the dedicated database subnet, a simplified inbound policy fragment would be:
| Priority | Source | Destination | Protocol and destination port | Action |
|---|---|---|---|---|
| 200 | asg-orders-api-prod | asg-orders-db-prod | TCP 1433 | Allow |
| 4000 | Any | Any | Any | Deny |
Source ports are unrestricted in this fragment because the application requirement concerns the destination listener.
Before deploying the deny rule, add the approved administration, monitoring, backup, replication, health-probe, and other operational dependencies. The example also assumes that no security admin Always allow rule overrides the intended NSG restriction.
The catch-all deny is deliberately not limited to the database ASG. Within this dedicated subnet, a database VM that loses its ASG membership should lose application access rather than fall through to a broader network allowance.
Microsoft’s NSG overview documents default rules permitting VirtualNetwork traffic. Adding only the application allow rule would not remove that broader permission.
The source side must also be considered. Where an outbound baseline is enforced on the API tier, explicitly permit the approved database connection and its other required dependencies. Where both subnet and NIC NSGs exist, Microsoft documents that the relevant checks must permit the connection; an allow in one does not cancel a deny in another.
Finally, distinguish connection initiation from response traffic. NSGs are stateful. Permitting the API’s database connection does not require a separate rule granting the database permission to initiate arbitrary connections back to the API.
Extending the Policy Across a Hybrid Boundary
During coexistence, the database may remain on-premises while the API tier moves into Azure. The security requirement remains the same, but the enforcement design changes.
The following example assumes that hybrid application traffic must traverse a designated inspection point. The exact gateway and firewall topology must be designed for the environment.
Verify the Route That Actually Carries the Traffic
A firewall deployment does not establish an inspection path by itself.
Microsoft’s virtual-network routing documentation describes route selection using destination prefixes and route precedence. A default route toward a firewall is therefore not sufficient evidence that more-specific internal or hybrid traffic traverses it.
For each important flow, record the effective forward and return paths from the actual workload locations. Repeat the assessment for the intended recovery path.
A backup connection that restores service while bypassing required inspection is a different security design. It needs an explicit decision, not an assumption that restored connectivity means restored protection.
Record the Address Each Control Evaluates
Source network address translation can change which application identity an address-based control sees.
Microsoft documents that Azure Firewall network rules do not use SNAT by default for destinations in RFC 1918 private ranges or RFC 6598 shared address space. Application rules use SNAT through the firewall’s proxy behavior, and network-rule SNAT behavior can be configured.
Do not generalize from those defaults to every deployed path. Inspect the actual configuration and observed addresses.
When several application sources become one translated address, the downstream database policy can no longer distinguish those sources by their original addresses. The upstream control must preserve that distinction, and the evidence must connect the original flow to the translated flow.
For the Orders application, document whether the on-premises controls evaluate individual Azure API addresses, a tightly controlled address range, or a translated source. That decision determines where application-specific authorization is enforced.
Include DNS in the Acceptance Test
When an application depends on a private endpoint, DNS determines which address the client attempts to reach.
Microsoft’s private endpoint DNS integration guidance documents hybrid patterns using DNS forwarding and Azure DNS Private Resolver. The selected pattern must work from the application’s actual locations, not only from an administrator’s test VM.
Validate the resolved address, connection path, and application operation from Azure, on-premises, and recovery locations. A successful lookup is not sufficient when it resolves to a destination outside the intended private path.
Rebuild Defaults and Evaluation Order Deliberately
Some translation errors remain invisible until a broader rule takes precedence.
The VirtualNetwork service tag deserves particular attention. Microsoft documents that it can include connected on-premises address spaces, peered VNets, gateway-connected networks, and prefixes used by user-defined routes. It should not be read as “only this application’s local VNet.”
The operational implication is straightforward: review the effective trust boundary after connectivity changes, not only after firewall-rule changes.
Azure Firewall has a separate processing model. Microsoft documents DNAT processing before network rules, and network rules before application rules. A broad matching network allowance can prevent a later application rule from providing the restriction the designer expected.
Azure Virtual Network Manager introduces another distinction. A security admin Allow rule permits subsequent NSG evaluation. Always allow bypasses that NSG evaluation, while Deny stops the traffic. Microsoft also documents that security admin rules do not currently apply to private endpoints.
These differences should be visible in the design review. Do not translate source priority numbers directly into target priority numbers or select the strongest-sounding action to make a rule win.
Where the source depends on user identity or application-layer conditions, mark the requirement for specific redesign. A port-level rule is not an equivalent substitute merely because it restores the connection.
A Phased Policy Translation and Migration Strategy
Establish the Source Baseline
Begin with read-only discovery. Retain the source configuration, group membership, dependency evidence, and existing exceptions together.
Review the observation period against the application’s operating cycle. Include scheduled processing, maintenance, backup, and recovery requirements. A source rule with no recent hits should become a review candidate, not an automatic deletion.
The phase is complete when the application and security owners agree on the required communication and prohibited relationships.
Design the Target and Coexistence States
Create separate designs for the final architecture and the temporary migration state.
The final design might use same-VNet ASG relationships. The coexistence design might require explicit Azure source addresses in on-premises controls, temporary replication permissions, and a different DNS path.
Give temporary access an owner, purpose, expiry or removal trigger, and rollback relationship. Avoid combining temporary and permanent access into one broad rule that becomes difficult to remove safely.
The design gate should reject unresolved enforcement gaps and unapproved access expansions.
Pilot the Boundary Before Migrating the Wave
Choose a representative application path that exercises membership, routing, inspection, and logging. Test permitted and prohibited communication against functioning destinations.
Include a newly deployed instance and an intentionally unclassified instance. The first should receive its approved access before entering service; the second should remain outside the application trust boundary.
A pilot that proves only that the database connection works has not tested the translation method.
Cut Over Through Explicit Stop Conditions
Before cutover, confirm the deployed configuration, membership, routes, DNS, telemetry, and recovery procedure.
Stop the wave when an unauthorized source reaches a protected destination, required inspection is bypassed, or a critical denial cannot be explained. Treat loss of required operational access as a stop condition too.
Rollback must restore the previous policy and connectivity state, not merely restart the source VM. Once the target has accepted writes, application and data recovery decisions must govern whether returning to the source is safe.
Stabilize Before Retiring Source Controls
Keep source and coexistence controls until the agreed recovery window closes. Then remove temporary permissions, obsolete address objects, unused group membership, and migration-only identities through a reviewed change.
Retest after cleanup.
Retirement is part of the migration because temporary connectivity can otherwise become an undocumented permanent trust relationship.
Tooling and Automation Considerations
Automation should make the translation repeatable without hiding the decisions.
Use the source APIs and approved discovery tooling to collect evidence. Keep the approved requirements in version control, then generate or maintain target configuration through platform-specific deployment modules.
A small descriptive record can connect one security requirement to its implementation and tests. The following YAML is an illustrative project format, not a native NSX or Azure API payload.
policy_id: ORDERS-API-DB purpose: Production order transaction processing owner: orders-platform source_requirement: application: orders environment: production role: api destination_requirement: application: orders environment: production role: database flow: protocol: TCP destination_port: 1433 initiator: source target: topology: same-vnet source_group: asg-orders-api-prod destination_group: asg-orders-db-prod enforcement: nsg-orders-db-prod protected_scope: dedicated-database-subnet membership_owner: workload-deployment-pipeline acceptance: api_to_database: allow web_to_database: deny unrelated_to_database: deny unclassified_to_database: deny status: pending_validation
Replace the application identities, owners, port, and target objects with approved values. Extend the record with source rule identifiers, resource identifiers, operational dependencies, and evidence locations.
The record should not become “validated” because a deployment completed. That status should require the associated acceptance evidence.
Useful automation gates include unresolved object references, empty or unexpectedly broad memberships, unowned exceptions, missing deny tests, and configuration drift. When a source construct cannot be represented faithfully, the process should stop for a design decision rather than silently discard the condition.
Validation, Evidence, and Operational Caveats
Test the Connections That Must Fail
Build the acceptance matrix from the approved requirement, not from the list of generated rules.
| Test | Expected result | Evidence needed |
|---|---|---|
| Approved API instance reaches the database listener | Allowed | Successful application operation and expected path |
| Web instance initiates a database connection | Denied | Denial attributable to the intended control |
| Unrelated production workload reaches the database | Denied | Negative test from a representative unrelated source |
| Newly deployed API instance joins the application | Allowed only after controls are effective | Membership, configuration, and admission evidence |
| Unclassified instance attempts database access | Denied | Proof that the baseline does not grant application access |
| Application uses its approved recovery path | Required access works; prohibited access remains blocked | Path, policy, and application tests after failover |
A timeout does not necessarily prove policy enforcement. The service may be unavailable, the listener may be closed, or the route may be missing. Verify the destination’s health and correlate the result with the expected control.
For Azure VM paths, Microsoft documents effective security rules and Network Watcher IP flow verify as useful diagnostics. Use them alongside application-level tests rather than treating either as a complete end-to-end verdict.
Account for Existing Connection State
Microsoft’s NSG documentation states that rule changes apply to new connections while existing connections can remain uninterrupted.
Run newly initiated sessions after policy changes. A connection pool that continues working may be preserving an existing flow rather than demonstrating that the new rule permits access.
Incident containment needs a separate procedure when established sessions must be terminated. Removing an allow rule should not be the entire containment plan.
Treat Private Endpoints as a Separate Control Review
A private endpoint does not complete the security design.
For Azure Storage, Microsoft explicitly documents that creating a private endpoint does not automatically block the public endpoint. Applications also continue to use the service’s authorization mechanisms.
Review private connectivity, public exposure, and authorization separately.
Where the design relies on NSGs or user-defined routes for private endpoint traffic, verify the relevant subnet network-policy settings. Microsoft’s guidance also states that a default 0.0.0.0/0 route does not, by itself, override a private endpoint route.
Do not assume that the VM example can be copied unchanged to every managed service.
Design Telemetry Around the Actual Enforcement Path
For new Azure logging designs, plan around virtual network flow logs rather than a new NSG flow-log dependency. Microsoft no longer supports creating new NSG flow logs and schedules their retirement for September 30, 2027.
Coverage still needs verification. Microsoft documents that virtual network flow logs cannot record traffic at the private endpoint itself; relevant traffic can be captured at a supported source VM. ExpressRoute gateway logging also has path-specific limitations.
Retain enough evidence to explain the result: the policy revision, resolved membership, test endpoints, observed addresses, expected path, actual outcome, and available control telemetry.
Assign ownership for maintaining that evidence and rerunning the tests after routing, membership, deployment, or recovery changes. The boundary must remain understandable after the migration team has moved on.
Conclusion
Network policy translation succeeds when the target preserves the approved trust relationships, not when it contains a familiar-looking collection of rule names.
Start with source evidence, resolve the business requirement, and select the Azure and hybrid controls that can enforce it. Keep membership, enforcement location, route selection, address translation, and default behavior visible throughout the design.
Then prove the result through a representative pilot, controlled coexistence, explicit cutover gates, and deliberate retirement of temporary access. Required connections must work, but prohibited connections must also fail for the intended reason.
The most useful first step is to select one application and build its complete policy translation record before generating a migration wave’s rules. That exposes the gaps while the design is still changeable and provides a repeatable acceptance model for everything that follows.
External References
- Broadcom: NSX-T Data Center REST API, Read a group by ID
Canonical URL: https://developer.broadcom.com/xapis/nsx-t-data-center-rest-api/latest/method_ReadGroupForDomain.html - Broadcom: NSX-T Data Center REST API, Read a distributed firewall rule by ID
Canonical URL: https://developer.broadcom.com/xapis/nsx-t-data-center-rest-api/latest/method_ReadSecurityRule.html - Microsoft Learn: Introduction to Azure VMware Solution
Canonical URL: https://learn.microsoft.com/en-us/azure/azure-vmware/introduction - Microsoft Learn: Azure network security groups overview
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview - Microsoft Learn: How network security groups filter network traffic
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works - Microsoft Learn: Application security groups
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network/application-security-groups - Microsoft Learn: Azure service tags overview
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview - Microsoft Learn: Security admin rules in Azure Virtual Network Manager
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network-manager/concept-security-admins - Microsoft Learn: Azure Firewall rule processing logic
Canonical URL: https://learn.microsoft.com/en-us/azure/firewall/rule-processing - Microsoft Learn: Azure virtual network traffic routing
Canonical URL: https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-udr-overview - Microsoft Learn: Azure Firewall SNAT private IP address ranges
Canonical URL: https://learn.microsoft.com/en-us/azure/firewall/snat-private-range - Microsoft Learn: Azure Private Endpoint DNS integration
Canonical URL: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns-integration - Microsoft Learn: Use private endpoints for Azure Storage
Canonical URL: https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints - Microsoft Learn: Manage network policies for private endpoints
Canonical URL: https://learn.microsoft.com/en-us/azure/private-link/disable-private-endpoint-network-policy - Microsoft Learn: Overview of network security group flow logs
Canonical URL: https://learn.microsoft.com/en-us/azure/network-watcher/nsg-flow-logs-overview - Microsoft Learn: Virtual network flow logs
Canonical URL: https://learn.microsoft.com/en-us/azure/network-watcher/vnet-flow-logs-overview
TL;DR Hybrid certificate lifecycle management should preserve working trust relationships, not merely produce certificates with later expiration dates. Centralize ownership, policy, inventory,...