VMware Cloud Community
hla
Enthusiast
Enthusiast
Jump to solution

Bug - ESXi 3.5 U4: Broken ntp.conf file causes an open NTP server

By mistake I configured a machine on my network to use my ESXi 3.5 build 158874 server as an NTP peer. I was surprised that the server allowed a query from a machine on another network.

I then logged into the ESXi server using the "unsupported" method and checked the /etc/ntp.conf file.

restrict kod nomodify notrap noquery nopeer
restrict 127.0.0.1
server dk.pool.ntp.org
server pool.ntp.org
driftfile /etc/ntp.drift

Looking in "/var/log/messages" the server complains that "kod" is an invalid host:May 7 13:02:17 root: ntpd Starting ntpd

May 7 13:02:17 ntpd286306: ntpd 4.2.4p2@1.1495 Wed Jun 27 23:39:23 UTC 2007 (
1)
May 7 13:02:17 ntpd286307: precision = 0.468 usec
May 7 13:02:17 ntpd286307: Listening on interface #0 wildcard, 0.0.0.0#123 Di
sabled
May 7 13:02:17 ntpd286307: Listening on interface #1 lo0, 127.0.0.1#123 Enabl
ed
May 7 13:02:17 ntpd286307: Listening on interface #2 vmk0, 192.168.42.200#123
Enabled
May 7 13:02:17 ntpd286307: kernel time sync status 2040
May 7 13:02:17 ntpd286307: frequency initialized 9.259 PPM from /etc/ntp.drif
t
May 7 13:02:17 ntpd286307: getaddrinfo: "kod" invalid host address, ignored
May 7 13:02:18 ntpd286307: using drift file "/etc/ntp.drift" instead of "/etc/ntp.drift"

Seems like there is a missing "default" in the first line which should probably be:

restrict default kod nomodify notrap noquery nopeer

I have only used the VI Client to configure NTP. Can anyone confirm that this is an issue?

Best regards

Henrik

0 Kudos
1 Solution

Accepted Solutions
JOstro
Enthusiast
Enthusiast
Jump to solution

EDIT : -Sorry that was another issue

NTP bug

View solution in original post

0 Kudos
13 Replies
hla
Enthusiast
Enthusiast
Jump to solution

Anyone with ESXi 3.5 U4 and paches from 04/29/2009 that could configure NTP again from the VI Client and check the content of /etc/ntp.conf using the "unsupported" login feature?

0 Kudos
Scissor
Virtuoso
Virtuoso
Jump to solution

I can confirm the same behavior. Good catch!

0 Kudos
JOstro
Enthusiast
Enthusiast
Jump to solution

I got the following

68457]: getaddrinfo: "kod" invalid host address, ignored

68457]: using drift file "/etc/ntp.drift" instead of "/etc/ntp.drift"

0 Kudos
hla
Enthusiast
Enthusiast
Jump to solution

Could someone with a support contract report this bug to VMware. Apparently there is no way to report a bug or defect if you don't have a support contract...

I will give the "correct answer" points to the first person that confirm that they have created a case with VMware for this issue. I have no way to confirm it, so this is based on trust.

0 Kudos
JOstro
Enthusiast
Enthusiast
Jump to solution

Rang VMWare and they told me you can report online. (Although I do have a email address that is attached to support contract)

I have done this, and will let you know about their feedback

To Report-->

0 Kudos
hla
Enthusiast
Enthusiast
Jump to solution

Hmm... This is the opposite of what they write here:

0 Kudos
JOstro
Enthusiast
Enthusiast
Jump to solution

Just going by what the support tech # 03 86237239 advised I could do.

Didnt

really want to sit on the phone and wait to be transfered to a call

center in another country.. The email address I left has a valid

support contract so Im sure I will get a timely response.

Will keep you posted

0 Kudos
hla
Enthusiast
Enthusiast
Jump to solution

Have you created a support case using your support contract?

Did you get a case ID?

0 Kudos
JOstro
Enthusiast
Enthusiast
Jump to solution

EDIT : -Sorry that was another issue

NTP bug

0 Kudos
hla
Enthusiast
Enthusiast
Jump to solution

Thank you, please keep us posted about the result of the case.

0 Kudos
hla
Enthusiast
Enthusiast
Jump to solution

JOstro - any updates in this case?

0 Kudos
JOstro
Enthusiast
Enthusiast
Jump to solution

Nothing as yet, I have to ring support for another issue today, so I will ask about this case Smiley Wink

0 Kudos
Scissor
Virtuoso
Virtuoso
Jump to solution

Looks like they have fixed this issue in ESXi4.

0 Kudos