Forum Discussion
Nimbostratusname based virtual host redirection with allowed ip addresses
Hi,
I am new to irules and F5 in general, and would apprciate some advice. I have a single ip address connecting the F5 to the internet, so I am using a name based virtual host irule to redirect traffic internally to a pool. Next I have another irule to restrict the source ip address to only two source ip addresses. This is all working. However, I will add further URL's to the name based virual host rule, and unfortunately as my code stands now, they will all be restricted to the same source ip address.
I am wondering how best to split up the irules, and how best to call them, to prevent all name based virtual hosts being restricted to the same source ip addresses(both irules are attached to the same VirutalServer)..... the easiest way I can think of is to just cut/paste the "source based ip address restriction" irule into the middle of the case statement for the "site1.domain.com". This I think would work, but hardly seems elegant, and will just become messy/unworkable over time. Is there a better way to say call one irule from another, or similar?. Maybe I should have a different kind of VS? The obvious thing to me would be to put the "source based ip address restriction", rule onto the pool, but that is not possible(probably for good reasons I am not aware of). Am open to suggestions on what might be the best way forward. I have copied the two irules and the appropriate data group for reference below:-
irule - name based virtual host.
when HTTP_REQUEST {
log local0. "redirect rule 1"
log local0. "Request: [HTTP::uri]"
log local0. "Request: [IP::remote_addr]"
log local0. "Request: [HTTP::host]"
switch [HTTP::host] {
site1.domain.com { pool scm1_https_pool }
default { reject }
}
log local0. "redirect rule 2"
}
irule - restrict on source ip address
restrict ip addresses that can connect to this Virtual Server
when HTTP_REQUEST {
if { ([HTTP::uri] starts_with "/") and !([class match [IP::remote_addr] equals external_address ]) } then {
drop
}
elseif { ([HTTP::uri] starts_with "/") and ([class match [IP::remote_addr] equals external_address ]) } then {
do nothing, but allow the traffic through
}
else {
drop
}
}
data group external_address
56.234.12.123 several ip addresses...
3 Replies
What_Lies_Bene1Cirrostratus
Sorry but your requirements are unclear to me. Do you want to restrict all access to the multiple hostnames to the IPs in the Data Group or not? If not, which hosts do you wish to have restricted and which unrestricted?- Kevin_Stewart
Employee
I can see a few alternatives, depending on your intentions.
If the source IP restriction is the same for all, I'll put that at the start of your one HTTP_REQUEST event:when HTTP_REQUEST { if { [class match [IP::client_addr] equals external_address ] } { switch [string tolower [HTTP::host]] { "site1.domain.com" { pool scm1_https_pool } default { reject } } } else { drop } }
You don't really need to filter for NOT in the data group. I'm also curious why you'd need the [HTTP::uri] starts_with "/" statement. Technically speaking, all URIs should start with "/" so not sure what value that conditional will give you. Also, IP::client_addr is probably a better fit.
Now, if this is more simplistic than it needs to be, you foresee the two filters getting more complicated and more dependent on the host, and the iRules get much more complicated and fragile, then another alternative is VIP targeting. In this case, instead of a pool statement you use a virtual statement, sending the traffic to another (internal) virtual server. So then you can keep all of your host and IP filtering iRules, and anything else more complicated, separated amongst different virtual servers. 
elastic_82555Hi,
Just a quick update, I investigated the "virtual" statement, but this gives me several other issues, like no connection mirroring (vip to vip)
http://support.f5.com/kb/en-us/solutions/public/14000/100/sol14180.html
However, I am going with a rework of what I had with your comments taken into account. I will come back with the finalised code for comments soon.
thanks
Sc0tt...
