On 8/4/08, Tangren, Bill <bill.tangren@xxxxxxxxxxxxx> 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@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
