trogan152
asked on
Company website's logging users out.
We are a print company that offer an online service. One of our customers has been using the service for the last few months without a problem. But from last week all their users kept getting logged out seconds after they log in. The software is running on windows 2003 standard server. I went over to the company to try and sort out the problem and while waiting for the software developers to call me back i thought i'd check my email via Kerio webmail. This sits on a Linux Redhat Enterprise 3 box. I also get sessioned out of this straight away. I can access both applications from anywhere else (home, 2 other branches, developers). Both servers sit behind a Draytek Vigor 2910 firewall. The problem only seems to oocur from this one customer! Any help would be greatly appreciated as everyone seems to be scratching their heads!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If the load balancer is not set to persist connections, it could be a problem, as every request _may_ be sent to a different server, and the previous session lost. However, since it is only one user, it is most likely caused by the IE7 bug mentioned in that thread.
-dZ.
-dZ.
ASKER
there are actually 3 users with different log-in's but all at the same site. I'll check the IE7 settings when i can speak to one of them.
ASKER
also, when i use my laptop at home to connect to our servers i don't have any problems (IE7 or FF2). When i connect laptop to their network i get the same problems as them. One of the sites won't work with FF2 and i haven't tried the mailserver yet.
Thanks for all your help with this issue.
Thanks for all your help with this issue.
While not the end all test I would see if when on their LAN do they (or you when on site) have problems keeping sessions open to any other (excluding your server) destinations. For example if you logged into say Netscape or AOL webmail or such would you remain logged in? If you can't keep state anywhere it would lean heavier toward the load balancer being the culprit. This is because the destination server may see every other packet coming from a different source. It would not affect web pages in which state does not matter (non ssl) as each request could be it's own transaction. To prevent against false negatives track your cookies during your testing.
Also, does this customer VPN to access your servers, or are they Internet accessible?
Also, does this customer VPN to access your servers, or are they Internet accessible?
Actually AOL or Netscape mail might be bad examples as I don't believe they use SSL, and rely more upon cookies, which would last through different source IPs.
ASKER
It looks like it's definitely the load balancing. Spoke to their IT guy who turned the option off, logged in and broswed for 10 mins no problem. Turned the option back on and the system kicked him straight out. The wierd thing is I logged onto a different company using the same system and it worked fine! 'dropzone' mentioned 'session persistency' but they tell me there are no options for this on the router. At least we've narrowed the problem down. Thanks for all your help.
It wouldn't be an option on the router, but on the load balancing software/hardware. That option (or something called similarly) was the one on our system, an F5 Big-IP load balancer.
There are a few reasons why the other company's servers may not manifest the problem:
a. They may not have load balancing.
b. If load-balancing, they may have only 1 server (stupid, but it happens).
c. You have been very, very lucky to always get the same server when connecting to their system (stranger things have happened!)
d. They are using Session State Server instead of InProc Session State.
I'd go with "d": Session State Server is a service that comes with IIS which keeps all sessions separated from the HttpApplication process. Because of this, no matter which server you get in the load-balancing scheme, your session is available to all of them. There are some very good reasons to use State Server, among them the ability to reboot IIS or the machine without losing users' sessions, but there are some drawbacks also: The session needs to be serialized, which may incur a performance hit; and the Session_OnEnd event cannot be triggered (because the application does not have access to the lifetime events of the session).
dZ.
There are a few reasons why the other company's servers may not manifest the problem:
a. They may not have load balancing.
b. If load-balancing, they may have only 1 server (stupid, but it happens).
c. You have been very, very lucky to always get the same server when connecting to their system (stranger things have happened!)
d. They are using Session State Server instead of InProc Session State.
I'd go with "d": Session State Server is a service that comes with IIS which keeps all sessions separated from the HttpApplication process. Because of this, no matter which server you get in the load-balancing scheme, your session is available to all of them. There are some very good reasons to use State Server, among them the ability to reboot IIS or the machine without losing users' sessions, but there are some drawbacks also: The session needs to be serialized, which may incur a performance hit; and the Session_OnEnd event cannot be triggered (because the application does not have access to the lifetime events of the session).
dZ.
It could be on the router, as it is a load balancing router. When they come from different source IPs your web application will not inherently understand why every other packet is coming from a different source IP, and is viewing it as two half hearted conversations.
You should be able to, on their router, specify using which types of traffic go out on which WAN interface based on the port, source and destination IP ranges. So what I would recommend is having them bind all traffic to your network/servers to go out the same (ideally faster) interface thus having the same source IP when it gets to your server.
You should be able to, on their router, specify using which types of traffic go out on which WAN interface based on the port, source and destination IP ranges. So what I would recommend is having them bind all traffic to your network/servers to go out the same (ideally faster) interface thus having the same source IP when it gets to your server.
ASKER
thanks exploitedi, sounds like it could well be the case. I'll let you know when I visit customers site next week.
ASKER