Unexpected ICMP packets in mirror capture

asked 2025-10-04 18:17:18 +0000

AaronJ8
1 ●2 ●1

updated 2025-10-04 18:23:38 +0000

Hi all. I wonder if anyone can help me with this?

I’m performing a remote packet capture of interface 1 (vlan 1610) of an Aruba 6200F switch with mgmt IP address of 10.230.255.11. I've used the mirror tunnel option to send the data to an off-site server running wireshark (10.230.100.59) using a GRE tunnel. On the server I then filter packets to include only those containing the IP address 10.230.255.11.

I’m comfortable with the ARP information in the pack, but my confusion is that I don't understand how/why the ICMP packets are present. I can clearly see the conversation is between the switch and the capturing server, so my assumption is that it's the mirror data being sent (but that's just a guess).

Thank you very much

image description

edit retag flag offensive close merge delete

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2025-10-06 17:45:00 +0000

AaronJ8
1 ●2 ●1

Ok guys, thanks so much for everyone's input. You may have noticed that i'm still very much learning this trade.

Here is a very rough picture of what I think must be happening.

Left hand switch sends out ARP frames on vlan 1610
An ARP frame is sent out of interface 1 (the interface being mirrored)
interface 1 ARP frame is encapsulated in GRP and routed to the capturing server
Capturing server receives GRP packet, decapsulates it, realises it's an ARP frame
Capturing server doesn't understand how to respond to the ARP frame
Capturing server sends the Type 3 Code 2 ICMP message to tell the source of the ARP that it doesn't understand the request

Am I anywhere near close?

image description

edit flag offensive delete link

Comments

Not quite. please see my response to Chuck underneath Jaap's answer. That explains it a bit more in detail. In short, unless you configured something on the capturing system to decapsulate the GRE packets, the ARP is not recognized as an arp. And simply sending GRE packets to a system does not automatically decapsulate them.

SYN-bit ( 2025-10-06 19:11:47 +0000 )edit

Ah yes, I think the penny has just dropped. I work on Windows, so i'll investigate how to configure the GRE listener. Thanks again all. I'm sure i'll be back here soon, as i'm going to be working on IPSec next. Thanks again.

AaronJ8 ( 2025-10-06 19:20:44 +0000 )edit

add a comment

answered 2025-10-05 11:23:33 +0000

Jaap

13782 ●720 ●115

Well, what does the ICMP message tell you? Destination unreachable/Protocol unreachable.

So, the capture server's network interface is receiving GRE packets, with which it doesn't know what to do. How is it to respond? Since the IPv4 protocol is attached to that interface, an ICMP message Destination unreachable/Protocol unreachable is send back.

How to prevent this? Remove the protocols from the capture interface.

edit flag offensive delete link

Comments

Thank you very much for your response, I think I now under the situation. To be clear, is your recommendation to remove ICMP from the pcap via a filter?

AaronJ8 ( 2025-10-05 17:09:45 +0000 )edit

I think @Jaap meant to remove the IP stack from the NIC, but that would mean the packets won't be sent to your capture system, unless you create a hardcoded ARP entry on the gatewaay in the capture server subnet to forward these packets to your capture system.

SYN-bit ( 2025-10-06 06:52:47 +0000 )edit

Type 3 / Code 2 is Protocol Unreachable but does not indicate which protocol is causing the error.
There must be a GRE listener because that's how the packets are delivered to the capture system.
Why is this not caused by the ARP request for a device that's not on the local subnet?

Chuckc ( 2025-10-06 15:01:45 +0000 )edit

@Chuckc The packets are delivered to the capture system because it has the IP address of the GRE endpoint, that does not mean it has a GRE listener. GRE is a connectionless protocol. Compare it to a DNS packet being sent to UDP port 53. Since the UDP protocol is indeed present, you do not get a protocol unreachable, but when there is no listener on UDP port 53, you do get a destination, port unreachable. And in this case, as there is no protocol listener on protocol 47, you get the "protocol unreachable".

The ARP request is not seen by the IP stack on the capture system, they are just a blob of data underneath a protocol that is not handled.

This is a very common issue when doing ERSPAN or any other GRE tunneled mirror protocol towards a capture endpoint that does not terminate the GRE tunnel. Easy ...(more)

SYN-bit ( 2025-10-06 15:40:04 +0000 )edit

off-site server running wireshark (xxx.xxx.xxx.xxx) using a GRE tunnel

My bad - I saw "off-site" and "tunnel" and assumed there was encryption that was being unpacked.
Thanks for the lesson. :-) So much to learn. (not sure what I retain)

Chuckc ( 2025-10-06 16:24:33 +0000 )edit

add a comment

answered 2025-10-06 06:50:38 +0000

SYN-bit

18600 ●9 ●370 ●255 https://SYN-b.it

As your capture system does not have a GRE endpoint configured, the IP layer does not know what to do with these packets (but you see them anyway as they passed the point in the stack where the capture library is implemented). You can do three things:

Make sure the capture system is a GRE endpoint so that the packets will be processed. But this is not needed for your purpose of just getting the packets to your capture system. It could be beneficial though to capture on the decapsulated side of the tunnel to see the traffic without the GRE tunneling.
Create a filtering rule in the IP stack of your capturing system to not send out these ICMP packets back to the switch. If you are on Linux, an iptables rule can do this for you. This would be the cleanest solution.
Do nothing and have the ICMP packets be sent, And to clean up your capture, you can then add a capture filter ip proto 47 to only capture the GRE encapsulated packets.

edit flag offensive delete link

Comments

If you look at the ICMP packet, it put the IP packet that generated the error message into it's payload. And as you can see, it is the full IP/GRE/Ethernet/ARP packet that generated the error, as there is no handler for the GRE protocol, so no decapsulation and instead the ICMP protocol unreachable messages.

SYN-bit ( 2025-10-06 19:15:41 +0000 )edit

add a comment