Firewall causing delay from web server?

I think this is a firewall related question. I have an Apache web server that sits behind the company firewall. However, an entry has been made to allow outside traffic to access the web server. The web server needs to be behind the firewall so it can query data from other protected servers and provide that to the public. The web server has read only access to the other server.

When a user from outside the company network first contacts the web server there is a 25 second delay before the response page is received. Subsequent responses are less than 1 second as long as there is a continuing dialogue between the user and the web server. As long as the user makes another request of the web server within about 15-20 seconds, the web server responds very quickly. When the user waits 30 seconds or more, there is once again a 25 second delay in response from the web server.

There seems to be an initial negotiation that takes place which stays in effect as long as there is a continuing dialogue between the server and the user. If there is too long a gap in communications, the connection has to be renegotiated.

Is anyone familiar with this scenario? Is there a setting that would allow for a longer time period before the connection has to be renegotiated?

Our users are frustrated by the 25 second delay in response from the web server. The delay does not occurr for users within the company network, behind the firewall.

Thanks for your help. :shock: :shock:

Can there be some timeout proleme becouse in 10-15 seconds if the user asks for data then it replay fast but after 25-30 seconds it
takes some more time.

Correct me if i am mistakeing.

Could be any one of a number of things. I've seen a similar but different behaviour that was due to ARP cache problems. You could try putting a static ARP cache entry in your webserver for the MAC address of the firewall.
If it's nothing to do with that, tell us what kind of firewall you've got and we'll have another think

It can also be a DNS issue, make sure you do not block DNS traffic at UDP & TCP 53 port, that your dns server can resolve correctly domain names and ip addresses and your webserver is configured to use it. Additionally check that "HostnameLookups" is Off at the httpd.conf.

If it is a DNS problem, perhaps the logs of the DNS server can be of some help. I don't think the error_log of apache would hold anything, but check that too.

grahamb47,

Your problem does sound odd and I'm sure there's an explanation for it.

Because we have no idea where the problem exists, I'd suggest this simple method to discover it: Place a sniffing tool on the public and private interfaces of your web server and observe the connections from your public clients.

The 25-30 second delay will surely show up on one of the two interfaces. From there on, depending on the protocols and sessions used, you'll need to do a bit more digging to figure out the reason of the delay, but also find a way to resolve it.

Packet sniffers are your best friend in situations like these, and a good packet sniffer will provide you with more information you could imagine while also saving you a hell of a lot time trying to figure out what's happening!

When you get around to it, please do post us your results so we can track and help in your progress.

Judging from your post, without any information about the firewall used and the methodology implemented to provide protection - I'd assume your using some type of tcp sequence/ack protection scheme before passing the connection to the internal servers;

A protection like this could be accountable for the delays experienced during the session setup.

Cheers,

The firewall could be over burdened. Or the tcp session timers could be set way too low (that is if the firewall is even stateful). If the firewall is natting the traffic to the internal webserver, coupled with short session timers and being taxed could add up to a 25-30 second delay in initial response time, but even then the firewall would have to be running on something like a 286, or handling 50,000 connections to have that sort of response time.

Chris makes a good point about how the session is handled within the firewall. Perhaps there is a mis-configuration in the http security server.

The suggestion about DNS queries is also a good one. I've not seen it for http services, but sometimes smtp servers are configured to require reverse lookups.