On Thu, 3 May 2007, [EMAIL PROTECTED] wrote:
Thanks for your reply Paddy ! ;-)
>> Anybody ? Anything wrong with what I am suggesting ??
>
> What you are describing, I would call a firewall. It is supposed to protect
> those in other compartments when things blow up.
Indeed what I am suggesting is definitely called Destination Address
Network Translation at it definitely takes place at what we usually call
the firewall level. It has to be a stateful firewall. Note that more
and more devices offer firewall AND routing capabilities in 2007 and that
most of them are now stateful.
>
> In an ideal world, it wouldn't interfere with normal usage, whatever
> that is.
> And, in an ideal world, it wouldn't be used as an excuse to allow other
> stuff to remain broken: that path leads to trouble.
>
-In an ideal world, I wouldn't put metal detection devices at the gates of
airports. I would educate everybody so they don't blow up the planes. ;-)
I agree that path could cause trouble, but if the trouble is worth the
gains, then it should be fine. Then again, I said I am currently using
that solution on live networks and I have seen 0 problems so far, I
think it should be worth investigating a little more seriously.
Here is what happens with that config, from inside a LAN a machine
configured with 7 different ntp sources. The LAN machine thinks the 7
sources return approximately the same time, that's it ! The LAN machine
thinks it is talking to 7 different ntp servers thanks to DNAT. All
queries are answered by the same ntp servers in reality.
And no, it doesn't break anything. It could only break things if an
application would try to use udp 123 for other purpose than ntp. I am not
aware of any other applications using udp 123 except trojans or malicious
software so it seems safe to do this. In short, DNAT was made to handle
this very type of use case.
:~# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+18.26.4.105 .USNO. 1 u 279 1024 377 28.254 1.613 0.268
-206.223.0.15 .USNO. 1 u 254 1024 377 28.406 1.331 4.226
*18.145.0.30 .USNO. 1 u 375 1024 377 28.322 1.488 0.183
+64.230.172.46 .USNO. 1 u 135 1024 377 28.389 1.578 0.115
+64.230.159.74 .USNO. 1 u 222 1024 377 28.398 1.479 1.144
-128.233.150.93 .USNO. 1 u 204 1024 377 28.277 1.399 5.980
+128.233.154.245 .USNO. 1 u 263 1024 377 28.448 1.543 5.574
:~# ntpq -pn 18.26.4.105
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.21.0 .USNO. 0 l 1 16 377 0.000 0.004 0.001
+10.1.4.40 .USNO. 1 u 16 64 377 0.158 0.021 0.006
-204.34.198.41 .USNO. 1 u 9 64 377 62.109 -0.179 1.448
-10.1.4.209 .USNO. 1 u 32 64 376 1.942 0.762 0.410
+10.1.4.85 .USNO. 1 u 2 64 377 0.175 0.046 2.273
:~# ntpq -pn 128.233.154.245
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.21.0 .USNO. 0 l 4 16 377 0.000 0.004 0.001
+10.1.4.40 .USNO. 1 u 1 64 377 0.158 0.021 1.680
-204.34.198.41 .USNO. 1 u 43 64 377 62.109 -0.179 1.448
-10.1.4.209 .USNO. 1 u 3 64 377 1.986 0.897 0.333
+10.1.4.85 .USNO. 1 u 28 64 377 0.185 0.039 0.017
I see where you are coming from a purist standpoint although, I sure
wouldn't like my own provider to play tricks like that on me !!! ;-)) hehehe...
But I still think it is OK to use DNAT for ntp in a lot of LAN setups.
>> If not, why isn't anybody else seeming to be doing or recommending this ?
>
> plenty of people promote the use of firewalls.
I am glad to hear this, I just wished more people promoted the use of DNAT
in stateful firewall to handle their ntp traffic internally.
>
>> Could catching udp 123 outgoing request interfere with other applications ?
>
> The simple system you describe sounds like it is immediately going to
> screw with the expectactions of anyone carefully and deliberately using
> port 123 for anything but the simplest purpose, eg: checking one source
> against another.
See above, I haven't found one thing it breaks yet and I have searched and
searched, believe me.
> why not just block 123 at the firewall and provide an ntp service ?
>
That's an acceptable alternative !
1) It is less sneaky and more straight forward, forcing users to configure
their devices properly.
2) But it risks to break more things, devices loosing their time. We have
to think about all kinds of devices using ntp, not only the hosts
running a full fledged OS. ( voip devices, printers, sip phones, modems,
voip embedded servers, etc.)
As you can see, I am not a big believer into the chances of success of an
ntp police forcing all users to reconfigure their devices ;-))
I'll rest my case now. I have expressed the idea many times on this list
and I think there is no point in defending it anymore that I have
already done.
I might set up a FAQ page showing how to do this with major
brand firewalling and routing devices if I have time. If I do I'll post
the link here but apart from that, that's it for me on this
topic ! ;-)
Best regards,
Louis
http://www.pool.ntp.org/scores/74.14.248.210
http://www.pool.ntp.org/scores/207.236.226.149
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
