Cookie Insert Persistance - Same V Server, different Service

I'm thinking you could define the nodes on port any (0) and then use the standard cookie insert persistence profile, but I haven't tested this.

 

 

Else, you could try referring to this related post:

 

Click here

 

 

Aaron

 

 

The nodes aren't where the port is defined, our configuration defines that at the Virtual Server level.

 

I have two virtual servers, one for port 80 & one for port 443. The VServer for Port 80 has a cookie insert profile and has an iRule that directs it up to SSL. Then the second VServer serves up the SSL traffic but the cookie that was inserted at port 80 is not maintained.

 

 

Let me know if this doesn't make sense, this is my first time posting.

If the VIPs are configured on the same IP address (and domain), you could define the nodes on port 0 and use the same pool for both VIPs. Then configure cookie insert persistence on both VIPs.

 

 

I believe this should work as the persistence entry in the cookie is recording the node's IP address and service that a request is load balanced to (not the VIP's port).

 

 

The VIPs need to be on the same IP address or domain so that the client will present the cookie when requests go to the HTTPS VIP.

 

 

Aaron

Unfortunately, can't define the node to port 80 since we're using the Big-IP for SSL termination.

 

Since we are SSL terminating, we need the defined endpoint.

 

 

If you define the port on a single pool to 0 and disable address translation, the connection to the pool will be made using the same destination port as the VIP. So if you have two pools currently: one on port 443 and the other on port 80, you could replace them with a single pool on port 0. The persistence record added to the cookie will then be valid for both VIPs.

 

 

On the other hand, if you're leaving the traffic from the 443 VIP decrypted to the node, you should be able to use just one pool defined on port 80.

 

 

If neither of these scenarios are accurate, please provide more detail on what you have configured and what you require.

 

 

Thanks,

 

Aaron

Hi,

 

Thanks for your responses. Let me try and explain the configuration a little more.

 

 

I have 2 Virtual Servers, with the same IP address, one for port 80 & one for port 443.

 

The VServer for port 80 has an iRule defined that redirects the user up to SSL and an insert cookie profile.

 

The VServer for port 443 also has an insert cookie profile and an iRule that checks that the browser for a bad cipher. The SSL profile is also set here. The iRule defined here checks to see if the pool is available, and if it is, sends the user to that pool. The two members of that pool are set to node1:80 & node2:80. There is only one pool set up, and VIP:80 points to node1:80 and node2:80 in a pool. The VIP:443 points to the same pool/node configuration. Based on that configuration, definining the nodes to port 0 wouldn't help. The VIP's are set to the same nodes/pool now and the cookie does not persist.

 

 

Thanks for the clarification. I think this is your current configuration:

 

 

VIP:443 -> client SSL profile -> iRule1 -> pool1:80

 

VIP:80 -> iRule2 to redirect to VIP:443 (-> pool1:80??)

 

 

Are you redirecting all requests to VIP:80 to the VIP:443 using iRule2? Do requests ever make it to the nodes for the VIP:80?

 

 

If all requests to VIP:80 are being redirected to HTTPS or if no stateful content is being provided over HTTP, there shouldn't be any need to persist client requests to VIP:443 to the same node they used for VIP:80 (and therefore you shouldn't need to add a persistence profile to VIP:80).

 

 

Regardless, if you're using the same pool for both VIPs, the cookie insert persistence profile should work without setting the nodes in the pool to port 0. This assumes that the two VIP's are on the same IP address or host (so the client will actually send the cookie it received from VIP:80 to VIP:443).

 

 

This is a basic function of persistence. I don't think either rule should have any bearing on the peristence functionality. If this isn't working, I would suggest contacting support to get some assistance. It should be pretty straightforward for someone to take a look at your configuration in a tech.out and figure out exactly what's not working and why.

 

 

Aaron

The request initally hits the VIP:80 and then is redirected with the IRule, but a cookie gets passed back from the first request on port 80. The cookie does not get persisted and the user gets a message:

 

'You don't have cookies enabled, you must have cookies enabled to view page'. If they refresh the screen, they are fine.

 

 

We have an open case with F5 tech and they recognize the problem, but suggested coming here to look for an IRule to resolve it.

It sounds like the web app requires statefulness between HTTP and HTTPS requests. I'm also guessing that the issue isn't with the BIG-IP's persistence cookie, but the web app's.

 

 

Is the web app setting a cookie when the client makes the initial request(s) via HTTP?

 

 

Is the client not presenting the cookie it receives from the web app via HTTP to the HTTPS VIP?

 

 

If so, what are the properties of the cookie (path, domain, etc)?

 

 

Are the two VIPs on the same virtual IP address?

 

 

Is the client accessing the VIPs by hostname?

 

 

If so is the hostname the same for both HTTP and HTTPS?

 

 

Also, what's the case number?

 

 

Thanks,

 

Aaron

Here's the answers to your questions:

 

 

Is the web app setting a cookie when the client makes the initial request(s) via HTTP? Yes

 

 

Is the client not presenting the cookie it receives from the web app via HTTP to the HTTPS VIP? Yes, this is where the cookie gets lost

 

 

If so, what are the properties of the cookie (path, domain, etc)?

 

The cookie is generated from peoplesoft, tells you the server name, and the session ID

 

 

Are the two VIPs on the same virtual IP address? Yes

 

 

Is the client accessing the VIPs by hostname? Yes

 

 

If so is the hostname the same for both HTTP and HTTPS? Yes

 

 

Also, what's the case number? The case is: C283615