[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: problem with ntp in a DMZ



Bill,

I'm not certain this is your problem, but . . .

AFAIK, 192.x.x.x is a non routable (internal) address. It's possible that your DNS server or NTP server is blocking that address from the DMZ. Perhaps try starting a VPN client on the DMZ machine and see if that clears it up. Also, check that SELINUX is not interfering.

Good luck.

Tangren, Bill wrote:
I have two essentially identical servers, RHEL ES 4.6 fully patched. The
only difference is, one is in a DMZ and the other is not. Both can do an
nslookup on the time server I use (tick.usno.navy.mil), but when I turn
off ntp and use the ntpdate command, it fails on the server in the DMZ
and succeeds on the one that is not. Here is the output from ntpdate in
debug mode. First the one that succeeds:


[root ceres ~]# ntpdate -d tick.usno.navy.mil
 4 Aug 08:35:11 ntpdate[16244]: ntpdate 4 2 0a 1 1190-r Wed Apr 23
07:36:43 EDT 2008 (1) Looking for host tick.usno.navy.mil and service
ntp host found : ntp0.usno.navy.mil
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
receive(192.5.41.40)
transmit(192.5.41.40)
server 192.5.41.40, port 123
stratum 1, precision -20, leap 00, trust 000 refid [USNO], delay
0.02966, dispersion 0.00238 transmitted 4, in filter 4
reference time:    cc4175f6.c33a64a3  Mon, Aug  4 2008  8:35:02.762
originate timestamp: cc4175ff.647a9322  Mon, Aug  4 2008  8:35:11.392
transmit timestamp:  cc4175ff.62961c36  Mon, Aug  4 2008  8:35:11.385
filter delay:  0.02966  0.03514  0.03532  0.03551
         0.00000  0.00000  0.00000  0.00000 filter offset: -0.00061
0.002036 0.002256 0.002382
         0.000000 0.000000 0.000000 0.000000 delay 0.02966, dispersion
0.00238 offset -0.000610

 4 Aug 08:35:11 ntpdate[16244]: adjust time server 192.5.41.40 offset
-0.000610 sec


Now, the one that fails:

[root aa ~]# ntpdate -d tick.usno.navy.mil
 4 Aug 07:34:12 ntpdate[26513]: ntpdate 4 2 0a 1 1190-r Wed Apr 23
07:36:43 EDT 2008 (1) Looking for host tick.usno.navy.mil and service
ntp host found : 192.5.41.40
transmit(192.5.41.40)
transmit(192.5.41.40)
transmit(192.5.41.40)
transmit(192.5.41.40)
transmit(192.5.41.40)
192.5.41.40: Server dropped: no data
server 192.5.41.40, port 123
stratum 0, precision 0, leap 00, trust 000 refid [192.5.41.40], delay
0.00000, dispersion 64.00000 transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  1:28:16.000
originate timestamp: 00000000.00000000  Thu, Feb  7 2036  1:28:16.000
transmit timestamp:  cc4167b7.6069a4df  Mon, Aug  4 2008  7:34:15.376
filter delay:  0.00000  0.00000  0.00000  0.00000
         0.00000  0.00000  0.00000  0.00000 filter offset: 0.000000
0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000 delay 0.00000, dispersion
64.00000 offset 0.000000

 4 Aug 07:34:16 ntpdate[26513]: no server suitable for synchronization
found

You can see that in the latter case, it found the ntp server, but it got
no response from the transmit commands.
I noticed this problem just after updating to RHEL ES 4.6, though may
well have been coincidental. I talked to the firewall guy, and he says
that the port is open both ways into and out of the DMZ and no error
messages show up in the firewall logs when I run this command.

Can anyone point me in the right direction to solving this mystery?


---
Bill Tangren
U.S. Naval Observatory




--
veritatas simplex oratio est
        -Seneca

Andrew Bacchi
Systems Programmer
Rensselaer Polytechnic Institute
phone: 518.276.6415  fax: 518.276.2809

http://www.rpi.edu/~bacchi/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]