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

    127.0.0.1:3129 TCP:FA and TCP:RA spamming the firewall

    Scheduled Pinned Locked Moved Firewalling
    5 Posts 4 Posters 1.7k 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.
    • R
      rzlbrnft
      last edited by

      I am using the newest version of pfsense for a few networks.
      Recently I get the messages in the screenshot on the network that's used for mobile phone devices.

      On that network, the ssl interception is active as a transparent proxy. Port 3129 is the one the squid uses for that.

      What am I reading here?

      I tried to allow all traffic from 127.0.0.1 Port 3129, both on the interface and as a floating rule.
      But both rules seem to be ignored, that traffic is still logged as blocked.

      Can anyone clarify why that happens?
      firewall.PNG
      firewall.PNG_thumb

      1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        Those are out of state.. Se the RA and FA.. Which means Reset Ack and Fin Ack..

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • K
          kpa
          last edited by

          Do you have logging enabled for the default deny rules (set at Status->System Logs->Settings->Log firewall default blocks)? You should turn it off if you do because it will only log useless noise such as this case.

          What you're seeing is really useless noise because the blocked packets are the final RST and FIN packets that are supposed be part of a TCP connection tear-down but the standard is muddy and some implementations send unnecessary packets and some don't. Also the packets might be lost or delayed and that could cause retransmissions and by the time the packets finally arrive the state has already been destroyed on the firewall and they are logged as out of state packets.

          1 Reply Last reply Reply Quote 0
          • R
            rzlbrnft
            last edited by

            Thanks for the info so far. So that means ssl should work despite those messages obviously.
            Guess I just have to rely on my colleagues to tell me if something is not working.

            Yes I have enabled default logging since I don't think I captured everything I need to allow yet. Will disable that now.
            Thanks for quick help.

            1 Reply Last reply Reply Quote 0
            • H
              Harvy66
              last edited by

              It is interesting that it's from localhost

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