Your NSX-T firewall rules do not migrate. Not one of them. That distributed firewall protecting your TKGI clusters today matches on IP sets, NSGroups and tags that Antrea has never heard of, so every rule you rely on has to be rebuilt as label based policy on the new cluster before a single workload moves. That sounds like a loss until you see how much smaller the result gets.

Why NSX-T DFW rules do not travel to Antrea

Last part we wired identity, RBAC and Harbor on dev-tkg-01 in the web-app namespace. A web tier, an api tier and a PostgreSQL database now run, images pull, and developers can deploy. What they cannot do yet is trust the network, because nothing is segmenting it. On the source estate that segmentation lived in the NSX-T distributed firewall, the DFW being the hypervisor level firewall NSX-T enforces on every vNIC, and it protected the TKGI pods through NSGroups populated by NSX-T tags.

Here is the core mismatch. A DFW rule reads something like allow source NSGroup web to destination NSGroup db on TCP 5432, where each NSGroup is a dynamic membership of IP addresses that NSX-T keeps current as pods churn. Antrea does not know your NSGroups and does not care about pod IPs, which are ephemeral anyway. Antrea (the CNI that VKS installs by default, built on Open vSwitch) evaluates policy against Kubernetes labels, so the same intent becomes allow from podSelector app equals api to podSelector app equals postgres on TCP 5432. The intent survives. Mechanism, object model and every identifier are new.

That is why this is a translation, not an export. You cannot dump the DFW ruleset and load it into VKS. You read the intent out of each DFW section and express it again in Antrea, and along the way most estates find their real ruleset is far smaller than the DFW made it look, because IP based rules fan out into many entries that one label selector now covers.

Preflight before translating microsegmentation

Four things must be true before you write a single policy. Antrea is the CNI on the target cluster and its controller is healthy. Your workload pods carry consistent app labels, because label hygiene is the whole game now. You can reach the cluster as an operator. And you have exported the DFW sections that apply to the source clusters so you have the intent in front of you. The checks below prove the first three, and the export you do from NSX-T Manager or with the policy API.

What green looks like: the Antrea controller and agents are Running, the five static tiers report their priorities in order, and every pod shows an app label you can select on. If a pod has no app label, stop and fix the deployment first, because a policy that selects nothing fails open and you will not notice until traffic you meant to block sails through.

Map DFW constructs to Antrea policy

This mapping table is the reference artifact for the whole segmentation cutover. I keep it open next to the exported DFW sections and tick each construct off as I express it in Antrea. Build yours from the constructs your DFW actually uses, not from a generic list, because the point is to prove every source rule has a target home before you delete anything on NSX-T.

Table 1. NSX-T DFW to Antrea mapping. That default section row is the one people get wrong.

Tiers are what let this stay legible. Antrea ships five static admin tiers plus a baseline tier, and an admin policy names one. Rules in a higher tier win before lower tiers are even consulted, and a policy with no tier lands in application by default. Put estate wide guardrails in securityops, put per app allow rules in application, and put the catch all default deny in baseline so it runs after any developer written Kubernetes NetworkPolicy. Traffic walks the tiers in that order until a rule matches.

flowchart TD
  A[Packet to a pod] --> B[emergency tier]
  B --> C[securityops tier]
  C --> D[networkops tier]
  D --> E[platform tier]
  E --> F[application tier]
  F --> G[Kubernetes NetworkPolicy]
  G --> H[baseline tier default deny]
  H --> I[Allowed only if a rule said Allow]

Convert the web tier ingress with Antrea policy

Start with the allow rules, because if you lead with a default deny you strand the app while you write them. That DFW section for the source app carried three intents worth keeping: external traffic reaches the web tier on 443, the web tier reaches the api tier on 8080, and only the api tier reaches PostgreSQL on 5432. Express the web to api allow as an Antrea ClusterNetworkPolicy in the securityops tier so it sits above app level noise.

Apply it, then confirm Antrea realized it. A realized policy shows a current node count that matches where the selected pods run, which is how you know the agents programmed the rule and it is not just sitting in the API server.

Prove the api tier reaches the web tier before you move on. Two curls from inside the cluster, one that should pass and one that should still be open because you have not denied anything yet, tell you the allow landed without a surprise.

Isolate the database tier at the baseline

