Just following the similarly names thread with a bit of interest and I decided
to check my own ntp setup and, to my surprise, discovered I also have a machine
which does nothing. What is more surprising to me is that it has the same
config as a number of other machines, all of which work.
We have a segment of network which is behind a NAT, and there is a BSD box
running 'pf' actiing as the NAT gateway. Running ntpd on the actual
NAT box does not work, but running it on the clients the far side of
the NAT does, or on clients the live side of the NAT. I should probably
exolain that the NAT goes onto another network which is also natted, though
that NAT is out of my control.
The ntp.conf file looks like this on all machines:
disable auth
enable ntp
driftfile /etc/ntp.drift
server 10.17.19.0
server 195.40.0.250
server 158.43.128.33
server 158.43.128.66
server 158.43.192.66
The time servers there are for easynet, pipex and an internal machine at
a remote location. ntpdate on the machine can query all the hosts fine,
but ntpdc -p gives:
remote local st poll reach delay offset disp
=======================================================================valliere.ns.eas
172.16.1.8 16 64 0 0.00000 0.000000 0.00000
=turpentine.ratt 172.16.1.8 3 128 7 0.01451 -0.007633 1.93823
=ntp2.pipex.net 172.16.1.8 16 64 0 0.00000 0.000000 0.00000
=ntp0.pipex.net 172.16.1.8 16 64 0 0.00000 0.000000 0.00000
=ntp1.pipex.net 172.16.1.8 16 64 0 0.00000 0.000000 0.00000
As you can see, it can only reach the internal machine. On other machines
behind the NAT it looks like this:
remote local st poll reach delay offset disp
=======================================================================valliere.ns.eas
10.50.50.2 2 256 377 0.00577 -0.004396 0.01192
=turpentine.ratt 10.50.50.2 3 256 377 0.01534 -0.004566 0.00482
*ntp2.pipex.net 10.50.50.2 2 256 377 0.00635 -0.004052 0.00899
=ntp0.pipex.net 10.50.50.2 2 256 377 0.00729 -0.002443 0.01395
=ntp1.pipex.net 10.50.50.2 2 256 377 0.00768 -0.002426 0.00951
But those connections are flowing through the NAT box oon which ntpd
is not connecting!
Any suggestions ? I assume it has something to do with the NAT, but I am
not sure what. All other TCP connections out from that machine to
external systems work fine, so it is not as if outbound connections from
there are not working at all.
-pcf.
On Monday 23 July 2007 13:50:09 Pete French wrote:> Just following the similarly names thread with a bit of interest and I > decided to check my own ntp setup and, to my surprise, discovered I also > have a machine which does nothing. What is more surprising to me is that it > has the same config as a number of other machines, all of which work. > > We have a segment of network which is behind a NAT, and there is a BSD box > running 'pf' actiing as the NAT gateway. Running ntpd on the actual > NAT box does not work, but running it on the clients the far side of > the NAT does, or on clients the live side of the NAT. I should probably > exolain that the NAT goes onto another network which is also natted, though > that NAT is out of my control. > > The ntp.conf file looks like this on all machines: > > disable auth > enable ntp > driftfile /etc/ntp.drift > server 10.17.19.0 > server 195.40.0.250 > server 158.43.128.33 > server 158.43.128.66 > server 158.43.192.66 > > The time servers there are for easynet, pipex and an internal machine at > a remote location. ntpdate on the machine can query all the hosts fine, > but ntpdc -p gives: > > remote local st poll reach delay offset disp > ======================================================================> =valliere.ns.eas 172.16.1.8 16 64 0 0.00000 0.000000 0.00000 > =turpentine.ratt 172.16.1.8 3 128 7 0.01451 -0.007633 1.93823 > =ntp2.pipex.net 172.16.1.8 16 64 0 0.00000 0.000000 0.00000 > =ntp0.pipex.net 172.16.1.8 16 64 0 0.00000 0.000000 0.00000 > =ntp1.pipex.net 172.16.1.8 16 64 0 0.00000 0.000000 0.00000 > > As you can see, it can only reach the internal machine. On other machines > behind the NAT it looks like this: > > remote local st poll reach delay offset disp > ======================================================================> =valliere.ns.eas 10.50.50.2 2 256 377 0.00577 -0.004396 0.01192 > =turpentine.ratt 10.50.50.2 3 256 377 0.01534 -0.004566 0.00482 > *ntp2.pipex.net 10.50.50.2 2 256 377 0.00635 -0.004052 0.00899 > =ntp0.pipex.net 10.50.50.2 2 256 377 0.00729 -0.002443 0.01395 > =ntp1.pipex.net 10.50.50.2 2 256 377 0.00768 -0.002426 0.00951 > > But those connections are flowing through the NAT box oon which ntpd > is not connecting! > > Any suggestions ? I assume it has something to do with the NAT, but I am > not sure what. All other TCP connections out from that machine to > external systems work fine, so it is not as if outbound connections from > there are not working at all. > > -pcf. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"It's deja-vu all over again. I found my works NTP service was broken on Friday, just after I started my holiday. Packets were going out but nothing was coming back. I'm using IPFW and ipnat, which I believe is somewhat unusual. Ipnat is there to 'fix' the source IP. Don't ask! Checking the logs it appears that this broke after I updated from 6.2-RELEASE-p1 to 6.2-RELEASE-p5. I found this in messages. May 30 17:25:31 firewall ntpd[825]: ntpd 4.2.0-a Tue May 29 20:59:19 BST 2007 (1) May 30 17:27:31 firewall ntpd[825]: too many recvbufs allocated (40) ntpq -p would report No Association ID's (from memory) Anyway; I just did a cleandir x2, rebuild and update to p6, and it's working again. Might be worth a try. -- ian j hart
Pete French wrote: > [...] > Any suggestions ? I assume it has something to do with the NAT, but I am > not sure what. All other TCP connections out from that machine to > external systems work fine, so it is not as if outbound connections from > there are not working at all. Note that NTP does not use TCP, but UDP. Are you sure that your filter rules are OK? It's certainly possible to have a bug in the rule set so it forwards NTP replies for the internal clients, but doesn't allow them to reach the ntpd running on the machine itself. Another question: Do you have a dynamically assigned IP address? In that case ntpd needs to be restarted when a new address is assigned, because ntpd has the unfortunate habit to bind to all addresses that exist at the time it is started. I'm running ntpd on a NAT gateway myself (RELENG_6), and there are no problems at all. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.