Forum Discussion

Austin_Geraci's avatar
Jan 11, 2010

HTTPS - direct based on URI - not terminating SSL

I need to direct traffic to a particular pool based on uri contents. I'm NOT terminating SSL.

 

 

1-Can I do this without terminating SSL

 

 

2-do I need the else statment or will it default to the pool associated with the VS?

 

 

when HTTP_REQUEST {

 

if {[HTTP::uri] starts_with "/test/" } {

 

pool test1_443

 

} else { pool test2_443 }

 

}

7 Replies

  • If you want to inspect or modify the HTTP headers or payload (including the URI), you must decrypt the SSL on LTM. If you need to also use SSL between LTM and the servers, you could decrypt on the clientside using a client SSL profile and re-encrypt on the serverside using a server SSL profile.

    If you did decrypt the SSL, you'd want to specify a pool for all cases in the rule when you specify a pool for any case. Here is an example where you don't need to explicitly define the VIPs default pool by name:

     
     when CLIENT_ACCEPTED { 
        set default_pool [LB::server pool] 
     } 
     when HTTP_REQUEST { 
        if {[HTTP::uri] starts_with "/test/" } { 
           pool test1_443 
        } else { 
           pool $default_pool 
        } 
     } 
     

    Aaron
  • Gotcha make sense.

     

     

    It works enabling the client and server side ssl profile, I'd expect it not to work if I don't enable the server side as well, but it does.. Ideas?

     

     

     

    On the second question, to clarify, once one uses an iRule you do not step back down to the VS logic for load balancing, correct?

     

     

    Thanks!
  • I would expect the iRule to work with a client and server SSL profile enabled on the VIP with the VIP and pool members defined on port 443. If you remove the server SSL profile, the iRule should only work if you configure a pool on port 80 (or if the servers allow non-SSL requests on port 443).

     

     

    The VIP's default pool will come into play if the rule doesn't specify a pool. You can either enable a OneConnect profile and not specify a pool in all cases, or specify a pool in all cases. See this post for details:

     

     

    iRule Editor can't find default_pool

     

    http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=33921&ptarget=57229

     

     

    Aaron
  • Gotcha, Thanks for the reference post. We did figure out what was going on, and yes the server was accepting non SSL traffic on it's SSL port.. either way it looks like we need to host the cert if we want to decrypt and encrypt with out a cert error..

     

     

    To clarify, You're only specifying CLIENT_ACCEPTED because you need to define the default pool in your example before the pool has been selected on the TCP connection... I can disregard it if I'm using a specific pool in my else statement, correct?

     

     

     

     

  • Good to see you figured out why it was working without a server SSL profile. Yes, you can remove the CLIENT_ACCEPTED part of the iRule if you're hard coding the iRule for both cases. Or you could remove the CLIENT_ACCEPTED event and the else case if you add a OneConnect profile to the VIP. If you're not using SNAT with OneConnect and need exact correlation between client connections and server connections, you can set the OneConnect source mask to 255.255.255.255.

     

     

    Aaron
  • Good info Thanks!

     

     

    Now the catch.., this may be resolved with an iRule or we just might be screwed... Since we're getting a cert error now I had to install the cert on the LTM and load a custom clientssl... that works just fine... the problem is we use a bunch of client certificates.. is there any way to pass that through to the server or would we need to terminate those client certs on the LTM as well to get it to work?

     

     

    Thanks!
  • LTM can validate client certs against a root cert you configure in the client SSL profile. If you want to handle failures with something other than a TCP close/reset, you'll need to use an iRule.

     

     

    If you have the advanced client auth module licensed, you can validate the client cert against a root CA cert and check the cert status using LDAP, OCSP, CRLDP server (or a few other types).

     

     

    However, there is no way for LTM to proxy the actual client cert for the serverside SSL handshake as LTM doesn't have the client cert private key. You can have LTM insert the cert or cert details on the HTTP request headers sent to the servers. But the app would need to be changed to parse the cert or cert details from the HTTP headers.

     

     

    There are a few related examples in the iRule codeshare:

     

     

    http://devcentral.f5.com/Wiki/default.aspx/iRules.CodeShare

     

     

    http://devcentral.f5.com/Wiki/default.aspx/iRules/ClientCertificateCNChecking.html

     

    http://devcentral.f5.com/Wiki/default.aspx/iRules/InsertCertInServerHeaders.html

     

    http://devcentral.f5.com/Wiki/default.aspx/iRules/RequestClientCertificateAndPassToApplication.html

     

    http://devcentral.f5.com/Wiki/default.aspx/iRules/Validate_certificate_Common_Name_and_revocation.html

     

     

    Aaron