Spoof Guard

  1. One of the security features offered by NSX is spoof guard.
  2. The spoof guard feature protects against spoofing of IPs preventing malicious attack.
  3. Spoof guard allows to trust the IP reported by vCenter to the NSX manger with the help of VMware tools.
  4. In case of any spoofed IP or violation, Spoof Guard blocks the traffic on that particular vNIC. (Prevents the virtual machines vNIC from accessing the network)
  5. This functions independently of the Distributed Firewall of NSX.
  6. Spoof Guard supports both IPv4 and IPv6 addresses.
Use cases:
  • Preventing rogue VM from assuming the IP address of an existing VM & start sending malicious traffic.
  • Preventing any unauthorized IP address change for the VMs without proper approval.
  • Enhanced security feature which prevents any VMs from by passing the DFW firewall policies by changing the IP address of the VM.
Enabling spoof guard feature is very simple & easy with few clicks.
By default, Spoof Guard feature is disabled.
 
Creating Spoof Guard Policy:
1.By default, IP detection type is None. It should be changed.
2.2 options are supported.
a.DHCP Snooping
b.ARP Snooping
 
  1. As next step, you can edit the default policy or create a new policy. In this example we will create a new policy.
  2. Create the policy name as “Test” & select the option “Enabled”
  3. In this we will select to Manually inspect & approve all the IP address.

  1. As next step, select the network for which you need to apply this policy.
  2. The network could be Distributed port group, legacy port group or it can be logical switch.
 
  1. Once the network is selected, you will be able to view the IPs detected & they are waiting for the “Approve” action.
  2. Unless approved, the VMs will not be part of the network & no traffic passes.

 

 

 

 

 

 

 

 

NSX Traceflow

 

NSX Trace flow:

  • Troubleshooting virtual environment is challenging & also quite interesting.
  • Trace flow is one of the tools which was introduced from NSX for vSphere 6.2 used for troubleshooting & planning.
  • It allows to inject packet into the network & monitor its flow across the network.
  • The traffic can be injected at the vNIC level for the VM without the need to touch the operating system or logging to the VM.
  • One of key benefits using Trace flow is that it can be used even when the VM is down.
  • The output of trace flow indicates the hops that was traversed for the traffic from source to destination.
  • It also indicates whether the packet is delivered to the destination or not (Whether DFW is blocking the traffic or not)

 

Trace Flow Use cases:

  • Trouble shooting network failures to see the exact path that traffic takes
  • Performance monitoring to see link utilization
  • Network planning to see how a network will behave when it is in production

Following traffic are supported by Trace flow

  1. Layer 2 unicast
  2. Layer 3 unicast
  3. Layer 2 broadcast
  4. Layer 2 multicast

Note: The source for any trace flow should be always the vNIC of the VM. The destination could be any device in NSX overlay or underlay.

 

Using Trace flow:

  • Login to vCenter & navigate through Networking & Security -> Tools -> Tracefllow
  • Its required to select the source VM vNIC & the destination VM vNIC (refer below screenshot)
 
  • Under advanced options choose the protocol of the choice from the drop down. (Supported protocols are TCP, UDP & ICMP)
  • In this example we have selected Protocol “TCP”
  • Destination Port TCP 22 is selected in this example

Click on “Trace” to initiate the trace between the source & the destination.

  • The simulated traffic is initiated between the source & destination VMs vNIC.
  • The complete traffic flow including the vNIC, firewall , ESXi host is visible.
  • It is easily identified whether the packet is delivered or not.

  • To identify which firewall policy is hit or followed, just click on the firewall & it shows the Rule ID which allowed or blocked the traffic.

 Trace flow is a very simple & easy tool for troubleshooting virtual network infrastructure.

NSX Backup

  • One of the key considerations during the NSX deployment is proper planning of backing up the NSX manager.
  • Proper & regular backing up of NSX Manager is critical to ensure to the NSX can be recovered due to any failure or un foreseen issues.
  • NSX Manager backup is critical as backing up any other components in SDDC environment.
  • As a best practice of deploying SDDC, one needs to ensure that proper backup procedure & process is in place.
The NSX backup contains the configurations of the below:
  • Controllers
  • Logical switching
  • Routing entities
  • Security
  • Firewall Rules
  • Events & Audit logs

Virtual switches (vDS) are not part of NSX Manager backup.

 

 

Best Practices:

  • Before & after any NSX upgrade or vCenter upgrade
  • After any configuration changes related to NSX controllers, logical switches, logical routers, Edge Service Gateways, Security & Firewall policies.
  • Ensure that the vCenter Server including its database server are backed up along with the NSX backup schedule.
  • In case of any trouble or issue & when it is required to restore the entire environment, it is always recommended to restore the NSX backup along with the vCenter server backup including its database which has been taken at the same time.
  • Create a backup strategy policy to schedule the backup periodically along with the vCenter & its database.
 

NSX Manager Backup Method:

  1. Web Interface:NSX Manager with FTP/SFTP
  2. REST API Method
The recommended way to take the NSX backup is via Web Interface using FTP/SFTP, since it is very simple & easy to configure.
 

Procedure – NSX Manager Backup:

  • NSX Manager backup is very simple & straight forward procedure.
  • The below VMware article explains the same & it is easy to setup.

 

Ref:

https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.4/com.vmware.nsx.upgrade.doc/GUID-2A75A102-518D-4D6C-B23D-877C421B1536.html

 

Restoring NSX Manager Backup:

  • Restoring NSX Manager requires backup file to be loaded to the NSX Manager appliance.
  • VMware recommendation is to reinstall or setup a new NSX Manager appliance & then restore the backup file.
    •     Restoring NSX Manager is compatible between the NSX Manager of the same version. (The backup file version & the restoring NSX version should be the same)
  • Restoring the backup file to the existing NSX Manager appliance will also work but sometimes it will cause issue.
VMware also recommends having the details of the old NSX manager settings like the IP Address, Subnet Mask, Default Gateway settings in prior, which needs to be specified to the newly deployed NSX Manager Appliance.

 

Ref:
 
There may be situations where the NSX Edges becomes inaccessible or failed due to some reasons.
In this case the NSX Edges can be easily restored by clicking Redeploy NSX Edge () in the vSphere Web Client.
It is not required to restore the complete NSX Manager backup.
Note: Individual backup of NSX Edge devices is not supported.