Forum Discussion
Rosieodonell
Cirrus
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.
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.
RosieodonellVirtual 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.
How are you getting traffic from Virtual Server A to virtual server B? HTTP redirect or something else?
- Rosieodonell
So 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?
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.
