Configuring ESXi Firewall Rules: Methods, Tips & Best Practices

By default, the ESXi host’s firewall is enabled and blocks all ports except those strictly required for core services like SSH, DNS, DHCP, and vMotion. While this default stance effectively minimizes the attack surface, administrators inevitably need to modify these rules to allow for backup agents, monitoring tools, or specific management networks.

This guide covers the four primary methods to manage these rules, from GUI-based approaches to command-line automation.

The “System Owned” Limitation

Before modifying rules, it is vital to understand a restriction introduced in vSphere 8.0 Update 2 which persists in vSphere 9.0. Certain system-managed services – specifically the NFS Client, vSAN encryption, and Trusted Infrastructure key management – can no longer be restricted to specific IP addresses via the ESXi firewall.

If you attempt to uncheck “Allow connections from any IP” for these services, the operation will fail with the error: “Cannot change allowed IP list for this ruleset, it is owned by system service”. This is an intentional security design by VMware to prevent misconfiguration from disrupting core storage and encryption services.

Community Insight: Do not attempt to bypass this via the command line, as the system enforcement exists at the API level. If you need to restrict traffic for NFS or vSAN, you must implement these controls at the network layer (e.g., physical switch ACLs or external hardware firewalls) rather than on the host itself.

Method 1: Using the vSphere Client

For environments managed by vCenter Server, the vSphere Client provides a centralized “pane of glass” to view and edit security profiles. This method is best for auditing compliance and making one-off changes, though it becomes tedious for bulk updates without automation.

How to Configure: To modify rules, navigate to the target host in the inventory and select the Configure tab. Under the System section, select Security Profile. The Firewall section on the right will display all active rules.

1. Click Edit to open the firewall settings dialog.
2. Select the service you wish to modify. You can toggle the service on or off using the checkbox.
3. To restrict access, uncheck “Allow connections from any IP address”.
4. Enter the permitted IP addresses or CIDR subnets (e.g., 192.168.0.0/24) separated by commas.

Changes apply immediately without requiring a service restart. Note that for the “system-owned” services mentioned earlier, the Allowed IP fields will be greyed out.

Method 2: The ESXi Host Client

The ESXi Host Client is a web-based interface running directly on the host, accessible via https://<esxi-host-ip>. This method is essential for standalone hosts not managed by vCenter, or as an emergency access point if vCenter is unavailable.

How to Configure: Log in with root credentials and navigate to Networking in the left-hand menu, then select the Firewall rules tab.

1. Select the desired service and click Edit settings.
2. Change the rule from “All connections from all IP addresses” to “Only allow connections from the following networks”.
3. Input the allowed subnets (e.g., 172.16.10.0/22) and click OK.

Community Insight: This is often the preferred method during initial hardware deployment before the host is joined to vCenter. If you lock yourself out of vCenter access, logging directly into the Host Client from a permitted IP is the fastest recovery path.

Method 3: PowerCLI

VMware PowerCLI is the standard for applying consistent configurations across multiple hosts. It allows for “Infrastructure-as-Code” management, enabling you to version-control your firewall policies.

Managing Rules: PowerCLI uses the Get-VMHostFirewallException and Set-VMHostFirewallException cmdlets to manage the state of rules.

To enable a service, such as the DHCP Client:

Get-VMHostFirewallException -VMHost "esx01.lab.local" -Name "DHCP Client" | Set-VMHostFirewallException -Enabled $true

Restricting IP Addresses: Standard PowerCLI cmdlets do not natively support setting allowed IP addresses. To achieve this, you must interact with the ESXCLI object within PowerShell.

Community Insight: Experienced engineers recommend using the V2 ESXCLI object for better stability. The script below demonstrates how to restrict the SSH service to a specific management subnet:

# Create the ESXCLI V2 object

$esxcli = Get-EsxCli -VMHost "esx01.lab.local" -V2

# 1. Disable "Allow All" for the specific ruleset (sshServer)

$rulesetArgs = $esxcli.network.firewall.ruleset.set.CreateArgs()

$rulesetArgs.rulesetid = "sshServer"

$rulesetArgs.allowedall = $false

$esxcli.network.firewall.ruleset.set.Invoke($rulesetArgs)

# 2. Add the specific allowed IP/Subnet

$ipArgs = $esxcli.network.firewall.ruleset.allowedip.add.CreateArgs()

$ipArgs.rulesetid = "sshServer"

$ipArgs.ipaddress = "192.168.10.0/24"

$esxcli.network.firewall.ruleset.allowedip.add.Invoke($ipArgs)

Method 4: ESXCLI

ESXCLI provides direct, low-level control over the firewall. It is useful for troubleshooting via SSH or the local console shell when the management agents are unresponsive, or for use in kickstart scripts (%firstboot) during installation.

Common Commands:

• List all rules: esxcli network firewall ruleset list This helps identify the correct ruleset-id (e.g., sshServer, dhcp).
• Enable a rule: esxcli network firewall ruleset set –ruleset-id=”dhcp” –enabled=true.
• Restrict IP Addresses: This is a two-step process. You must first disable the “allow all” flag, then add the specific IPs.

1. esxcli network firewall ruleset set –ruleset-id=”dhcp” –allowed-all=false.
2. esxcli network firewall ruleset allowedip add –ruleset-id=”dhcp” –ip-address=”172.16.10.0/22″.

To verify your configuration, use esxcli network firewall ruleset allowedip list.

Best Practices & Troubleshooting

• Don’t Lock Yourself Out: When restricting remote access services like SSH or the vSphere Web Client, ensure your current workstation’s IP is included in the allowed list before applying the rule. If you lock yourself out, you will likely need physical console access (or iLO/DRAC) to revert the changes.
• Defense in Depth: Do not rely solely on the ESXi firewall. It is a secondary measure. Your primary defense should be network segmentation (Management VLANs) and hardware firewalls.
• Avoid Custom XML Rules: While you can create custom firewall rules by editing XML files in /etc/vmware/firewall/, these changes are not persistent by default and may vanish after a reboot. Making them persistent requires creating a custom VIB (vSphere Installation Bundle), which is an advanced workflow. Stick to standard services unless you are comfortable maintaining custom VIBs.
• Documentation: ESXi does not allow you to add comments to firewall rules. Maintain external documentation of why specific ports were opened to assist with future audits and upgrades.

Conclusion

Effective firewall management in ESXi is about choosing the right tool for the scale of your environment. While the vSphere Client and Host Client are excellent for troubleshooting and small-scale adjustments, they are inefficient for large deployments. For consistency and auditability across clusters, PowerCLI remains the professional standard.

Regardless of the method chosen, administrators must adapt to the security hardening introduced in vSphere 8.0 U2 and continued in ESXi 9.0. The inability to restrict “system-owned” services like NFS and vSAN at the host level is not a bug, but a directive to move those access controls to the physical network layer. By combining these host-level rules with robust network segmentation and keeping updated on VMware’s evolving security model, you ensure your infrastructure remains both accessible and secure.