HTTPS passthrough & fallback

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

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