According to the ICMP message type (
3 "Destination Unreachable"), these are not monitoring but error packets (which is the most common use of ICMP). They do not use TCP, but they were caused by a TCP packet.
To allow the receiving host to associate the error report with some specific socket or connection, each error packet must include the original packet's network-layer and transport-layer headers. So the port numbers reported by Wireshark aren't for the ICMP packet itself but for its payload (i.e. the original TCP packet that caused this error).
(Wireshark dissects the payload as a nested IP packet so that you could see the information, but it cannot distinguish the "depth" of the dissected fields, so the entire captured packet receives a
tcp.dport == 443 property regardless of how deep the TCP header is.)
By looking at the ICMP payload (the "returned" packet), you can see that the HTTPS server at 192.168.15.4:443 was trying to send a TCP FIN to the client host 172.16.30.3, but either the client host is down and the gateway couldn't do an ARP lookup, or the packet was blocked by the gateway, so the undelivered packet is being returned to the web server.
(Edit: Looking at the full trace that OP posted in a now-deleted reply, the FIN is sent after ~60s idle, so it looks like a somewhat-normal situation where the client host established a whole bunch of TCP connections and exchanged a normal request/reply at first, but then disconnected from Wi-Fi without closing them – or something along those lines. The gateway is behaving like it should and sending "Host Unreachable" to indicate that it couldn't resolve 172.16.30.3 via ARP anymore.)
Another thing I found curious is that the ICMP traffic is in one direction using different destination ports. Like it's doing a port scan, is that even possible? The source port is always 443.
Clients always choose a random port as their source port for each TCP connection, so it's perfectly normal that responses from server to client will appear to have 443 as source and a random destination.
You're assuming that "source port" always means "client port", but that is not always the case – it depends on the direction that the packet originally went; for packets from the server to client, the source/destination port numbers are swapped (just like the addresses are swapped).