[OpenAFS] OpenAFS for Windows 1.5.72, Windows 7, VPN session killing

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

--------------ms020508070408060601030406
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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:jblaine@RCF.OUR.ORG"?
>=20
> 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 "jblaine@RCF.OUR.ORG" 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.
>=20
> 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.
>=20
> 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.
>=20
> I installed Wireshark and had a look at the small portion of
> network traffic before the VPN session was killed.
>=20
> 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.
>=20
> As soon as I added the following to libdefaults in krb5.ini,
> based on a completely bogus reading of the packets,
> everything worked fine:
>=20
>     dns_lookup_realm =3D no
>     dns_lookup_kdc =3D no
>=20
> 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).
>=20
> 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


--------------ms020508070408060601030406
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC
AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX
DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy
aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6
y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL
kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE
jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp
Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG
A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK
ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z
cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF
9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT
HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow
czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl
ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv
aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/
QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6
m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4
Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/
bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S
VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt
YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB
gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd
wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2
Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw
gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV
+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr
hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh
YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/
TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc
OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID
bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ
AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN
AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMTQwNDQ3MjhaMCMGCSqGSIb3DQEJBDEWBBRmeuqq
FVJMSmpFCYbWm0S/1VBUZzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw
YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x
LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs
9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBAGuvyYggnmlW9nm4HS5Qct5e4ELyy9lQBRSv
TlM1YMuWz/Ti4FQHr7GwMoLxgw8PXG9ACGFBXEU247sRVkhEBZxwNcXlJqmjP02jrlhJpEO7
EcLmJW8mESAn2xWxHh4E7mcgFtBlJKlGolm45NhO82RByfj7qt0878UMDrOtfg50STYiQF+h
RErxD3KYzmZDKTcsu9WaibWryh0E7FY9pKhccPwX+6/Xs2qjzle2yE10y5n6HxdifmsmzYFy
e39hX6l8S3uL8ZgojUIZUKJLlBEyhS8u7ClKs+/L/GHjaFESENkx/4nMjCadvCEQfYnGEjsU
QYgacN9KhQycbYlRGr8AAAAAAAA=
--------------ms020508070408060601030406--