A city permitting web VM talks to a tax database VM on an NSX-T overlay. How should the administrator classify that conversation when choosing a firewall?

City permitting-web to tax-database traffic on an NSX-T overlay is east-west overlay conversation inspected by the Distributed Firewall at each workload vNIC. Treat that pair as two civic offices on the same floor exchanging records, not as a citizen entering from the street: the control plane that sees and enforces the flow is Distributed Firewall, not the Edge north-south path. Classifying the conversation as north-south that must publish through an Edge gateway VIP fails by concept because both VMs live on the overlay and never need a published VIP for their mutual talk; Gateway Firewall is for traffic that enters or leaves the overlay. Treating it as physical underlay traffic only a hardware TOR ACL can inspect fails because NSX-T encapsulates and steers the overlay conversation above the TOR, and TOR ACLs do not replace Distributed Firewall micro-segmentation for guest pairs. Treating it as internet SaaS traffic that belongs only on a Workspace ONE Access reverse proxy fails because this is VM-to-VM data-plane traffic between civic workloads, not browser SSO to a SaaS app. Exam caveat: east-west overlay VM pairs are Distributed Firewall candidates at the vNIC; Edge VIP publication, underlay TOR ACLs, and Access reverse proxies answer different problems and do not reclassify overlay application conversations. Operational check: Traceflow or NSX Intelligence from permitting-web to tax-DB, confirm Distributed Firewall hits at the vNICs, verify no requirement to hairpin through an Edge VIP for that pair, and document the east-west classification in the city firewall design so future Edge rules are not written as if this were north-south citizen traffic.