Traffic mirroring with tc over GRE Tunnel only gets ingress Traffic

Question

i am trying to mirror "all" network traffic from one interface with the help of tc trough an GRE-Tunnel tun0. The GRE-Tunnel is working fine, i can ping and send packets trough it without any problems. I added the tc-qdisc and tc-filter with the following commands:

tc qdisc add dev ens5 ingress

tc filter add dev ens5 parent ffff: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0

and

tc qdisc add dev ens5 handle 1: root prio

tc filter add dev ens5 parent 1: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0

like in this Tutorial

Problem

The Problem is that only ingress traffic is coming through the GRE-Tunnel. When i ping another computer over interface ens5 than i only get the icmp echo replies through the tun0 interface. What am i doing wrong?

Debug

ubuntu@switch:~$ tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:23:28.952197 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 1, length 64
10:23:29.954454 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 2, length 64
10:23:30.952864 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 3, length 64
10:23:31.953207 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 4, length 64
10:23:32.955350 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 5, length 64
10:23:33.957000 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 6, length 64
10:23:34.956313 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 7, length 64

Answer 1

Solved the Problem by myself.

tc mirrors the egress traffic with the Ethernet-Header and the ingress traffic without Ethernet-Header The GRE-Tunnel expects only IP-Packets, so there was an header-mismatch. If i am using VXLAN instead of GRE it works fine.

Answer 2

I never worked with GRE-Tunnels, but based on the Tutorial link you posted, it has something to do with bridge interfaces? I'm currently also working with Linux Traffic Control (tc) on a bridge interface - in my case it is a bridge created by Docker and I have to manipulating the traffic (not only redirecting it).

Based on my experience, I can tell you that tc is not working like expected when you are adding tc classes/filters to a bridge interface. It is mostly based on the definition of ingress and egress traffic on a bridge, which is (for me) very confusing. I also tested my configuration of tc with the ICMP-Ping functionality and like you I was also only able to manipulate the ICMP reply.

My assumption was that tc is not reacting to the ICMP request, as in my case, it was only switched between the bridge ports and not routed. I was able to handle the ICMP request with tc by dropping it with the ebtables (http://ebtables.netfilter.org) and therefore forced it to being routed instead of being switched between the bridge ports.

Still I’m not sure if this will be the solution to your problem, as I’m not sure how GRE-Tunnels work, or how they are implemented.