Webmail Session times out after 5mins of inactivity

Hi Andy,

 

 

I wouldn't suggest setting any idle timeout to indefinite as unclean closes will leave stale connections in the connection table until a restart.

 

 

I'd guess it's a SNAT timeout that you're hitting if you've already checked the protocol profile idle timeout. It could also be the timeout on the persistence profile. I assume if you're using a fastL4 profile that you're using source address persistence. You might try creating a custom persistence profile with the idle timeout set to something like 3600 seconds and retest.

 

 

SOL7606 has details on the various session timeouts:

 

 

SOL7606: Overview of BIG-IP LTM idle session timeouts

 

https://support.f5.com/kb/en-us/solutions/public/7000/600/sol7606.html

 

 

Aaron

Hi Aaron,

 

 

1/ SNAT timeout was the other thing I thought of as well bc it has it's idle timeout set to 300sec, however I don't think I'm using SNAT. I mean it's enabled on the POOL but my connections from the outside are not being SNAT-ed so I wouldn't think SNAT comes into play.

 

 

Eg:

 

WEBMAIL_HTTPS_POOL

 

Allow SNAT Yes

 

 

Maybe I'll try Allow SNAT No and see if this is the culprit.

 

 

2/ I've tried a custom persistence profile with the idle timeout set to something higher but still getting session time outs at 5mins.

 

 

3/ On another note I went back and tried the fasthttp profile with cookie persistence and this seems to keep the session open. I noticed that the fasthttp profile has an idle timeout of 300sec. What happens after 300sec bc I'm not seeing the session close at all?

 

 

When using the fastL4 profile(s), I noticed that after 300sec I would be returned to the webmail login. With fasthttp profile, after 300sec my session is still active but I think my cookie session ID changes every 5mins??

 

 

When I first log on, the URL looks like this:

 

https://webmail.netspace.net.au/horde/imp/mailbox.php?mailbox=INBOX

 

 

After 5 mins, URL chnanges to this...

 

https://webmail.netspace.net.au/horde/imp/mailbox.php?page=1&uniq=1261572664b9d6c25dffec

 

 

Thanks.

 

 

Andy

It's all getting too confusing now...

 

 

Last week I could not get this working at all with fastL4 profile using source address persistence. After 5mins my session would time out and I would be back at the webmail login prompt.

 

 

Today I did a few things...

 

 

I tried fasthttp profile with cookie persistence:

 

- works ok but intermittent issues where the page would not load and just hang

 

 

I went back to using fastl4 profile with source address persistence:

 

- now working ok, didn't work last week

 

- haven't come across any known issues yet

 

 

Can somebody please see if my understanding of the persistence timeout is correct?

 

 

With cookie persistence, it has Session Cookie Expiration enabled. Is this just saying that when I close the browser or tab, the session officially ends then or does the cookie timeout after a certain time?

 

 

With source address peristence, it has Timeout set to 180sec. From reading about this, the timer indicates that the persistence will timeout after 180sec of my session ending. This means if I was end my session and then re-log back in before 180sec then I would hit the same real machine again.

 

 

Thanks.

 

 

Andy

 

 

 

 

We're seeing very strange results with this setup now.

 

 

We're load balancing 4 webmail servers using fastL4 profile with source address persistence. I'm seeing my webmail session time out on 5mins so I'm thinking this is great because it must be matching the idle timeout of the fastL4 profile which is set to 300 seconds. To further test this out, I changed the idle timeout to be 30secs - but what do you know, it's not timing out after 30secs of my webmail session being idle but at 5mins again. I don't get it. We're not using any SNAT so you can rule out that timeout. The only other option is the VLAN group but I don't even think that comes into play based on the the line below.

 

 

https://support.f5.com/kb/en-us/solutions/public/7000/600/sol7606.html

 

 

"In a VLAN group configuration, traffic that does not match a configuration object, such as a virtual server or SNAT, is handled by the Layer 2 (L2) forwarding proxy."

 

 

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=189

 

 

Option | Default in seconds | Configurable?

 

Protocol profiles (tcp, fastHTTP, or fastL4) 300 Y

 

Protocol profile (udp) 60 Y

 

SNAT / SNATpool 300 Y

 

SNAT automap 300 N

 

VLAN group 300 N

 

 

Any ideas ?

 

 

Thanks.

 

 

Andy

 

Two semi random ideas, which may or may not help.

 

 

1) A firewall in the mix could also impose that idle timeout issue (I always suggest matching them with BigIP), and

 

 

2) I'd test all this again after you're 100% positive that the connection table on the BigIP is clear. You may be re-using old connections with old behavior attached.

 

 

-Matt

 

I believe I've been able to fix this now.

 

 

I think what is happening is that once a connection is intiated between the client > LTM > server, the LTM keeps track of two different idle time outs.

 

 

1/ fastl4 profile - idle timeout 300 sec (to do with keeping the tcp connection /socket alive )

 

2/ source address persistence - idle timeout 180sec (to do with keeping the session alive )

 

 

I believe webmail (horde) has a feature where every 300sec it renews/updates the session id. We've noticed that every 5mins, the URL refreshes and contains a new "uniq=14423679ba97d91" string at the end of it.

 

 

So at the 300sec mark, webmail tries to renew /update the session id but the LTM has already trashed the session id information because it's got a source address persistence idle timeout of 180sec. And so because there is no matching session id found on the LTM, webmail ends the session and logs out the user.

 

 

To fix this, we need to ensure that the source address persistence idle timeout is greater than 300 sec which I've set to 360 sec. Testing seems to indicate this is working.

Hi Andy,

 

 

With source address persistence, LTM only checks the client IP address using the persistence profile source netmask to check if there is an existing persistence table entry. LTM does not check anything other than the client IP address (or anything above layer 4). So the app session ID changing wouldn't have any impact on LTM persistence.

 

 

Your fix is correct though: if you want to ensure the client is persisted to the same pool member for longer than 180 seconds you'd want to extend the idle timeout on the persistence profile.

 

 

Aaron

Hi Aaron,

 

 

Thanks for clearing that up.

 

 

All I know from my testing is that if we didn;t alter the persistence time out to be greater than 300sec, when the webmail session id changed/refreshed at the 300sec interval, the session would be logged out and we;d be return the the webmail login screen.

 

 

 

Cheers.

 

 

Andy

Yep, the protocol profile idle timeout only affects the TCP connections. The persistence timeout affects the client being persisted to the same server and therefore the session being available.

 

 

Aaron

We have version 10.2 and are trying to use Cookie persistence with the FastHTTP profile and in some cases the application just hangs.