netdev - GPE traffic gets stuck between ppp and br0 interface, ipv4 traffic works fine, ideas?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 13 Oct 2021 22:00:55 +0200
From:   Jelle de Jong <jelledejong@...ercraft.nl>
To:     netdev@...r.kernel.org
Subject: GPE traffic gets stuck between ppp and br0 interface, ipv4 traffic
 works fine, ideas?

Hello everybody,

I am trying to add an GPE tunnel over a fully working IPv4 setup and I 
am having the issue that the GPE packages get stuck on the Debian 
modem/router at ppp0 (package visable) and the br0 (package gone)

I have setup two virtual machine both with an external ip address, 
without firewall and I have setup an standard GPE tunnel between the two 
for testing. One virtual machine is in a data centre the other one is at 
our office server room.

uplink fiber -> switch -> bond0 -> vlan6 -> ppp0 -> br0 -> vlan34 -> 
switch -> bond0 -> br0 -> eth0 (virtual machine).

I can ping both virtual machines on there external IP address just fine 
and I dont have any other issues with this setup and it has been stable. 
I wanted to add a GPE tunnel as I need to route extra IP address in the 
future.

So I got a ping running on both machines, but they do not get a reply back.

When looking with tcpdump I see both the incoming ICMP request (the one 
from the data centre, ends at ppp0 on our xs4all Debian modem (its uses 
ppp to get the external ip addr).

Then the ICMP request from our virtual machine nicely makes it to our 
bridge on our xs4all Debian modem, but then stops and does not go out 
our PPP interface with the external ip addr.

I have added full information in the attachment.

root@...all:~# tcpdump -i ppp0 proto 47 and ip[33]=0x01 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 
262144 bytes
18:43:50.046573 IP 185.87.185.190 > 80.127.158.82: GREv0, length 88: IP 
10.0.0.1 > 10.0.0.2: ICMP echo request, id 5137, seq 1347, length 64

root@...all:~# tcpdump -i br0 proto 47 and ip[33]=0x01 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:44:07.293275 IP 80.127.158.82 > 185.87.185.190: GREv0, length 88: IP 
10.0.0.2 > 10.0.0.1: ICMP echo request, id 31130, seq 821, length 64

root@...all:~# sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_use_pmtu = 0

/sbin/iptables --append FORWARD --protocol GRE --in-interface br0 
--out-interface ppp0 -j ACCEPT
/sbin/iptables --append FORWARD --protocol GRE --in-interface ppp0 
--out-interface ppp0 -j ACCEPT

What am I missing? How come the GPE data is not routed like the ipv4 
data is? Any ideas how to fix my issue?

Much appreciated.

Kind regards,

Jelle de Jong

View attachment "debug-gre-2021-10-13.txt" of type "text/plain" (11085 bytes)