Forum Discussion

lkchen's avatar
lkchen
Icon for Nimbostratus rankNimbostratus
Sep 15, 2008

HTTPS passthrough & fallback

Last night we had an outage of a service that is HTTPS passthrough to a pool of servers (with port translation).

 

 

When the outage continued this morning, it was time to see about putting in a fallback redirect.

 

 

So, I found the iRule HTTPS_passthrough_fallback_URL (which I pasted in, and removed the log lines).

 

 

And, eventually got it working (hard part was tracking down the java key store and extracting the private key from it).

 

 

But, then some servers in the pool returned...but the redirect continued to happen. So, I had to revert the virtual server.

 

 

So, I'm wondering what needs to be done to get things to work for next time?

 

 

Lawrence

 

 

 

 

4 Replies

  • Hi Lawrence,

     

     

    The rule checks whether the default pool configured on the virtual server has one or more available members before redirecting a request. Were you seeing the default pool marked green, while clients were still being redirected? If so, are you able to reproduce the issue during a maintenance window? You could try adding more logging to the rule to confirm the default pool name, how many active members there are and whether the pool is marked up while clients are redirected.

     

     

    One scenario where I could see this happening is if a client makes a request while the pool is down, the pool comes back up and then the client continues to use the same TCP connection to make further HTTP requests (possibly if you have a proxy server in front of LTM). If this is the issue, you could add a TCP::close after the HTTP::redirect command. This will force the client to establish a new TCP connection for any subsequent request. When a new TCP connection is established to the VIP, the check of active members is re-run.

     

     

    Aaron
  • lkchen's avatar
    lkchen
    Icon for Nimbostratus rankNimbostratus
    Yes, the pool was marked green. And, at least for the location I was at, clients were still being redirected to the unavailable page.

     

     

    I'm not sure when the next planned outage is...maybe January, so not really in a position to try anything out until then (or the next unplanned outage, which I hope to at least be prepared for on my end).

     

     

    There's no proxy server (that I know of) between the remote site and LTM, but could persistence come into play?

     

     

    Lawrence
  • Persistence would only dictate which pool member the client would be sent to--it wouldn't affect the functioning of the rule.

    Maybe you could create a new VIP to test this? Other than the continued requests over the same TCP connection, I can't really see where the rule would redirect after the pool is marked up again.

    In a quick test, the only way I was able to get a redirect after the pool had at least one member marked up by a monitor was by sending multiple requests over a TCP connection that was initiated while the pool was still down.

    Adding TCP::close after the redirect fixed this:

      
     when CLIENT_ACCEPTED { 
      
        log local0. "[IP::client_addr]:[TCP::client_port]: Received connection with active members: [active_members [LB::server pool]]" 
      
         Check if there are members available in the VIP's default pool 
        if {[active_members [LB::server pool]]}{ 
      
            Disable the client SSL profile so the HTTPS traffic is passed through encrypted to the node 
           SSL::disable 
      
            Disable the HTTP profile as we're not going to redirect this request 
           HTTP::disable 
      
           log local0. "[IP::client_addr]:[TCP::client_port]: Members available" 
        } 
     } 
     when HTTP_REQUEST { 
      
         The HTTP_REQUEST event is only triggered if the pool members are down and the client SSL and HTTP profiles are left enabled 
      
         Redirect the client 
        HTTP::redirect https://maintenance.example.com 
      
         Close the TCP connection so that the pool is checked for every HTTP request 
           This should prevent clients from being continuing to be redirected after the pool comes up 
           (which would happen if they re-used the same TCP connection). 
        TCP::close 
      
        log local0. "[IP::client_addr]:[TCP::client_port]: Redirecting request" 
     } 
      

    Aaron
  • Sorry, I had a copy/paste error there. The TCP::close command should be after the redirect as listed in the edited rule above.

     

     

    Aaron