# Persistence issues when using two different Virtual servers for the same traffic **URL:** \ **Category:** Technical Forums\ **Tags:** big-ip-access-policy-manager-apm, persistence, https, ltm, application-delivery, cookie, nat\ **Created:** [October 21, 2019, 2:26pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376 "2019-10-21T14:26:44Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Rosieodonell](https://avatars.discourse-cdn.com/v4/letter/r/ba9def/32.png) [@Rosieodonell](https://community.f5.com/u/Rosieodonell)\ **Post date:** [October 21, 2019, 2:26pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376/1 "2019-10-21T14:26:44Z")
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](https://website.org) (external) to [https://server/website.org](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. ---
**Author:** ![AceDawg1](https://avatars.discourse-cdn.com/v4/letter/a/3ab097/32.png) [@AceDawg1](https://community.f5.com/u/AceDawg1)\ **Post date:** [October 21, 2019, 8:30pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376/2 "2019-10-21T20:30:41Z")
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: 1. Virtual server A: clientside and serverside SSL profiles 2. Virtual server A: http profile (optional but recommended) 3. Virtual server B: clientside SSL profile (serverside SSL profile depends on whether the pool members have SSL enabled) 4. Virtual server B: http profile 5. 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. ---
**Author:** ![Rosieodonell](https://avatars.discourse-cdn.com/v4/letter/r/ba9def/32.png) [@Rosieodonell](https://community.f5.com/u/Rosieodonell)\ **Post date:** [October 21, 2019, 8:38pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376/3 "2019-10-21T20:38:19Z")
​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? ---
**Author:** ![crodriguez](https://avatars.discourse-cdn.com/v4/letter/c/b77776/32.png) [@crodriguez](https://community.f5.com/u/crodriguez)\ **Post date:** [October 21, 2019, 8:43pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376/4 "2019-10-21T20:43:00Z")
How are you getting traffic from Virtual Server A to virtual server B? HTTP redirect or something else? ---
**Author:** ![Rosieodonell](https://avatars.discourse-cdn.com/v4/letter/r/ba9def/32.png) [@Rosieodonell](https://community.f5.com/u/Rosieodonell)\ **Post date:** [October 21, 2019, 8:49pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376/5 "2019-10-21T20:49:51Z")
​Virtual server A (which is using an app portal and not a loadbalanced pool) is sending traffic to [https://server/website](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. ---
**Author:** ![crodriguez](https://avatars.discourse-cdn.com/v4/letter/c/b77776/32.png) [@crodriguez](https://community.f5.com/u/crodriguez)\ **Post date:** [October 21, 2019, 9:26pm UTC](https://community.f5.com/t/persistence-issues-when-using-two-different-virtual-servers-for-the-same-traffic/55376/6 "2019-10-21T21:26:35Z")
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: ![image_246537.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/9/9a52a82981b67699cdbadc79164b552153946b91.png) 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](http://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.