Determine when overlapping ERPs is necessary

Default rule: ERPs are unique and non overlapping, and no two ERPs may share addresses. Overlapping ERPs is a deliberate Prism Central setting. Enable it when two or more VPCs must use the same prefix and you can guarantee separate broadcast domains. Both conditions must hold:

• The VPCs with overlapping ERPs must not match to the same external VLAN network.
• The VPCs with overlapping ERPs must not match to the same transit VPC.

Path: Prism Central Settings → Network Controller → VPC Management → Allow overlapping External Routing Prefixes (ERPs). Clearing the checkbox disables it.

Associate Scale out VPC Gateway nodes to a VPC

Field: Number of Active Hosts, inside the Associate External Subnet window on Create VPC or Update VPC. It appears only when the selected external subnet is a NAT or No-NAT VLAN subnet.

Determine when to set the default route · Determine routes to be set during VPC creation

Set the default route 0.0.0.0/0 with the external subnet as next hop whenever the VPC needs any connectivity outside the cluster. One external subnet, NAT or No-NAT, means you must add that default route. Both a NAT and a No-NAT subnet means you must instead configure routes that say which destination prefix uses which external subnet. Subnet extension also requires a default static route with 0.0.0.0/0 and the external network next hop, because that is what gives the Network Gateway appliance its NTP and DNS access.

Two route inputs exist at creation. Destination Prefixes on the external subnet association are the prefixes for which that subnet is the next hop, selected by longest prefix match. Static Routes in the Associate External Subnet window list the prefixes using that subnet as next hop, and you must also configure return routes on the physical router. Afterwards: open the VPC → Routes tab → Manage Static Routes → Add Static Route, with fields Destination Prefix and Next Hop Link.

Assign a specific Router IP / SNAT IP · Change the external network for a VPC

The SNAT IP / Router IP is the VPC router’s address in the external subnet. On NAT it is the SNAT IP. On No-NAT the physical router uses it as next hop for everything reachable inside the VPC.

In Associate External Subnet set SNAT IP/Router IP to Custom Defined. A table shows IP Pool Range, Used IPs in Pool, and Free IPs in Pool. Enter an address from the free pool into Custom SNAT IP / Router IP. The alternative, Auto Assigned, lets the Network Controller pick.

To change the external network: Network & Security → Virtual Private Clouds → select the VPC → Actions → Update. External Connectivity rows carry Edit and Delete actions, and Associate External Subnet adds one. The one NAT and one No-NAT limit applies on update too.

Create an Overlay External Network · Associate a VPC to a transit VPC Overlay External Network

Network & Security → Subnets → Create Subnet. Type Overlay. Select a transit VPC (the dropdown offers only transit VPCs for an overlay external subnet). IP Address Management is mandatory: Network IP Prefix and Gateway IP. Turn on External Connectivity, which for an overlay subnet only appears once a transit VPC is selected. The NAT checkbox under it selects NAT (default) or No-NAT.

To attach a user VPC: select the user VPC → Update → Associate External Subnet → Subnet Type Overlay → pick the overlay external subnet. Details shown are Network Address/Prefix and NAT ed status (VLAN ID only shows for VLAN subnets). Then set Static Routes and SNAT IP/Router IP. For the hub to advertise the spoke’s networks, add the user VPC’s ERPs to the transit VPC’s ERP list.

• Overlay external subnet attaches only to a transit VPC, never to a regular VPC.
• Only regular VPCs connect through it. No VMs or workload entities, and no regular VPC to regular VPC.
• Two transit VPCs cannot be joined this way.
• A No-NAT overlay external subnet does not support No-NAT gateway scale out.

Determine when to connect a VPC to a NAT or a No-NAT network

Create network load balancer with a target group of VMs

FVN provides a native Layer 4 load balancer, distributed and implemented in the AHV host. Layer 7 is not native; Nutanix points to policy based routing or Service Insertion and to contact Support. The listener is the primary component and uses the load balancing algorithm to distribute traffic to target VM NICs.

External load balancing distributes traffic entering the VPC, with a floating IP from the NAT external subnet range as the external address. Internal load balancing distributes intra VPC traffic, and the virtual IP need not be reachable from outside.

