Decapsulation ERSPAN Traffic With Open Source Tools

Cisco Encapsulated Remote SPAN (ERSPAN) feature allows to monitor traffic on one or more ports and send the monitored traffic to one or more destination ports.  Traffic is encapsulated into GRE tunnel and routed via network to ERSPAN destination. Any device that supports ERSPAN can be used as ERSPAN destination. It might be another Cisco device or Linux with installed software that can decapsulate GRE traffic.

The goal of this article is to show methods and tools for decapsulation of  ERSPAN traffic. For this purpose I have built simple lab that consists of a Cisco CSR 1000v router and two Linux boxes. Core Linux represents a network host and generates network traffic (ICMP) that is going to be monitored. It is connected to the port GigabitEthernet1 of the Cisco router. The router is configured to monitor traffic on the port Gi1 and it sends traffic encapsulated in GRE tunneling protocol to IP address 10.230.10.1. It is the IP address of the ERSPAN destination configured on Linux  Security Union. Security Onion is a unique Linux distro for intrusion detection, network security monitoring, and log management based on Ubuntu however any other Linux distro can be used.

Picture1_Toplogy

Picture 1 - ERSPAN Lab Topology

Below is an example of ERSPAN configuration on the CSR 1000v router. This is the source ERSPAN type and with configured rspan_id 1. The interface Gi1 is being monitored and the GRE traffic is sent to ERSPAN destination address IP 10.230.10.1.

CSR1000v# show running-config | b monitor
monitor session 1 type erspan-source
description ERSPAN to 10.230.10.1
source interface Gi1
destination
erspan-id 1
mtu 1464
ip address 10.230.10.1
origin ip address 10.230.10.2

You also must issue the command no shutdown after the command monitor session 1 type erspan-source in order to activate session.

1. Capturing ERSPAN Traffic with Wireshark

We are going to capture and analyze ERSPAN traffic with Wireshark packet sniffer. First configure IP address 10.230.10.1 on interface eth1 of the Linux Security Onion.

janosik@onion:~$ sudo su
root@onion# ip address add 10.230.10.1/24 dev eth1

Now use Wireshark to capture GRE traffic on Security Onion on its interface eth1 and ping the router IP address 192.168.1.2 from the Linux Core host (IP 192.168.1.1). If the source ERSPAN is properly configured on router, packets from the subnet 192.168.1.0/24 should appear in Wireshark output.

A closer look at the picture below reveals that the original packet ICMP packet (MAC header, IPv4 header and ICMP header) is now encapsulated as following.

MAC header + IPv4 header (10.230.10.2, 10.230.10.1) + GRE header (Protocol type ERSPAN) + ERPAN header + (original packet)

Picture1_Wireshark_Capture

Picture 2 - Encapsulated GRE Traffic Captured on Interface Eth1

An original ICMP packet is encapsulated into GRE tunnel and the new outer MAC and IPv4 + GRE + ERSPAN headers are added to original packets. It allows encapsulated traffic to be forwarded through network to ERSPAN destination. However if we want software application such as IPS/IDS to analyze encapsulated packets, the outer L2 and L3 headers must be striped from packet. This can be done with tools such as RCDCAP  which dissects packets from GRE tunnel.

2. Configuring GRE tunnel on ERSPAN Destination Device

If for some reason we do not want to install special software that dissects packets from GRE tunnel we can configure GRE tunnel on ERSPAN destination (Linux Security Onion) and let IDS to listen on a tunneled interface. Thanks to this configuration the outer MAC and IPv4 headers are stripped and do no appear in Wireshark output.

a) Load GRE module to kernel

janosik@onion:~$ sudo su
root@onion# modprobe ip_gre

You can check if GRE module is loaded into a kernel with command below.

picture3_gre_module_loaded

Picture 3 - GRE Module Loaded Into Kernel

b) Choose receiving interface and assign IPv4 to it

root@onion# ip addr add 10.230.10.1/24 dev eth1

Set the MTU of the network interface that receives GRE packets larger than 1500 e.g. to 1900.  Otherwise we are going to miss some bytes in larger packets.

root@onion# ip link set dev eth1 mtu 1900

