Forum Discussion
Ted_Smith_11168
Nimbostratus
Nimbostratusseeing multiple app sessions from iRules?
This might be a long post, so please forgive me...
using a wide IP in 3DNS for aac.alliedinsurance.com
When a user comes into the aac.alliedinsurance.com site, I want to redirect them to aac2.alliedinsurance.com site (which is not a wide IP)
Setup:
1st iRule tied to aac.alliedinsurance.com on port 80:
agentcenter-80-redirect-443
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/plquoting/templates/receiveincomingfile.cfm" } {
HTTP::uri "/PersonalLines/Templates/receiveincomingfile.cfm"
}
else {
HTTP::redirect https://[HTTP::host][HTTP::uri]
}
}
Purpose of rule, match specific uri on port 80, otherwise re-direct to https
2nd iRule tied to aac.alliedinsurance.com on port 443
agentcenter-443-redirect-aac2
when CLIENT_ACCEPTED {
set ckname aac2
set ckvalue [IP::client_addr]
set ckdomain .alliedinsurance.com
set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue $ckdomain]
}
when HTTP_REQUEST {
set uri [HTTP::uri]
}
when HTTP_RESPONSE {
HTTP::respond 302 Location "https://aac2.alliedinsurance.com$uri" "Set-Cookie" $cookie
}
Purpose of rule, set cookie info, redirect to aac2.alliedinsurance.com
3rd iRule tied to aac2.alliedinsurance.com on port 443
aac2.alliedinsurance.com
when CLIENT_ACCEPTED {
set ckname aac2
set ckvalue [IP::client_addr]
set ckdomain .alliedinsurance.com
}
when HTTP_REQUEST {
set uri [HTTP::uri]
set host [HTTP::host]
set new_uri /center/templates/welcome.cfm
set new_url $host$new_uri
if {[HTTP::cookie exists $ckname]} {
if { $uri contains "agencyctr" } {
HTTP::redirect https://$new_url
} else {
pool Shared
}
} else {
HTTP::redirect "https://aac.alliedinsurance.com$uri"
}
}
Purpose of rule, check for cookie set in 2nd rule, allow user to site. If cookie not present redirect to aac.alliedinsurance.com:443 to set cookie.
Problem: During loadtesting developers are telling me that 2 application sessions are being set one one user accesses the site.
My fear is that on the first or second rule, the bigip is allowing the client back to the app server (which would set the session). My understanding is that the bigip should only allow client through to app server if iRule conditions are met.
Am I understanding this correctly or do I have a problem with my iRule logic. I have some network traces done, but ssl makes it hard (impossible) to see details. There is a lot of complexity here and I don't know if I have done a good job of explaining everything.
Please ask questions if something is not clear. I've got to get some hard answers back to developers.
Thanks,
Ted Smith
Allied Insurance
9 Replies
- JRahm
Admin
If your server folks will give you the ssl key, you can use ssldump on your tcpdump captures. The executable is available on the BigIP system. The syntax I use:
ssldump -Ad -r -k > 
Ted_Smith_11168Ya, I am trying to convice powers that be to give me SSL info with password so I can see more details.
Appreciate the specific syntax.
More to the point though, If irule 1 is run against an incoming connection, it shouldn't make it past the bigip unless it matches the uri syntax compare.
Same with iRule2... shoudl set cookie and re-direct client. Packet should not be passed to the defined pool.
Is my assumption correct, or do I have something mis-configured?
Thanks for any help- JRahmIn the third rule, it looks like this will never be matched:
if {[HTTP::cookie exists $ckname]} {
if { $uri contains "agencyctr" } {
HTTP::redirect https://$new_url
}
because you are setting ckname to aac2 directly above it. I'd remove this:
when CLIENT_ACCEPTED {
set ckname aac2
set ckvalue [IP::client_addr]
set ckdomain .alliedinsurance.com
}
from your third rule since the first line appears to overwrites the information you want out of the 2nd rule and the next two lines aren't used. I'd also recommend not setting variables unless you will use them frequently. If I were to rewrite your third rule, I'd do something like this:when HTTP_REQUEST { if {[HTTP::cookie exists "aac2"]} { if { [HTTP::uri] contains "agencyctr" } { HTTP::redirect https://[HTTP::host]/center/templates/welcome.cfm } else { use pool Shared } } else { HTTP::redirect https://aac.alliedinsurance.com[HTTP::uri] } }
HTH - JRahmHmm, not thinking straight, you're just looking for the cookie name, so that should work. I've updated the post to look for the cookie name without the variable. I'd add some logging throughout all the rules to see if you can find where the ball is being dropped.
- Well, looking at your second rule, it looks as though you have it configured to forward the traffic to teh application servers (or whatever is configured as the default pool for that VIP).
Since the rule allows the connection through after setting the HTTP::uri on the HTTP_REQUEST event, the server is seeing the traffic and responding, which is how you're able to use the HTTP_RESPONSE event to set the cookie and send the client the 302 redirect.
Then again in the third rule, you're redirecting people to the same host, with a specific URI.
It sounds like a successful request would hit the servers behind your BIG-IP twice on a normal pass through this series of rules. Is this your intended setup?
-Colin - Ted_Smith_11168Thanks again for your help. I'll do some editing to remove some of the variables. I inherited these a while ago and thought they were needed. I think I just mis-understood how to best use information already available from the client headers.
Did I mention that I am not a coder :-)
in rule 2 I re-direct the client and set a cookie:
when HTTP_RESPONSE {
HTTP::respond 302 Location "https://aac2.alliedinsurance.com$uri" "Set-Cookie" $cookie
}
Is this command different than using the:
HTTP::redirect command?
can cookie info be set the same way? Is one better than the other?
Thanks!! - Ted_Smith_11168Colin,
Thanks for the reply!
Just to make sure I am referencing same rule, this is rule 2
when CLIENT_ACCEPTED {
set ckname aac2
set ckvalue [IP::client_addr]
set ckdomain .alliedinsurance.com
set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue $ckdomain]
}
when HTTP_REQUEST {
set uri [HTTP::uri]
}
when HTTP_RESPONSE {
HTTP::respond 302 Location "https://aac2.alliedinsurance.com$uri" "Set-Cookie" $cookie
}
I've stared at this so long, I looked right past the most obvious cause!
No, with this rule, I do not want the client being passed to the defined pool. Can I simply move the http::respond command to the HTTP_REQUEST section or do I need to use an HTTP::redirect command is there a difference?
Looking at rule3 do I need:
when CLIENT_ACCEPTED {
set ckname aac2
set ckvalue [IP::client_addr]
set ckdomain .alliedinsurance.com
When the cookie was set in rule2
My oringial intent was to bring a user into rule2, set the cookie, redirect to rule3. In rule 3 verify that cookie has been set by rule 2. If cookie not set, go back to rule2 and set cookie.
Thanks again for your help. You guys are the greatest! - Ted_Smith_11168OK, I modified my iRules and I am still seeing multiple sessions being created in my App servers.
Here are my altered irules:
UITAAC port 80 VIP RULE 1
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/plquoting/templates/receiveincomingfile.cfm" } {
HTTP::uri "/PersonalLines/Templates/receiveincomingfile.cfm"
}
elseif { [HTTP::host] == "uitaac.allied.nwie.net" or [HTTP::host] == "uitaac"} {
HTTP::redirect https://[HTTP::host][HTTP::uri]
}
}
UITAAC port 443 VIP RULE 2
when CLIENT_ACCEPTED {
set ckname uitaac1
set ckvalue [IP::client_addr]
set ckdomain .allied.nwie.net
set cookie [format "%s=%s; path=/; domain=%s" $ckname $ckvalue $ckdomain]
}
when HTTP_REQUEST {
log "rule 2 incoming cookie is: [HTTP::cookie names]"
HTTP::respond 302 Location "https://uitaac1.allied.nwie.net[HTTP::uri]" "Set-Cookie" $cookie
}
UITAAC1 port 443 VIP RULE 3
when HTTP_REQUEST {
log "rule 3 incoming cookie is: [HTTP::cookie names]"
if {[HTTP::cookie exists "uitaac1"]} {
pool UITShared
}
else {
HTTP::redirect "https://uitaac.allied.nwie.net[HTTP::uri]"
}
}
If the user uses http://uitaac.allied.nwie.net, app server only issues 1 session
If user uses https://uitaac.allied.nwie.net, the app server issues 2 sessions.
I can't see why there is a difference since rule1 redirects the user to rule2.
Any ideas/help?? - Ted_Smith_11168I am still having issues with this... anyone have any ideas?
Thanks!
-Ted
