Forum Discussion
CirrusDoing redirects from VIPs on one loadbalancer to VIPs on another.
I might not need the solution to this problem anymore, but this has been driving me crazy for the past week.
I've got a VIP on load balancer which has and irule. With a certain URI, it redirects to a VIP on another F5, which also has irules. After implementing the irules, I get the following when trying to open the browser with the redirect. "The connection has been reset."
when HTTP_REQUEST {
if {[HTTP::uri] contains "/foo/BAR" }
pool my-vip-redirect
} else {
pool my-vip
}
}
The pool, my-vip-redirect is a pool with a single server in it, the IP for the VIP on the other F5 listening on port 8443
Now on the second loadbalancer, where the second VIP resides
when HTTP_REQUEST {
if
!some elseif statement to other uris snipped!
elseif { ([HTTP::uri] contains "/foo/BAR") } { pool othervip-US-BAR-8443 }
!more elseif statements to other uris snipped!
}
As I said, this has been puzzling me all week, but it looks like they were planning to move the second VIP onto the same lb where the first LB resides, which should make things much easier. Would've been nice if they'd mentioned that beforehand, but I'd still like to know what was happening here to prevent it from working.
19 Replies
What_Lies_Bene1Cirrostratus
That error generally suggests that either the second VS or the real server is sending return packets directly back to your client (or the first F5) rather than through the F5. I'd suggest you carefully check your return routing for each hop from the real server to the client you're testing from. Most likely you need some SNATting somewhere.
atothNo its not that. There's SNAT enabled on both VIPs. I took a TCP dump on the first LB and I'm seeing packets come back and forth from the LB. Essentially. What happens is a a three-way handshake between the the two, and the next packet is a FIN which comes from the first LB, which ACKed by the second, which then send its own FIN, which is ACKed by the first LB>
- Kevin_Stewart
Employee
Do you, by chance, not have a server SSL profile applied to your external F5 VIP? I'm assuming the 8443 port on the internal F5 VIP is SSL, so you'll need that. These should also be standard virtual servers (port and address translation enabled). - atothChecking just now, there are both specific Client SSL profiles and generic Server SSL profiles to both VIPs
- Kevin_StewartAh, so it's:
Client -> 443 (SSL) VIP with client SSL and server SSL profiles -> 8443 pool -> 8443 (SSL) VIP with client (and server) SSL profile -> application
I'm also assuming these are standard virtual servers with port and address translation enabled, and SNAT enabled (you've confirmed this piece). We know based on the TCPDUMP that the two LBs can talk to each other, so routing isn't an issue. Is there any reason to believe that the second LB would not be accepting the SSL from the first? Do you have any unique settings in the second LB's client SSL profile?
Just for giggles, try an SSLDUMP between the two.
ssldump -k -i 0.0 -AdNn port 443
-k - you need the physical location of the private (*.key) file that is specified in the client SSL profile
-i 0.0 - this means use all interfaces, but you can narrow it down to a single VLAN/interface
-AdNn - this esentially means decrypt the traffic if possible and clean up the capture
port 443 - this is your filter. SSLDUMP absolutely requires a filter string. You can narrow this down to an IP address or anything else as long as the filter string is present.
What you're looking for is anything in the SSL traffic that would indicate a failure to negotiate. - atoth
I'm assuming I can use -w for the path and filter on a host ip as well?
- Kevin_StewartYou can filter on anything you want, similar to tcpdump, but ssldump does not have a switch for writing to a file. You can save a capture with tcpdump and then read it (to decrypt) with ssldump. If you can narrow the filter down to a specific IP or set of IPs, your capture shouldn't be that big, so copying it from the command shell would probably be easier.
- atothIts not liking that command; I keep getting the below. Even if I specify an interface, I still get the below error message about ETH0 not having an ip address.
ssldump -k -i 0.0 -AdNn port 443 host "ip address"
PCAP: eth0: no IPv4 address assigned - Kevin_StewartTwo things:
1. you need to specify the physical location of a private key (the one applied to the internal LB's client SSL profile).
2. you should use the "and" keyword to separate the filter parameters: port 443 and host 10.10.10.10 - atoth
Ok, this is what I get, the same 3 lines looping over and over again
New TCP connection 1: 'ip address 1'(35785) <-> 'ip address 2(443)
1 0.0630 (0.0630) C>S TCP FIN
1 0.1252 (0.0621) S>C TCP FINSame dealy if I use port 8443
