On 11/10/2010 6:11 AM, Harry wrote: > On Nov 10, 2:59 am, "David L. Mills" <mi...@udel.edu> wrote: >> Harry, >> >> Autokey is not designed to work behind NAT boxes. The Autokey server and >> client must have the same (reversed) IP addresses. The intended model is >> using two interfaces, one for the Internet side running Autokey, the >> other for the inside net on the other side of the NAT box. >> >> Dave >> >> Harry wrote: >>> Hello, >> >>> I want to employ the AutoKey method of securing NTP. >> >>> Basically, I want one host that would act as an NTP client of an >>> external NTP server, talking AutoKey. This NTP client is to become the >>> NTP server for other hosts on the intranet. All these hosts are behind >>> a corporate firewall and are very likely using NAT / IP masquerading >>> as well. (I can tell NAT / IP masquerading is in use in our >>> environment because all hosts report the same IP address at >>> http://www.whatismyipaddress.com.) >> >>> I ask this question because I ran into a circa 2004 link (http:// >>> www.ecsirt.net/tools/crypto-ntp.html) that says, >>> Be Aware! >>> Before we start building ntpd, one important notice: >>> NTP with Autokey does not work from a host that is behind a >>> masquerading or NAT host! >> >>> Is this a conceptual / fundamental limitation, or something related to >>> NTP version? If latter, I'm hoping that it would probably have been >>> fixed by now. >> >>> If AutoKey and NAT don't go together conceptually, what would be my >>> next best option of securing NTP? Though MD5 method is there but it is >>> symmetric cryptography and prone to man-in-the-middle attacks... which >>> is why btw I was hoping to be able to employ AutoKey. >> >>> Many thanks, >>> /HS >> >>> _______________________________________________ >>> questions mailing list >>> questi...@lists.ntp.org >>> http://lists.ntp.org/listinfo/questions >> >> > > Dave, I really appreciate your response to my newbie question. > > May I ask (you or other users of this forum)... > > 1. What, then, would be the next best way (MD5-based symmetric key > mode?) to syncing up a behind-NAT NTP client from an external NTP > server in a tamper-proof manner? I'm not competent/powerful enough to > advise the powers what be in my organization to have an Autokey NTP > client outside our NAT/Firewall; most likely, I'll be told to continue > to operate from behind the NAT/Firewall. > > 2. What physical/network setup should Autokey-desiring NTP clients > follow? Is it OK, e.g., to have a Autokey client host (AkH) outside > one's NAT network and have all the hosts inside the NAT network use > AkH as a NTP server? > > > I also skimmed thru your (excellent) book on NTP. I was hoping to find > a mention of NAT in Chapter 9, but didnt. Not complaining, just humbly/ > respectfully bringing it up. So, please do elaborate here if you can > on this issue. > > Many thanks in advance, > /HS
The problem that you are running into is that NAT boxes rewrite addresses in the packet. Autokey depends on the addresses of both sender and receiver for the autokey authentication mechanism but because the addresses get changed the protocol will fail validation. NAT's are evil and not just for this reason. Danny _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions