Forum Discussion
ScottG_82592
Nimbostratus
NimbostratusAdding IP Filtering after pool selection and/or http redirect
So I have a shared application URL VIP that I have configured. Currently it is context based on ports 80/443. So right now I am routing based on the URI of the request. But now I have been tasked with adding security to a portion of that pathway and wide open down the other path. So I am aware of how to do IP Filtering initially in iRules and use it routinely but not sure how to properly put filtering in after the pool has been selected. I tried using a when LB_Selected but that failed.
Current Flow Requirements:
Path 1: All traffic routed to http://sharedapps_VIP/qa/ or /b2b/qa
A. Redirect (in another iRule) to https://sharedapps_VIP/qa or b2b/qa
B. The below rule then routes it to pool "sharedapps_1_qa_pool"
Path 2: All traffic routed to http://sharedapps_VIP/sms/ or /b2b/services
A. Redirect (in another iRule) to https://sharedapps_VIP/sms/ or b2b/services
B. The below rule then routes it to pool "sharedapps_1_prod_pool"
Path 3: All traffic routed to http://sharedapps_VIP/
A. Redirect (in another iRule) to https://sharedapps_VIP/
B. The below rule then routes it to pool "sharedapps_2_qa_pool"
C. Appends the weburi to end of request.
Current iRule:
rule SharedApps_Web_Redirect {
when HTTP_REQUEST {
set host [HTTP::host]
set uri [HTTP::uri]
if { [HTTP::uri] starts_with "/qa" or [HTTP::uri] starts_with "/b2b/qa/" } {
log local0. "chosen pool is QA Pool"
pool sharedapps_1_qa_pool
} elseif { [HTTP::uri] starts_with "/sms" or [HTTP::uri] starts_with "/b2b/services" } {
log local0. "chosen pool PROD Pool"
pool sharedapps_1_prod_pool
} elseif { [HTTP::uri] equals "/" } {
set weburi "/web/loginreg/loginStart.do"
HTTP::redirect "https://$host$weburi"
pool sharedapps_2_Prod_Pool
} else {
pool sharedapps_2_Prod_Pool
}
}
}
What is needed in new requirements:
Current Flow Requirements:
Path 1: Restrict traffic routed to http://sharedapps_VIP/qa/ or /b2b/qa
A. Redirect (in another iRule) to https://sharedapps_VIP/qa or b2b/qa
B. The below rule then routes it to pool "sharedapps_1_qa_pool"
Path 2: Restrict traffic routed to http://sharedapps_VIP/sms/ or /b2b/services
A. Redirect (in another iRule) to https://sharedapps_VIP/sms/ or b2b/services
B. The below rule then routes it to pool "sharedapps_1_prod_pool"
Path 3: All traffic routed to http://sharedapps_VIP/
A. Redirect (in another iRule) to https://sharedapps_VIP/
B. The below rule then routes it to pool "sharedapps_2_qa_pool"
C. Appends the weburi to end of request.
So you can see I am at an impasse and I have used Google and looked over devcentral. I know it is something easy that I am missing but I thought I would reach out for some assistance. If I left anything out I apologize and will provide it to assist in any help.
Thanks in Advance.
hoolioCirrostratus
Hi Scott,
I'm not sure I clearly understand your updated requirements. What IP filtering logic do you want to implement? Do you want to check the source IP address/subnet or the pool member IP address/subnet? Under which case(s) do you want to perform this check?
Also, your existing rule is issuing a redirect and selecting a pool for requests to /. I think the redirect would take precedence over the pool selection. You could remove which either action you don't need done in that scenario.
Lastly, you might find a switch statement as a cleaner way to implement the URI checking. Here is a link to the switch wiki page:
http://devcentral.f5.com/wiki/default.aspx/iRules/switch
Aaron
ScottG_82592Thx Aaron,
Basically I have to restrict traffic to sharedapps1 path but not restrict traffic to the sharedapps2 path. So I have to allow all traffic to one but restrict all unauthorized traffic to the other.- hoolioWhen you say restrict, do you mean check the client IP to see if it's valid? If so, you can use class match (v10) or matchclass (v9) to check the client IP against an IP address/subnet datagroup of whitelisted addresses. You could send an HTTP response with HTTP::respond, reset the TCP connection with the reject command or drop any subsequent packets on the connection using drop.
If that's not what you're aiming for, can you you clarify the scenario?
Thanks, Aaron