The latest major release of VMware Cloud on AWS includes a wealth of new features. See the release notes for a definitive list.

In this post, I’m going to walk through two of these new features, specific to Networking & Security.

• VMC Networking UI in standalone mode
• NSX Traceflow for Visibility and Self-serve Troubleshooting

Photo by Piotr Chrobot on Unsplash

VMC Networking UI in standalone mode

The first new feature I’m going to dive into, is the VMC Networking UI in standalone mode. i.e. NSX Manager UI. This is a nice option for customers who may already be leveraging NSX-T in their on-premises environment, and are more familiar with this look and feel.

To Access the UI

1. Login to the VMware Cloud Services Portal
2. Select the VMware Cloud on AWS tile
3. Click on the relevant SDDC

You will now see the option to Open NSX Manager, go ahead and click it

In this example, I’m going to access via the Internet. In a real world production setup, you will likely be accessing via VPN or Direct Connect.

In order to access via VPN/DX etc, click the settings tab, expand the chervon next to NSX Manager URLs and click the relevant URL. Note you choose to login either via CSP authentication, or the local NSX Manager account.

I’m now presented with the NSX Manager UI.

This version of the NSX Manager UI has been customized for VMC on AWS. For example, if you click the Networking tab, you’l see options for VMC on AWS specific items such as Direct Connect, Transit Gateway and Connected VPC.

NSX Traceflow for Visibility and Self-serve Troubleshooting

I’m excited to see this feature is now available for use with VMC on AWS. I’ve leveraged this tool with the on-premises version of NSX extensively, It provides a great way to validate and troubleshoot your NSX security policy. Traceflow will inject a packet on the virtual wire, and you can trace the full path. Including which firewall rule allowed or blocked the traffic.

So let’s walk through an example. The scenario is you’ve deployed firewall rules to secure an application, but something isn’t working quite right. We’ll leverage the traceflow feature to troubleshoot.

I’ve deployed a 3-tier app within VMC on AWS. If you have taken a NSX related Hands On Lab, you will probably recognize it. Check out this blog from the HOL team for details

The topology is as follows.

I’ve created a security policy to match this topology.

• Any to Web on TCP 443
• Web to App on TCP 8443
• App to DB on TCP 80
• Then a Drop rule to block anything else

So we should now be able to connect to the 3-tier-app. Let’s try it!

Hmm. When I try to connect I get a 502 Bad Gateway error. I’ve setup the necessary rules, so what’s going on?!

With a large set of firewalls, this could be a laborious task to troubleshoot manually. Let’s leverage traceflow to quickly get to the cause of the problem. First, we’ll validate the web tier can communicate with the app tier on TCP port 8443

• Within the NSX Manager UI, select Plan & Troubleshoot, then Traceflow
  

• Protocol Type, select TCP
• Destination Port, enter 8443
• Source Virtual Machine, click the drop down and select web-01a
• Destination Virtual Machine, click the drop down and select app-01a (note how traceflow automatically populates the IP & MAC Address details)
• Once all the parameters have been entered, click Trace

From the results, we can see that the traffic was actually DROPPED by Firewall Rule ID: 2032

Now that we are armed with this information, lets search for the rule in question

• Click on the Security tab, then Distributed Firewall

• Click on Apply Filter, then scroll down and select Rule ID

• Enter the Rule ID of 2032 and click OK. This was the rule ID that traceflow showed was blocking the traffic

Searching by Rule ID is especially useful when dealing with a large rule base. As opposed to trawling though the policy manually. Here we can see that there is an explicit rule, outside of the policy I had created for the 3-tier-app, rejecting all traffic from the web-tier -> app-tier.

For the purpose of this example, we’ll disable this rule. This can easily be achieved by toggling the Enable/Disable Rule option to off.

• Then click Publish

• Again select Plan & Troubleshoot, then Traceflow
• Note how the parameters from earlier are still present, no need to reenter the details. Nice! 👍
• Click Retrace, then Proceed

Now we see that the packet was delivered successfully

Switching back to my client VM, I refresh the browser and verify the application connectivity is working as expected

Conclusion

In this post we walked through accessing the NSX Manager UI, and leveraging the Traceflow tool to easily troubleshoot the firewall policy.

Thanks for visiting my bog. If you have any questions, please leave a comment below, or contact me via Twitter

• NSX
• VMC