When securing my device (ubuntu) I noticed strange ufw logs. I am behind a router which should be blocking these kinds of requests? I realise these are using port 443 but I was under the impression that my outgoing connections to a website shouldn't produce incoming connections to me.

[UFW BLOCK] IN=wlp1s0 OUT= MAC=b0:fc:36:e0:0f:2d:2c:30:33:34:bf:32:08:00 SRC= DST=<my ip> LEN=40 TOS=0x00 PREC=0x00 TTL=123 ID=0 DF PROTO=TCP SPT=443 DPT=43648 WINDOW=0 RES=0x00 RST URGP=0

Other info:

  • There was only one other device connected to the network.
  • This router was recently reset. upnp is disabled.
  • Recently plugged a usb stick into the pc.
  • I have all incoming connections blocked and only allow http, https and dns out.

2 Answers 2


Your event is showing a TCP reset coming from port 443 of (the server) into port 43648 of your machine (the client):

In logs for a HTTPS connection attempt you should see the port 443 as destination port , the server IP address as destination IP and the flag SYN active. But the event shows a packet in the opposite direction and with RST flag active. This is is not an incoming connection towards your machine.

I´ve seen similar events from stateful firewalls being caused the server sending additional packets to the client with RST active after a TCP connection from client to server has been terminated.

Stateful firewalls track the state of the connection and automatically allow incoming packets which are a reply for an outbound connection that has been allowed. Once the TCP connection is terminated (by the exchange packets with flag FIN active between client and server) the firewall will not match any more packets with the connection, even if such packets are generated. Therefore, when the additional packet with RST active is sent from server to client the firewall has no connection to match this packet with and denies it generating the event you are seeing.

0 is on Fastly's network. Fastly is a widely used CDN. It's possible that you were connected to a website that uses Fastly as it's CDN. Then, perhaps because of a network glitch, Fastly's web server thought the connection was still open and tried to reply to it, but your firewall thought the connection was closed and the session was no longer active.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .