VPN CHAP authentication is extremely slow

Question

When a client connects to VPN server, its connection usually time-outs. Investigating the logs show that CHAP authentication takes almost 2 minutes to complete. No wonder that the clients time-out. Does anybody have any idea why this happens? The log looks like this:
Fri Feb 15 14:44:57 2008 : rcvd [CHAP Response id=0xae <16d8af347907c328c8f5b372e5189d6700000000000000001ff63e1d9cb760c3ac7d3546075970 e6dcf77da48b6fdc4500>, name = "andrus"]
Fri Feb 15 14:46:47 2008 : sent [CHAP Success id=0xae "S=F4AFFA3E4908A8963BE2F7E8F2572AF91030E0B3 M=Access granted"]
There is 1:50 delay between lines 1 and 2.

Answer 1

I don't remember exactly what I did, because I tried out so many things, but I can summarize something.
It was my first OS X server setup and considering Apple's legendary ease of use, I didn't plan much ahead. Turns out that although it looks easy, you can end up with a bad configuration 90% of the time and this is really easy.
My planning was bad in a lot of ways.
1) I configured both network interfaces at first assigning static IP-s. Turns out that when I later disabled the use of the second interface because I didn't need it, the configuration records about this interface were left in many places in the system, notably the Kerberos and Open Directory.
2) I setup a local DNS server and used DNS domain name ".local" - a very bad idea, because it turned out that Bonjour (mDNS) uses that same name causing delays and conflicts. The idea was to setup the .local domain on the public IP addresses at first and later move over to private address use (192.168.x.x). Whenever you want to setup your own DNS on that same server and serve addresses that include your server's IP, then you absolutely MUST setup the DNS temporarily on another computer. After you have installed OS X you are free to migrate it over to it. You have to have all DNS records in place before you start the install, because Kerberos will be setu using the nane obtained using reverse lookup.
I think the second mistake caused the most of the trouble, but stray IP address records were also a nuisance. In the end I made a clean install with 10.4.11 instead of Leopard.