PfSense is killing the connection- RST flag at 3-way-handshake
at our customer site I used m0n0wall as a hotspot server (captive portal) and I recently upgraded on pfSense 2.0 (by now RC3). From the beginning I had some troubles reaching some sites on internal Webservers. All connections to the internet are working properly. With m0n0wall, everything worked fine.
The topology is:
|Client| -> |pfSense 18.104.22.168| -> |Backend Firewall| -> |internal Webserver 22.214.171.124|
As you can see at the attached packet capture, pfSense is sending a RST Flag after the SYN/ACK from the server.
Is this problem known? If not, what advices could you give me.
Many thanks and greetings.
eri-- last edited by
You are matching a previous not cleaned state.
Seems your application is doing something wrong or you have more delays in your application than expected.
The information provided does not help to really solve the issue and i would check more the application than pfsense.
cmb last edited by
Something more going on there than that capture shows. Couple things stick out, one the SYN ACK is initially lost ("TCP previous segment lost", and the timing between also indicates that's likely the case), two the RST is destined to 00:00:0c:07:ac:02 which isn't the source of the SYN ACK. Check more points of reference with the capture, both sides of all involved firewalls, the source host, the destination host, and that should help track things down.
Thanks so far.
I just made a packet capture for another connection to an internal server. Here also the capture says that pfSense receives a ACK for a segment which was not seen before.
It's a bit weird because with m0n0wall everything worked fine.
danswartz last edited by
Unless you replace pfsense with monowall and retest now, that isn't a compelling argument. e.g. something else may have changed in the interim.
problem is solved for now. I configured another default gateway.
But it seems, that pfSense didn't take the right route. When a client tries to reach the server, pfSense routes the packets to the default gateway even though the subnet with the server is located behind another gateway for which I created a route to.
But I have a working solution now.
All in all, thanks for your help. I appreciate that!