SSL Offloading + X-Forwarding + Cookie persistence

when i want to use cookie persistence i need to do SSL offloading due the fact that the VIP and REAL Servers use HTTPS.yes

Configured a Client SSL Profile, created a HTTP profile with Redirect Rewrite All and Insert X-Forwarded-For enabled. Results in TOO_MANY_REDIRECTScan you try clientssl, serverssl, http profiles with x-forwarded-for and cookie persistence?

e.g.

root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm virtual bar
ltm virtual bar {
    destination 172.28.20.111:443
    ip-protocol tcp
    mask 255.255.255.255
    persist {
        cookie {
            default yes
        }
    }
    pool foo
    profiles {
        clientssl {
            context clientside
        }
        myhttp { }
        serverssl {
            context serverside
        }
        tcp { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    vs-index 6
}
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm profile http myhttp
ltm profile http myhttp {
    app-service none
    defaults-from http
    insert-xforwarded-for enabled
}
root@(ve11a)(cfg-sync Changes Pending)(Active)(/Common)(tmos) list ltm pool foo
ltm pool foo {
    members {
        200.200.200.101:443 {
            address 200.200.200.101
        }
    }
}

 test

[root@ve11a:Active:Changes Pending] config  curl -Ik https://172.28.20.111
HTTP/1.1 200 OK
Date: Thu, 08 Aug 2013 09:33:07 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Thu, 23 May 2013 00:28:46 GMT
ETag: "4185a8-59-c3efab80"
Accept-Ranges: bytes
Content-Length: 89
Content-Type: text/html; charset=UTF-8
Set-Cookie: BIGipServerfoo=1707657416.47873.0000; path=/

There's actually a few things going here I think.

 

 

1. Users are getting moved around between servers because you don't have any kind of persistence enabled. The cookie-based persistence recommendation is actually a good one. Simply apply it in the virtual server properties and the client will receive a cookie that indicates the first chosen pool member.

 

 

2. Using any kind of layer 7 persistence method (cookie, universal, hash) requires the BIG-IP to be able to SEE the HTTP payload, so you would definitely need to decrypt the traffic with a client SSL profile. Whether you re-encrypt with a server SSL profile is up to you and the server admins, but generally speaking you're going to get a potentially huge performance boost if you leave it unencrypted.

 

 

3. The x-forwarded-proto header is rarely used, if ever, and I can't image Blackboard cares about it either. The x-forwarded-for header, however, is used quite often in situations where the proxy (BIG-IP) must change the client's source address (for internal routing) but the server still needs to be able to see the client's true source. You didn't indicate that you were SNATting, so I don't believe this header is necessary.

 

 

4. The HTTP profile's Redirect Rewrite setting is used when you are NOT re-encryting to a backend server, and that server (because it doesn't realize it's behind an SSL-based proxy) sends redirects to itself using "http://". The setting automatically rewrites these to "https://". If you're re-encrypting to the server, then this setting has no purpose.

 

 

 

Also, can you elaborate on "TOO_MANY_REDIRECTS"?

Thanks for your answers.

 

 

I've got SSL Offloading and cookie insertion working, only not for the intended servers.

 

 

When i use the server pool that uses HTTPS i get the error message in Chrome ERR_TOO_MANY_REDIRECTS

 

If i use a different pool that uses HTTP all works fine.

 

 

I configured the HTTP_Profile for this VIP with Redirect Rewrite setting, but with no result.

 

For Source Address Translation i use Auto Map

 

 

Is there a way to troubleshoot this?

 

When i use the server pool that uses HTTPS i get the error message in Chrome ERR_TOO_MANY_REDIRECTS can you post the virtual server and pool configuration?

 

 

tmsh list ltm virtual (virtual server name)

 

tmsh list ltm pool (pool name)

ltm virtual ELEUM-ACCEPTATIE-443 {

 

destination x.x.x.x:https

 

ip-protocol tcp

 

mask 255.255.255.255

 

persist {

 

ELEUM_COOKIE {

 

default yes

 

}

 

}

 

pool ELEUM-ACCEPTATIE

 

profiles {

 

SSL-ELEUMACCEPT {

 

context clientside

 

}

 

eleum-http { }

 

um_lan-optimized_tcp_profile_5400 { }

 

wan-optimized-compression { }

 

}

 

source 0.0.0.0/0

 

source-address-translation {

 

type automap

 

}

 

vlans {

 

external

 

}

 

vlans-enabled

 

}

 

tmsh list ltm pool ELEUM-ACCEPTATIE

 

ltm pool ELEUM-ACCEPTATIE {

 

members {

 

y.y.y.y:https {

 

address y.y.y.y

 

session monitor-enabled

 

state up

 

}

 

z.z.z.z:https {

 

address z.z.z.z

 

session monitor-enabled

 

state up

 

}

 

}

 

monitor um_https_monitor

 

}

When i use the server pool that uses HTTPS i get the error message in Chrome ERR_TOO_MANY_REDIRECTS when https pool was used, you also added serverssl profile to the virtual server, didn't you?

I'm not using serverssl as Kevin mentioned that it would not be necessary and a performance boost

What I meant was that if you're NOT re-encrypting to the server (not sending to port 443 pool members), then you don't need a server SSL profile. If you ARE sending to port 443 (SSL) pool members, then you DO need a server SSL profile. This profile is what allows the BIG-IP to establish an SSL session with the back end servers. You would generally see a performance increase if you DO NOT do SSL at all on the application servers - pure port 80 traffic.

Ok, clear.

 

 

I need to do ServerSSL to get this to work.

 

 

Thanks both of you for the support!