I am trying to reach my local Apache from another source in the local network. The IP of the machine running Apache is, the os is xubuntu 12.04. Via this machine I can reach the Apache instance but it is not possible from any other pc or mobile device. The router's firewall is shut down.

sudo netstat -tulpen | grep apache

gives me either:

tcp        0      0*               LISTEN      0          1115713     4606/apache2

or (depending on configuration in ports.conf):

tcp        0      0*               LISTEN      0          1115713     4606/apache2

Both do not work. The host machine in pingable by the other machines in the network.

I simply can not imagine why this turns out to be so difficult...

  • Local firewall on the server? what do you get with "sudo iptables -vL"? – Juha Laiho Sep 20 '12 at 14:03
  • No firewall on the server, please see the output of iptables -vL under pastebin.com/y3Z7qnVY – dave Sep 20 '12 at 14:10
  • Try running nmap from one of the other machines and see if port 80 is in fact open on this server. – steps Sep 20 '12 at 19:09
  • Yeah, tcpdumps, telnets and so on. No firewall? That pastebin looks like a gigantic, complicated firewall. – Steve Kehlet Sep 20 '12 at 22:52

Do you make a distinction between the other computers in the local network that can ping the Apache server and the remote PC/mobile devices that try to access the Apache server (and fail at it)? I mean, are they in the same network?

Just to make sure, and sorry for mentioning this if it's obvious to you: is a private IP address which won't be routed and thus is not accessible from the Internet. The remote PC and mobile devices you mention must be located in the same local network in which the Apache server resides, or reachable through a router of yours (not your ISP's, unless you've configured it to forward some outside port to port 80 of your Apache server, of course -- I guess that's not the case).

I'll assume now that a remote PC is located in the same local network (let's say with IP address

1) First check that Apache can be accessed locally on (you wrote that access from the server itself works - I list it here for the sake of completeness):

telnet 80

If you don't get something similar to this:

$ telnet 80
Connected to
Escape character is '^]'.

don't look further and check your Apache configuration/installation, for something doesn't work as it should.

If you see the output above Apache is running. Close the telnet session with Ctrl-] and proceed to 2).

2) Now let's see if any network traffic reaches from the remote PC ( On type:

sudo tcpdump dst and dst port 80

to dump any network packets with destination

Now log into, type:

telnet 80

and then "GET /". That's an HTTP request, let's see if the server got it.

Go back to the tcpdump command and check its output. If it looks similar to this:

22:12:13.748106 IP > Flags [S], seq 3557385561, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 239423238 ecr 0,sackOK,eol], length 0
22:12:13.748190 IP > Flags [.], ack 1456211961, win 9186, options [nop,nop,TS val 239423238 ecr 239423238], length 0

packets are coming through, so proceed to 3).

If you don't see any packets from test the steps above on a couple of other PCs in the local network. If you see the same behavior flush the firewall rules on

sudo iptables-save > /tmp/save
sudo iptables -F

and try again. If no packets reach it's pretty difficult to say what's going wrong... some wild guesses are... but first restore the iptables configuration:

sudo iptables-restore < /tmp/save

I was saying, some wild guesses are: or has a corrupted ARP cache (list the ARP cache with arp -n and then delete the entries with arp -d ip_address), has a defective ethernet card or cable, IP address is used by another PC on the network, the remote PCs are configured to use IPv6...

3) Let's check whether IP packets are going back to Stop tcpdump with Ctrl-C and type:

sudo tcpdump dst src port 80

to see any packets going back to from source port 80 (that is, the Apache server). If you see an output similar to this:

23:03:33.054023 IP > Flags [S.], seq 1739061544, ack 502726814, win 65535, options [mss 16344,nop,wscale 4,nop,nop,TS val 242492771 ecr 242492771,sackOK,eol], length 0
23:03:33.054062 IP > Flags [.], ack 1, win 9186, options [nop,nop,TS val 242492771 ecr 242492771], length 0
23:03:34.344572 IP > Flags [.], ack 8, win 9186, options [nop,nop,TS val 242494052 ecr 242494052], length 0

packets are going back. Proceed to 4).

No tcpdump output means that is not getting any packets back... maybe a firewall? And from another remote PC, same behavior? ARP problem (list the ARP cache with arp -n and then delete the entries with arp -d ip_address)?

4) Check the output of the telnet command above. If it looks similar to this:

Connected to 
Escape character is '^]'. 
GET / 
Content-Type: text/html; charset=UTF-8

there may be a problem with your web browser. Maybe the HTTP proxy doesn't exclude computers in the local network?

  • What a fantastically detailed and helpful response. Welcome to SO and Server Fault. – Steve Kehlet Sep 20 '12 at 22:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.