On Thu, Feb 04, 2021 at 12:00:53PM +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.
> > 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.
Ok, that says that inbound 443 works, and inbound 80 does not work. There
must be some device somewhere which has different rules for 443 and 80
involving your nginx machine.
> This is the output:
> root@home:/home/pi# iptables -L -v -n
This does not mention anything different between ports 80 and 443 that
I can see.
I am slightly surprised at the "policy ACCEPT 0 packets, 0 bytes" parts,
and at the lack of "RETURN" in the Chain f2b-sshd section; but maybe
different version of the tools show different output.
> 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
This shows the the nginx service is attempting to respond to the presumed
incoming syn packet from the client, and nginx is not getting back the
ack packet that it expects.
What should happen here is that you see a [S] packet from the
client-high-port to nginx-port-80 (which is not in this tcpdump
output; perhaps the tcpdump started late); and then a [S.] packet from
nginx-port-80 to the client-high-port (here you see 5 of them, because the
nginx server retries); and then a [.] packet from the client, which will
include or be followed by more [.] packets including the http request.
Something on your network path is either preventing the [S.] from getting
from nginx to the client, or is preventing the [.] from getting from the
client to nginx. But (presumably) it did allow the [S] from the client
to nginx.
Find and fix that something, and thing should Just Work.
> > (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
That is a [.] packet that will have followed the original TCP three-way
handshake. It proves that network routing between the client and the nginx
server is correct; something else is blocking some of the port-80 traffic.
Good luck with it,
f
--
Francis Daly fran...@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
