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

    (solved) pfSense blocking nomachine connections without reason

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    5 Posts 3 Posters 3.1k 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.
    • W
      Willy
      last edited by

      I never used pfSense 1.x.x so I'm not sure if the problem exists there. Feel free to move this thread to a more appropriate section if it's not 2.0-RC related.

      I have a pfSense setup to replace our old Zywall35 setup. Because the Zywall did not have enough LAN ports I had two extra gateways in my LAN subnet. One of these is a MPLS VPN line to another location. Ultimately this GW will be moved to another network card but not until I'm sure the below problem is solved.

      Schematic view:
      pfSense 10.10.0.5 –------------ Client 10.10.7.101
                                |
                                 --- MPLS 10.10.1.6 ------- VPN ----- nomachine server 10.9.1.101

      The default GW of the client is pfSense 10.10.0.5. There I have a static route 10.9.0.0/16 via GW 10.10.1.6. I have firewall rules on the LAN subnet to allow traffic from the LAN subnet to the remote subnet and to make sure I made another rule doing the opposite.

      Client route to nomachine@10.9.1.101:
      Tracing route to 10.9.1.101 over a maximum of 30 hops

      1    <1 ms    <1 ms    <1 ms  10.10.0.5
       2    <1 ms    <1 ms    <1 ms  10.10.1.6
      ~
       8    23 ms    23 ms    23 ms  10.9.1.101

      Trace complete.
      Hops 3~7 are the VPN subnets.

      Now when I open a connection to the nomachine server it starts just fine and I can work with it for a minute or so, then the connection is dropped. Checking the log of pfSense, it appears pfSense is doing the dropping although technically I don't think that pfSense has anything to do with the connection other than pointing the way (route) for the client, since the client and the GW are in the same subnet.

      A dump of the pfSense FW log is attached as image. The connections is first allowed, then later connections are blocked.

      When I change the "Firewall Optimization Options" from normal to conservative I can work a little longer with nomachine but the connection still terminates. When I change the clients default GW back to the Zywall (thus not using pfSense in the route) the connection never terminates.

      Which setting in pfSense did I forget?

      Any help appreciated.
      pfSenseFW.png
      pfSenseFW.png_thumb

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

        I experienced the same issue but worked around it.

        I had pfSense and a Cisco router on the same LAN subnet, it would randomly drop the connection to the remote network on the cisco router after a small period of time.

        The logs show that packets were being dropped.
        Just like you, I don't see why it should. I can only guess that pfsense is actually routing the packets for the client instead of redirecting the client to the other router.
        This worked fine before I replaced our aging router.

        pfSense  LAN 10.10.1.1/16
        Cisco LAN 10.10.1.5/16  –-------- T1 -----------  Cisco Remote 192.168.1.1/24

        I worked around it by moving the Cisco router to it's own subnet and adding the new interface and static route on pfSense.

        Using 2.0 RC built on Tue Mar 29 13:39:02

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

          The logs show that the blocked packets are "return" traffic, that is traffic trying to go back to the other side in reply to packets received.

          Normally seeing such packets indicates one of two things:

          • You have asymmetric routing, where traffic is taking a different path back than the way it left, so it doesn't match the existing state
          • The existing state was removed for some reason, causing the packets to be dropped.

          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
          • W
            Willy
            last edited by

            I'll move the MPLS to it's own interface/subnet next week and will keep my fingers crossed.

            When moved there shouldn't be any chance of a async routing so that should solve the issue.

            1 Reply Last reply Reply Quote 0
            • W
              Willy
              last edited by

              Solved by moving the MPLS gateway into its own subnet/interface

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