You need to localize which part isn't working. Breaking down "browsing a web page" into it's respective parts:
- resolve DNS
- connect to IP
- receive response
So, first you need to verify that DNS is resolving correctly. Ideally, this should be from a machine outside (I'm assuming you're serving pages to external customers) your network.
Secondly, telnet to port 80, internally first. For me this is:
greeblesnort@greeblesnort:~$ telnet 172.18.1.100 80
Trying 172.18.1.100...
Connected to 172.18.1.100.
Escape character is '^]'.
GET / <<<<<<<<<<<<<<type this and hit <ENTER> twice
HTTP/1.0 301 Found <<<<<<<<<<<<this, while a "bad" response, *is* a response from the web server
If that works (with any valid server response), then the server is responding on that port. If you wanna be picky, you can use:
GET /index.htm HTTP/1.0
replacing index.htm with whatever your server uses for it's default. This should return a valid page:
HTTP/1.1 404 Not Found
Content-Type: text/html
Server: Microsoft-IIS/7.0
x-info: result=success;server=web01;build={IIS}
Date: Fri, 18 Sep 2009 21:56:47 GMT
Connection: close
Content-Length: 12579
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
...
Now, if you can do this, from the outside, and receive any sort of valid server response, then the problem is on the server itself (code or configuration).
Third, you need to verify that your server is able to communicate it's response back to the customer. This one is probably more of an issue with SLB setups where the NAT, server, and virtual are all different addresses and the server can communicate back to the customer via a different address than the request was made to (asynchronous routing).
Hope that helps. If you give some more information, I'm sure some of us would be willing to help you verify the external stuff...
edit:
Well, if 91.135.5.118 is the correct resolution, then DNS appears to be fine from both nameservers.
However, when I try:
[greeblesnort@fjdx421 greeblesnort]$ telnet www.enfotext.com 80
Trying 91.135.5.118...
Connected to cust118-dsl91-135-5.idnet.net (91.135.5.118).
Escape character is '^]'.
GET /index.htm HTTP/1.0
it times out.
This would normally make me suggest that you talk to your ISP about them potentially blocking inbound port 80 requests. But, that would be kinda silly if they're allowing all those other ports that appear to be open.
I did a packet capture, just to see what was happening on the wire, and it appears that your server is never actually completing a TCP handshake. It appears to receive the initial SYN, returns a SYN/ACK, I send the final ACK, and your server keeps trying to resend the SYN/ACK.
My bet moves to a firewall config either upstream or on your server.