Frank --

Thanks for your follow-up private e-mail, as I don't follow these forums.

No, I have not heard of any solutions. In further research, I came across
this knowledgebase article

http://support.microsoft.com/default...b;en-us;325034

which I think is the root of my (our) problem and which got my hopes up in
its reference to an update described in another knowledgebase article:

http://support.microsoft.com/kb/818043

but then my hopes were dashed when I saw that the "L2TP/IPsec NAT-T update"
described in 818043 is included in WinXP SP2 -- which I of course installed
long ago, so clearly this update did not fix the problem.

I suspect the problem is that the IPSec component of the TCP/IP stack in
WinXP continues to think the certificate for the previously engaged IPSec
session is still valid even though the session has been disconnected, and
there's some sort of a 60-second timer in the IPSec code for
trying/re-trying/re-re-trying the Last Known Good certificate before the code
gives up and starts down whatever road it has to go down to get a new, valid
certificate with which to set up the new IPSec connection. The fix probably
should be a catch in the code that when an IPSec session disconnects, the
certificate being used for that session immediately becomes invalid and the
code shouldn't waste any effort trying to use the same cert again on the next
IPSec connection attempt.

Again, please note this is all said under the terms of my original
disclaimer that I don't have a clue how IPSec and related technologies
actually work.

Bottom line: I remain at a loss for a fix and continue to waste minutes of
my life here and there because of this problem.

-- LBA

"FrankV" wrote:

- quote -

Thanks for the detailed description. I think you have found the problem but,
as you said, it's a general answer without the specifics of actually
correcting it. I hope someone else who really understands this can give us a
way to go-around the problem.

Frank


"afrinl" <afrinl[at]discussions.microsoft.com> wrote in message
news:41A5CF18-A485-42FB-878F-641D0D05BC61[at]microsoft.com...
- quote -

Howdy --

I have reason to believe that the MS Money "sign-in could not be verified"
problem (witnessed by me in MS Money '03 and '06, and reported by others in
many other annual releases of this app) is not a problem in Money but rather
is a much deeper problem rooted somewhere in the Secure TCP layer of the
TCP/IP network stack.

Disclaimer: I am not a networking software engineer and have virtually no
understanding of network stacks or network security issues such as
encryption, SSL, HTTPS, tunnelling and L2TP, IPSec, VPN, etc., but on the
plus side I've got 30 years of software development experience, so I've got a
reasonably well-developed sense of "smelling" the likely location of a
problem once I've seen how an app (mis)behaves.

I have been observing problems on my WinXP laptop with (mostly Microsoft)
apps that need to communicate to servers out on the Internet via secure
channels ever since I installed VPN software on my laptop several years ago.
My institution uses Cisco VPN servers, so I use Cisco VPN client software,
but the problem has persisted across many versions of the Cisco VPN client,
and thus I have some suspicion that the problem is actually rooted in the
WinXP network stack.

Here's the (mis)behavior that I've seen: I fire up the app, and for one
reason or another it needs to establish a secure connection to a remote
server. For example, I fire up Internet Explorer and I need to visit an
https://... site, or I fire up Money and I need to go through the secure
login process with my MS Passport.

Well, if the VPN connection is engaged prior to firing up the app, the
secure connection to the remote server typically proceeds immediately,
without trouble.

However, if I have disengaged my (previously engaged) VPN connection prior
to firing up the app (so that I'm now talking directly to my ISP's network
rather than tunnelling through my ISP to my institution's network), then I
find that the secure connection attempt hangs, typically for about one
minute, and then, most of the time, reports a failed connection attempt. (In
Internet Explorer, I simply get the usual error message about how the remote
server cannot be found. In Money, I get the "sign-in could not be verified"
message.) On occasion, I will get a successful connection after the hang,
but the great majority of the time I get the hang and then the failure.

If I experience this hang and connection failure, and then go back,
re-engage the VPN connection, and try to connect with the app again, the
secure connection goes right through.

Also, if I have freshly booted the machine and have not yet engaged a VPN
connection, my secure connection attempts go right through.

And, if I am using a non-Microsoft app (say, Firefox or Opera), the secure
connection will typically be made quickly, without a hang, even if I have
disengaged the VPN from a previously engaged state.

But overall, over the last few years, I have gotten the distinct sense that
(1) disconnecting a VPN session leaves the Secure TCP layer of the network
stack in some sort of confused state that makes it difficult to subsequently
establish secure connections, and (2) Microsoft apps, moreso than
non-Microsoft apps, are doing "something" extra when attempting to establish
secure connections that makes it much more likely that they (the MS apps)
will get tripped up by this confused state and hang.

Thus, I am curious as to what proportion of all the people who have been
reporting "sign-in could not be verified" problems in Money are working on
machines that also have a VPN client.

The issue absolutely is not related to whether the VPN *service* is running
on my macine. The service is always running. Rather, the issue is whether
or not a VPN connection is actively engaged at the time I fire up the app and
it attempts to establish a secure connection to some remote server.

I have additionally observed that when the secure connection attempt fails,
subsequent attempts sometimes work and sometimes don't. Usually, if the
first try fails, the second or third try succeeds, though sometimes many,
many tries still fail; sometimes I even have to exit and restart the app to
get it to securely connect properly. The number of times I have to try seems
random, but I'm sure it's just my failure to identify other subtly
interacting factors.

Ironically, even my VPN client is subject to this problem. When I call up
the client to engage a VPN session the first time after I've booted the
machine, it establishes a secure connection with the remote VPN server very
quickly. But if I disengage that connection (which most typically happens
because I shut the laptop lid and it goes into Standby or Hibernation mode,
but can also happen because I manually choose to disengage) and then later
attempt to re-engage it, the VPN client almost always suffers the one-minute
hang before it successfully connects with the remote VPN server. Not always,
but almost always, and I have yet to figure out which factors affect this.
(Actually, that's not totally true. This may sound crazy, but I have
observed that if I hit the Enter key (same as clicking on the Connect button)
within an instant of the appearance of the VPN window on my desktop, the
likelihood of a secure connection to the VPN server going right through is
far higher than if I pause. If I pause -- for even a second -- after the VPN
window comes up before I hit the Enter key or click on the Connect button,
the connection progress status quickly gets to the "Contacting VPN server"
point and then fairly reliably hangs for a minute before the connection
finally goes through.)

This obviously is one of those problems for which it's exceedingly difficult
for a plain old user to accurately describe, much less pin down the source,
so I'm not too surprised that I haven't found any significant discussions of
the matter. I suspect what's actually happening is that users are reporting
specific errors they're seeing with various apps, but few folks are seeing
the overall pattern that this is a problem with establishing secure TCP
connections that may have some interaction with VPN functionality. I have
searched the net (including Microsoft and Cisco knowledgebases) as best I can
to find descriptions of, and solutions to, this problem, and basically have
been unable to find either. But I know what I see, and there's no question
in my mind that the "sign-in could not be verified" problem I'm seeing in
Money when my VPN is disengaged is exactly the same "hang" problem I'm seeing
with most other MS apps trying to make secure connections when my VPN is
disengaged.

I'm posting this just as a piece of general information which, hopefully,
some day, will help some network software engineer identify a solution so I
don't keep losing these random minutes of productivity for the rest of my
life.

Thanks for listening...

Sincerely,

Larry Afrin, M.D.
Associate Professor of Medicine, Division of Hematology/Oncology
Director of Information Technology, Hollings Cancer Center
Medical University of South Carolina
afrinl[at]musc.edu