Forum Discussion

Jeff_Unger_1067's avatar
Jeff_Unger_1067
Icon for Nimbostratus rankNimbostratus
Dec 22, 2005

HTTP -> HTTPS -> HTTP Cookie Persistence

I have a ticket open with F5 technical support, but thought I might post my issue here as well, just to see if anyone might have some insight. I am not sure if this needs to be handled by an iRule specifically, or if basic configuration options can yeild the desired result?

 

 

A user connects to http://www.gosolodev.com:80 and enters login information. The BigIP directs the request to server1 and the user authenticates. At this point, the user is logged in to server1 and the BigIP uses cookie persistence to continue to direct that user to server1. As the user is navigating throughout the application, they click a link that uses SSL so they access https://www.gosolodev.com:443. At this point, the BigIP is not matching the cookie persistence and re-load balances the connection, possible directing the user to server2. Since the user was logged in to server1, server2 requires them to authenticate.

 

 

What we need to happen is as long as the same user with the same session is connecting to the BigIP, they should go to the same server, regardless of whether they are connecting via HTTP or HTTPS. The re-login presentation that happens is really just a by product to the issue. Does anyone know how to do this?

 

 

The following are the relevant entries in bigip.conf

 

 

monitor gosolodev-wl-https {

 

defaults from https

 

interval 10

 

timeout 31

 

send "GET /um/login.jsp"

 

}

 

monitor gosolodev-wl-http {

 

defaults from http

 

reverse

 

interval 10

 

timeout 31

 

recv " Weblogic Bridge Message Failure of server APACHE bridge:

 

No backend server available for connection: timed out after 10 seconds.

 

Build date/time: May 8 2003 15:20:38

 

Change Number: 257949 "

 

send "GET /um/login.jsp"

 

}

 

profile clientssl gosolodev-clientssl {

 

defaults from clientssl

 

key "gosolodevssl.key"

 

cert "gosolodevssl.crt"

 

}

 

profile serverssl gosolodev-serverssl {

 

defaults from serverssl

 

key "gosolowildssl.key"

 

cert "gosolowildssl.crt"

 

ca file "ca-bundle.crt"

 

}

 

profile http gosolodev-http {

 

defaults from http

 

insert xforwarded for enable

 

}

 

profile persist dev-gosolo-cookie {

 

defaults from cookie

 

mode cookie

 

cookie mode insert

 

cookie name GOSOLODEV-COOKIE

 

cookie expiration 0d 02:00:00

 

across services enable

 

across virtuals enable

 

}

 

pool dev-https {

 

monitor all gosolodev-wl-https

 

member 192.168.103.79:https

 

member 192.168.103.126:https

 

}

 

pool dev-http {

 

monitor all gosolodev-wl-http

 

member 192.168.103.79:http

 

member 192.168.103.126:http

 

}

 

rule strip-www-gosolodev {

 

when HTTP_REQUEST {

 

if { [HTTP::host] equals "www.primerica.gosolodev.com" } {

 

HTTP::redirect "http://primerica.gosolodev.com"

 

}

 

virtual dev-http {

 

destination 192.168.103.190:http

 

ip protocol tcp

 

profile gosolodev-http oneconnect tcp

 

persist dev-gosolo-cookie

 

pool dev-http

 

vlans DEV enable

 

}

 

virtual dev-https {

 

destination 192.168.103.190:https

 

ip protocol tcp

 

profile gosolodev-clientssl gosolodev-http gosolodev-serverssl oneconnect tcp

 

persist dev-gosolo-cookie

 

pool dev-https

 

vlans DEV enable

 

}

 

 

 

Thanks.

6 Replies

  • This is just a suggestion.

     

    If you wanted the BIG-IP to handle the SSL termination, you could use the same pool *http_pool" for both virtual servers then "match across virtual servers" would probably work.

     

     

    See:

     

    http://tech.f5.com/home/bigip-next/manuals/bigip9_0/bigip9_0config/ConfigGuide9_0-10-1.htmlwp1184508

     

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    The only way to do this would be if the BIG-IP is handling the SSL termination. And, since you are naming your cookie, this should already work (by default, the cookie name includes the pool name but since you specified the cookie name, it has to lookup the node in whatever the current pool is).
  • Posted By unRuleY on 12/27/2005 6:15 PM

     

    The only way to do this would be if the BIG-IP is handling the SSL termination.

     

     

    Unfortunately, this is not possible for us (junger and I work together). Due to other security requirements, we must have SSL termination at the end server that handles the request. We cannot have unencrypted traffic between the LB and the processing server when the incoming client request is over SSL.

     

     

    Is it not possible to have HTTP and HTTPS persistence if the BIG-IP is not the SSL terminator? We don't have to use cookie based persistence if one of the other methods will accomplish this.
  • This is the same issue that is being discussed in a different thread without the SSL termination issue (http://devcentral.f5.com/Default.aspx?tabid=28&forumid=5&postid=5939&view=topic).

     

     

    In that thread you state:

     

     

    Posted By unRuleY on 1/03/2006 2:25 PM

     

    Unless you decide to use cookie persistence, you will probably want to use the across virtuals and across pools settings to allow a persistence record to be applied to different pools.

     

     

    Can you expand on this? Why does cookie persistence matter here? We've tried all combinations of matching to no avail so I'm assuming it's the SSL pass through that's causing the failure...
  • It is possible to have client-side ssl offload, then re-encrypt for your SSL requirement on the backside. No performance gain in doing so, but you gain the traffic management control.
  • By using both client_SSL and server_SSL you can have end to end encryption and still have control over the traffic using the load balancer.

     

     

    Use the client_SSL profle to handle SSL to the client side, and server_SSL profile for encryption to the server.