Forum Discussion
NimbostratusHTTPS 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?
11 Replies
- nitass
Employee
what is the reset cause?
sol13223: Configuring the BIG-IP system to log TCP RST packets
https://support.f5.com/kb/en-us/solutions/public/13000/200/sol13223.html 
heskez_36146I don't know :) I suspect the web server application but I need some evidence.
- heskez_36146
BTW I noctice the RST only on my firewall.
- nitass
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).
- heskez_36146
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.
- heskez_36146
Hi, We're getting somewhere here :) 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
- nitass
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?
- heskez_36146
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?
- nitass
22.055425 ipwebapp.50168 -> publicip.443: 3767854316 ack 2377740293
22.086639 ipwebapp.50169 -> publicip.443: 1586917823 ack 4126254047are you looking at correct tcp stream? i think source port of webserver's response should be 80 (i.e. not random port).
- heskez_36146
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.
