1

I am trying to make my nginx "status" page from machine A (Ubuntu 16.04) available from machine B (Ubuntu 20.04), but I am getting error port 80: No route to host when trying to access the page.

Both machines are connected through an internal network with addresses 10.3.1.1 and 10.3.2.201.

ping works in both directions and I have setup my nginx conf file as follows:

server {
    listen 127.0.0.1;
    listen 10.3.1.1:80;
    root /home/www/public_html;
    index index.html;

    location /basic_status {
      stub_status on;
      allow 127.0.0.1;
      allow 10.3.2.201;
      allow 10.3.1.1;
      deny all;
    }
}

For some reason I'm able to access the /basic_status page on machine A from machine A, but not from machine B:

ubuntu@machine-a:~$ curl http://10.3.1.1/basic_status
Active connections: 1
server accepts handled requests
 187325 187325 2010480
Reading: 0 Writing: 1 Waiting: 0

ubuntu@machine-a:~$ curl http://127.0.0.1/basic_status
Active connections: 1
server accepts handled requests
 187326 187326 2010481
Reading: 0 Writing: 1 Waiting: 0

ubuntu@machine-b:~$ curl http://10.3.1.1/basic_status
curl: (7) Failed to connect to 10.3.1.1 port 80: No route to host

ufw is configured on machine A to accept incoming connections to port 80 from anywhere:

ubuntu@machine-a:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

At this this point I don't know what other setting could be causing this...

Buno
  • 155
  • 2
  • 8
  • 1
    Well, is there a route? Run `traceroute`. – Michael Hampton Jun 21 '20 at 22:21
  • Indeed it seems no route is found.. yet `ping 10.3.1.1` works perfectly fine from machine B? – Buno Jun 22 '20 at 08:57
  • 1
    It could also be a 3rd party (router) blocking the connection, or UFW not telling all the truth. I'd run two tcpdump, one per system, and then try again ping, curl and traceroute, to check if machine A received the packet or not, and sent the no route to host or not (arp requests too should be checked when the message is "no route to host"). When the cause doesn't appear clearly, it's all about thorough testing to rule out causes. – A.B Jun 22 '20 at 10:37
  • Upon further investigation, it seems that UFW was "telling the truth" - but it merely creates rules for iptables on your behalf.. and there were a bunch of iptables rules already in place superseeding UFW. After a good cleanup it now works! Thanks all – Buno Jun 23 '20 at 07:45
  • 2
    I think that you should either answer your question with the content of your last comment and mark it as accepted, or close/delete the question. Either way that tells this question doesn't expect an answer anymore. – A.B Jun 23 '20 at 09:45

1 Answers1

0

Upon further investigation, it seems that UFW was "telling the truth" - but it merely creates rules for iptables on your behalf.. and there were a bunch of iptables rules already in place superseeding UFW. After a good cleanup it now works.

Buno
  • 155
  • 2
  • 8