• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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.4k 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
    nikkilocke
    last edited by May 11, 2010, 9:51 AM

    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
      kpa
      last edited by May 11, 2010, 9:59 AM

      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
        nikkilocke
        last edited by May 11, 2010, 1:51 PM

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

        1 Reply Last reply Reply Quote 0
        • J
          jimp Rebel Alliance Developer Netgate
          last edited by May 12, 2010, 12:39 PM

          @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
            nikkilocke
            last edited by May 12, 2010, 5:41 PM

            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
            • J
              jimp Rebel Alliance Developer Netgate
              last edited by May 12, 2010, 6:00 PM

              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
              6 out of 6
              • First post
                6/6
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                This community forum collects and processes your personal information.
                consent.not_received