The NSX-T agent installed on the servers provides connectivity and security to the bare metal workloads.

Use Ansible to configure virtual interfaces and NSX-T on Windows Server 2016 and secure workloads using NSX-T.

In this procedure, establish connectivity between the workloads and NSX Manager. Then, configure DFW rules to secure ingress and egress traffic running between virtual or physical and Windows Server 2016 or 2019 bare metal workloads.

Prerequisites

  • Configure your own proxy settings on the physical server.

Procedure

  1. Enable Windows Remote Management (WinRM) on Windows Server 2016 to allow the Windows server to interoperate with third-party software and hardware. To enable the WinRM service with a self-signed certificate.
    1. Run PS$ wget -o ConfigureWinRMService.ps1 https://raw.githubusercontent.com/vmware/bare-metal-server-integration-with-nsxt/master/bms-ansible-nsx/windows/ConfigureWinRMService.ps1.
    2. Run PS$ powershell.exe -ExecutionPolicy ByPass -File ConfigureWinRMService.ps1.
  2. Configure WinRM to use HTTPS. The default port used for HTTPS is 5986.
    1. Run PowerShell as an administrator.
    2. Run winrm quickconfig.
    3. Run winrm set winrm/config/service/auth ‘@{Basic=“true”}’.
    4. Run winrm set winrm/config/service ‘@{AllowUnencrypted=“true”}’.
    5. Run winrm create winrm/config/Listener?Address=*+Transport=HTTPS ‘@{Hostname=“win16-colib-001”;CertificateThumbprint=“[output of the 2nd command]"}’.
    6. Verify configuration of WinRM. Run winrm e winrm/config/listener.
  3. Add the bare metal server as a standalone transport node. See Configure a Physical Server as a Transport Node from GUI.
  4. Verify whether OVS bridges are created on the Windows server. The OVS bridge connects the application virtual interface to the NSX switch on the transport node.
    ovs-vsctl show
    The output must show the bridges created from nsxswitch and nsx managed host component. The nsxswitch bridge is for the transport node that was created. The nsx managed bridge is created for the application virtual interface on the Windows host. These bridge entries indicate that communication channel is established between the NSX switch and Windows remote listener.
  5. On the overlay-backed transport node, verify:
    • The static IP address is reflected as the IP address of the overlay segment to which the Windows Server workload is connected.
    • The GENEVE tunnels are created between the NSX switch and the NSX managed host component on the Windows host.
    Note: Likewise, on a VLAN-backed transport node, verify that the static IP address is reflected as the IP address of the VLAN segment to which the Windows Server workload is connected.
  6. In Windows, customize OVSIM driver for the Windows server to create two new network adapters - application virtual interfaces and virtual tunnel endpoint (VTEP) for overlay-backed workload.
    $:> Get-NetAdapter
    vEthernet1-VTEP: Used for overlay-backed VTEP interface. Not needed for a VLAN-backed workload.
    vEthernet1-VIF1: Used for virtual interface or application interface of the bare metal Windows server.
  7. To verify network adapters, go to the Windows server and run Get-NetAdapter.
  8. Verify connectivity between the application, Windows bare metal server, and NSX Manager .
  9. Add and publish L2 or L3 DFW rules for the overlay or VLAN-backed bare metal workload.
  10. Verify ingress and egress traffic between virtual or physical workloads and bare metal workloads is flowing as per the DFW rules published.