I think this a question about nginx/https but it may be about
iptables (too) in case I'm misinterpreting things.
I have recently setup a firewall on my router between my web server (nginx) and the internet. Nginx is set to listen on ports 80 and 443 and redirects most 80 calls to 443, using a let's encrypt certificate. With proper forwarding in place everything works quite nicely - at least I haven't found any glitches yet.
The firewall (iptables filter table) is set to
ACCEPT policy but when a packet hits the end of the
INPUT chain it gets forward to a
LOGDROP chain that, well, logs it and drops it.
Going through the logs I found dropped packets originating from port 443 on the server directed to the router. Example (MAC and IP addresses randomized,
.136 is server,
.122 is router):
Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped: IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272 WINDOW=0 RES=0x00 RST URGP=0
These attempts show up semi-regularly (1-3 attempts every ten minutes) over the course of a night after which they petered out.
Assuming that I interpret the log correctly, the server is contacting the router directly from the https port - which doesn't make sense because why would a router need web content, encrypted or unencrypted? And seemingly getting it without having asked for it?
I'm assuming that the outside requests for https content go over the
FORWARD chain both ways and so would not show up here. As I said AFAICT all https requests to the server are answered as they should.
My question is:
What is the likely explanation for these packets? A weird server tick that causes nginx to send packets where no packets are asked for? Or is it getting requests from somewhere that causes it to respond to the wrong machine?