Forum Discussion

Sean_O_Brien_65's avatar
Sean_O_Brien_65
Icon for Nimbostratus rankNimbostratus
Apr 13, 2010

iRule forward URL to different domain for http and https

We are planning a website cutover to another (new) existing domain, both going through the F5 currently...

 

 

This weekend I will change the DNS to point to different VS on F5 and at that point I will be implementing an iRule to change the old url request (such as in peoples bookmarks, etc...) to point to the new url with a different domain.

 

 

I created a test VS and pool to test the iRule I have below, and I believe my problem is forwarding both http and https requests with one iRule.

 

 

This is what I have now:

 

 

when HTTP_REQUEST {

 

switch [string tolower [HTTP::host]] {

 

"domain1.com" { HTTP::redirect "https://domain1.domain2.com"

 

}

 

"www.domain1.com" {

 

HTTP::redirect "https://domain1.domain2.com"

 

}

 

}

 

}

 

 

As it stands, when I try to go to my "domain1.com" after updating my hosts file to point to test VS, I get page not found... Also, if I try https://www.domain1.com, I get an SSL error and it stays as domain1.com in the address bar. Thanks for any help!

 

5 Replies

  • Hi Sean,

    Do you have this iRule applied to both an HTTP and an HTTPS VIP?

    Do you have a client SSL profile added to the HTTPS VIP? If so, is the cert in the profile for domain1.com or www.domain1.com?

    What is the SSL error?

    Do you see any run time TCL errors in /var/log/ltm when you get the page cannot be displayed error?

    You could combine the switch cases into one (though this won't change the effect of the iRule). You could also append the originally requested URI to the query string on the redirect:

    
    when HTTP_REQUEST {
       switch [string tolower [HTTP::host]] {
          "domain1.com" -
          "www.domain1.com" {
             HTTP::redirect "https://domain1.domain2.com[HTTP::uri]"
          }
       }
    }
    

    Aaron
  • I did apply iRule to HTTP and HTTPS VIP after troubleshooting, but that made no difference.

     

     

    Yes, client SSL profile is being used on HTTPS VIP, the cert is for domain2.com, since that is what I am trying to forward to, and the existing domain traffic (on the VIP we will be pointing to) is using this profile (it is a wildcard for domain2.com).

     

     

    SSL error is simple 'untrusted connection' since the url domain's are different.

     

     

    There aren't any entries in the ltm for my 'test' VIP or Pool.

     

     

    I like the combination iRule you showed... I also need to keep in mind that the original traffic going to blah.domain2.com is still going through this connection and my existing iRule for HTTP -> HTTPS and adding a uri has to work as well for each of these requests...

     

  • If blah.domain2.com and another hostname like domain1.com or www.domain1.com are resolving to the same VIP, then clients will get a mismatched cert warning on HTTPS requests when trying to access a hostname that the cert isn't issued for. You would want to have a cert installed which matches the hostname(s) that the client is making the request to--not the domain that you're redirecting the clients to.

     

     

    You could either get a single cert which is valid for all the domains (using subject alternate names and/or a wildcard cert) or change the name resolution to point to separate IP addresses.

     

     

    Aaron
  • I think I just found my error... I had inadvertently set the SSL client and SSL server profiles to my HTTP VIP... That was causing the block or dropped requests...

     

     

    I'm still seeing issue with requests going to https://domain1.com which makes sense... I'm guessing I will need another iRule applied to my HTTPS VIP to forward just like the HTTP one.

     

     

    Thanks again!
  • That sounds about right. Forwarding to a second VIP won't help with trying to handle multiple certs on a single client facing IP address:port combination as you'd need to try to decrypt the SSL on the first VIP before knowing which traffic to forward to the second VIP. Sending the "wrong" cert on the first VIP to the client will trigger the mismatched cert warning on the browser before you can send the request to the second VIP with the "correct" cert.

     

     

    Aaron