2

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?

1

The example log message you've provided is a RST packet, which is usually sent by the kernel when there's nothing listening on the target port.

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

Specifically here, there will have been a previous request from 192.168.1.122 to 192.168.1.136:443 that has been rejected by the server 192.168.1.136 because nothing was - at that moment - listening on port 443. (Or there's a firewall on 192.168.1.136 with a REJECT rule for that address/port combination. At this level we can't differentiate.)

Unfortunately this doesn't explain why your router .122 should have been trying to communicate with nginx on .136, but it may help you interpret the log file message more easily.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.