Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Red Hat Linux (http://www.linux-archive.org/red-hat-linux/)
-   -   problem with ntp in a DMZ (http://www.linux-archive.org/red-hat-linux/137199-problem-ntp-dmz.html)

"Tangren, Bill" 08-04-2008 02:16 PM

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

Andrew Bacchi 08-04-2008 03:59 PM

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

"Michael Simpson" 08-05-2008 11:48 AM

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 03:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.