Forum Discussion
Stephen_Anderso
Nimbostratus
NimbostratusiRule Causing SSL Problems
I created an iRule to handle mobile user detection and redirection. That part works great, but when it's active, SSL no longer works. The browser just waits for a response and never gets one. Not sure if this matters, but our SSL certs are currently on our web servers and we are not offloading to the F5 yet.
Here's an abridged version of our mobile detection script. Not sure where it is getting hung up. I tried wrapping the mobile detection with something like if { [TCP::local_port] != 443 } { ... } but that didn't seem to help. Is there something I should do before the HTTP_REQUEST to check for SSL and ignore the rest?
when HTTP_REQUEST {
if { [HTTP::uri] equals "/" and not [HTTP::cookie exists "hide-mobile"] } {
switch -glob [string tolower [HTTP::header User-Agent]] {
"*android*mobile*" -
"*iphone*" -
"*ipod*" -
"*kindle*" {
HTTP::redirect "http://m.[domain [HTTP::host] 2]"
return
}
}
if { [string tolower [HTTP::header Accept]] contains "vnd.wap.wml" } {
HTTP::redirect "http://m.[domain [HTTP::host] 2]"
return
}
}
}
hooleylistCirrostratus
Hi Stephen,
Do you have this iRule enabled on more than one virtual server? Which port(s) are the virtual server(s) listening on? If you're not decrypting HTTPS traffic you couldn't use this iRule as it is on a virtual server accepting HTTPS traffic. TMM needs to decrypt the traffic if it's encrypted and have an HTTP profile enabled to use the iRule.
Aaron
Stephen_AndersoThe virtual server is allowing all ports to pass through, so it's just 1 virtual server allowing both http and https. If the iRule cannot be applied to https traffic since the headers are encrypted, I guess that means we could separate out virtual servers and only apply the iRule to http? Either that or offload the SSL certs to the F5?
I'm fine doing it that way, but is there a way to code the iRule to not break things if applied to encrypted https traffic?
Joel_MosesYes, you'd need to offload the certs to the F5 to have this iRule fire. You can still re-encrypt to the pool if you need to do that, or you can offload SSL to the F5 and talk to the pool in-the-clear.
If you want to keep this rule from firing when applied to an SSL VIP, you could probably do it like this:when CLIENT_CONNECTED { if { [TCP::local_port] == 443 } { event HTTP_REQUEST disable } }
But you should probably consider offload or just not applying that iRule to the SSL VIP.- hooleylistI think it's cleaner and simpler to create two separate virtual servers for two different protocols. If you wanted to do this with one you could disable the HTTP filter and the iRule logic for non-HTTP requests using HTTP::disable and return. Here's a related example:
https://devcentral.f5.com/wiki/iRules.HttpHttpsSingleVirtualServer.ashx
Also, if you want to redirect mobile user-agents who make HTTPS requests to the mobile site, you'd need to decrypt the HTTPS using a client SSL profile.
Aaron - hooleylistSorry Joel, I didn't see your reply. I think we both agree :)
Aaron - Stephen_AndersoI agree that it would be cleaner to separate them out. I was more curious about why the iRule was getting hung up and the example you gave helps to clear that up. Thanks a bunch guys!