Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    LAN to LAN getting blocked pfsense 2.2.4

    Scheduled Pinned Locked Moved Firewalling
    3 Posts 3 Posters 643 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.
    • Y Offline
      yaboc
      last edited by

      so i upgraded from 2.1.5 yesterday to 2.2.4 and had to re-create a bunch of fules.
      Today I see some strange behavior. I can't ssh to some of my servers on the same LAN.
      People are getting kicked out from quickbooks which connects to a file share

      i do have

      IPv4 TCP LAN net * * * * none Easy Rule

      in my lan tab but in the log i still see

      block/1000000103 Sep 25 15:31:35 LAN 10.18.66.x:135 10.18.66.x:50103 TCP:SA

      which is my file server

      i thought i have this covered by my LAN rule.

      Thanks

      1 Reply Last reply Reply Quote 0
      • KOMK Offline
        KOM
        last edited by

        Systems on the same network talk directly to each other without pfSense being involved at all.  As a router, pfSense facilitates connections between different networks.  Local traffic stays local.  I'm not sure why you would have to recreate rules after an upgrade.  Surely you could just restore from your config.xml backup?  At any rate, the firewall rules are a red herring.  Blocks you see on LAN are out of state packets:

        https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection

        1 Reply Last reply Reply Quote 0
        • C Offline
          cmb
          last edited by

          That's a clear indication there's something wrong with the network config of the host that's the source of that traffic (10.18.66.x:135), as it shouldn't be sending traffic destined to the same subnet back to the firewall (the original SYN isn't hitting it, so the SYN ACK in reply is blocked).

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