GRE tunnels are a bit like those Russian nesting dolls, but for network traffic. You’ve got your regular IP packet, and then inside that, you’ve got another IP packet (the GRE header) and then the actual payload. Wireshark lets you peek inside these dolls.
Let’s watch a GRE tunnel in action. Imagine two routers, 192.168.1.1 and 192.168.2.2, connected via a GRE tunnel. We’ll send a simple ICMP ping from a host on 192.168.1.10 to a host on 192.168.2.10.
First, on 192.168.1.10, we run:
ping 192.168.2.10
Now, on 192.168.1.1 (the GRE tunnel endpoint), we’d capture traffic with Wireshark. If we just looked at the raw capture, we’d see an IP packet with source 192.168.1.10 and destination 192.168.2.10. But because it’s going over a GRE tunnel, the actual packet on the wire between 192.168.1.1 and 192.168.2.2 will look different.
Here’s what Wireshark might show you before you tell it about the tunnel:
Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
...
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.2.10
...
Internet Control Message Protocol: Echo (ping)
...
This is the inner packet, the one we’re interested in. But how does it get to the other side? The router at 192.168.1.1 takes this packet, wraps it in a GRE header, and then wraps that in another IP header for transport across the physical network.
The outer IP header will have the source IP of the GRE tunnel endpoint (192.168.1.1) and the destination IP of the other GRE tunnel endpoint (192.168.2.2). The GRE header itself contains information about the protocol being carried (IP in this case) and other optional fields.
To see this properly in Wireshark, you need to tell it that GRE traffic is expected. You can do this by right-clicking on a GRE packet in the packet list, selecting "Protocol Preferences," and then choosing "GRE." You might need to specify the protocol type if it’s not automatically detected.
Once Wireshark decodes the GRE, the view changes dramatically. You’ll see the outer IP header, then the GRE header, and then the original IP packet (the ping in our example) nested inside.
Frame 1: 102 bytes on wire (816 bits), 102 bytes captured (816 bits)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.2.2
...
0100 .... = Version: 4 (IPv4)
.... .... 0100 = IHL: 5 (20 bytes)
...
Protocol: GRE GRE (47)
...
Generic Routing Encapsulation
Flags: 0x0000 (00000000)
Protocol Type: IPv4 (0x0800)
...
[Nested Packet]
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.2.10
...
Internet Control Message Protocol: Echo (ping)
...
This is crucial for understanding what’s happening inside the tunnel. You can now apply Wireshark’s powerful filtering and analysis tools to the original traffic, not just the tunnel encapsulation. For instance, to see only the original IP traffic within GRE tunnels, you can use the display filter: gre.protocol == 0x0800.
The key problem GRE tunnels solve is extending a private network across a public one, or creating secure tunnels. The GRE protocol itself doesn’t provide encryption; it just encapsulates packets. You’d typically layer IPsec on top for security.
The "magic" of GRE in Wireshark is its ability to intelligently de-encapsulate. When it sees an IP packet with Protocol 47 (GRE), and it has been configured to understand GRE, it automatically parses the GRE header and then presents the payload as a nested packet. This is what allows you to filter and analyze the inner traffic as if it were directly captured.
A common misconception is that GRE is inherently slow. While it adds overhead due to the extra headers (IP + GRE), the performance impact is often less significant than feared, especially with modern hardware offloading. The real challenge is managing and troubleshooting the traffic within these tunnels.
The counterintuitive aspect of GRE analysis in Wireshark is that the packet you see first on the wire, and that your interface might initially identify, is not the packet you’re ultimately interested in. It’s the wrapper. Wireshark’s ability to "unwrap" it, based on protocol type and configuration, is what makes analysis possible. You’re not just looking at what the tunnel is, but what it’s carrying.
The next challenge you’ll encounter is analyzing traffic that’s been encapsulated multiple times, perhaps GRE within GRE or other tunneling protocols layered on top.