Vincent Zweije schreef: > || I think you are over-estimating the fault finding abilities of the > || average Internet user. I have seen often enough that bad error > || conditions persist for a long time, even after the admin has been > || notified. Many admins won't put fault finding at a high priority as > || long as the network is not completely down. > > I am guessing that if someone misconfigures a device to use unroutable > addresses, more than just NTP will be broken, and it will probably be > noticed and acted on. > You assume that there will be other things broken than NTP. But this is not necessarily the case.
For example, at work we use PPTP tunneling for some remote access (laptops via UMTS). The PC signs on to Internet, gets a public IP, then builds a tunnel to the router public IP and gets a private IP address for use on the company network from PPTP. Say the laptop has public IP A.B.C.D and gets private IP 10.11.12.13. The router is on public IP E.F.G.H and has private IP 10.0.0.1. The NTP client on the laptop (running Windows XP Professional) is configured to obtain time from 10.0.0.1, a Cisco that runs NTP service. When the laptop is on the LAN it gets another address in the 10.*.*.* network on its ethernet interface, and this works beautifully. But in the above remote access scenario, the firewall starts logging attempts to send NTP packets from A.B.C.D to 10.0.0.1 via the tunnel. I.E. Windows encapsulates the packets to be sent to the private tunnel endpoint address, but the source address of the packets is not the local tunnel endpoint but the public IP address on Internet. This is of course a bug in Windows XP. Would you think that someone at Microsoft actually notices this and will do something about it? Apparently not. The user will not notice there is no timesync when working mobile, and the clock will be resynced when they are back at base. The only reason I know this, is because we have quite restrictive firewall rules that detect this problem. (there are also some other packets with the same problem during startup of the session, but the only persistent problem is the NTP client service. all other traffic flows normally) Rob _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
