problem with ntp in a DMZ

[Andrew Bacchi]

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 at ceres ~]# ntpdate -d tick.usno.navy.mil
>  4 Aug 08:35:11 ntpdate[16244]: ntpdate 4.2.0a at 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 at aa ~]# ntpdate -d tick.usno.navy.mil
>  4 Aug 07:34:12 ntpdate[26513]: ntpdate 4.2.0a at 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/