Thanks to both bishop and Michael for their comments. By the way, I omitted mentioning this in the original post, but I'm working with vtun 2.6-1. I doubt that submitting a patch for debugging for 2.6 would do much good.
Shortly after I posted the message, I decided that I was too impatient to wait, and started throwing vtun_syslog() calls into auth.c and recompiling. I narrowed the problem down to the second phase of the challenge - the client isn't returning the response that the server expects. Both ends have, for the connection configuration: tapbridge { passwd MyPasswordHere ; # Password type ether; # Ethernet tunnel proto udp; # UDP protocol compress no; # no compression encrypt no; # no encryption stat no; # turn off connection statistics keepalive yes; # Keep connection alive multi yes; # multiple connections allowed } I've confirmed that that portion of the config is identical at both sides (I omitted the up{} and down{} blocks. Unfortunately, the clients are Soekris net4501 and net4801 boxes. They're running an image that was developed by a previous employee quite a few years ago. The binaries on the client are statically linked, and I have no knowledge of how they were compiled, or even whether they've been patched from the official release. At this point, since I've narrowed it down to the server receiving an "incorrect" challenge, I'm going to try recompiling without SSL. Thanks, Jason Antman ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Vtun-Users mailing list Vtun-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-users