Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to reach my local Apache from another source in the local network. The IP of the machine running Apache is 192.168.2.36, 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 192.168.2.36:80         0.0.0.0:*               LISTEN      0          1115713     4606/apache2

or (depending on configuration in ports.conf):

tcp        0      0 0.0.0.0:80         0.0.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...

share|improve this question

migrated from stackoverflow.com Sep 20 '12 at 16:54

This question came from our site for professional and enthusiast programmers.

    
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
add comment

1 Answer 1

up vote 4 down vote accepted

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: 192.168.2.36 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 192.168.2.100).

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

telnet 192.168.2.36 80

If you don't get something similar to this:

$ telnet 192.168.2.36 80
Trying 192.168.2.36...
Connected to 192.168.2.36.
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 192.168.2.36 from the remote PC (192.168.2.100). On 192.168.2.36 type:

sudo tcpdump dst 192.168.2.36 and dst port 80

to dump any network packets with destination 192.168.2.36:80.

Now log into 192.168.2.100, type:

telnet 192.168.2.36 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 192.168.2.100.50272 > 192.168.2.36.http: 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 192.168.2.100.50272 > 192.168.2.36.http: 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 192.168.2.100 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 192.168.2.36:

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

and try again. If no packets reach 192.168.2.36 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: 192.168.2.36 or 192.168.2.100 has a corrupted ARP cache (list the ARP cache with arp -n and then delete the entries with arp -d *ip_address*), 192.168.2.36 has a defective ethernet card or cable, IP address 192.168.2.36 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 192.168.2.100. Stop tcpdump with Ctrl-C and type:

sudo tcpdump dst 192.168.2.100 src port 80

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

23:03:33.054023 IP 192.168.2.36.http > 192.168.2.100.50471: 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 192.168.2.36.http > 192.168.2.100.50471: Flags [.], ack 1, win 9186, options [nop,nop,TS val 242492771 ecr 242492771], length 0
23:03:34.344572 IP 192.168.2.36.http > 192.168.2.100.50471: 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 192.168.2.100 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:

Trying 192.168.2.36.... 
Connected to 192.168.2.36. 
Escape character is '^]'. 
GET / 
Location: http://192.168.2.36 
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?

share|improve this answer
    
What a fantastically detailed and helpful response. Welcome to SO and Server Fault. –  Steve Kehlet Sep 20 '12 at 22:50
    
Thanks! Let's see if Dave finds it useful... –  jaume Sep 20 '12 at 23:01
add comment

Your Answer

 
discard

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

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