ESX Firewall Oddity

Since I’ve been performing quite a bit of Kerberos-based testing recently (and since Kerberos is very sensitive to clock skew), I wanted to make sure that my ESX-based hosts were keeping accurate time.  Since ESX ships with NTP already installed, I planned on just enabling the NTP traffic outbound, configuring the daemon, and going on my merry way.  No big deal, right?

To make a long story short (I’ll spare you all the intricate details), what I discovered was that even though the “NTP Client” service was showing as enabled in VirtualCenter, it was being reported as blocked by esxcfg-firewall, the command-line tool for manipulating the ESX Server firewall (this was with the command “esxcfg-firewall -q ntpClient”).  To add to the confusion, NTP worked on some hosts but did not work on other hosts even though the firewall configuration and NTP configuration was the same on all the hosts.

A quick search on the Internet turned up this VMTN Forums thread, which suggested to restart the management agent (“service mgmt-vmware restart”).  I did this, waited for VirtualCenter to shake itself back out again, and noted that NTP had disappeared from the list of enabled services in the firewall configuration in VirtualCenter.  At least I had VirtualCenter and esxcfg-firewall in sync now.

I enabled NTP client traffic in VirtualCenter again, but returning to the ESX host I again found that esxcfg-firewall was still reporting NTP traffic as blocked.  Even after allowing almost ten minutes for the change from VirtualCenter to be applied back to ESX, esxcfg-firewall still reported NTP as blocked.  On that one host, I restarted the VMware management agent again, and again NTP disappeared from VirtualCenter’s list of services allowed through the firewall.

So, to avoid any other problems, I enabled NTP with the following command:

esxcfg-firewall -e ntpClient

The “esxcfg-firewall -q ntpClient” command now listed the service as enabled, but what did VirtualCenter say?  Even after a reboot and a disconnect/reconnect sequence, VirtualCenter still did not report NTP client traffic as enabled.

What do I take from this?  Perhaps it’s a bit harsh, but don’t trust VirtualCenter—at least, not with regards to firewall settings.  If you want to know what’s going on, then drop the service console and find out from the source.  Just repeat after me:  “The command line is my friend. The command line is my friend. The command line is my friend…”

Tags: , , , ,

  1. Kevin’s avatar

    Thank you for this! I have on host that shows NTP being blocked while everyone else is fine. CLI is my friend, CLI is my friend… ;-)

  2. Corne Beerse’s avatar

    the /etc/init.d/ntpd script does open a firewall port. However, it does that the linux way, not informing the esx configuration…

    Hence, best to force it all:
    /etc/init.d/ntpd restart
    chkconfig ntpd on
    esxcfg-firewall -e ntpClient
    esxcfg-firewall -o 123,udp,in,nptServer
    esxcfg-firewall -o 123,udp,out,nptServer

    yep, I’d also open the port for ntp-server usage: Best to configure all esx-hosts as each others ‘peer’ in the ntp config. Then if the central clock fails, the hosts keep in sync among themself.

  3. GregW’s avatar

    Agree

    Slight amendment though guys

    Hence, best to force it all:
    /etc/init.d/ntpd restart
    chkconfig ntpd on
    esxcfg-firewall -e ntpClient
    esxcfg-firewall -o 123,udp,in,ntpServer
    esxcfg-firewall -o 123,udp,out,ntpServer

    (ntpServer not nptServer)

    nice work guys!

Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>