Path: Network & Security → Network Services (opens on Network Load Balancer) → Create Load Balancer Session.

Session details view

Tabs: Summary, Target VM NICs, Alerts, Audits. A dash (-) in any field means the value is not available or not applicable.

Target VM Status widget, a donut chart with the data stacked beside it: NIC Health (number of Healthy and Unhealthy NICs) and CPU Usage (target VMs in bands of under 50 percent, 50 to 75 percent, over 75 percent).

Analyze the status of BGP peering sessions, including advertised and received routes

Path: Network & Security → Connectivity → BGP Sessions tab, then click a session name. The details page has Summary, Routes, and BGP Logs tabs. The Routes tab opens on Advertised and also carries Received, each with Next Hop.

Session Status versus eBGP Status: two attributes, not one

This reads at first like three competing vocabularies for one field. It is two distinct attributes, plus one inconsistent filter pane.

Behaviors that shape what you see: a session automatically advertises all ERPs of the one VPC its gateway services; it ignores received routes when the VPC has no routable No-NAT external subnet; received routes install FIFO, not by prefix length; the appliance learns and installs up to 250 routes; a session advertises a single next hop per ERP.

Define a Policy Based Routing policy to redirect traffic via a security appliance

Use PBR for traffic already crossing a routed boundary between subnets inside a VPC, redirecting it to a firewall VM. The reroute happens on the virtual router and the original packet is forwarded to the active destination VM, which forwards or drops. Traffic Mirroring is the alternative when traffic does not cross a routed boundary or must be copied rather than forwarded.

Path: Virtual Private Clouds → VPC name → Policies tab → Create Policy.

Assign a floating IP to a workload for external access under NAT

SNAT alone permits only outbound initiated connections, because the SNAT IP is shared across the VPC and the NAT gateway only allows return traffic. A floating IP lets an outside endpoint initiate inbound to one specific VM.

Request: Network & Security → Floating IPs → Request Floating IP. Select an external subnet (the page shows IP Pool Ranges, Used IPs, Free IPs). Number of Floating IPs: maximum 50 per request. Tick Define Custom Floating IPs to pick specific addresses. Tick Assign Floating IPs to bind at request time, which shows one Search VMs and IP Address row per requested IP; the secondary IP must already exist to bind to it. Clear it to assign later from the Floating IPs view via Actions → Update.

Translation happens in the hypervisor virtual switch, invisible to the VM. Floating IP translation may run on the VM’s own host. SNAT translation is typically centralized on a specific host. Multiple floating IPs can map to multiple secondary IPs on one VM NIC.

Create resiliency within BGP neighbors

Resiliency comes from multiple gateway pairs plus the path attributes below, not from multiple sessions on one pair. eBGP only, peering with up to 5 infrastructure routers. A local and remote BGP gateway pair hosts a maximum of one session, so more redundancy means more gateway pairs.

Note the direction of the two priority controls. Dynamic Route Priority raises or lowers preference on the Nutanix side. AS Path Prepend lowers preference as the neighbor sees it. They are not two ways of doing the same thing.

Only Name, Dynamic Route Priority, and Password can be updated on an existing session. Local and Remote BGP Gateway are greyed out, so changing those means building a new session and deleting the old one. Broader resiliency: Nutanix recommends Prism Central scale out from one VM to three, plus Prism Central backup and restore. Monitoring: the BGP Session Details page gives Session Status (Up or Down), eBGP Status (Established or Active), and live BGP Logs.

• Advertised Externally Routable Prefixes: All in VPC advertises every ERP; Custom filters to a listed set, so different peers can receive different routes.
• Password is optional and works only for BGP gateway VMs in VLAN Subnets. NAT breaks password verification for VPC attached gateway VMs. Characters a-z, A-Z, 0-9 and ~!@#%^&*()_-+=:;{}[]|<>,./?$, length 1 to 80.
• Creating, updating, or deleting BGP sessions needs VPC Admin or Nutanix Infra Admin.
• Session creation fails without an ERP. Up to 250 learned and installed routes, installed FIFO.

Determine when monitoring mode is appropriate for policy creation

Monitor mode allows all traffic including what the policy does not permit, and highlights the disallowed traffic on the monitoring page. Nothing is blocked until enforce.

