ntpd on a NAT gateway seems to do nothing

[ian j hart]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at 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