WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

How to Create Custom Firewall Rules in ESXi 5.0

07.18.2011 by William Lam // 29 Comments

In ESXi 5.0, the firewall system has been completely revamped to provide the same functionality as the classic ESX Service Console esxcfg-firewall command. To access the firewall configurations, you can use the following esxcli namespace: esxcli network firewall. By default, there are set of predefined services that a user can enable or disable upon startup.

To list the default firewall rules, you can run the following command:  

esxcli network firewall ruleset list

You can also create your own custom firewall rules/services, but unfortunately this has to go outside of the esxcli framework with a custom firewall rule configuration file. An example firewall rule can be viewed under /etc/vmware/firewall/ if you have FDM enabled and you should find a file called fdm.xml which looks a little something like this:
This XML configuration file describes the name of the firewall rule/service and also specifies the various ports, port type, protocol and direction of a given service.

In the following example, I will create a new firewall rule called "virtuallyGhetto" and it will have port 1337 using TCP for both inbound/outbound and port 20120 using UDP for both inbound/oubound. You will need to create a new XML file and specify a name which I have called /etc/vmware/firewall/virtuallyGhetto.xml

<ConfigRoot>
  <service>
    <id>virtuallyGhetto</id>
    <rule id='0000'>
      <direction>inbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>1337</port>
    </rule>
    <rule id='0001'>
      <direction>outbound</direction>
      <protocol>tcp</protocol>
      <porttype>dst</porttype>
      <port>1337</port>
    </rule>
    <rule id='0002'>
      <direction>inbound</direction>
      <protocol>udp</protocol>
      <porttype>dst</porttype>
      <port>20201</port>
    </rule>
    <rule id='0003'>
      <direction>outbound</direction>
      <protocol>udp</protocol>
      <porttype>dst</porttype>
      <port>20201</port>
    </rule>
    <enabled>true</enabled>
    <required>false</required>
  </service>
</ConfigRoot>

Next we will need to reload the firewall by performing a "refresh" operation and then list the rules again using the following command:  

esxcli network firewall refresh
esxcli network firewall ruleset list

We can also verify that the individual rulesets for our new firewall rule/service by running the following command and grepping for the rule in question:

esxcli network firewall ruleset rule list | grep virtuallyGhetto

The new ESXi firewall also allows you to specify specific IP Address or IP ranges to access a particular service. In the following example I disable the "allow all" and specify a particular range for the virtuallyGhetto service using the following commands:

esxcli network firewall ruleset set --allowed-all false --ruleset-id=virtuallyGhetto
esxcli network firewall ruleset allowedip add --ip-address=172.30.0.0/24 --ruleset-id=virtuallyGhetto

The new firewall rules/services are also viewable under the host configuration section "Security Profile" using the vSphere Client:

As you can see it is pretty straight forward to add your own firewall rules and this can easily be incorporated into your kickstart builds.

UPDATE1: How to persist custom firewall rules in ESXi 5, take a look at these two articles here and here.

UPDATE2: Duncan Epping just posted an article on creating your own vibs which will persist firewall rules, definitely take a look as another option.

UPDATE3: You can now easily create persistent firewall rules and other files using the new VIB Author Fling, please take a look at this article here for some examples.

Categories // Uncategorized Tags // ESXi 5.0, firewall, ruleset, vSphere 5.0

SSH Keys & Lockdown Mode Caveat in ESXi 5

07.17.2011 by William Lam // 6 Comments

Hopefully everyone is familiar with ESXi's Lockdown Mode and what it means from a security standpoint. Here is a table of the behavior between normal and Lockdown Mode:

In ESXi 5, the use of SSH keys is officially supported without having to manually create any hacks to preserve .ssh directory as you did with prior releases of ESXi. If you use Lockdown Mode, there is an additional caveat to be aware of in which the use of SSH keys is able to by-pass the Lockdown Mode configuration for an ESXi 5 host.

Here is a quick example demonstrating the process from VMware's VCVA (vCenter Virtual Appliance):

Step 1 - Create SSH keys

vcenter50-1:~ # ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
a1:8c:24:60:0e:fe:9a:cf:4a:35:17:d6:89:ba:08:9d root@vcenter50-1
The key's randomart image is:
+--[ DSA 1024]----+
|o. |
|=. o . |
| o. .+ o. |
| ..+oo.. . |
|. E=..o S |
|. = + |
| = . |
|. o |
| ..o |
+-----------------+

Step 2 - Copy SSH public keys over to destination ESXi 5 host into the authorized file under /etc/ssh/keys-root/authorized_keys

vcenter50-1:~ # scp .ssh/id_dsa.pub root@vesxi50-4:/etc/ssh/keys-root/authorized_keys
Password:
id_dsa.pub 100% 606 0.6KB/s 00:00

Step 3 - Enable Lockdown Mode via vCenter

Step 4 - SSH into locked down ESXi 5 host utilizing SSH keys

