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.

Improve this question
2
  • 4
    some of what you wrote doesn't make much sense but why don't you look at where wireshark shows the actual packet and analyse further the makeup of the packet? Also I wouldn't talk of one protocol "using" another. You can say one protocol encapsulates another, or doesn't encapsulate another.
    – barlop
    Commented Dec 8, 2022 at 10:50
  • 2
    also try pinging a computer (That should be proper ICMP), see how that looks(there souldn't be any TCP there). Compare it to the weird thing you are looking at.
    – barlop
    Commented Dec 8, 2022 at 10:51

1 Answer 1

Reset to default
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).

Improve this answer
3
  • 1
    I'd say that not distinguishing the "depth" of dissected field is not a limitation of Wireshark but a very useful feature. It means that if you filter for a particular flow or tcp.dport == 443, you also get to see the related ICMP messages, which helps tremendously in interpreting what's going on.
    – TooTea
    Commented Dec 8, 2022 at 20:53
  • Sometimes yes, but in most non-ICMP cases it has been more annoying than useful. There were cases when I couldn't write a filter that matches specific packets by their inner tunneled IP header without it also matching every single packet by its outer header...
    – grawity_u1686
    Commented Dec 9, 2022 at 6:42
  • With Wireshark 4.0.0 and later, you can utilize the new layer operator to distinguish inner vs outer IP header fields. For example, if you want to match the outer IP source address, then you could use ip.src#1 == 192.168.15.1, and if you want to match the inner IP source address, then you could use ip.src#2 == 192.168.15.64. Besides the release notes for Wireshark 4.0.0, you can also read about the layer operator in the wireshark-filter man page.
    – Christopher Maynard
    Commented Dec 10, 2022 at 16:01

You must log in to answer this question.

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