various timeouts on server - dashboard timeout

[dinsdale]

Hi,

I've noticed some strange timeouts on my ispconfig server. It appears that everytime when some remote content is fetched via PHP this results in a timeout. Here are some examples.

Log on to ispconfig:
the file dashboard.php takes 2.0 minutes (times out) until the page fully loads. In the source code I have the line:
$new_version = @file_get_contents('http://www.ispconfig.org/downloads/ispconfig3_version.txt');

a google javascript plugin looks up a long/latitude destination and the page hangs for 2 minutes and the plugin doesn't load

I cannot update TYPO3 Extensions remotely in the extension manager - it times out after 2 minutes

What could lead to these problems? I have a seperate development server running the same OS/ISPconfig version withouth these problems. Only difference is that on the dev server I didn't change the hostname manually in the config files and that it's not behind a external firewall. Also the dev server is a single server install and the webserver is distributed between email/web. both have allow_fopen enabled. What does like it sound to you what could be the problem?

I'm currently using ispconfig 3.0.3 on ubuntu 10.04

[till]

This might be a dns issue. Please take a look in the file /etc/resolv.conf and make sure that the nameservers listed there are working and reachable from your server.

[dinsdale]

checked the nameservers - I don't think they are the problem since it resolves correctly from the cli. It's only when I try to fetch some remote content with php that I get the timeouts. (wget works)
I did a couple of other changes in /etc/hosts since my last post since I think I didn't have my interfaces configured correctly and the /etc/hosts confirms now to manual but it didn't help. I set up the server on a private network and then changed the IP addresses - could this have led to problems?

To my knowledge all you need to fetch remote content is fopen - according to phpinfo() this shouldn't be the problem. Only other thing I did different from the manual is I installed xcache.

allow_url_fopen On On
allow_url_include Off Off

[dinsdale]

This is really a strange problem ...

If I try to fetch the content of a file with file_get_contents on a different domain which is hosted on the same server it works.
If I try to do the same with a domain which is not hosted on the same server the request times out.
It is not a DNS related problem since fetching per IP times out as well.

I'm at my wits end - any suggestions where to dig further?

[falko]

Are there any errors in Apache's error log?

[dinsdale]

No, there are no errors in the log file - I did a network sniff and after the timeout I only receive one strange ? character in the content field of requests that timed out.


At this moment in time I don't think it's anything server related. I did a couple of other tests and found out that if I request content via file_get_contents() from inside the internal network (/27 mask) I do get a response. Only if a request is routed via the gateway which appears to be running a firewall am I running into the timeout problem.

$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
XX.XX.122.32 0.0.0.0 255.255.255.224 U 0 0 0 eth4
0.0.0.0 XX.XX.122.36 0.0.0.0 UG 0 0 0 eth4

This is strange since applications like lynx or wget are working without problems for internal and external URLs and they should be working on the same ports. The only conclusion I can draw from this is that the firewall is somehow capable to filters content on the application level and recognized a request made by apache and somehow blocks it. I wasn't aware that firewalls work on this level.

In any case I have contacted my network provider and asked him to check it out and will let you know what comes out.

[dinsdale]

Good news everyone, it finally was a firewall configuration issue.

It appears the problem is related to a sonicwall firewall and enabled content filtering. The sonicwall firewall does actually filter on the application level and filters the 'minimal' HTTP headers coming from PHP. wget and lynx seem to be more verbose in their HTTP headers and are allowed to pass. I tried playing with the user_agent in the php.ini and some other settings but no luck.

I didn't do the changes on the firewall myself - according to my provider a simple reboot fixed it... I did read however that the tricky part for sonic firewall owners is that the content filtering module on some models is enabled by default despite it being a 'pay for' module. On these models you have to disable it manually on a non documented page http://your.ip/diag.html .

Thanks for your help, it's a big relieve it's working now.