Use it when the policy is new and the rule set is unverified, when you need to discover legitimate traffic before blocking anything, and when documenting an application’s flows.

Do not use it for service insertion, which does not support monitor mode, and it does not exist for strict quarantine. All other policies have a monitor mode.

Configure syslog to ship logs externally / enable policy logging

TN-2094 says to set severity 6 Informational for the Audit and Security Policy Hit Logs modules.

Limits on when hit logs appear

• Not generated when both source and destination are in an inbound or outbound category.
• For isolation policies, generated only in monitor mode.
• For multi isolation policies, the direction shows as outbound instead of source and destination.
• Isolation policies show connection attempt counts and discovered ports; identifying the specific source or destination VM requires the hit logs on the syslog server.
• Hit logs and visualization are not synchronized in multi Prism Central DR.

Define or update a policy rule set using flow visualization and captured traffic

In enforce mode the policy engine discovers the traffic the policy denied and shows it on the policy details page. To turn it into rules:

1. Security Policies → open the policy. Discovered traffic sits in Inbounds and Outbounds.
2. Update, then Next.
3. List view: Inbound Rules or Outbound Rules → Discovered Traffic → select source → Allow. Visual view: Inbounds > Discovered or Outbounds > Discovered → hover → Allow Traffic.
4. On Allow Traffic pick Show Tiers (a source reaching different AppTypes within an AppTier) or Show All Traffic (consolidated list of sources reaching all AppTiers).
5. Select sources and choose a service. Multiple sources allowed. A new service can be created inline.
6. Allow Discovered Traffic → Next → select a policy mode on Review → Confirm.

Visualization limits

• FNS 5.2 supports visualization in every policy a VM is part of when the VM belongs to the same category. Previously it appeared in only one policy.
• Where the same or overlapping categories or secured entities repeat across policies, visualization is still available in only one of them.
• VDI policies do not support visualization at all.
• For isolation policies, traffic between the isolated entities is not visualized in enforce mode, unless ARP was already resolved for the destination before the policy was created or enforced.

Recognize the purpose and use case for a shared services policy

The reason it exists: shared service traffic takes precedence over an isolation policy. Even when an isolation policy blocks traffic between two entities, the shared service policy overrides it. Without this, isolating environments would also cut them off from infrastructure services. Constraint: one common service category per shared service policy.

Create via Security Policies → + Create Security Policy → Policy Type Shared Services. Advanced Configuration defaults: IPv6 blocked, Policy Hit Logs disabled. Intra tier traffic rule customization applies to shared service policies as well as application policies.

Determine the appropriate policy type based on business needs

The key distinction: application policies allow configurable sources and destinations between apps, while isolation policies enforce strict separation with no exceptions. An application policy can also isolate one group from all others without an isolation policy.

Rules act commonly on a VM: if a VM is in the allowed list in one policy of an application, it is allowed list across every policy that VM belongs to. FNS 5.2 permits policies with the same or overlapping categories or secured entities, so a monolithic policy can be split into micro policies. Named benefits: smoother migration to Next-Gen, and simpler cloning. Trade off: visualization appears in only one of the overlapping policies.

Configure Isolation policies between two or more entities

Prerequisite: Network Controller managed VLANs must exist. Path: Security Policies → Create Security Policy → Policy Type Isolation: Isolate Environments → Next → Configure Entities: pick Scope (Global, VPC in category, VPC name, VLAN only), Add Entity up to 32, search the category and press Enter, up to 10 categories per entity → Next → Review → Confirm.

Scoping a subset: the documented example isolates location: site1 from location: site2, then narrows with application: app1. Adding a third group that must be isolated from the existing two requires additional policies, one per pair.

Intra tier traffic rule configuration is not supported for isolation or quarantine policies.

Configure Application Policies with appropriate Secured Entities

Before you begin

• At least one VPC must exist to secure entities within a VPC.
• Create categories and associate the VMs to protect. Built-in Environment and AppTier categories can be extended.
• Consider raising the Prism Central session timeout.
• Up to 1000 user defined application policies.

Procedure

