On 3/13/2010 11:00 PM, Jeff Blaine wrote: > MIT KfW 3.2.2 > Windows 7 32-bit > Cisco VPN 5.0.05.0290 > Cisco VPN does not exist for 64-bit, and is essentially EOL'd
So this is the old Cisco VPN that is not supported on Windows 7. >> Its worth a hell of a lot. Now you have narrowed down a minimal >> reproducible test case. The next question is "what is your ccache?" >> Is it the MSLSA or is it something like "API:[email protected]"? > > I've not set anything explicit anywhere, so it's whatever the > default is. How would I check from the cli tools? the MIT klist.exe tells you. > The nid log said it was using API:, but I don't know if that > translates over to the KfW *cli* tools (which I've never touched > in my life before yesterday on Windows). NetIdMgr supports multiple ccaches at the same time. The ccache that is marked as "default" is the one that will be listed as the default for the command line tools as well as all applications that do not explicitly access a specific cache. >> Unfortunately, the only way to debug the krb5_32.dll library is to >> use a source code debugger. Attach a debugger to kinit.exe, set the >> command line to "[email protected]" and step into the library and >> execute one function at a time until the connection drops. Then >> repeat the process by going one level further with each repetition >> until the Win32 call that is triggering the event is identified. > > Would I be able to do this with Cygwin + gdb perhaps? I don't > own a dev environment for Windows. I've done it before a handful > of times with Solaris+Linux. You would use "Microsoft Debugging Tools for Windows" coupled with the symbol files that are included as an optional install component in the installer package. You would want to download the source code to match from MIT's web site. >> Another source of useful information would be to attach WireShark >> to the VPN connection and capture the traffic that is sent on the >> connection up until the connection drops. Cisco has experienced >> problems in the past with packet fragmentation of UDP packets. This >> could be a new instance of the problem. > > Yes, you've helped me before with that. Thank you. I already > have RxMaxMTU set to 1300 (tried 1400, then 1300, and left it > there). 1400 worked with XP and the same VPN client previously > for me. This is only for AFS communications. It does not affect other protocols such as Kerberos or DNS. >> I am fairly sure though that you can rule out any issues with OpenAFS >> and NetIdMgr. > > I installed Wireshark and had a look at the small portion of > network traffic before the VPN session was killed. > > I *originally* thought the AS_REQ that *did* happen and > get logged before the VPN session was killed was to an > incorrect IP address. I saw the DNS queries just before > AS_REQ, jumped the gun, and incorrectly thought, "Why is > it querying DNS to find the KDCs?" Is your KRB5.INI section complete? Do you have a "master_kdc" specified for your realm? If not, the DNS lookups will be used to try to determine which of the KDCs is the master. > Turns out, this misread was serendipitous. > > As soon as I added the following to libdefaults in krb5.ini, > based on a completely bogus reading of the packets, > everything worked fine: > > dns_lookup_realm = no > dns_lookup_kdc = no > > Looking back at the pcap more carefully, I noticed that all of > the DNS queries before AS_REQ were of the proper KDCs (3) and > in fact the AS_REQ and AS_REP were done with a proper KDC for > RCF.OUR.ORG. Were the AS_REP packets successful? Or were they returning an error? > So now I'm really confused. I re-ran both krb5.ini cases > (old and lines added) and confirmed that the addition of these > 2 lines above saves my VPN sessions from being killed, even > though without them I was talking to the proper KDCs fine > (but the VPN session was dying). > > Any ideas on that? Not really. I would need to look at the wireshark capture and preferably step through the code in a debugger. If the problem is related to DNS SRV queries, that would be very weird indeed. DNS SRV queries are performed using the Win32 DNS API. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
