ssl persist fails - 2 users go to the same session!

I don't know what you mean by sayign a client can enter into a session from another client. What are they doing, and what is happening that you don't want? How did it improve when you change the profile configurations?

 

 

Colin

 

Hello,

 

 

I apologize if the explanation was confusing. I will try to explain it better.

 

 

1- Web browser client1 access to: https://virtual_server_1:8081

 

2- LTM receives the request an open a new SSL request to one real server:

 

https://chosen_real_server:8081

 

3- Client1 authenticates in chosen_real_server and he/she enters in his/her account.

 

4- Web browser client2 access to: https://virtual_server_1:8081

 

5- LTM receives the request an open a new SSL request to one real server:

 

https://chosen_real_server:8081

 

6- Client2 authenticates in chosen_real_server and when he/she enters in his/her account but appears session of client1.

 

 

All real servers are identicals. They are apache servers working as front end servers in front of a database where users accounts are stored. They have got the same logical name: server.mydomain.com to reply answers to the LTM.

 

 

I have not got caching features purchased in LTM.

 

 

Thanks a lot for your help

 

 

Juanma

 

Hello,

 

 

I suspect that the re-used ssl session could be an old WEB session ended by closing the browser instead of closing it by the proper function in the Web portal. LTM could keep opened the session and to assign it to another client.

 

 

Thanks for your help

 

 

Juanma

Juanma -

 

 

Out of curiousity are your users coming from behind a proxy, perhaps a bluecoat? We have experienced a very similiar issue. With our old version 4.5.13 we had no issues, only when we try to release to the new units 9.3, we experience users information who would crossover. In our debugging of tcpdumps and such we noticed a pattern that all the users that were having the issues were coming from proxies.

 

 

Thanks,

 

Andrea

If either or both of you could contact F5 Support to determine if this is a product issue, that would be most helpful. (I'd escalate it myself, but I don't have any details or ability to repro.)

 

 

You can open a support case online: Click here or call 1-888-882-4447

 

 

Let us know if you find an issue we should know about.

 

 

thx!

 

/deb

Hi Deb -

 

 

I have gone through tech support on this issue, that is why I am asking Juanma if there are proxies that the customers are coming from. We had this issue and it took us over 7 months to figure out that the issue was with the way that v9 was changed and how proxies interacted with it. I wanted to try to save Juanma from the grueling pain of trying to figure out why this is happening. For us it was because 4.x sends the persistent cookie back everytime insuring that the cookie set to MAX Age = 0 would not be registered with the proxies. However in v9.x the cookie is only set on the first interaction with the client. All subsequent requests see this cache max age = 0 and bluecoats specifically consider this to be a type t-value object and will set it to cache causing users information to cross data. In order to solve this issue we had to change out max age= 0 to set it to private.

 

 

Thank you,

 

Andrea

 

Hello,

 

 

I opened a case in F5 to solve that issue a few days ago. For the moment, they are examinig my configuration and tcpdumps. I upgraded to the latest hotfix and force to renegotiate ssl sessions each 3 hours. The problem has not appeared yet but I remembered that it appearead passed some weeks from we put LTM in productive.

 

 

With regard to the proxy, internal users use a corporative proxy. I think that it could be from bluecoat too (I don´t manage it). I will let it know to the F5 technicals.

 

 

I will post the solution from F5 here as soon as I receive it.

 

 

 

Thanks a lot for your help.

 

 

Hello.

 

I probably had the same situation.

 

Is your case solved?

 

 

regards

 

pj

 

 

Hello,

 

 

After F5 specialists analyze: logs, configuration, operating system version and traffic flows they have diagnosed that my LTM is working fine but we would need a more deep study of the relationship between LTM and our corporate WEB application. They assure that this amazing behaviour could be originated from our corporate WEB application. As my F5 support does not include consultantship, they can´t continue working in. Nevertheless, they gave me one solution that has been working fine since then.

 

To configure my virtual server as a PERFORMANCE (LAYER 4). Disadvantages are that I can´t use any feature over layer 4 but fortunately this is not essential in my particular scenario. At this moment we are triying to configure https for clients-LTM and http for LTM-Servers, I think that it would work better.

 

 

I would like to thank for help from this splendid forum.

 

 

Juanma