7

For some time now I have found myself interested in packet analyzing and I try to figure out all kinds of stuff that I see in network captures. I hope you guys might want to help me find out this one.

In a company network, I see a Fortigate 100E router continuously sending ICMP packets to an application server. My first thought was, "okay not that special, perhaps they use ICMP for monitoring or keep-alive purposes". But then I noticed that the source and destination ports were filled in.

screenshot

It uses TCP in the ICMP messages. That is weird right? I always thought that ICMP was a layer 3 control protocol that does not use layer 4 TCP.

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.

I do not control the router so I can't check the router config. I'm just trying to understand the traffic that I'm seeing in the traces that I received.

Spiff
  • 110,156
Deluccio
  • 73

1 Answers1

16

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).

grawity
  • 501,077