Forum Discussion
NimbostratusRedirection and DNS Masking
I am having problems implementing an iRule to solve the following situation:
Customer has 2 sites; a.b.com and y.z.com. Both sites are hosted on the F5 and have functioning VIPs. We are trying to redirect a URI string of http://a.b.com/apply to https://y.z.com, while maintaining the a.b.com/apply host name.
So far this is what I have done.
On a.b.com I have applied an irule(Rule 1) that redirects traffic to https://a.b.com/abc/common/Pages/welcome.aspx. if the URI matches "/apply"
On the https://a.b.com VIP i have applied a rule(Rule 2) that says if the URI matches "/abc/common" use pool y.z.com. Rule 1 is working fine, the redirection happens no problem. Rule 2 is throwing a connection was reset in the browser. I am at a loss here any help would be appreciated.
Thanks,
Jason
Rule 1:
when HTTP_REQUEST {
if {
[string tolower [HTTP::uri]] starts_with "/apply"} {
HTTP::redirect "https://a.b.com/abc/Pages/welcome.aspx" }
}
Rule 2:
when HTTP_REQUEST {
if {
[string tolower [HTTP::uri]] starts_with "/abc/common/" } {
pool y.z.com
}
}
- Chris_Miller
Altostratus
So, Rule 2 is applied to a VIP listening on port 443...is this VIP terminating the SSL connection? Are you seeing connection reset for traffic that meets the /abc/common URI, or for other traffic? 
Jomar_46001That is correct. VIP 2 is listening on 443 and is the SSL terminator. We are seeing the connection reset for anything that matches the /abc/common URI. All other traffic is passing as expected.- Chris_MillerPosted By Jomar on 10/20/2010 07:28 AM
That is correct. VIP 2 is listening on 443 and is the SSL terminator. We are seeing the connection reset for anything that matches the /abc/common URI. All other traffic is passing as expected.
On what port is pool y.z.com listening? If different than 443, is port translation enabled?Have you done a tcpdump from LTM to see whether the RST is coming from the pool members or directly from the VIP? I'd be interested to see whether the 3-way handshake, and cert exchange are happening properly.
Have you checked your LTM logs to see whether we're throwing any errors?
- Jomar_46001On what port is pool y.z.com listening? If different than 443, is port translation enabled?
Yes it is.
Have you done a tcpdump from LTM to see whether the RST is coming from the pool members or directly from the VIP? I'd be interested to see whether the 3-way handshake, and cert exchange are happening properly.
A good idea, will take a look at that now.
Have you checked your LTM logs to see whether we're throwing any errors?
Yes I have checked the logs, and there are no errors. - Chris_MillerPosted By Jomar on 10/20/2010 08:02 AM On what port is pool y.z.com listening? If different than 443, is port translation enabled?
Yes it is. Have you done a tcpdump from LTM to see whether the RST is coming from the pool members or directly from the VIP? I'd be interested to see whether the 3-way handshake, and cert exchange are happening properly.
A good idea, will take a look at that now. Have you checked your LTM logs to see whether we're throwing any errors?
Yes I have checked the logs, and there are no errors.
Can you also check the stats to confirm the iRule on VS 2 is being executed? If not in stats, add a log statement so rule 2 looks like thiswhen HTTP_REQUEST {if {[string tolower [HTTP::uri]] starts_with "/abc/common/" } {pool y.z.comlog local0. "User requested [HTTP::uri] and was sent to pool y.z.com"}}Then, check LTM logs to confirm URI is matching. - Jomar_46001
With the logging turned on.
Oct 20 11:24:17 local/tmm info tmm[4980]: Rule abc : User requested /abc/common/Pages/welcome.aspx and was sent to pool y.z.com
- Chris_MillerPosted By Jomar on 10/20/2010 08:27 AM
With the logging turned on.
Oct 20 11:24:17 local/tmm info tmm[4980]: Rule abc : User requested /abc/common/Pages/welcome.aspx and was sent to pool y.z.com
Perfect...so that tell us the rule is being hit, and the SSL magic is happening. So, a request for that page is met with a Connection Reset? What happens if you hit the server directly with that request? No firewalls between the LTM and server, right? If you telnet from the F5 to the pool member and do a similar GET request, does it work fine? - Jomar_46001Perfect...so that tell us the rule is being hit, and the SSL magic is happening. So, a request for that page is met with a Connection Reset? What happens if you hit the server directly with that request? No firewalls between the LTM and server, right? If you telnet from the F5 to the pool member and do a similar GET request, does it work fine?
The pool in question already has a VIP in front of it, and serves content as expected, so there are no firewall/connection issues from the F5 to the pool members.
Also, GET request to one of the pool members returned the expected content. - Chris_MillerPosted By Jomar on 10/20/2010 08:46 AM
Perfect...so that tell us the rule is being hit, and the SSL magic is happening. So, a request for that page is met with a Connection Reset? What happens if you hit the server directly with that request? No firewalls between the LTM and server, right? If you telnet from the F5 to the pool member and do a similar GET request, does it work fine?
The pool in question already has a VIP in front of it, and serves content as expected, so there are no firewall/connection issues from the F5 to the pool members.
Also, GET request to one of the pool members returned the expected content. Does the VIP in front of pool yz have the same settings as the other VIP? If using SNAT, same SNAT settings and all that? - Jomar_46001Does the VIP in front of pool yz have the same settings as the other VIP? If using SNAT, same SNAT settings and all that?
I believe that I have found the issue. I will post back later. Thanks for all the help.
