Browse Category


VDI Segmentation in Minutes with VMware NSX

Securing VDI workloads with VMware NSX is incredibly easy and quick. In this post, I’ll demonstrate how to implement segmentation for VDI workloads to prevent undesirable and unintended VDI to VDI communications.

In most environments, there are more users than applications and the number of desktops greatly outnumbers servers. Thus, the attack surface for user compute workloads is much larger and poses a much greater risk to the majority of organizations. Being able to quickly and easily implement scalable and dynamic security to prevent VDI to VDI risks is key to any solution and VMware NSX does this without any changes to the user compute workloads or underlying network.

Let’s take a look at what we need to do to create VDI segmentation with VMware NSX for vSphere.

After logging into the vSphere web client, we click on Menu and navigate to Networking and Security. Click the Firewall menu item on the left to display the NSX Distributed Firewall interface. We add a firewall rule section named VDI and then create a blocking rule for VDI to VDI traffic, using NSX Security Groups with dynamic membership based on a string of characters in the VM name, such as “vdi”. We then create an allow rule above the block rule, for any intended VDI to VDI communications traffic, which is usually, Skype, Slack or the like.

That’s it folks. It’s that simple. A VDI to VDI block rule based on a string of characters in the name, which provides dynamic addition of any VDI desktops to the security policy, as they are created and destroyed.

Check out this video of the entire process and see how you can achieve VDI segmentation in Minutes with VMware NSX for vSphere:

There are a large number of VDI environments running NSX for vSphere, as it offered client endpoint antivirus protection integrations early on in SDN, that are massively beneficial from a standpoint of architecture and performance. These same capabilities are now available in NSX Data Center and any new VDI deployments are certainly taking advantage of the all the improvements in NSX-T.

With that said, after a bit of thought, it seemed logical to create this blog and demo video in NSX for vSphere. While the process for creating VDI segmentation in NSX Data Center (NSX-T) may vary by a few steps, the implementation is just as simple as NSX for vSphere. Anyone that’s using NSX Data Center can create the same rules in NSX-T. …and should.

Simple. Quick. Scalable. …that’s VMware NSX.

Updating Docker in Kubernetes for the NSX-T NSX Container Plugin

I recently put on a little Saturday morning hackathon for a friend and figured I’d share a poorly documented NSX-T NSX Container Plugin tip.

The default Ubuntu repositories don’t have the most current version of Docker and the NSX-T NCP requires a very current version of Docker and related packages.

Run the following command as a string (it’s piped, just copy, paste and run) to install the latest version of Docker on you Kubernetes master, then minion nodes. Once you do this, you’ll be able to install the latest version of the NSX-T NSX Container Plugin.

sudo apt install apt-transport-https ca-certificates curl software-properties-commoncurl -fsSL | sudo apt-key add -sudo add-apt-repository "deb [arch=amd64] bionic test"sudo apt updatesudo apt install docker-ce

(*reppin’ #NSTAM in containers) 🤘🏻

BGP with FortiGate and NSX

At home I use a Fortinet FortiGate 60E firewall between the internet and my lab environment. I do a lot of NSX testing and experimenting and typically have used static routes between devices because its easy. This is fine for a while, but eventually it becomes more effort to manage the static routes. Most of time when I have a connectivity problem it was because I forgot to add a route. So, I’ve decided to make my life easier and have started using a dynamic routing protocol, BGP.

I’m going to show you the steps to configure BGP peering between my FortiGate appliance with both NSX-v and NSX-t edges that I have running in my lab.  While some of these steps are specific to a FortiGate the NSX parts will be the same for any device.

I like pictures because it helps me visualize how devices are connected.  These are the networks I’m going to work with in this example.


FortiGate Firewall
A quick check of my routing table on my FortiGate shows that it only knows about the its own default route and the interfaces that are directly connected to it.


The first thing I do is setup the Local BGP Options on my FortiGate. (Note: if you don’t see the BGP tab in the web interface, make sure it’s visible. System -> Feature Visibility -> Advanced Routing, enable)

  • Network -> BGP
  • For my environment I’m going to set the following;
    • Local AS = 1
    • Router ID =
  • Create my BGP Neighbors
  • For my NSX-v environment I’ll use
    • IP = (IP of my ESG)
    • AS = 65170
  • For my NSX-t environment I’ll use
    • IP = (IP of my Tier-0 Router)
    • AS = 65138
  • Apply


NSX-v environment
I’m going to configure peering between the FortiGate and my NSX-v environment first. No particular reason, I just have to start someplace.  The screenshots are from NSX-v 6.4.4 but this process has been the same for number of NSX-v releases.

  • Login to vCenter
  • Networking & Security -> Edges -> double click my 3 Tier ESG
  • Routing -> Global Configuration
  • Click Edge for the Dynamic Routing Configuration. Select the Router ID and save.
  • Publish Changes


  • Next, select BGP
  • BGP Configuration click Edit
    • Enable BGP
    • Set Local AS = 65170
    • OK
  • Click the green plus by Neighbors to add a new neighbor.
    • IP Address = (IP of FortiGate)
    • Remote AS = 1
    • Make sure your Keep Alive Time and Hold Down Time matches the setting on the FortiGate
    • OK
  • Publish Changes


  • Next, select Route Redistribution
  • Route Redistribution Status, click Edit
    • Enable BGP
    • OK
  • Click the green plus by Route Redistribution table.
    • Set Lerner to BGP
    • Select Static Routes & Connected
    • OK
  • Publish Changes


My BGP link should now be up. We can confirm by looking at the FortiGate and ESG route tables. You can see my virtual machine logical switch networks, including the transit network between my ESG and DLR.

       get router info routing-table all


From the NSX-v ESG, I can also see the routes it knows about. Notice that I’m using static routes to get between the ESG and DLR. This is just a lab but normally you would want to use dynamic routing like BGP or OSPF so you don’t have to update your routes every time you add a new logical switch.

       show ip route


And I can also confirm the BGP peering is established.

       show ip bgp neighbors


NSX-v environment
Next, I’ll configure peering between the FortiGate and my NSX-t environment. NSX-t 2.3 introduced a number of web interface changes. The screenshots are from my NSX-t 2.3 environment so they may look a little different if you are using an earlier version.

  • Login to NSX Manager
  • Networking -> Routing
  • Select my Tier-0 Router
  • Select Routing -> BGP
  • Select Edit for BGP Configuration
    • Status = Enabled
    • Local AS = 65138
    • OK
  • Neighbors, click Add
    • Neighbor Address =
    • Remote AS = 1
    • Make sure Keep Alive Time and Hold Down Time match the FortiGate
    • Add


Now I have to enable route distribution.

  • Select Routing -> Route Distribution
  • Select Edit for Route Distribution
    • Status = enabled
    • Save
  • Add
    • Name, I called mine RouteDist but you can call it whatever you want.
    • Sources, check NSX Connected and NSX Static
    • Add


If I check my FortiGate routing table I now see my new networks.

From the NSX-t Tier-0 Router I can also check its routing table. Notice that I can also see all of the NSX-v networks that I added before.

      get route


I can also check the BGP peering.

      get BGP neighbors


Doing some basic ping’s and I can confirm that all of my routing is working.

I hope my examples will help you see that configuring BGP with NSX and other physical devices is straight forward and can really help keep down administration overhead of manually adding static routes.

Happy Routing!!!