netdev - Re: Routing in case of GRE interface under a bridge

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZJ24XsOnpKZFna/d@shredder>
Date: Thu, 29 Jun 2023 19:59:10 +0300
From: Ido Schimmel <idosch@...sch.org>
To: Nayan Gadre <beejoy.nayan@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: Routing in case of GRE interface under a bridge

(Please avoid top-posting).

On Thu, Jun 29, 2023 at 09:00:21PM +0530, Nayan Gadre wrote:
> Yes, the l2gre0 on System A and System B is a gretap created using
> following command
> 
> ip link add l2gre0 type gretap remote 192.168.0.10 local 192.168.0.103
>             --> and vice versa on System B.
> 
> On system A, l2gre0 and eth0 are under a bridge br0. l2gre0 does not
> have an IP address.

That's OK. It's meaningless to assign an IP address to a bridge port.

> On system B, l2gre0 is independent but has IP address 10.10.10.1, and
> a DHCP server is running on it providing IP to clients connected
> through the tunnel.
>                       System A
>  |                               System B
>                                             192.168.0.103            |
>                      br0                         br1
>     |                        eth0
> l2gre0
>            eth0           l2gre0            eth1                     |
>                   192.168.0.10                        10.10.10.1
> 
> On system A:
> / # ip r
> default via 192.168.0.10 dev br1.1
> 169.254.0.0/16 dev br1.1 proto kernel scope link src 169.254.32.107
> 192.168.0.0/24 dev br1.1 proto kernel scope link src 192.168.0.103
> 
> On system B:
> ngadre@...1-7h4wrf3:~$ ip r
> default via 10.110.234.254 dev eno1 proto dhcp metric 100
> 10.10.10.0/24 dev l2gre0 proto kernel scope link src 10.10.10.1
> 192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.10
> 
> As we can see, on System B there is a route pointing at l2gre0.
> However, there is no such route on System A. Yet the packet gets
> encapsulated
> A client connected to eth0 on System A sends packet with destination
> 10.10.10.1 (def gateway). So I am guessing l2gre0 receives this packet
> since it gets flooded by br0 and even though System A not having a
> route to 10.10.10.0/24 it will encapsulate.

The overlay IP address is irrelevant. System A does not inspect it, it
simply forwards Ethernet frames (based on DMAC) between both bridge
ports - eth0 and l2gre0.

As to whether it gets flooded or not, it depends on the DMAC of the
frame received via eth0 and the FDB of br0. I expect the DMAC to be the
MAC of l2gre0 on system B. You can dump the FDB on system A using the
following command:

# bridge fdb show br br0 | grep master

> Is this the behavior in case of a bridged tunnel interface ?.

This is the encapsulation flow on system A as I understand it from your
data:

1. Ethernet packet is forwarded by br0 from eth0 to l2gre0.

2. l2gre encapsulates the Ethernet packet with
{sip=192.168.0.103,dip=192.168.0.10,ip_proto=0x2f,gre (proto=0x6558)}

3. Encapsulated packet is routed out of br.1 that has the most specific
route of 192.168.0.0/24 towards 192.168.0.10