Forum Discussion
Anhtuan_Huynh_1
Nimbostratus
NimbostratusiRule to redirect to new pool and sending it to the SSL proxy (HTTPS) does not work
Hi all -
I have a little problem that could probably be answered
very quickly here given the expertised. I have included
data from the techout ran on the bigip.
platform: BIGIP2000 - 4.5PTF3
Old Web Pool (called WLUI-POOL)
URL: https://www.stress.inttra.com
VS - 172.16.20.243
pool WLUI-POOL {
persist simple
simple_timeout 1800
simple_mask 255.255.255.0
persist_mirror enable
member 172.16.20.10:http
member 172.16.20.11:http
virtual 172.16.20.243:80 unit 1 {
use rule STWLUI_RULE
}
proxy 172.16.20.243:443 unit 1 {
target virtual 127.0.0.243:80
clientssl enable
clientssl key www.stress.inttra.com.key
clientssl cert www.stress.inttra.com.crt
clientssl cipher insert enable
clientssl ciphers "EXPORT40:HIGH:MEDIUM"
redirects rewrite all
}
PROXY +---> 172.16.20.243:443 -- Originating Address -- Enabled Unit 1
| Client-side SSL: enabled
| Client-side Key File Name: www.stress.inttra.com.key
| Client-side Cert File Name: www.stress.inttra.com.crt
| Client-side Chain File Name: none
| Client-side CA File Name: none
| Client-side CA Path: /config/bigconfig/ssl.crt/
| Client-side CRL File Name: none
| Client-side CRL Path: none
| Client-side Client Cert CA File Name: none
| Insert Client Cipher: enabled
| Insert Client Certificate: disabled
| Insert Client Session ID: disabled
| Client-side SSL Ciphers: "EXPORT40:HIGH:MEDIUM"
| Invalid Client-side SSL versions: none
| Client Certificate: ignored
| Authenticate Client Certificate: once
| Authenticate Client Depth: 9
| Client Session Cache Size: 20000
| Client Session Cache Timeout: 300
| Server-side SSL: disabled
| Server-side Key File Name: none
| Server-side Cert File Name: none
| Server-side Chain File Name: none
| Server-side CA File Name: none
| Server-side CA Path: /config/bigconfig/ssl.crt/
| Server-side CRL File Name: none
| Server-side CRL Path: none
| Server-side SSL Ciphers: "DEFAULT"
| Invalid Server-side SSL versions: none
| Server Certificate: required
| Authenticate Server Depth: 9
| Added HTTP Header: none
| Redirects Rewriting: enabled all
| Client-side TCP connection limit: 0
| Authorization set header: disable
| Authorization set remote user header: disabled
| Authorization model list:
| On authorization failure: reject
| On authorization failure user name: unknown
| OCSP responder list:
| LastHop Pool Name: none
| ARP: enabled
| Disabled Vlans: none
+===> 127.0.0.243:80 -- Destination Address -- Virtual
(cur, max, limit, tot) = (0, 304, 0, 2179620)
(pckts,bits) in = (50279232, 63440874928), out = (77262430, 524117324424)
URL(notice the "newapp"): https://www.stress.inttra.com/newapp
New Web Pool (called APACHE_WEB_POOL)
pool APACHE_WEB_POOL {
member 172.16.20.30:http
member 172.16.20.31:http
}
my current iRule
if (http_uri contains "newapp") {
redirect to " https://%h/newapp"
}
else {
redirect to " https://%h/CTP.ecocp"
}
What we want to do is when users go to "http://www.stress.inttra.com" they will get redirected to the original Web Pool. This will hit the SSL proxy (redirect https://h%/CTP.ecocp), but when we added the "newapp" after the URL, they will still go though the orginal session (VS 172.16.20.243->STWLUI_RULE -> 127.0.0.243:80 -> WLUI-POOL), but get redirected to the new web pool and have the session
be sent to the SSL proxy.
I managed to get this to work, but could not get the new URL redirected to the SSL proxy. Can you let me know what I am doing wrong or what's needed to get this to work? If i do not specify the http(s), it gets redirected without issues.
error generated by BIGIP.
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
Thank you in advanced.
Anhtuan
- Anhtuan,
I'd love to help you but I can't because you've not posted enough of your configuration. The 127.0.0.243:80 virtual is missing. Also it is not entirely clear to me what really happens and what you'd like to happen. Having said that, I'm 99% sure that the problem is not in the iRule. The rule looks correct (assuming that I understand correctly what it is supposed to do. In order to troubleshoot the problem, you can logging statements to your rules to see whether requests are passed to them and which braches are bing triggered. Example:if (http_uri contains "newapp") { log local0.debug "request from: " + client_addr + " url: " + http_uri + " redir to https://" + http_host + "/newapp" redirect to " https://%h/newapp" } else { log local0.debug "request from: " + client_addr + " url: " + http_uri + " redir to https://" + http_host + "/CTP.ecocp" redirect to " https://%h/CTP.ecocp" }
This will log messages similar to the following to /var/log/bigip:Dec 2 17:06:12 b1 kernel: RULE url_switch - request from: 10.66.66.1 url: /newapp redir to https://10.66.66.167/newapp
if the rules is really being used. 
Anhtuan_Huynh_1mmac,
what we want to do is when users go to "http://www.stress.inttra.com" the get redirected to
the original pool "WLUI-POOL" giving them "https://stress.inttra.com". but when they put
"newapp" after "http://stress.inttra.com/, i.e http://www.stress.inttra.com/newapp". they should
get redirected to "https://www.stress.inttra.com/newapp". notice the "http(s)". the session should
still go through the VS (172.16.20.243), but the difference is, they get redirected to the new web
server pool call "APACHE_WEB_POOL" trough the original session, but hit the SSL proxy therefore encryption
their session. This works if i take out the redirect to " https://%h/newapp" and use "use pool APACHE_WEB_POOL"
in my irule. but the problem is, the traffic is only http not https.
load balancing rules
rule Redirect_Rule {
redirect to "https://%h/"
}
rule STWLUI_RULE {
if (http_uri contains "newapp") {
redirect to " https://%h/newapp"
}
else {
redirect to " https://%h/CTP.ecocp"
}
}
virtual 127.0.0.243:80 unit 1 {
use pool WLUI-POOL
}
proxy 172.16.20.243:443 unit 1 {
target virtual 127.0.0.243:80
clientssl enable
clientssl key www.stress.inttra.com.key
clientssl cert www.stress.inttra.com.crt
clientssl cipher insert enable
clientssl ciphers "EXPORT40:HIGH:MEDIUM"
redirects rewrite all
}- Anhtuan,
I'm still not entirely sure that I fully understand your problem, but possibly following change may improve things. Assuming that the URI after the redirection to the SSL proxy (for URIs containing "newapp") is supposed to be unchanged, your rule should be:rule STWLUI_RULE { if (http_uri contains "newapp") { redirect to " https://%h/%u" } else { redirect to " https://%h/CTP.ecocp" } }
(note the %u instead of "newapp" in the first branch of the rule)
Just to make sure that we are on the same page - following is an overview of steps involved in the HTTP redirection that you want to achieve (if understand correctly your desired behavior):
- client connects to virtual server 172.16.20.243:80 let's say sends
request with URI containing "newapp",
- the virtual server invokes the rule and HTTP 302 redirect response is
returned to the client,
- client closes connection to virtual server 172.16.20.243:80
(clients are required to use new conenction after redirect according
to RFC 2616),
- client establishes new SSL connection to the proxy at
172.16.20.243:443 and sends the URI that has been returned in the
Location header of the redirect response (the content of the Location
header of 302 responses generated by BIG-IP is the argument of the
"redirect to" command with all % macros expanded),
- the SSL proxy decrypts the data and passes the request to virtual
server 127.0.0.243:80 which passes it to one of the servers in the
WLUI-POOL (based on configured persistence and loadbalancing method).
I can also guarantee you that the "404 response", that you've mentioned in your first post, is not generated by the BIG-IP. The only responses generated by BIG-IP are those above mentioned 302 redirects. All other HTTP responses have to come from one of the origin servers (pool members). That makes me think, that the URI returned in the redirection, actually does not exist on your servers. You should consult log files on your servers to confirm/disprove that.
