Forum Discussion
Harold_Deadman_
Nimbostratus
Sep 28, 2011what is appropriate way to use SSL::disable serverside/ SSL::enable serverside
We have a requirement to encrypt server-side traffic between the F5 and our SSO web application (CAS) because passwords are transmitted. Our F5 VIP has several different applications behind it on several different pools and we have an i-rule that is routing traffic to the appropriate pools. Most pools are accessed via HTTP rather than HTTPS. I added a server side profile to the VIP and then I disabled it in the CLIENT_ACCEPTED event. If the traffic is bound for the pool where our SSO application lives then I enable server side SSL before sending traffic to the pool (SSL::enable serverside). The login process proceeds quickly but then there are severe delays on subsequent requests to non SSL pools. What appears to be happening is that SSL remains enabled and that the F5 is falling back to HTTP if it can't negotiate an SSL connection (but only after a significant delay or timeout).
Is that what is happening? I would have expected the F5 to fail rather than falling back to not encrypting the traffic.
Is enabling/disabling server-side SSL an expensive operation? Is there a method to tell the current state or do I need to keep track in a variable? When I try to disable it or enable it prior to each pool request (based on whether the pool is to an SSL port or not) it seems that I still see delays and worse performance than if I don't have server-side SSL on the VIP at all. If the operation is expensive then maybe I need to keep track of the state so I am only turning it off or on if it is in the wrong state for the pool that traffic will be sent to.
Where (which event) is the appropriate place to turn SSL off and on? I notice that if I turn SSL on before the pool statement and disable it after the pool statement then the SSL response from the server is not decrypted by the F5 and the encrypted response from the server is re-encrypted and sent to the browser. Is there an event after the HTTP response is sent where I could disable server-side SSL?
Thanks for any insights or pointers to any resources on this topic.
11 Replies
- Michael_Yates
Nimbostratus
Hi Harold,
I had a similar situation where we wanted traffic to be Secure depending on the area that the client was going to. Our configuration sounds pretty close to what yours is (URI's destinations are hosted on different servers and have different Pools, so we used the Pool as the trigger).
See if this methodology works for you.when CLIENT_ACCEPTED { SSL::disable serverside } when HTTP_REQUEST { } when SERVER_CONNECTED { if { ([string tolower [LB::server pool]] eq Target.Pool.Name.For.SSL.Enable) } { SSL::enable serverside } else { SSL::disable serverside } } - Harold_Deadman_
Nimbostratus
That works much better. I am not sure why it wasn't working for me (performance-wise) when I was doing the SSL::disable in HTTP_REQUEST prior to the pool statement but this is cleaner because it doesn't clutter up the HTTP_REQUEST part of the i-rule (and performance seems to be good). Maybe the server_connected event is firing less often...
Unfortunately I had my i-rule in our development environment for a couple months and we noticed the slowness but we didn't figure out that it was i-rule until we made the change in production. Unfortunately that roll-out coincided with some ISP problems so we didn't immediately pin the problem on the i-rule change.
Thanks for your help. - tarsier_90410
Nimbostratus
Isn't the above CLIENT_ACCEPTED event unnecessary?
With a serverssl profile the following should do the trick:when SERVER_CONNECTED { if { not ( [LB::server pool] eq Target.Pool.Name.For.SSL.Enable) } { SSL::disable } } - Michael_Yates
Nimbostratus
I set it to put it into a known state, but I suspect that you are correct and it does not need to be there (unfortunately I do not have my normal testing environment available to confirm it at the moment). - Remco
Nimbostratus
Hi,
we last week introduced a similar setup in our environment (server side ssl for a selected pool) and had similar problems with performance.
We had the following symptoms:
- 20% CPU increase
- significant less active session than before
- significant more new conn/sec than before
I had used the same approach as the orginal poster.
At the beginning of the irule added:
when CLIENT_ACCEPTED {
SSL::disable serverside
}
and under the HTTP_REQUEST event I enabled serverside ssl only for the pool required.
Our assumption was that since the pool with the serverside ssl is hit during the users login procedure, somehow the F5 is trying serverside ssl to the other pools. But when we removed the call to the serverside ssl pool in the login procedure the problems did not dissappear. On an application level they removed the call to the pool where serverside ssl was required. The conclusion in this post was that once the serverside ssl pool was hit the F5 kept trying serverside ssl to the other pools, but if you are not hitting the serverside ssl pool wouldn't it show normal behaviour?
What would your advise?
Modify the irule to disable serverside ssl in the SERVER_CONNECTED event as suggested by Tarsier?
when SERVER_CONNECTED {
if { not ( [LB::server pool] eq Target.Pool.Name.For.SSL.Enable) } {
SSL::disable }
} - hoolio
Cirrostratus
Hi Remco,
Which iRule did you test with? What configuration did you compare the performance for CPU/connections/sessions with?
Aaron - Remco
Nimbostratus
Hi Aaron,
our irule before the change was:when HTTP_REQUEST { switch -glob [HTTP::host][HTTP::uri] { "xxxx/123*" { if { [active_members pool-123] > 0 } { pool pool-123 persist cookie insert 123 } else { pool pool-sorry persist none } } "xxxx/456*" { if { [active_members pool-456] > 0 } { pool pool-456 persist cookie insert 456 } else { pool pool-sorry persist none } } "xxxx/789*" { if { [active_members pool-789] > 0 } { pool pool-hij persist cookie insert 789 } else { pool pool-sorry persist none } } default { persist none HTTP::respond 302 noserver Location "https://xxxx/123/" } } }
and we had the problems when we changed it like:when CLIENT_ACCEPTED { SSL::disable serverside } when HTTP_REQUEST { switch -glob [HTTP::host][HTTP::uri] { "xxxx/123*" { if { [active_members pool-123] > 0 } { pool pool-123 persist cookie insert 123 } else { pool pool-sorry persist none } } "xxxx/456*" { if { [active_members pool-456] > 0 } { pool pool-456 persist cookie insert 456 } else { pool pool-sorry persist none } } "xxxx/789*" { if { [active_members pool-789] > 0 } { pool pool-hij persist cookie insert 789 } else { pool pool-sorry persist none } } "xxxx/abc*" { if { [active_members pool-abc] > 0 } { SSL::enable serverside pool pool-abc persist none } else { HTTP::respond 404 noserver } } default { persist none HTTP::respond 302 noserver Location "https://xxxx/123/" } } } - Remco
Nimbostratus
sorry I accidently submitted my last post twice - Remco
Nimbostratus
Hi,
I am trying to setup our test environment but both the suggested SERVER_CONNECTED irule event does not work.
rule:when SERVER_CONNECTED { if { not ( [LB::server pool] eq Target.Pool.Name.For.SSL.Enable) } { SSL::disable } }
Gives the following error:
01070151:3: Rule [test] error: line 2: [parse error: PARSE syntax 63 {syntax error in expression " not ( [LB::server pool] eq Target.Pool.Name.For.SSL.Enable)...": variable references require preceding $}] [{ not ( [LB::server pool] eq Target.Pool.Name.For.SSL.Enable) }]
and rulewhen CLIENT_ACCEPTED { SSL::disable serverside } when HTTP_REQUEST { } when SERVER_CONNECTED { if { ([string tolower [LB::server pool]] eq Target.Pool.Name.For.SSL.Enable) }{ SSL::enable serverside } else { SSL::disable serverside } }
gives error:
01070151:3: Rule [test] error: line 7: [parse error: PARSE syntax 153 {syntax error in expression " ([string tolower [LB::server pool]] eq Target.Pool.Name.For...": variable references require preceding $}] [{ ([string tolower [LB::server pool]] eq Target.Pool.Name.For.SSL.Enable) }]
According to the wiki:
http://devcentral.f5.com/wiki/irules.LB__server.ashx
is LB::server not supported in the SERVER_CONNECTED event. - hoolio
Cirrostratus
LB::server should work fine in SERVER_CONNECTED. I think the issue is that Target.Pool.Name.For.SSL.Enable is a string and needs to be double quoted as "Target.Pool.Name.For.SSL.Enable".
Aaron
Recent Discussions
Related Content
DevCentral Quicklinks
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
Discover DevCentral Connects
