VMware ESXi and vSphere Cluster Management
Configure the ESXi Firewall in vSphere
Learn how to view, enable, disable, and restrict ESXi firewall rulesets in the vSphere Client while protecting management and infrastructure services.
The ESXi firewall is a host-level security control that filters network traffic associated with ESXi services. It helps protect management interfaces and infrastructure functions from unsolicited connections. This lesson explains how to inspect and change firewall rulesets through the vSphere Client, restrict inbound sources, validate changes, and avoid common access and availability problems.
Prerequisites and key terms
You should understand basic TCP/IP networking, IP addresses, subnets, routing, VLANs, VMkernel adapters, ESXi hosts, vCenter Server inventory, host services, and vSphere permissions.
An ESXi firewall is the built-in host firewall that controls traffic associated with ESXi services and rulesets. A ruleset is a named policy grouping that permits the protocols and ports required by a service or host function. A management network is the network path used for host administration and core management communication.
- Allowed IP addresses: A source-address allowlist that determines which systems may connect through a selected ruleset.
- Security Profile: The ESXi host security area containing host services, firewall settings, and related controls.
- SSH: Secure Shell remote command-line access to the host.
- ESXi Shell: A local or console-oriented ESXi command-line service, separate from remote SSH.
- Lockdown Mode: An access-control feature that limits direct host administration methods; it is separate from firewall filtering.
- Least privilege: Allowing only the services, source systems, and access paths required for an operational task.
How the ESXi firewall works
ESXi normally has its firewall enabled by default. Its general model is default deny for unsolicited traffic: traffic is not accepted merely because it reaches the host. Rulesets needed for authorized host functions provide the required exceptions.
In the standard vSphere Client workflow, administrators generally manage named service rulesets rather than opening arbitrary individual ports. Each ruleset groups the protocol and port permissions needed by a particular ESXi service or feature.
A ruleset being enabled does not automatically mean that the associated host service is running. Conversely, starting a service does not remove the need for an appropriate firewall rule. Both the ruleset state and the service state must support the intended operation.
Common ESXi firewall ruleset categories
Available rulesets vary by ESXi release, installed components, enabled features, and host configuration. The names shown in a particular host may therefore differ from these representative examples.
| Category | Representative services or features | Typical traffic source or destination | Security considerations |
|---|---|---|---|
| Host management | vSphere management traffic, management services, CIM or related management functions | vCenter Server, trusted management systems, or other ESXi hosts | Keep management traffic on dedicated networks and avoid broad exposure. |
| Remote troubleshooting | SSH and ESXi Shell-related access | Approved administrator workstation or bastion host | Use only for an approved, time-bounded task; stop the service afterward. |
| Name and address configuration | DNS client and DHCP client | Configured DNS or DHCP infrastructure | Permit only the infrastructure actually used by the host. |
| Storage connectivity | NFS client and iSCSI | NFS servers or iSCSI storage targets | Coordinate with storage networks, VMkernel bindings, and upstream ACLs. |
| Live migration and cluster traffic | vMotion and vSAN | Participating ESXi hosts and cluster infrastructure | Enable consistently on participating hosts and protect the dedicated networks. |
| Monitoring and log forwarding | SNMP and syslog | Monitoring servers or remote log collectors | Restrict inbound sources where applicable and verify the collector configuration. |
vMotion is VMware live virtual machine migration. NFS provides network file storage access, iSCSI provides IP-based block storage, and vSAN provides distributed storage across hosts. SNMP is commonly used for monitoring, while syslog forwards host logs to a remote collector.
View firewall configuration in the vSphere Client
- Sign in to the vSphere Client with an account that has permission to view or modify the host security configuration.
- Open the vCenter inventory and select the target ESXi host, not a similarly named host, cluster, or virtual machine.
- Open the host's Manage or Configure area. The exact label depends on the vSphere Client and ESXi release.
- Locate Security Profile, Firewall, or the firewall settings within the host security section.
- Review each named ruleset, its enabled status, and its permitted source configuration.
Before editing, verify the host name, management IP address, cluster membership, and current task context. This check is especially important when several hosts have similar names.
Enable or disable a firewall ruleset
- Open the firewall configuration for the confirmed ESXi host.
- Choose the edit action for the firewall settings.
- Select the named service ruleset required by the operational task.
- Enable the ruleset to permit its associated traffic, or clear and disable it when the service is not required.
- Save or apply the change.
- Test the affected service from an approved source and confirm that dependent host capabilities still work.
Enable only rulesets with a documented operational requirement. Disabling a ruleset can interrupt storage access, migration, monitoring, logging, cluster communication, or management. Disabling an SSH- or ESXi Shell-related ruleset can prevent remote troubleshooting access, while enabling it unnecessarily increases direct host administration exposure.
Restrict allowed source IP addresses
For a selected ruleset, the workflow may provide a choice between permitting connections from all IP addresses and permitting connections only from explicitly allowed addresses. Use the restricted option for sensitive inbound services whenever the design supports it.
- Edit the selected ruleset.
- Choose the option for specified or allowed IP addresses instead of unrestricted sources.
- Enter the approved IPv4 or IPv6 addresses. Where supported by the selected workflow, enter network ranges using the required CIDR notation.
- Save the change and test from an approved system.
Examples include allowing SSH only from a bastion host, permitting SNMP only from the monitoring server or monitoring network, and limiting syslog-related access to the designated logging infrastructure. Source filtering applies to inbound traffic for the selected ruleset. It does not replace VLAN design, network segmentation, upstream ACLs, or perimeter firewalls.
Firewall ruleset state versus host service state
| Firewall ruleset enabled | Host service running | Expected result | Administrative implication |
|---|---|---|---|
| Enabled | Running | The service can receive permitted traffic, subject to source restrictions and other network controls. | Normal usable state when the service is required. |
| Enabled | Stopped | The firewall allows the relevant traffic, but no running service may respond. | Check the service startup policy and running state. |
| Disabled | Running | The service may be active locally, but the firewall blocks traffic covered by the disabled ruleset. | Do not assume a running service is reachable. |
| Disabled | Stopped | The service is not running and its related traffic is blocked. | Typical state for an unused service. |
Security Profile services
The ESXi Security Profile brings together host service controls, firewall settings, and related security controls. Service startup policy determines whether a service starts automatically, and the running state determines whether it is currently active. Firewall ruleset status determines whether associated network traffic is permitted.
These are related but distinct settings. Enabling a firewall ruleset does not necessarily start a host service. Starting a service does not make it reachable if its ruleset is disabled or its source allowlist excludes the client.
SSH and ESXi Shell provide powerful direct administration capabilities. Keep them stopped or disabled when they are not needed. For troubleshooting, use an approved maintenance window, restrict sources, record who enabled access, and stop the service and remove or restrict the ruleset when the task ends.
Lockdown Mode and the ESXi firewall
Lockdown Mode controls methods of direct ESXi host administration. The firewall controls network traffic associated with services. They are separate controls.
A permitted firewall rule does not override Lockdown Mode restrictions. A connection can be allowed by the firewall and still be rejected because the chosen direct-host administration method is not permitted. Before enabling Lockdown Mode, plan the approved vCenter management path, exception users if required, role-based permissions, and recovery access.
Do not use firewall configuration as a substitute for Lockdown Mode, vSphere role-based access control, network isolation, authentication controls, or host hardening.
Safe firewall change process
| Change item | Questions to verify | Validation method | Rollback action |
|---|---|---|---|
| Service owner and purpose | Who requested the change, and which host function requires it? | Match the request to a documented feature or service requirement. | Disable the ruleset if the requirement is withdrawn. |
| Source systems | Which administrator, monitoring server, storage system, or peer host must connect? | Confirm source addresses, routing, NAT, and network paths. | Restore the previous source allowlist. |
| Ruleset and service state | Is the correct named ruleset selected, and must the host service be running? | Review the ruleset and service state, then perform a controlled test. | Return both settings to the recorded prior state. |
| Feature impact | Could storage, vMotion, vSAN, monitoring, logging, or management be affected? | Run migration prechecks, storage tests, monitoring checks, or log-forwarding tests as appropriate. | Restore the known-good configuration and investigate dependent paths. |
| Maintenance and documentation | Is a maintenance window or approval required? | Record the host, ruleset, sources, reason, time, and test result. | Follow the documented rollback and break-glass procedure. |
Before changing a rule, identify the service owner, source systems, protocol and port requirement, and maintenance impact. Record the current enabled state and source restrictions. Apply least privilege, save the change, test from an approved source, and confirm that required host capabilities remain functional.
Practical example: temporarily allow SSH
- Identify the approved administrator workstation or bastion host and its actual source IP address.
- Enable the SSH-related firewall ruleset only if the support task requires it.
- Restrict the ruleset to that source address or an approved management subnet.
- Start the SSH service only for the maintenance period, according to the organization's service policy.
- Validate access from the approved source.
- When the task is complete, stop the SSH service and disable or re-restrict the firewall ruleset.
Firewall permission and service state must both be considered. Temporary remote access should not become a permanent exception.
Practical example: restrict monitoring access
- Locate the relevant monitoring or SNMP ruleset.
- Allow traffic only from the monitoring server or approved monitoring network.
- Save the source allowlist and record it in the change documentation.
- Test monitoring from the authorized system.
- Confirm that unapproved sources cannot reach the service through the selected ruleset.
This keeps required monitoring available without exposing the service to every reachable network.
Practical example: enable a host infrastructure capability
- Identify whether the capability is vMotion, NFS, iSCSI, vSAN, logging, or another host function.
- Confirm the required service, network design, VMkernel adapter, and endpoints.
- Enable the matching named ruleset if it is not already enabled on the required hosts.
- Validate the feature with a controlled test, such as datastore connectivity or migration prechecks.
- Do not enable unrelated rulesets as a workaround for an unidentified problem.
Inspection commands for troubleshooting
The graphical vSphere Client workflow should be the normal administration path. If direct shell access is authorized by organizational policy, these commands can help inspect firewall configuration. Command availability and output vary by ESXi release.
esxcli network firewall get
esxcli network firewall ruleset list
esxcli network firewall ruleset allowedip list
Use direct SSH or ESXi Shell access only under the host-access policy. Inspection commands do not replace change approval, source validation, or documentation.
Troubleshooting
SSH connection fails after enabling the ruleset
- Verify that the SSH host service is running.
- Verify that the SSH firewall ruleset is enabled.
- Check whether the allowed-source list includes the administrator's current source IP.
- Confirm routing, VLAN, upstream firewall, and management-network connectivity.
- Check whether Lockdown Mode or another access policy prevents direct-host login.
A permitted service still does not work
- Confirm that the selected ruleset matches the service or feature.
- Confirm that the corresponding ESXi service or feature is configured and active.
- Check VMkernel adapters and network bindings for storage, vMotion, vSAN, or management traffic.
- Validate the external endpoint, such as an NFS server, DNS server, log collector, or monitoring server.
- Inspect upstream network ACLs and firewalls.
The host becomes inaccessible after source restrictions are saved
- Compare the allowlist with the client's actual source address.
- Check for an incorrect subnet mask or CIDR notation.
- Determine whether traffic is NATed or originates from a bastion rather than the administrator workstation.
- Use an approved alternate management path to correct the allowlist.
- Review the change record and restore the prior known-good setting if necessary.
vMotion, storage, or cluster operations fail after hardening
- Identify the exact feature and required ruleset.
- Verify that the ruleset remains enabled on every participating host.
- Confirm the correct VMkernel network is configured for the feature.
- Review source restrictions for inter-host or storage-network traffic.
- Check feature-specific logs and vCenter task or event details.
Operational and security best practices
- Use vCenter-managed administration where possible instead of broad direct-host access.
- Limit SSH and ESXi Shell to approved, time-bounded support tasks.
- Restrict management-plane access to dedicated management networks and trusted administration hosts.
- Review enabled rulesets after troubleshooting, feature retirement, host repurposing, and security audits.
- Keep ruleset changes consistent across hosts that participate in the same cluster or infrastructure function.
- Use defense in depth: VLANs, ACLs, physical and network firewalls, certificates, authentication, role-based access control, Lockdown Mode, and patching complement the ESXi firewall.
Exam-relevant notes
- The ESXi firewall is normally enabled and uses a default-deny approach for unsolicited traffic.
- Standard vSphere Client administration is organized around named service rulesets, not arbitrary individual port entries.
- Firewall ruleset state and host service running state are different settings.
- Allowed source IP restrictions apply to inbound traffic for the selected ruleset and do not replace network segmentation.
- Lockdown Mode restricts direct administration methods and is distinct from firewall filtering.
- Enabling SSH or ESXi Shell should be limited to approved troubleshooting or maintenance needs.