Forum Discussion

dave_jensen_201's avatar
dave_jensen_201
Icon for Nimbostratus rankNimbostratus
Mar 17, 2010

F5 Persistence SSL (Pass-through) Safari Browser Issue

I hope everyone is doing well. We have an odd issue with traffic through our F5. Let me start by saying that SSL and session for our website works just fine through IE8/IE7, Firefox/Mozilla, Chrome, Opera.

 

 

Basically we have a number of servers in our web farm, our website establishes session in two ways, SSL session ID through the IIS/F5 where a user is bound to a server, and the session that gets created with our own application as the user logs in.

 

 

Long story short, when a user accesses our site via Safari the SSL session is not working. They are bounce around all servers making it impossible for our application session to remain. We use inproc session in our .net website (no database) and our users on Safari are having an extremely poor experience.

 

 

Any help that you can provide is appreciated. I read a post about SSL Pass Through and OneConnect being enabled at the same time causing problems with page display but these users are not having issues with page display, just session.

 

 

Let me know if you need any details and I'll get them. I didn't configure this LTM but I am familiar with it.

 

 

Thanks,

 

 

- Dave
config
design

17 Replies

Sort By
Show More
  • naladar_65658's avatar
    naladar_65658
    Icon for Altostratus rankAltostratus
    Mar 23, 2010
    You might try this iRule, line for line it matches the code in the URL that I posted, but I added the to log local0 lines so that you can check the output via your BIG-IP logs. Granted I haven't had a chance to test it myself, but you might give it a spin and see if it works for you.

     

     

     
 when RULE_INIT { 
   set allzeros [string repeat "0" 64] 
 } 
 when CLIENTSSL_CLIENTCERT { 
   set cert [SSL::cert 0] 
   set sid [SSL::sessionid] 
   if { $sid ne $::allzeros } { 
      If this SSL session will be cached, then it may be 
      resumed later on a new connection. Cache the cert 
      in the session table in case that happens. Because ID's 
      are not globally unique, the session id needs to be combined  
      with something from client address to avoid mismatch.   
     set key [concat [IP::remote_addr]@$sid] 
     session add ssl $key $cert 180 
   } 
 } 
 when HTTP_REQUEST { 
    if { [info exists cert] } { 
     set sn [X509::serial_number $cert] 
   } else { 
     set sid [SSL::sessionid] 
      We don't have a cert, possibly because this is 
      a new connection that was a resumption of a 
      previous SSL session. If that is the reason, 
      the cert will be in the session table. 
     if { $sid ne $::allzeros } { 
        This SSL session was resumed; retreive the cached cert 
       set key [concat [IP::remote_addr]@$sid] 
       set cert [session lookup ssl $key] 
       if { $cert != "" } { 
           set sn [X509::serial_number $cert] 
       } else { 
            dunno how this happened 
           reject 
           return 
       } 
     } 
   } 
   if { [info exists sn] } { 
     HTTP::header insert Serial $sn 
     log local0. "The User Agent String is: [HTTP::header User-Agent]" 
     log local0. "The Serial number is: [X509::serial_number $cert]" 
   } else { 
      no sn available, reject the client 
     reject 
     return 
   } 
 }
  • dave_jensen_201's avatar
    dave_jensen_201
    Icon for Nimbostratus rankNimbostratus
    Mar 23, 2010
    Forgive me for being dense, but is this 'doing' anything to the SSL session table or the requests. Admittedly this is a production type issue for us and I don't expect any guarantees but from your expertise, is it effecting any change or just gathering information?

     

     

    Thanks,

     

     

    - Dave
  • naladar_65658's avatar
    naladar_65658
    Icon for Altostratus rankAltostratus
    Mar 23, 2010
    Looks like it is just an information gathering and then inserts the session into the header and with the log entries will log the user agent and session id into your LTM log file.
  • dave_jensen_201's avatar
    dave_jensen_201
    Icon for Nimbostratus rankNimbostratus
    Mar 23, 2010
    Am I missing something for iRules to be executed? Once an iRule is created and assigned to a partition, there isn't anything else that needs to be done in order to apply it, is there? Once created it should execute assuming its criteria is met?
  • dave_jensen_201's avatar
    dave_jensen_201
    Icon for Nimbostratus rankNimbostratus
    Mar 23, 2010
    I created the iRule and the first step (RULE_INIT) executed 2 times (zero fail, zero abort), but did not execute the other two steps and therefore provided no logging. I'm missing something but I cannot see it (probably gonna feel stupid when I do and that'll be nice)...

     

     

    Thanks again.

     

     

    /stumped

     

     

    - Dave
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 23, 2010
    If you're not decrypting the SSL, you wouldn't want to add an HTTP profile to the VIP and therefore shouldn't be able to add an iRule to the VIP which references HTTP events. I'd expect your first example to work. Just add it to the VIP on the resources tab and then check /var/log/ltm for the rule output. 

     
 when CLIENT_ACCEPTED { 
    log local0. "[IP::client_addr]:[TCP::client_port]: SSL sessionid is: [SSL::sessionid]" 
 }

    If you have a Safari browser you can reproduce the issue with, I'd restrict the iRule to log only your client IP address: 

     
 when CLIENT_ACCEPTED { 
    if {[IP::addr [IP::client_addr] equals 1.1.1.1]}{ 
       log local0. "[IP::client_addr]:[TCP::client_port]: SSL sessionid is: [SSL::sessionid]" 
    } 
 }

    Aaron