Forum Discussion
pjcampbell_7243
Cirrus
CirrusSwitching pool members when going to SSL?
As I mentioned before we have a BIG-IP 9.4.3 Build 1.4 Final - For the same website we've got 2 separate virtual hosts and 2 separate pools (albeit the same IPs, just answering on 80 and 443 respectively). At some point in the process of checkout, we "go secure" and at that point, sometimes it will switch servers and we seem to loose session info, and the check out fails.
Persistence seems to be working properly up to that point. Is there a way to ensure that we stay on the same pool member when we change from HTTP to HTTPS. Since (to my knowledge) HTTP and HTTPS have to be separate virtual servers (I only see an option for 1 listen port), how do we do this?
pjcampbell_7243More info:
for the http profile, we have oneConnect and http profile. for SSL we have neither.- The_Bhattman
Nimbostratus
In the persistance profile, do you have "match accross virtuals" or "Match across Services" enabled if the you are using the same VS with different services?
CB - pjcampbell_7243Thanks again for your reply. I think we may have some fundamental issues with how this is configured.
We have a site that is http and then goes https during the checking process and is switching servers which is causing problems for us. We need it to stay the same and I am not sure how that should be setup correctly. As-is, there's 2 separate virtual server configs, one for http and one for https, as well as 2 separate pools, one for each.
where are these 'match across' options, or, how would we use the same virtual server with both http and https (I only see one service port option under the virtual server). Thanks...
For the HTTP virtual, we've got a custom named cookie persistence, using HTTP Cookie Insert, with an iRule to encrypt the cookies, then on the HTTPS virtual, we've got the generic/default SSL persistence. 
hoolioCirrostratus
If you want to use the same node IP for two VIPs, you would need to use the same persistence method. There are a few options for doing this:
1. Create one HTTP VIP and one HTTPS VIP pointing to the same HTTP pool. This would require decrypting the SSL and using no SSL between LTM and the pool. You could then use cookie insert persistence.
2. Create one HTTP VIP and one HTTPS VIP pointing to different pools. Add an iRule that Kirk just added to the Codeshare to each VIP:
Cookie Encryption across pools and services (Click here)
This might be the most flexible option as it should support client and/or server side SSL.
3. Use source address persistence with Match Across Services enabled on the persistence profile:
SOL5837: Match Across options for session persistence (Click here)
Aaron- pjcampbell_7243Thanks hoolio - this is basically what we ended up doing. We used JSESSIONID and universal persistence, and terminated SSL on the BIGIP.
