Good afternoon, I’ve a question about the following setup.
We’ve a F5 loadbalancer connected to a firewall. Behind the firewall there’s a Web application we’d like to logon to with HTTPS from the internet. So what I did is create a virtual server on the loadbalancer, place the web server in a pool and connect that pool to the virtual server. Create a SSL Client profile with a SSL certificate to be offloaded. The web application listens to HTTP.
So far so good, with the webserver still offline I’ve tested the HTTPS connection from the internet to logon to the ipaddress of the Virtual server directly with HTTPS, to check the offloading process on the loadbalancer. This went fine.
Next step I made the Virtual server’s ip address resolvable from the internet. No at this time the webserver is also setup completely. So now I type in HTTPS://mynewapplication and a error message within my IE browser shows: “Page cannot be displayed” Fox: “The connection was reset” I got into this with TCP Dump and I see HTTPS sessions on the outside interface of the loadbalancer as well as the inside interface. I see the HTTPS session also going through the firewall however, the way back looks not OK. The output of tcpdump of my firewall is as follow:
3497.161070 publicip.25863 → ipwebapp.443: syn 4107334300
So this looks like the session is somehow broken up. I’ve checked all policies and rules and interface configuration on that firewall and it looks fine to me.
Is there something I’m overlooking on the loadbalancer?
ipwebapp’s ip is the ip address of the outbound interface of the webserver NOT the VS. I expect port 80 to that ip address on the firewall, however I don’t see it.
Now I notice a SYN on the firewall’s outside interface with port 80 and a ACK on the firewall’s inside interface on port 443. (I was expecting port 80)
So It look likes the 443 request lands on the Loadbalancer. The certificate is offloaded and send a session on port 80 HTTP to the webserver, but the webserver replies at port 443 and that’s probably the reason the session is broken and the error message shows.
No the question is why does the webserver try to setup a session back at port 443?
It should be the correct one it’s the TCP stream which is been triggered direct after I fire up a refresh from my browser where I test the web application.