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?
