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

    PfSense very slow on TCP open

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 2 Posters 1.8k 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.
    • T
      tlum
      last edited by

      I'm having a problem with all of my TCP services (like HTTP and SMTP). There is a NAT rule that maps the WAN side public address to the DMZ and a firewall rule that lets it through. With packet capture on both sides you can see the open come in the public interface and a full 10 seconds later come out the DMZ side. By them some mail servers have timed out. Any idea why it would have this problem or where to start looking.

      TIA

      -Ted-

      1 Reply Last reply Reply Quote 0
      • N
        nocer
        last edited by

        Hi

        Any dns issues around? Because 10 sec delay is something like dns' time-out.

        cheers,

        1 Reply Last reply Reply Quote 0
        • T
          tlum
          last edited by

          This is a good question and I'm not sure of the answer. I have 4 DNS servers. 2 are private 2 are public. The private server do recursive lookups, so these are the ones I have specified. They are on a LAN subnet.

          The fact is that I don't know what pfSense needs in terms of DNS. I could simply give it public servers, but then anything specific to the internal zones will fail lookup. If I give it private servers I'm not sure if it expects them to be on a specific interface or what rules it might need to see them.

          -Ted-

          1 Reply Last reply Reply Quote 0
          • T
            tlum
            last edited by

            Yes, it looks like it was (is) a DNS problem. Mail server is trying to do a reverse lookup on the source address… which just happens to be one of my public subnets that I'm decommissioning. So the DNS query to the internal server tried to go out and back in to the public server and just kind of dies there. It seems like its just affecting my testing.

            -Ted-

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