By default the support of SSH is enabled, you will need to manually disable it to ensure that you are fully lockdown when you choose to enable Lockdown Mode. To disable SSH key support, you just need to comment the following line in /etc/ssh/sshd_config

# AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

The change takes effect right away and you do not need to restart the SSH daemon.

If you are interested in automatically disabling the use of SSH keys or you would like to copy an existing SSH key into your ESXi 5 host via kickstart, take a look at Automating ESXi 5.x Kickstart Tips & Tricks for more details.

Categories // Uncategorized Tags // ESXi 5.0, lockdown mode, ssh keys, vSphere 5.0

There's a new mob in town, FDM MOB for ESXi 5

07.15.2011 by William Lam // 1 Comment

That's right, vSphere is not the only one with a MOB, the new FDM (Fault Domain Manager) feature also includes a MOB view on an ESXi 5.0 hosts that is part of an FDM/HA enabled cluster. I originally noticed this new URL while parsing through the systems logs an ESXi host to get a better understanding of the startup process and found this little nugget. This page contains private APIs that are currently not exposed for public consumption with respect to FDM service, please use at your own risk.

To access the FDM MOB, you will need to point your browser to the following URL:

https://[esxi5_hostname]/mobfdm

Here is a screenshot of the main summary page:

On the summary page, you have some basic information about the particular host in question, one interesting property is the "clusterState" which will be either a master or slave node, this can be useful in troubleshooting if you do not have access to vCenter

The are two interesting methods that can provide some useful information: RetrieveClusterInfo and RetrieveHostList which should be pretty self explanatory in what they will be doing.

To generate the URL for the RetrieveClusterInfo you will need to point your browser to the following URL:

https://[esxi5_hostname]/mobfdm/?moid=fdmService&method=retrieveClusterInfo

As you can see from the screenshot, it provides a summary for the particular ESXi host within the FDM cluster, including the masterID, this ID will be useful when we call the other method to identify the master node in the FDM cluster.

To generate the URL for the RetrieveHostList you will need to point your browser to the following URL:

https://[esxi5_hostname]/mobfdm/?moid=fdmService&method=retrieveHostList

This method extracts all hosts from the FDM cluster and provides quite a bit of information about each host including the hostname and also the hostID. You can now translate ID found in the last method to identify the master node of the FDM cluster.

When you login to the FDM MOB for an ESXi host that is a master node in the cluster, the page will look slightly different with even more details including all slave nodes and protected VMs within the cluster.

As you can see this can be a useful tool for quickly identifying the master and slave nodes within an FDM cluster without going to your vCenter Server.

You can also get this information within the ESXi Shell, there is a hostlist file in an XML format that you can view the same information found in the RetrieveClusterInfo method located in /etc/opt/vmware/fdm/hostlist

~ # cat /etc/opt/vmware/fdm/hostlist
host-70
FB43716F-84A5-45AD-A5BB-F08BC64148DF-14-5db552f-vcenter50-133host-205esxi50-2.primp-industries.com58:C9:81:F1:3D:A1:47:B8:7A:C0:33:93:71:3A:B9:A1:51:AD:25:51172.30.0.7300:19:bb:26:25:8e00:19:bb:26:25:7e/vmfs/volumes/664220b6-9628e4e3/vmfs/volumes/f0613bc2-56e80c59443host-70esxi50-1.primp-industries.com25:C3:FE:23:B1:DB:5C:F8:94:13:A3:CD:B0:DC:EA:51:72:F1:53:4F172.30.0.7200:1f:29:c9:48:e200:1f:29:c9:48:f8/vmfs/volumes/664220b6-9628e4e3/vmfs/volumes/f0613bc2-56e80c59443

You also get the details of RetrieveHostList and cleaner output of the FDM host using the following script: /opt/vmware/fdm/fdm/prettyPrint.sh. The script can accept three different arguments: hostlist, clusterconfig and compatlist

Here is a screenshot of the hostlist:

Here is a screenshot of the clusterconfig:

Here is screenshot the compatlist:

Categories // Uncategorized Tags // ESXi 5.0, fdm, fdmmob, mob, vSphere 5.0

  • « Previous Page
  • 1
  • …
  • 105
  • 106
  • 107
  • 108
  • 109
  • …
  • 125
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Quick Tip: Reducing High CPU Utilization in VCF Automation (VCFA) on AMD Zen4/Zen5 CPUs 08/12/2026
  • VCF 9.1 - Quick Tip: Optimized Workflow for Configuring Distributed Transit Gateway (DTGW) with NSX Virtual Network Appliance (VNA) 08/11/2026
  • Quick Tip: Selective ESX Host Patching in VCF 9.1 08/10/2026
  • Playing with Zero Touch Provisioning (ZTP) in vSphere 9.1 using an ASUS NUC 08/07/2026
  • Quick Tip: Automating ESX System Resource Pool Workaround Prior to 8.0 Update 3g 08/06/2026
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.

To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2026