1. Security Policies → + Create Security Policy.
2. Define Policy: name, purpose, Policy Type Application: Secure Entities. Advanced Configuration: Allow for IPv6 (blocked by default, and if left blocked it stays blocked even in monitoring mode), Enabled for Policy Hit Logs.
3. Secure Application: pick Scope, add Secured Entities (Entity = VM, Subnet, VPC, Entity Group, then categories; Edit for the intra tier rule, Remove to exclude it from 5.2.1), add Inbound sources, add Outbound destinations.
4. Rules: click the source or destination, click the plus on the secured entity. Traffic Filtering Allow All Traffic or Allow Specific Traffic, then Add New Protocol-Port/Service for TCP (port or range), UDP (port or range), ICMP (type and code), or Service (a service group). Save.
5. Review tab: Save, Apply (Monitor), or Apply (Enforce). Confirm.

Scope options

Targeting a single vNIC

Built-in categories

Bring your own categories, but never reuse system defined names.

Intra tier traffic rule

Controls VM to VM communication inside a secured entity. Default is allow all. FNS 5.2 lets you set a specific service group, port, and protocol rather than only allow all or deny all. Configure from Secured Entities → Edit → Add Port-Protocol/Service → Allow Specific Traffic → Add New Protocol-Port/Service (TCP, UDP, ICMP, Service) → Save → Apply. Removal is available from 5.2.1, after which inbound and outbound rules govern that tier. Not supported on isolation or quarantine policies.

Service insertion

Configure Group ID lookup for Active Directory

The ID firewall imports AD groups into Prism Central as categories under the key ADGroup, then places VDI VMs into those categories automatically on detecting a user logon.

Prerequisites

• Microsegmentation enabled.
• WMI access allowed from Prism Central to every domain controller, in the network firewall and the AD firewall.
• Minimum AD domain functional level Windows Server 2008 R2.
• Security Groups only. Distribution Groups are not supported.
• NTP configured on Active Directory and on Prism Central.
• DNS configured on Prism Central if you want to use host names for domain controllers.

Domain configuration

Prism Central Settings → ID Based Security. Either Use Existing AD (Manually Add Domain Controller → + Domain Controller, entering every DC by IP or host name, one at a time) or Add New Domain (Name, Domain in DNS format, Directory URL as the LDAP address including port, Service Account Username as user@domain.com, Password). Add Inclusion Criteria under Manage the VM Inclusion Criteria to control which VMs get categorized by name; Nutanix recommends it to prevent unintended categorization. VMs with an AppType category cannot be categorized by ID Based Security.

Service account, repeated on every domain controller

1. Create the user in Active Directory.
2. Add to Distributed COM Users and Event Log Readers.
3. dcomcnfg.exe → Component Services → Computers → My Computer → DCOM Config.
4. Right click Windows Management and Instrumentation → Properties.
5. Security tab → Access Permissions → Customize → Edit.
6. Add the user, grant Local Access and Remote Access.
7. WMIMGMT.msc → right click WMI control (local) → Properties.
8. Security tab → expand Root → select CIMV2 → Security.
9. Advanced → Add → Principal → the user. Applies to: This namespace and subnamespaces.
10. Grant Enable Account and Remote Enable.
11. Restart winmgmt: net stop winmgmt then net start winmgmt, or reboot the DC.

Configure VDI Policies

A VDI policy is a form of application policy that secures VDI using AD group membership. Create it with Policy Type Application Secure Entities plus Secure VDI Groups only, then use the imported ADGroup categories as target groups, inbound, and outbound.

Default VDI policy (ADGroup:Default) covers two cases: securing a VDI VM before anyone logs on, and granting access to common network resources without adding them to every tier. Set it when creating a VDI policy or by updating an existing one.

Explain the use case for the quarantine function

Quarantine policies are system defined. Strict completely isolates an infected VM with no traffic in either direction. Forensic isolates it but lets a defined set of forensic tools reach it; the default in both directions is Allowed List, and Allow All can be set in both directions.

Four system defined entries exist, created for all VLANs and VPCs:

• Quarantine Forensic Policy – VLAN Subnets (Scope)
• Quarantine Strict Policy – VLAN Subnets (Scope)
• Quarantine Forensic Policy – VPC (Scope)
• Quarantine Strict Policy – VPC (Scope)

