Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense is killing the connection- RST flag at 3-way-handshake

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    6 Posts 4 Posters 4.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      skueeky
      last edited by

      Hi,
      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 195.145.22.55| -> |Backend Firewall| -> |internal Webserver 195.145.22.17|

      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.
      PC_pfSense.txt

      1 Reply Last reply Reply Quote 0
      • E
        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.

        1 Reply Last reply Reply Quote 0
        • C
          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.

          1 Reply Last reply Reply Quote 0
          • S
            skueeky
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • D
              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.

              1 Reply Last reply Reply Quote 0
              • S
                skueeky
                last edited by

                Hi guys,

                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!

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.