[pkg-ntp-maintainers] Bug#455717: ntpd source address problem

[Ian Jackson]

I have this problem too, in etch.  In my setup I noticed that ntpd,
which had started just before the VPN client, was still not working
even though everything should have been working and up around 2 hours
previously.  So the scan time if there is one is at least 1h30min; say
at least 6000 seconds.  Thus I think the problem is not that we are
not waiting long enough.  Restarting ntpd after the VPN is up makes
the problem go away for me.

In my configuration, the VPN provides the only route to the NTP
server.  My `server' line names an IP address accessible only via the
VPN.  When the VPN is up, the route for packets to the NTP server is
via the VPN interface (sl* in my case) which has an RFC1918 IP address
assigned to it and which is therefore not accessible via the public
internet.

When the VPN is down (eg while the VPN client is starting) the route
for packets to the NTP server is the default route via ethx which has
a public IP address.  A firewall (on the same host as the ntp server
as it happens) prevents packets with RFC1918 addresses leaking so
those packets do not reach the NTP server (and even if they did the
firewall at the other end would prevent them reaching the NTP server
and even if not then both sets of firewalls would prevent the
replies).

What happens is that ntpd starts up with the vpn down.  It chooses a
globally-routeable source address for its packets to the RFC1918 ntp
server; it gets an EACCES from sendto since the firewall is local and
this is exposed to local users of udp by the Linux kernel.  So far
this is all correct (although of course not functional - it is not
expected to work until the vpn comes up).

When the vpn comes up I would hope that ntpd would at some point
choose a different source address.  Rerunning the source address
selection would result in its choosing its RFC1918 source address,
which gives reachability in both directions to the ntp server.
However this does not appear to happen - at least, not within a
reasonable timeframe.  Multiple ks after system startup is not a
reasonable timeframe for ntpd to even start working on its
associations.

The information I have above about ntpd's behaviour was gathered from:
 * examination of logfiles two hours after system boot, to try
   to diagnose the apparently-broken ntpd
 * restarting ntpd with the vpn down } while observing via tcpdump
 * restarting ntpd with the vpn up   }  and/or strace and/or
                                         iptables LOG rules

In my application it would suffice if I could persuade ntpd to bind
only to its private IP address and never to use the public IP address.
However there is no such option.  There is `-L' which is described as
`Do not listen to virtual IPs. The default is to listen.' which is
meaningless the phrase `virtual IP' does not refer to anything
definite.  Perhaps it means alias interfaces but in any case a more
flexible and better-documented answer would be helpful.

Kurt asked Martin in December 2007 whether Martin had added `dynamic'
to the server line but I cannot find any reference to this in the
documentation.  I tried adding it to the end of my `server', or
putting it in ntpd.conf on its own, but the ntpd rejected it.

I suppose I shall hold my nose and try putting in a one-to-one NAT
rule in my firewall to fix up ntpd's broken packets.

Ian.