problem with ntp in a DMZ
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 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list |
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/ -- redhat-list mailing list unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list |
problem with ntp in a DMZ
On 8/4/08, Tangren, Bill <bill.tangren@usno.navy.mil> 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: > Hi there. This is almost always a firewall problem with source port 123 for the reply being blocked. I presume that nptdate uses some high value port for its source for the query and destination for the reply. However you state that 123 is open in both directions. Is the ntpd that you are querying bound to a specific interface or is it bound to *:123 in which case there used to be an issue where it would use a different ip address for the reply than the one it received the request on but that problem was patched a while ago. RFC1918 states that 192.168.x.x is the private address so 192.5.x.x should be ok certainly tick.usno.navy.mil is reachable from here in sunny scotland. My bet would be on the firewall config stopping the reply from tick.usno.navy.mil:123 reaching a high value (>1024) port bound to ntpdate. Run wireshark or tcpdump to see what is happening on aa at layer 2. best wishes mike -- redhat-list mailing list unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list |
| All times are GMT. The time now is 12:29 AM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.