VMware ESX 3.5 ntpdate strangeness

We just noticed that the time was very far off on our sparkly new VMware EXS 3.5 server. When I went to run ntpdate to bring it up to sync, I was suprised to find that it could not make a connection to the time server because outbound UDP 123 traffic was blocked by the internal firewall. Here is what I got:

# /usr/sbin/ntpdate -u time.nist.gov
9 Apr 03:47:53 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:54 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:55 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:56 ntpdate[20245]: sendto(192.43.244.18): Operation not permitted
9 Apr 03:47:57 ntpdate[20245]: no server suitable for synchronization found

Normally I would just add a rule to the “/etc/sysconfig/iptables” file to allow traffic out on this port, but Vmware ESX server does not use iptables… It uses its own firewall, so I had to figure out how to change it. Happily, it turns out that there is a handy “esxcfg-firewall” command built just for such things.

Running this:
/usr/sbin/esxcfg-firewall -q | grep 123

12300 1803K valid-tcp-flags  tcp  --  *   *     0.0.0.0/0        0.0.0.0/0

Confirmed that UDP port 123 outbound was disallowed.

Running this opened it up:
/usr/sbin/esxcfg-firewall -e ntpClient

Grep out “123″ again just to be sure:
/usr/sbin/esxcfg-firewall -q | grep 123

1  76 ACCEPT  udp  --  *    *    0.0.0.0/0      0.0.0.0/0     udp dpt:123

And you can now run ntpdate to sync up the time:
/usr/sbin/ntpdate -u time.nist.gov

9 Apr 09:52:54 ntpdate[20319]: step time server 192.43.244.18 offset 21689.039217 sec

Leave a 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>