Configure which tools may reach a quarantined VM: Security Policies → select the built-in quarantine policy → Actions → Update. Advanced Configuration allows IPv6 and Policy Hit Logs for both Forensic and Strict. On Secure Application, Add Source and Add Destination with entity types VM, Subnet, VPC, Address Group, Network Address (IPv4), Allow All, Entity Group.

Quarantine in enforce mode is the highest priority of any policy. Two constraints: the VPC in category scope does not support quarantine policies, and intra tier rules are not supported on them.

Multi Prism Central disaster recovery

Select FNS Next-Gen policies with Network Controller managed VLAN scope to synchronize to a remote Prism Central. Associated categories, address groups, and service groups sync with them. Synchronization is bi directional. Protects posture during planned and unplanned cold migration, and during async, NearSync, and synchronous (Metro) replication.

Create a policy in Monitor mode and identify discovered traffic · Enforce a monitored policy

Into monitor: Review tab → Apply (Monitor) → Confirm. Or Security Policies → select policy → Actions → Apply (Monitor) → type MONITOR → Confirm.

Into enforce: Security Policies → select policy → Actions → Apply (Enforce) → type ENFORCE → Confirm.

Reading the isolation policy monitor view: each circle is an isolated entity with its categories listed inside. Discovered traffic is a dotted line; one arrow is unidirectional, two arrows bidirectional. A small circle on top of an entity shows the number of common VMs, and only those are protected. Clicking the entity opens a side window with the categories, the total number of common (protected) VMs, and the discovered traffic.

In enforce mode the engine separately discovers the traffic it denied and shows it under Inbounds and Outbounds on the policy details page, which feeds the Allow Discovered Traffic workflow in 2.1.

Clone a policy and apply to a different Scope

1. Security Policies → select one existing policy. Only one policy can be cloned at a time.
2. Actions → Clone.
3. Define Policy tab: edit name and purpose. Default name is Copy of <Policy Name>. The policy type cannot be changed while cloning.
4. Secure Application tab: edit inbound rules, outbound rules, and the secured application configuration. This is where you change the Scope to Global, VPC in category, VPC name, or VLAN only.

Identify the number of entities potentially impacted by enforcing a monitored policy

From the CLI

SSH to a Prism Central VM and run flow_cli. The rule realisation commands report which policies apply to what, and in which mode:

• rule_realisation_status.policy policy-name returns policy name, rule UUIDs, policy mode (Monitor or Enforced), status and timestamp. Quote the name if it contains spaces, as VDI policy names do.
• rule_realisation_status.vm vm_name=name or vm_uuid=uuid returns the same from the VM side. A VM in more than one policy returns the rule UUIDs of both, which is the direct way to see everything acting on that VM.

Rule realisation is the point at which policy rules are enacted in the network. Status is In Progress, Complete, or Failed, and it is reported for creating a policy, updating a policy, powering on a VM, categorizing a VM, and migrating a VM. Failed does not mean monitoring or enforcement failed, only that the realisation command did not complete.

Where the UI surfaces that count

• Isolation visual view. A small circle on top of the entity circle shows the number of common VMs. The documented example: an AppTier tier_10 entity with 10 categories where only one VM is common.
• Entity detail side window. Categories, total number of common (protected) VMs, discovered traffic.
• At entity selection. Selecting multiple categories for an entity displays the number of common VMs; the policy protects only those. Entity Groups follow the same intersection logic.
• Security Central. The summary of changes displays the categories configured, all configured rules, and the other VMs that are affected.

Describe the different policy lifecycle modes

Save keeps a draft. Apply (Monitor) allows everything and highlights the disallowed. Apply (Enforce) blocks everything the policy does not allow. Beyond the three modes:

• Automated enforcement. Policies target categories, so they apply automatically regardless of VM count or network attributes. Prism Central connectivity to a registered AHV cluster is needed only to create, modify, or change a policy’s mode. Policies keep applying through a temporary connectivity loss, and changes land when connectivity returns.
• No same type priority. Prism Central does not let you prioritize one policy over another of the same type. Priority exists only between types and modes.
• Deleting: select one or several policies → Actions → Delete → type DELETE → Confirm.