Odd ICMP Type 3 Code 13

wastedtime

I am seeing wierd Type 3 Code 13 ICMP packets. The data in them is normal for the most part. The IP header inside the ICMP is normal but the last 64 bits is a bit off. The destination port seems to increment by 1 on connection that needs them sent and isn't any where near the original packet's destination port. This is a cisco router that is generating this. I noticed that it is being generated on a FIN, ACK packet and not always but usually have I have sent a RST, ACK just prior to that.

Anyone know what is going on? Or even a guess?

Is this possibly a way to identify ICMP packets between multiple connections to the same host? I thought the IP ident area did that.

Met44

Can you attach a pcap ****?

wastedtime

Here is a partial pcap with changed IPs so ignore the checksum errors. All of the streams are from the established state to the RST,ACK and FIN,ACK packets.

http://app04.bonpoo.com/cgi-bin/download?fid=4726A10800C011E08A936A878E215873

Met44

I noticed that in the IP header returned inside the ICMP message, the TTL is decremented by one from the packet that triggered the ICMP response. This indicates that the router is passing back a copy of the packet headers as they currently are, however far along in processing it is -- not the original packet header. Makes sense to do it that way.

So if some function of the router changed the TCP header on the original packet as it passed through, then the packet was rejected, that would cause the "returned" header embedded in the ICMP message to have the "new" port. NAT is the first thing that comes to mind that could mangle the packet... but that would be an odd NAT config (doesn't change the source or destination IP addresses).

Not thinking of anything else at the moment. Maybe the TTL clue will help though.

One of my Linux systems returns the proper port. Maybe particular IOSes munge the port number? -- don't have a Cisco router around to test on.

wastedtime

Ya, I was thinking a few hours back that maybe it has something to do with a wierd IOS bug with NAT timeouts (ya it is using NAT). I may try adjusting them and see if the same thing keeps happening. The server is part of the problem though...as it seems to lag at points and drop packets. I have even received a TCP packet with the CWR flag set which is the first time I have seen that used.


Edit:
Also it just seems to be this server it does it too....which is why I am finding it wierd.