c) Create virtual tunnel interface and associate it with IP previously configured on eth1 interface

root@onion# ip tunnel add mon0 mode gre local 10.230.10.1 ttl 8

d) Add IP address to interface mon0 which is not used for anything

root@onion# ip addr add 1.1.1.1/30 dev mon0

e) Change the state of mon0 device to up

root@onion# ip link set mon0 up

Check status of the interface mon0 with the command below. The interface must be in UP state and the Rx counter should increase.

picture4_status_of_mon0_interface

Picture 4 - Status of  Interface mon0

Again, generate network traffic in the subnet 192.168.1.0/24 and configure Wireshark to listen on interface mon0. Notice that the outer MAC and Ipv4 header are now stripped from the ICMP packet.

Picture2_Wireshark_Capture_GRE

Picture 5 - Decapsulated Traffic Captured on Interface mon0

3. Using RCDCAP for Decapsulating ERSPAN Traffic

RCDCAP is wrapper program that dissects the traffic and creates a virtual interface where the traffic is already decapsulated. I've compiled it from the source and created the Ubuntu package RCDCap-0.7.99-Linux for Ubuntu 15.04. Be aware that additional packages are needed to get it working.

janosik@onion:~$ sudo su
root@onion# apt-get install libboost-regex1.55.0

Use apt-get to install the packages below. If they are not available in a repository  download them from here and install manually with dpkg -i command.

  •  libboost-program-options1.48.0_1.48.0-3_amd64.deb
  •  libboost-thread1.48.0_1.48.0-3_amd64.deb
  •  libboost-system1.48.0_1.48.0-3_amd64.deb

root@onion# dpkg -i libboost-program-options1.48.0_1.48.0-3_amd64.deb libboost-thread1.48.0_1.48.0-3_amd64.deb libboost-system1.48.0_1.48.0-3_amd64.deb

Now we can install RCDCAP with the command.

root@onion# dpkg -i RCDCap-0.7.99-Linux.deb

Once RCDCAP is installed configure interface eth1 to prepare for capturing.

janosik@onion:~$ sudo su
root@onion# ip addr add dev eth1 10.230.10.1/24
root@onion# ip link set dev eth1 mtu 1900
root@onion# ip link set dev eth1 up

Start RCDCAP with the command below and let Wireshark to listen on interface mon1.

root@onion# rcdcap -i eth1 --erspan --tap-persist --tap-device mon1 --expression "host 10.230.10.1"

We can see that RCDCAP have dissected monitored traffic from GRE and only original MAC + IPv4 + ICMP headers and pyaload are presented in Wireshark output.

Picture3_Wireshark_Capture_Dissected

Picture 6 - Decapsulated Traffic Captured on Interface Mon1 

End.

Reference:
http://packetpushers.net/erspan-new-favorite-packet-capturing-trick/
http://networkengineering.stackexchange.com/questions/3274/remote-sniffing-with-erspan-to-the-desktop

6 thoughts on “Decapsulation ERSPAN Traffic With Open Source Tools

  1. I am following your setup, but I am failed to decrypt the ERSPAN packet generated from VMware. any idea?

    • Paul
      I am failed too with decrypt the ERSPAN packet generated from VMware
      Because VMware does not use ERSPAN. it use only GRE tunnel

      Did anyone ever got to Decapsulating traffic from the GRE tunnel (noe ERSPAN)?

  2. Is there a way to ENCAPSULATE traffic into an ERSPAN tunnel without using a cisco device? What if I wanted to source ERSPAN traffic from a Linux host instead of a switch?

  3. Hi I've tried following the steps above for the ip_gre tunnel and no packets are being received on the end of the tunnel.

    The ERSPAN from the Cisco router is arriving at interface eno1 so I have assigned IP address a.b.c.d/x to that interface and I have added an ip tunnel using 'ip tun add eno_gre mode gre local a.b.c.d/x ttl 255'. Then added ip addr 1.1.1.1/x to dev eno_gre and set it to up. When I do ifconfig on the eno_gre interface the Rx count is 0, despite packets arriving on eno1. Anybody any ideas what I am doing wrong?

Leave a comment

Your email address will not be published. Required fields are marked *