Network-Encapsulation-GRE

Network Encapsulation & GRE Tunnelling

Module: COMP10014 — Network Security | University of the West of Scotland
Topic: GRE Tunnel Configuration (Linux Kernel & OpenVSwitch), Packet Encapsulation Analysis

---

Objective

Create and analyse GRE (Generic Routing Encapsulation) tunnels using two approaches: native Linux kernel GRE and OpenVSwitch (OVS). Inspect encapsulated traffic using Wireshark to understand packet structure at each layer.

---

Tools Used

Tool	Role
ip tunnel	Linux kernel GRE tunnel management
OpenVSwitch (ovs-vsctl)	Software-defined virtual switch with GRE support
Wireshark	Deep packet inspection of encapsulated traffic
netcat (nc)	TCP/UDP traffic generation through tunnels
ping	ICMP traffic generation

---

Lab Environment

[Client VM]  10.0.1.2  ←→  [Router VM]  ←→  [Server VM]  10.0.2.2
GRE tunnel endpoints:
  Linux GRE:  tunnelgre — Client 10.200.0.100 ↔ Server 10.200.0.200
  OVS GRE:    br2       — Client (OVS bridge)  ↔ Server (OVS bridge)

---

Part A — Linux Kernel GRE Tunnel

Configuration

Created point-to-point GRE tunnel interfaces using the Linux ip tunnel command on both VMs:

• Client: tunnelgre assigned 10.200.0.100/24, remote endpoint 10.0.2.2
• Server: tunnelgre assigned 10.200.0.200/24, remote endpoint 10.0.1.2

L3 connectivity verified by pinging across the tunnel (10.200.0.100 ↔ 10.200.0.200).

Packet Analysis (Wireshark on Router VM)

Captured and inspected encapsulated traffic for three protocol types:

Protocol	Outer IP Protocol field	GRE Protocol Type	Inner Protocol
ICMP	47 (GRE)	0x0800 (IPv4)	1 (ICMP)
TCP	47 (GRE)	0x0800 (IPv4)	6 (TCP)
UDP	47 (GRE)	0x0800 (IPv4)	17 (UDP)

Key observation: The outer IP header always shows protocol 47 — this is the IANA-registered number for GRE. The original protocol (ICMP/TCP/UDP) only appears in the inner IP header after GRE de-encapsulation.

GRE operates as a Layer-3 tunnelling mechanism — it encapsulates IP packets directly, without including an inner Ethernet header. This is why the GRE payload begins at the network layer, not the data link layer.

---

Part B — OpenVSwitch GRE Tunnel

Configuration

Installed OpenVSwitch on both Client and Server VMs and created virtual bridge interfaces (br2) with GRE ports connecting the two VMs.

IP addresses assigned to bridge interfaces:

• Client br2: 10.200.1.100/24
• Server br2: 10.200.1.200/24

Connectivity verified via ping across the br2 interfaces.

Packet Analysis Differences (vs Linux GRE)

Field	Linux Kernel GRE	OpenVSwitch GRE
Outer Protocol	47 (GRE)	47 (GRE)
GRE Protocol Type	0x0800 (IPv4)	0x6558 (Transparent Ethernet Bridging)
Inner header	IP header	Ethernet frame

Key distinction: OVS operates the GRE tunnel in Layer-2 bridging mode — it encapsulates entire Ethernet frames rather than raw IP packets. The GRE Protocol Type value 0x6558 signals Transparent Ethernet Bridging, meaning the tunnel behaves like a virtual Ethernet link between the two bridges.

---

Key Findings

• GRE always adds an outer IP header with protocol 47, regardless of the payload type.
• Linux kernel GRE is a pure Layer-3 mechanism; OVS GRE operates at Layer-2, transporting Ethernet frames.
• Multiple GRE tunnels can coexist between the same endpoints provided they use unique interface names, tunnel keys, or endpoint configurations.
• The GRE header Protocol Type field (0x0800 vs 0x6558) is the primary indicator of whether the tunnel is L3 or L2 mode.

---

Security Takeaways

• GRE tunnels provide encapsulation but no encryption — traffic inside the tunnel is fully readable.
• In security-sensitive deployments, GRE is typically combined with IPsec to add confidentiality and integrity.
• Understanding GRE encapsulation is foundational for analysing VPN traffic, SD-WAN architectures, and network forensics.

---

Disclaimer

All testing was conducted exclusively within an authorised VirtualBox academic lab environment. No real networks or third-party systems were targeted.