problem with ntp in a DMZ

[Michael Simpson]

On 8/4/08, Tangren, Bill <bill.tangren at 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