HTTPS to HTTP redirect

Assuming you need both virtuals, and not just a simple SSL termination, this might help.

 

 

From what I've gleaned from the forum, to pass traffic from one virtual server to another, you need to create a loopback to the F5. The network cabling needs to allow for the following:

 

 

VS1 is on a external vlan

 

VS2 is on a dmz vlan

 

DEST is on an internal vlan

 

VS1 accepts and terminates ssl using an ssl profile, then passes traffic to VS2 on port80, via a pool containing VS2's ip.

 

That traffic goes out the dmz vlan port, but needs to come in on another vlan (either internal or external).

 

VS2 is listening for requests from all vlans (or the one you link to above).

 

VS2 then sends to DEST via its pool or irule, etc.

 

 

If you have the ports free, you can connect two of them directly, and assign one to a dmz vlan and the other to the internal vlan. (Don't put them both in the same vlan as it will create a broadcast storm). If you don't have the free ports, you'll have to play with your switching fabric to get the loop.

 

 

Jeff

Colin your irule is correct. I am currently using the same in my test lab.

I tried to configure two virtual servers - one for ssl termination and second for switching based on tcp:collect data, just like Jeff wrote, but I got problem with loopback vlan.

 

 

This is what I have done:

 

 

1. I created VS1 on EXT VLAN, and default pool for this VS is pool with VS2 as a member.

 

2. VS2 (IP:192.168.11.161)was enabled on DEST VLAN

 

3. DMZ VLAN was connected to DEST VLAN with cable. Self IP (192.168.11.160) was configured on DMZ VLAN.

 

 

At this point I have a problem with communication from BIG-IP to VS2 - BIG IP tries to reach the VS2 through self IP on DMZ VLAN, while VS2 is enabled on DEST VLAN. Despite those VLANs are connected with the cable this doesn't work.

 

Enabling VS2 on both VLANs (DMZ and DEST) makes that VS2 is reachable, but even in that situation redirecting traffic from VS1 to VS2 doesn't work (in statistics I can see that none packets arrive on VS2).

 

 

Any suggestions??

 

 

BR,

 

w.

I'm not sure about the loopback cable hack, but in 9.4.0 and later versions, you can specify in an iRule that the destination for a request should be another virtual server on the same BIG-IP, using the 'virtual' command (Click here).

 

 

Are you running 9.4.0+? If so, can you try an iRule instead?

 

 

Aaron

Yes I am using 9.4.2

 

 

iRule solved my problem. I have written simply:

 

 

when CLIENT_ACCEPTED {

 

virtual VS2

 

}

 

 

and it works :-)

 

 

Many thanks!!

 

 

Witek

 

 

When I tried this iRule, I got an error saying that I had to put an http profile on the virtual server in order to get it to work. I think it needs that to key off the HTTP_REQUEST. So, I did that, but it broke all https traffic using that current virtual server. As soon as I removed the profile, traffic was restored.

oak2207, if you're trying to redirect a client to HTTP, you would need to decrypt the client - VIP SSL using a client SSL profile and add an HTTP profile to interpret the traffic as HTTP. What criteria are you trying to use to redirect some traffic to HTTP and leave some encrypted? It may be possible to selectively apply a client SSL profile to issue a redirect, but leave the rest of the traffic encrypted. Else, you could decrypt all client side traffic, redirect what you need to and re-encrypt the rest that is sent to the server using a server SSL profile.

 

 

Aaron

Aaron,

 

 

I'm trying to send all traffic that comes in on HTTPS to HTTP. I do not have SSL termination on the LTM either, that's handled by the servers. We were trying to do a maintenance, and the server folks completely forgot they needed a splash page for HTTPS as well as HTTP. So they asked me to redirect HTTPS to HTTP since the HTTPS side of the service would be down (their splash page only worked on HTTP).

 

 

I tried the simple iRule given by Colin above, but it gave me an error saying I needed an HTTP profile. When I did that HTTPS broke (without the iRule even in place yet), so I couldn't really go any further with it. I don't need to encrypt only some of the traffic, I just wanted to HTTPS traffic to hit its normal VIP, then get bounced to come back in on HTTP and hit the splash page.

As Aaron said in his previous post, you can't redirect HTTPS to HTTP on the LTM without first decrypting the traffic. The LTM needs the traffic in the clear in order to evaluate the contents and issue the redirect. In your environment, if the LTM will not be offloading SSL, an ssl-enabled pool member should remain available to server the maintenance page.

Citiizen_elah is correct. Though, if you can import the SSL cert and key, there is another option. If you want to pass the SSL through LTM encrypted during normal operations but send a redirect during maintenance, you could adapt this example (Click here) to read a "maintenance" flag. If the maintenance variable was enabled, then LTM would decrypt the SSL and respond with a redirect.

This would require you to import the SSL cert and key and add a client SSL profile and an HTTP profile to the VIP. The two profiles would only be enabled during the maintenance window.

 
 when CLIENT_ACCEPTED { 
  
     Set this flag to 1 to decrypt the SSL and send a redirect to the client.  Set to 0 to pass the SSL through without decrypting it. 
    set maintenance_redirect 1 
  
    log local0. "[IP::client_addr]:[TCP::client_port]: Received connection with maintenance flag set to $maintenance_redirect" 
  
     Check if the maintenance flag is disabled (set to 0) 
    if {$maintenance_redirect==0}{ 
  
        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]: Maintenance flag is disabled" 
    } 
 } 
 when HTTP_REQUEST { 
  
     The HTTP_REQUEST event is only triggered if the maintenance flag is enabled and the client SSL and HTTP profiles are left enabled 
  
     Redirect the client 
    HTTP::redirect https://maintenance.example.com 
  
    log local0. "[IP::client_addr]:[TCP::client_port]: Redirecting request" 
 } 
 

Aaron