Configuring Windows Network Load Balancer (NLB) over PCD

Problem

• Microsoft Windows Network Load Balancer (NLB) cluster VIPs are unreachable when the NLB virtual machines are attached to a network that has port security enabled.
• Symptoms typically include:

  • The NLB cluster VIP cannot be pinged or reached from other VMs or hosts.
  • ARP resolution for the VIP fails or resolves inconsistently.
  • Client applications relying on the NLB VIP (for example, ADFS proxy services) intermittently or completely fail to connect.

Environment

• Private Cloud Director Virtualization
• Self-Hosted Private Cloud Director Virtualization
• Component - Networking

Cause

Windows NLB is designed to share a single Virtual IP (VIP) across all cluster nodes. Depending on the cluster's operating mode, NLB associates that VIP with a special shared MAC address:

NLB mode	VIP MAC behaviour
Unicast	A single shared unicast MAC (02:BF:...) is assigned to every node for the VIP.
Multicast (default/recommended)	A multicast MAC (03:BF:...) is assigned to the VIP, while each node keeps its own physical MAC.
Multicast with IGMP	A multicast MAC (01:00:5E:...) is assigned to the VIP.

In all three modes, cluster nodes deliberately advertise a MAC address for the VIP that does not match the node's own physical port MAC, and multiple nodes answer for the same VIP. This is fundamental to how NLB distributes traffic across the cluster.

PCD networking uses OVN, which enforces port security (anti-spoofing) by default. Port security only permits traffic whose source IP/MAC matches the addresses configured on the port. Because NLB's VIP traffic intentionally uses a shared or virtual MAC that differs from the port's own MAC, port security treats it as spoofed traffic and drops it. This is the same reason VMware requires the equivalent security options to be relaxed for NLB (see Additional Information).

Selectively permitting NLB traffic while keeping port security enabled is not a reliable option: it would have to account for every protocol NLB and its workloads use (ARP, ICMP, TCP, UDP, and many others), which is not sustainable. The supported approach is therefore to isolate NLB workloads on a dedicated network with port security disabled.

Resolution

Deploy Windows NLB VMs on a dedicated, isolated, VLAN-backed provider network with port security disabled, and terminate the NLB traffic on your external/physical router rather than a Neutron (tenant) router.

This confines the relaxed security settings to a single, purpose-built broadcast domain used only for NLB, so the rest of the cloud remains protected by port security.

Prerequisites

• Administrator access to PCD with permissions to create provider networks and manage ports.
• A dedicated VLAN provisioned on the physical/underlay network for the NLB traffic, trunked to the PCD hosts.
• The physical network label configured in the OVN bridge mappings on the hosts where the NLB VMs will run.
• Gateway/routing for the NLB VIP subnet provided by your external router (see step 4).

Step 1 — Create a dedicated VLAN-backed provider network

Create a provider network exclusively for the NLB VMs. Do not attach any other production workloads to it.

$ openstack network create \
  --provider-network-type vlan \
  --provider-physical-network <PHYSICAL_NETWORK_LABEL> \
  --provider-segment <NLB_VLAN_ID> \
  --external \
  nlb-provider-net

Step 2 — Disable port security on the network

Disabling port security at the network level ensures every port created on it inherits the setting.

$ openstack network set --disable-port-security nlb-provider-net

Create the NLB subnet on this network. Set the gateway to your external router's address on the NLB VLAN:

$ openstack subnet create \
  --network nlb-provider-net \
  --subnet-range <NLB_SUBNET_CIDR> \
  --gateway <EXTERNAL_ROUTER_IP> \
  nlb-subnet

Step 3 — Attach the NLB VMs and confirm port security is disabled

Attach each Windows NLB VM to nlb-provider-net. For any port that already exists, explicitly disable port security. A port cannot have port security disabled while security groups are attached, so remove them first:

$ openstack port set --no-security-group --disable-port-security <NLB_VM_PORT_ID>

Verify the setting on every NLB VM port:

$ openstack port show <NLB_VM_PORT_ID> -c port_security_enabled -c security_group_ids

Expected output:

| port_security_enabled | False |
| security_group_ids    |       |

Repeat for every NLB node's port.

Step 4 — Terminate NLB traffic on the external router

Route and terminate the NLB VIP traffic on your external/physical router, not on a Neutron router. The dedicated provider network is created as --external and mapped to the VLAN so that Layer 2 (including the NLB multicast/shared-MAC frames) stays within the isolated broadcast domain and is handed off directly to the physical network. Configure the default gateway of the NLB subnet to point at the external router, and configure any north-south routing for the VIP on that external router.

Step 5 — Configure Windows NLB

On the Windows guests, configure the NLB cluster as usual, using Multicast mode (the generally recommended mode). Once the cluster nodes are attached to the isolated, port-security-disabled network, the VIP becomes reachable and the cluster converges normally.

Risks

Disabling port security removes the anti-spoofing protection on the affected ports. This introduces the following risks:

• A compromised VM can impersonate other devices (MAC spoofing).
• Exposure to ARP poisoning and Man-in-the-Middle (MITM) attacks.
• Network instability caused by conflicting or duplicate MAC addresses.

Because of these risks, port security must never be disabled on a shared or production network. It should only be disabled on the dedicated, isolated NLB network described above.

Preventive Measures

To keep the exposure strictly contained:

• Isolate the network. Use a dedicated VLAN-backed provider network exclusively for the Windows NLB VMs. Do not attach any other production VMs to this network.
• Restrict the broadcast domain. Placing the NLB VMs on a dedicated VLAN limits the impact of MAC spoofing or ARP anomalies to that VLAN only.
• Terminate on the external router. Keep NLB traffic termination on the external/physical router so the relaxed-security segment never mixes with tenant routed traffic.
• Monitor continuously. Continuously monitor the NLB network segment for unusual traffic patterns, unexpected MAC addresses, and ARP table anomalies.

Additional Information

• This approach mirrors how other platforms handle Windows NLB. VMware supports NLB only when Promiscuous mode = Accept, Forged Transmits = Accept, and MAC Address Changes = Accept are set on a dedicated port group, the combination of which is equivalent to disabling port security in PCD. See the VMware knowledge base article on configuring NLB for more detail.
• The same dedicated-VLAN, isolated-broadcast-domain pattern is the standard guidance for running multicast-dependent workloads on top of OpenStack-based clouds generally. See Cisco's guidance on multicast with OpenStack for background.
• For further questions or assistance configuring Windows NLB on PCD, reach out to the Platform9 Support Team.