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

    HTTP - Server Timeouts

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 2 Posters 3.2k 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.
    • A
      andyh
      last edited by

      I've posted this previously in the Packages group, with no responses.  Thiought I'd try the general group, if this fails may stump for commercial support…..

      We have a pfSense 2.1 firewall, running Squid 2.6.18.1_07.  The unit has one lan, two load-balanced wan interfaces and a third enabled interface (bridged with LAN) that connects to an external VPN device.

      Occasionally http connections to certain servers on the VPN connection fail with server timeout messages from Squid.  We are able to ping the servers over the VPN, even though the we get HTTP time outs.  If we disable/enable the VPN connected interface http connectivity is restored to the sites.

      Has anyone come across this type of issue before or have any suggestions as to a possible solution.

      Andy

      1 Reply Last reply Reply Quote 0
      • Cry HavokC
        Cry Havok
        last edited by

        If restarting the VPN solves the problem then it's unlikely to be Squid related.  The problem is most likely network related, though without packet captures (at both ends) it'll be hard to say.

        1 Reply Last reply Reply Quote 0
        • A
          andyh
          last edited by

          I would only be able to get a packet capture from one end of the connection (pfSense).

          What level of packet capture be useful?

          1 Reply Last reply Reply Quote 0
          • Cry HavokC
            Cry Havok
            last edited by

            The far end is the important bit.  What you do is to put a packet capture device on the far end, configured to log traffic to the web servers on HTTP.  When you get the timeouts you can check the capture and see if the packets made it through the VPN.

            If they did, your problem is at the far end.  If they didn't, the problem is before that point and you can repeat the process at the near side of the VPN link.

            1 Reply Last reply Reply Quote 0
            • A
              andyh
              last edited by

              I see what you mean, unfortunately it's not possible to packet capture at the remote end.

              If I capure in pfSense, with a Count of 0, will it loop the logs at a certain point? Also, will these logs be any use to me for examination?

              Andy

              1 Reply Last reply Reply Quote 0
              • Cry HavokC
                Cry Havok
                last edited by

                Not sure about the packet capture in pfSense.  Captures from that end may help, they may not.  If it's all you can do then it's worth trying.

                1 Reply Last reply Reply Quote 0
                • A
                  andyh
                  last edited by

                  I run some network monitoring software  (Hobbit), that I should be able to perform some captures from.

                  I'll have a check on Monday.

                  1 Reply Last reply Reply Quote 0
                  • Cry HavokC
                    Cry Havok
                    last edited by

                    Umm, Hobbit (now Xymon) is for monitoring the health of systems, not performing packet captures.  Indeed, it has no packet capture facilities.

                    1 Reply Last reply Reply Quote 0
                    • A
                      andyh
                      last edited by

                      Sorry, I meant that I would run a capture from the system that's running Hobbit.

                      PS - Didn't realise that Hobbit is now Xymon - I'll look at the new version :)

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