Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a problem with the availability of server from the outside (from local network all works perfect). A key problem is the http, where the requests are carried out but only if the response is less than a certain number of KB.

  • if accessed via browser from the outside, only the request less than or equal to 4KB are responsed
  • if access via the wget from the remote server, the requests are successful only if they are less than or equal to 256bytes
  • if access from php (via file_get_contents function) the response is max 256kb (if the request to a dynamic php file, if the request to a static html file, only 128kbs)

Examples of succes and failed attempt:

# wget
           => `a.html'
Resolving done.
Connecting to[]:80...connected.
HTTP request sent, awaiting response... 200 OK
Length: 255 [text/html]

100%[=====================>] 255          249.02K/s    ETA 00:00

12:46:08 (249.02 KB/s) - `a.html' saved [255/255]

# wget
           => `b.html'
Resolving done.
Connecting to[]:80...connected.
HTTP request sent, awaiting response...

A similar problem is also with the FTP connections, for example, where the connection is interrupted if accessed to the directory that contains too many files or subfolders. I have tried with different versions of apache (and even ftp servers) but the result was always the same. In the IIS server the problem is the same.

I guess that the problem is somewhere on the level of rutinga / firewall but I failed to determine anything concrete. Does anyone have any idea what could be the problem?

share|improve this question

It sounds like a path MTU discovery problem to me. Have a look at this procedure from Microsoft:

Basically, from the server computer, try and PING the computer you performed the test above with the argument:

ping <machine above> -f -l 1472

This will give you back a "Fragmentation needed" reply from the first hop that can't handle packets of this size.

What kind of WAN connectivity does the server computer have? DSL connections typically have an MTU of less than 1500, for example.

Your firewall device may have a configuration option to "clamp" TCP MSS to the MTU such that you don't have to make any changes to your server computer's MTU. Once you've determined that it is an MTU issue then you can pursue a firewall-based fix.

share|improve this answer
Thanks for your reply. I dont understand what <machine> I must ping? Do I ping server from other computer? I pinged server from my computer home and got the folloving results > "ping -f -l 1272" returns "Reply from bytes=1272 time=195ms TTL=117" "ping -f -l 1273" returns "Packet needs to be fragmented but DF set." Server is located in company, wich has VDSL connection (speed 20/10). If I undestand, I must find max MTU and set it like is told on ? – glavić Jul 2 '09 at 17:44
I now tried to ping other sites on server, and figure it out that the 1472 is maximum value, 1473 doen't work anymore and "Packet needs to be fragmented but DF set." is printed out. – glavić Jul 2 '09 at 19:31
That sure seems like you don't have an MTU problem, since 1472 bytes is the expected quantity you should be able to send across a medium w/ a 1500 byte MTU. Even so, I can replicate what you're seeing fine from here (the failure). I'd be curious to have you install "Network Monitor" on the server computer and sniff the output from the server when it's serving one of these failing requests. – Evan Anderson Jul 2 '09 at 20:27

It looks like perimeter firewall is configured to limit HTTP request / response size. But why would firewall behave differently for different clients wget, browsers and php scripts is not clear. Use wireshark on both ends to see eaactly what is going on wire in each case. That should help you in solving the problem.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.