Now the two halves that reproduce a DFW default deny. First a tight allow that lets only the api tier reach PostgreSQL on 5432 and drops the rest, in securityops so it outranks anything an app team writes. Then a namespace wide default deny in the baseline tier, which is the piece a single Kubernetes NetworkPolicy cannot give you.

Add a default deny without breaking DNS

Here is the failure that cost me the better part of a morning, and every tutorial walks you straight into it. I applied a baseline ACNP that dropped all ingress and all egress for the namespace, exactly the DFW default deny I wanted. Within seconds the app fell over. Pods could not resolve anything, because a default egress deny also blocks DNS to CoreDNS on port 53, and nothing works once name resolution dies.

The fix is to allow DNS egress in a tier above baseline before the default deny takes hold. On the DFW you never thought about DNS because the infrastructure section allowed it globally. On Antrea you make it explicit, once, in the platform tier.

Verify enforcement and roll back

Enforcement is proven by what fails, not by what works. Run three probes from inside the cluster: the api reaches PostgreSQL on 5432 and passes, the web tier reaches PostgreSQL and is blocked, and every pod still resolves DNS. A blocked path with a baseline Drop times out silently, so give curl a short timeout or you sit there waiting.

To see what Antrea actually programmed on a node, ask the agent. antctl, the Antrea command line tool that ships in the agent pod, lists the realized policies and the pods each one is applied to, which is the fastest way to confirm a rule is live rather than merely accepted.

Rollback stays first class, because the source TKGI clusters and their DFW are still enforcing for every workload that has not moved. Backing out on the target is a delete, and because Antrea removes the flows immediately the namespace returns to open in under a second. You are never stuck with a half applied policy set.

Table 2. Antrea policy failures and their remediation. Four of the five are a name that does not match reality, one apiVersion, one tier, one namespace label, one pod label.

Field note and verdict

Translate segmentation before the first workload wave

A clean result looks like this: the Antrea tiers report in order, an allow DNS policy sits in platform, per app allows sit in securityops or application, a baseline ACNP denies the rest of the namespace, curl proves the api reaches PostgreSQL and the web tier does not, DNS resolves everywhere, and antctl shows every policy realized on the right nodes. Reach that on dev-tkg-01 and you repeat the pattern for staging and prod as each moves.

On your own estate on Monday, do one thing before you write any YAML: export the DFW sections that cover your source clusters and, using Table 1, write next to each rule the podSelector and namespaceSelector that will carry its intent. That mapping on paper, made before you touch the cluster, is what stops the missing label trap and proves nothing is orphaned when you finally decommission the DFW. For the deeper NSX and Antrea integration behind these same namespaces, the NSX complete guide and the field notes on the Antrea to NSX adapter on VKS go further than a migration runbook should. The full migration map lives on the TKGI to VKS guide. Next part starts the workload waves proper, with Velero on both estates as the migration toolchain.

Questions worth answering

Can I keep enforcing with NSX-T on VKS instead of Antrea?
You can, through the Antrea to NSX adapter that registers VKS inventory into NSX and lets you author policy centrally. That is a valid target if a security team owns firewalling estate wide. For a clean migration most teams start with native Antrea policy and add the adapter later.

Do I need ACNP, or is Kubernetes NetworkPolicy enough?
Kubernetes NetworkPolicy covers per namespace app rules that developers own. Use Antrea ClusterNetworkPolicy for anything estate wide, for tiering, and for a true default deny, none of which plain NetworkPolicy can express.

Where do dropped packets get logged?
Set enableLogging on the rule and Antrea writes to the node running the applied pod, under the Antrea log directory. There is no central pane like the DFW log unless you add the NSX adapter or ship the node logs yourself.

Should I mirror DFW rule priorities exactly?
No. Reuse the intent, not the numbers. Antrea tier order plus a small priority range per tier is easier to reason about than a flat DFW section with hundreds of sequence numbers.

This series covers a production migration. Apply any default deny in a change window against your own environment, prove DNS and the allow paths first, and leave the source DFW enforcing until the target is verified.

References

• Antrea Network Policy CRDs and Tiers, Antrea documentation
• VKS Clusters Antrea CNI Integration, Broadcom TechDocs
• Network Policies, Kubernetes documentation

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts