Forum Discussion
CirrusPersistence issues when using two different Virtual servers for the same traffic
Here is the scenario that I have:
Virtual Server A is set up with an a simple application portal that sends all external clients/users from https://website.org (external) to https://server/website.org which is on another Virtual Server B on the same F5. We use to have another load balancer and we replaced it using the same F5.
So i am sending https traffic from one virtual server to another and trying to use cookie persistence but i think that the SSL is preventing any cookie insert. Basically my second virtual server B only sees the IP of the internal float IP and treats all traffic as one user so i don't get traffic to all pool members.
I am hoping that there is some kind of fix to this or will i have to redesign my first virtual server to not go to another virtual server and just load balance it's own pool members.
5 Replies
AceDawg1Nimbostratus
Question- are you performing SSL decryption/encryption on the Virtual Server A? In order to support cookie persistence on a HTTP/s virtual server in your architecture, the following pieces should be in place:
- Virtual server A: clientside and serverside SSL profiles
- Virtual server A: http profile (optional but recommended)
- Virtual server B: clientside SSL profile (serverside SSL profile depends on whether the pool members have SSL enabled)
- Virtual server B: http profile
- Virtual server B: cookie persistence profile
With regards to the http profile for Virtual servers A and B, I would probably create a custom http profile where x-forwarded-for is enabled. That way, the "true" client IP address can be captured.
RosieodonellSo I a currently have it setup like you said. But it seems like the traffic is encrypted from virtual server A to virtual server B. I did look at X-forward-for but I thought this just adds the client source IP to the header and doesn't affect source address persistence.
Can anyone confirm that x-forward-for would affect source ip persistence when load balancing traffic to pool members or does it use the internal float ip of the first F5 virtual server?
How are you getting traffic from Virtual Server A to virtual server B? HTTP redirect or something else?
- Rosieodonell
Virtual server A (which is using an app portal and not a loadbalanced pool) is sending traffic to https://server/website which is the DNS entry for Virtual Server B. So I think I am going to have to redesign this setup so that virtual server A doesn't use a portal connection and I just use reverse proxy and load balance directly to the servers instead of using another virtual server as the load balancer. I was looking for a short cut that's all.
I don't know if this will work for you, but I think you can set up virtual server A with nothing on it (no SSL, HTTP, or persistence profiles or load balancing pool) and use a local traffic policy to forward traffic to virtual server B at client accepted time. The policy rule looks something like this:
By forwarding the traffic internally at layer 4, you bypass the need for client/server SSL and HTTP profiles on virtual server A, and for a redirect. The cookie persistence profile goes on virtual server B, along with the requisite client SSL and server SSL profiles, and an HTTP profile. So, to summarize:
- Virtual server A - Standard host virtual server but with the Local Traffic Policy described above assigned to it; no pool, no L7 profiles
- Virtual server B - Client SSL profile; server SSL profile (if needed by the back end pool members); HTTP profile; cookie persistence profile
To users, it still looks like they're connecting to "website.org." I ran a quick test in my "play" BIG-IP v14.1 environment, and it seemed to do what I think you are looking to do.
