HTTPS Offloading on virtual server session broken

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

3497.161506 ipwebapp.443 → publicip.25863: rst 0 ack 4107334301

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?

what is the reset cause?

sol13223: Configuring the BIG-IP system to log TCP RST packets

404 Page not found | BIG-IP Documentation

I don’t know :slight_smile: I suspect the web server application but I need some evidence.

BTW I noctice the RST only on my firewall.

3497.161070 publicip.25863 → ipwebapp.443: syn 4107334300

is ipwebapp webserver ip or virtual server ip?

if it is webserver ip, port should be 80, shouldn’t it?

if it is virtual server ip, you may check reset cause (sol13223).

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.

Hi, We’re getting somewhere here :slight_smile: Nog I notice only a SYN on the firewall. The RST is gone..

9277.411809 publicip.39399 → ipwebapp.80: syn 356713518 9278.412089 publicip.39399 → ipwebapp: syn 356713518

But still no SYN/ACK back

But still no SYN/ACK back

will response from webserver to client passing through bigip? if not, can you try snat automap under virtual server configuration?

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)

22.055425 ipwebapp.50168 → publicip.443: 3767854316 ack 2377740293 22.086639 ipwebapp.50169 → publicip.443: 1586917823 ack 4126254047

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?

22.055425 ipwebapp.50168 → publicip.443: 3767854316 ack 2377740293

22.086639 ipwebapp.50169 → publicip.443: 1586917823 ack 4126254047

are you looking at correct tcp stream? i think source port of webserver’s response should be 80 (i.e. not random port).

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.

Issue Solved. HTTP traffic back from the firewall to the loadbalancer was denied. Case closed.