Nginx not responding to port 80 on public IP address
Adam
adam at monkeez.org
Thu Feb 4 12:00:53 UTC 2021
Hi Francis,
I've tried your suggestions (inline replies below) but am still stuck.
On Thu, 4 Feb 2021 at 10:06, Francis Daly <francis at daoine.org> wrote:
> On Thu, Feb 04, 2021 at 07:40:35AM +0000, Adam wrote:
>
> Hi there,
>
> It sounds like something outside of your nginx is preventing the traffic
> from getting to your nginx.
>
> In that case, no nginx config can help you; but there are other things
> you can perhaps look at.
>
> > nginx is running and listening on port 80:
> > tcp 0 0 0.0.0.0:80 0.0.0.0:*
> > LISTEN 0 42297 3576/nginx: master
> > tcp6 0 0 :::80 :::*
> > LISTEN 0 42298 3576/nginx: master
> >
> > The server responds fine to requests on port 443, serving traffic exactly
> > as expected:
> > tcp 0 0 0.0.0.0:443 0.0.0.0:*
> > LISTEN 0 42299 3576/nginx: master
>
> > I have been testing by sshing to an external machine and trying telnet
> > my.host.name 80 - which times out, compared to telnet my.host.name 443,
> > which connects immediately.
>
> Do your nginx logs indicate that the 443 traffic actually gets to this
> nginx, and not to a random server that allows port-443 connections?
>
Yes - the log files are good for port 443.
> Perhaps use "curl" to make a request, and confirm that the response is
> from this nginx.
>
I have tried this on the remote machine and see the html appear in the
terminal.
> > The port is open on my router to allow port 80 traffic. This machine is
>
> Do you have any local firewall running on the nginx machine that might
> block or otherwise limit inbound traffic?
>
I do have iptables managed by fail2ban running on the nginx machine.
> > hosted on my home network, serving personal traffic (services which I
> use,
> > but not for general internet use). It does respond to port 80 internally,
> > if I use the internal ip address (http://192.168.178.43).
>
> If that test is "from the nginx machine itself", then a local firewall
> probably won't block it. If that test is from another machine on the home
> network, then a local firewall that only allows same-subnet connections
> would allow this, but not allow your external test.
>
> "iptables -L -v -n" might show things there; or whatever local firewall
> command your system might use.
>
>
This is the output:
root at home:/home/pi# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
52134 4559K f2b-sshd tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 22
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain f2b-sshd (1 references)
pkts bytes target prot opt in out source
destination
16 1280 REJECT all -- * * 123.31.41.31
0.0.0.0/0 reject-with icmp-port-unreachable
35 1677 REJECT all -- * * 103.81.13.80
0.0.0.0/0 reject-with icmp-port-unreachable
20 1616 REJECT all -- * * 67.205.181.52
0.0.0.0/0 reject-with icmp-port-unreachable
21 1668 REJECT all -- * * 51.83.128.135
0.0.0.0/0 reject-with icmp-port-unreachable
16 1224 REJECT all -- * * 14.99.117.194
0.0.0.0/0 reject-with icmp-port-unreachable
19 1332 REJECT all -- * * 185.2.140.155
0.0.0.0/0 reject-with icmp-port-unreachable
15 1160 REJECT all -- * * 110.225.122.98
0.0.0.0/0 reject-with icmp-port-unreachable
21 1672 REJECT all -- * * 112.85.42.74
0.0.0.0/0 reject-with icmp-port-unreachable
24 1840 REJECT all -- * * 161.35.161.170
0.0.0.0/0 reject-with icmp-port-unreachable
21 1668 REJECT all -- * * 198.23.228.254
0.0.0.0/0 reject-with icmp-port-unreachable
79 3720 REJECT all -- * * 189.254.227.84
0.0.0.0/0 reject-with icmp-port-unreachable
16 1312 REJECT all -- * * 81.68.228.53
0.0.0.0/0 reject-with icmp-port-unreachable
21 1616 REJECT all -- * * 101.32.116.55
0.0.0.0/0 reject-with icmp-port-unreachable
> > I've kind of run out of ideas, so thought I would post here.
>
> I would probably try to run "tcpdump" on the nginx server, to see what
> port-80 traffic that machine sees when the connection is attempted.
>
>
I'd forgotten about tcpdump - thanks for that. This is the output.
11:56:47.592217 IP home.fritz.box.http > mab.sdf.org.40180: Flags [S.], seq
1308629493, ack 3287509164, win 65160, options [mss 1460,sackOK,TS val
3744800432 ecr 1108123496,nop,wscale 7], length 0
11:56:48.597175 IP home.fritz.box.http > mab.sdf.org.40180: Flags [S.], seq
1324331976, ack 3287509164, win 65160, options [mss 1460,sackOK,TS val
3744801437 ecr 1108124499,nop,wscale 7], length 0
11:56:50.611211 IP home.fritz.box.http > mab.sdf.org.40180: Flags [S.], seq
1355801094, ack 3287509164, win 65160, options [mss 1460,sackOK,TS val
3744803451 ecr 1108126515,nop,wscale 7], length 0
11:56:54.937069 IP home.fritz.box.http > mab.sdf.org.40180: Flags [S.], seq
1423392629, ack 3287509164, win 65160, options [mss 1460,sackOK,TS val
3744807777 ecr 1108130771,nop,wscale 7], length 0
11:57:03.126721 IP home.fritz.box.http > mab.sdf.org.40180: Flags [S.], seq
1551356176, ack 3287509164, win 65160, options [mss 1460,sackOK,TS val
3744815967 ecr 1108138963,nop,wscale 7], length 0
> (And maybe look at what is seen for port-443 traffic as well, for
> comparison.)
>
> 11:58:00.144568 IP mab.sdf.org.36420 > home.fritz.box.https: Flags [.],
ack 1, win 251, options [nop,nop,TS val 1108196048 ecr 2740660288], length 0
These were run on the box that is running nginx.
> Good luck with it,
>
> f
> --
> Francis Daly francis at daoine.org
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
Thanks again,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20210204/ecd2e373/attachment.htm>
More information about the nginx
mailing list