Forum Discussion

Rosieodonell's avatar
Rosieodonell
Icon for Cirrus rankCirrus
Oct 21, 2019

Persistence 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.

application delivery
BIG-IP Access Policy Manager (APM)
cookie
https
LTM
nat
persistence

5 Replies

Sort By
  • AceDawg1's avatar
    AceDawg1
    Icon for Nimbostratus rankNimbostratus
    Oct 21, 2019

    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.

  • Rosieodonell's avatar
    Rosieodonell
    Icon for Cirrus rankCirrus
    Oct 21, 2019

    ​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?

  • crodriguez's avatar
    crodriguez
    Ret. Employee
    Oct 21, 2019

    How are you getting traffic from Virtual Server A to virtual server B? HTTP redirect or something else?

  • Rosieodonell's avatar
    Rosieodonell
    Icon for Cirrus rankCirrus
    Oct 21, 2019

    ​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.

  • crodriguez's avatar
    crodriguez
    Ret. Employee
    Oct 21, 2019

    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.