Forum Discussion
Dbow_21284
Nimbostratus
NimbostratusRewrite Host Header iRule on VS that changes to HOST Header on same VS
Hello guys,
I have a situation where our developers have a sight running on HTTPS that needs to rewrite the host header to a new host header, but DNS points it to the same VS on my LTM. I do have a clientssl profile so I can decrypt the traffic.
Important Points to consider:
1) I need to rewrite any requests that goto mydomain.net to sub.mydomain.net
2) DNS for mydomain.com and sub.mydomain.net both point to the same VS on the LB.
I have tried redirect iRules and HOST::HEADER replace iRules on my VS, but it doesn't appear to work. Here are examples of what I have done:
iRULE1:
Rewrite Host Header iRule
when HTTP_REQUEST {
if { [HTTP::host] equals "mydomain.net" } {
Rewrite host
HTTP::header replace Host sub.mydomain.net
}
}
iRULE2:
Redirect to sub.mydomain.net
when HTTP_REQUEST {
if {[HTTP::host] equals "mydomain.net" } {
HTTP::redirect https://sub.mydomain.net }
}
I am not sure why this doesn't work. I have used similar rules elsewhere. The only difference in those situations where it worked fine, is that the rewrite of the host header or redirect pointed to domain name that goes to different VS. Not sure if that is my issue. In both situations, the LB just lets the user access mydomain.com and nothing gets changed. I must be missing something here.
Any ideas as to why this wouldnt work or other approaches? Thanks in advance!
Denbownium
Michael_YatesYour second iRule should work if you put quotes around the redirect:when HTTP_REQUEST { if {[HTTP::host] equals "mydomain.net" } { HTTP::redirect "https://sub.mydomain.net" } }
You could also use a string map replacement:when HTTP_REQUEST { if {[HTTP::host] equals "mydomain.net" } { set host [string map {mydomain.net sub.mydomain.net} [HTTP::host]] HTTP::redirect "https://$host[HTTP::uri]" } }
Dbow_21284Yeah I have tried both and it does not work. Weird!
I am sure its going to the same VS that has the iRule. I have checked host files, DNS, etc. So I know I am hitting the VS that has the iRule. But it does not prepend the sub-domain in the host header.
I am wondering if it is not working because it goes to the same VS? Would that make a difference?
-Dbow
hoolioCirrostratus
Hi Denbownium,
Does the application use hardcoded references to the wrong hostname in response headers and/or payloads? You can use a browser plugin like HttpFox for Firefox or Fiddler for IE to view the HTTP headers and response payloads coming from the application. If the app references itself with the wrong hostname, the client will get a cert for the new hostname and generate a cert mismatch warning.
You can use HTTP::header replace to rewrite response headers. And you can use a blank stream profile and STREAM::expression based iRule for rewriting response content.
Here is a related post:
http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=30137&ptarget=30139
Aaron- Dbow_21284OK I will analyze the response headers and post what I find.
I can tell you that the site works with explicit sub.mydomain.com fine. We use a SAN cert (subject alternative name) that allows us to add host names at will. The cert allows both mydomain.com and sub.mydomain.com. I am not sure if that is part of the problem either. So when client enters explicit mydomain.com, it doesn got to the sub.mydomain.com. But with either host name, the site comes up and we don't get cert errors because both hostnames match names in the cert.
But I will do what you suggested. Thanks.
Dave - hoolioI assumed the issue was a mismatched cert warning when a client used the "wrong" hostname. If you have a cert which is valid for both hostnames, that shouldn't be a problem.
So what is the actual issue then? What does the client see when making a request to the VIP with sub.mydomain.net or mydomain.net when this fails?
Aaron - Dbow_21284Well actually nothing fails. ... The developers are really **bleep** about the URL being switched to www.mydomain.com in the browser. I think there is a big push from marketing on this as well. ... Dont even get me started.
Anyway, right now I have a HTTP and HTTPS VS for this site. The HTTP site has an iRule on it that has an all-encompassing redirect on it to https://www.mydomain.com (to the HTTPS VS basically). Thus, for the case where the user explicitly puts in just https://mydomain.com without the "www" prefix it remains at https://mydomain.com.
Thus, there isn't an issue per se. The developers say they need it this way for some reason. At this point it is a personal challenge to get this working for me, otherwise I probably wouldn't worry about it. I have tried redirects, HTTP::header replace, and http response rewrites on the HTTPS VS without any luck.
Stumped....
PS: The response headers come back mydomain.com:443 ... I have tried an iRule to rewrite this and that didnt work either. I used an iRule from someone else who stated it was successful for them ... here it goes.when HTTP_RESPONSE { set nowwwHost "mydomain.com" set wwwHost "www.mydomain.com" set location [HTTP::header location] if { $location starts_with $nowwwHost } { regsub -all $nowwwHost $location $wwwHost newLocation HTTP::header replace location $newLocation } }
I have thrown in dummy URLs to redirect to and headers to rewrite that arent even related to the site in all my attempts. Its like the iRules aren't even being processed. - Well, if you're talking about the location bar in the clients' browser, then all the header fiddling in the world won't change that. You need to do a redirect to the new location, something like:
when HTTP_REQUEST { if {[HTTP::host] equals "mydomain.net" } { HTTP::redirect "https://sub.mydomain.net[HTTP::uri]" } }
