Over the past week or so, i’ve been diving back into working on VMware Cloud on AWS… for the most, the experience hasn’t changed that much since I started tinkering back in 2018. That said, the main networking elements powered by NSX-T under the surface are now controlled through the main SDDC configuration portal. You do have the option of breaking out to the NSX-T Portal to configure items, but for the most it can now be done from the one location without having to configure things in the vCenter UI once the SDDC deployment has been completed.

That in itself led to this quick blog post. As has been the case since the start of VMware Cloud on AWS, once the SDDC is deployed (which still takes about 100-120 minutes) to gain access to vCenter through the Web UI, you need to configure a Gateway rule for the Management Cluster to allow that access. For me, the quickest and easiest way to achieve this is to create a rule similar to what’s show below.

So, vCenter inbound from ANY source to the vCenter destination on HTTPS. Pretty standard quick and nasty config to access things for testing and labbing. The one thing you notice with the picture above is that the rule is disabled. This wasn’t something that I did, but was automatically reverted to by an underlying health and security check as part of the VMC platform. It had me stumped for a while, and I reached out to Twitter to ask if anyone else had seen this happen while also making sure that I made it clear this wasn’t an optimal configuration by way of exposing the vCenter UI to the whole world.

Straight away I got a response from James Kilby saying that it was related to the log4j venerability which made perfect sense. I also got this response on Twitter.

Which confirmed the suspicion that the rule was being disabled due to it being a bad idea and not best practice 🙂

Quick Fix

So from reading the VMwareKB above, it seems as thought the platform is now configured to go one step further than the notification and just disable any rule that is deemed risky. So the solution to this is to just configure tighter Firewall rules… which honestly should be logical in a production scenario… but again, even now days if you are tinkering on transient setups (like what I am doing atm) it’s important to consider a security first mentality. For me, that meant creating a new Group that has my external IP and only allow traffic from that destination!