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

    Unexpected Firewall Log output

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 3 Posters 2.5k 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.
    • N Offline
      nikkilocke
      last edited by

      I have a new pfSense installation, running in a VMWare VM.
      My LAN interface is 192.168.100.10, connected to a router at 192.168.100.1 which routes to subnets 192.168.3.0/24 and 192.168.1.0/24.
      I have static routes for these subnets in pfSense with 192.168.100.1 as the gateway.
      My WAN interface is 192.168.2.10, connected to an ADSL NAT router at 192.168.2.5.
      I have NAT on the pfSense too.

      I am getting repeated log entries of the form:
      WAN 192.168.2.10:43624 (ip address censored):110 TCP:F

      Why should I be getting these?
      They are presumably relics of valid NATted sessions from a machine on my LAN which periodically checks my POP mailbox (which is at that address).

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

        http://doc.pfsense.org/index.php/Logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection,_why%3F

        1 Reply Last reply Reply Quote 0
        • N Offline
          nikkilocke
          last edited by

          Thanks for that. I take it there is no way to avoid these appearing in the logs?

          1 Reply Last reply Reply Quote 0
          • jimpJ Offline
            jimp Rebel Alliance Developer Netgate
            last edited by

            @nikkilocke:

            Thanks for that. I take it there is no way to avoid these appearing in the logs?

            No, because although they are related to a connection that just closed, there is no way for the filter to know this since the state is already gone. It's sort of a catch-22: If they were part of the state, the filter would know about it, and they wouldn't be blocked. If they aren't a part of the state, they get blocked, but there is no way to not log them because it no longer thinks they are valid.

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • N Offline
              nikkilocke
              last edited by

              Is there any way of slowing down the discard of the state, so that the FIN packet has time to arrive before the state is gone?

              1 Reply Last reply Reply Quote 0
              • jimpJ Offline
                jimp Rebel Alliance Developer Netgate
                last edited by

                You could try changing the firewall optimization to 'conservative' but I'm not sure if that will affect this particular type.

                Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

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