netdev - Re: Packet not rerouting via different bridge interface after modifying destination IP in TC ingress hook

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: <20200805133922.GB1960434@lunn.ch>
Date:   Wed, 5 Aug 2020 15:39:22 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Swarm NameRedacted <thesw4rm@...me>
Cc:     netdev@...r.kernel.org
Subject: Re: Packet not rerouting via different bridge interface after
 modifying destination IP in TC ingress hook

On Wed, Aug 05, 2020 at 08:19:57AM +0000, Swarm NameRedacted wrote:
> Hi,
> 
> I am trying to build a quick script via TC direct action and eBPF to
> modify the destination IP of a packet so that it is routed through a
> different bridge interface. Made a quick network diagram below to
> demonstrate it. 
> 
>       Packet (dst: 10.10.3.2)
>                 |
>                 |
>     ingress - (change dst to 10.10.4.1)
>                 |
>                 |
>                eth0
>                 |
>                 |
>       br0 - (addr: 10.10.3.1)
> __eth0______   ___ens19_______
>      |                |
>      |                |
>      |                |
>      |                |
> host: 10.10.4.1  host: 10.10.3.2
> 
> 
> 
> As shown, I send a packet from a separate client to eth0. eth0 is the
> WAN interface of its machine and ens19 is the LAN interface; both are
> connecting with bridge br0. Without modification, the packet goes
> straight through ens19 to 10.10.3.2. 
> 
> Theoretically, by modifying the destination IP to 10.10.4.1 at ingress,
> the packet should be rerouted to go back through eth0. However, in
> practice, I find that the packet still goes through ens19 after
> modification, and of course after that it never reaches anything. 
> 
> Why is it that ingress catches the packet before the bridging decision,
> but the packet isn't rerouted? Is there a better way to do this?

What is not clear is the subnet size. Is this all a /16 network? So
that 10.10.4.1 and 10.10.3.2 are in the same subnet? Or are these
different subnets, and you have a router somewhere you do not show in
your diagram? Is this redirect happening at L2, or L3? Maybe you even
have NAT involved, since you talk about WAN and LAN? Do you also need
to be modifying the destination MAC address?

You also need to think about at what layer in the stack is the IP
address being modified? A bridge works on L2. Is the packet being
bridges at L2 and sent out without an IP processing at L3? Do you
actually want to be using ebtables to modify the packet at L2?

But maybe take a step back. You are wanting to do something really
odd. What is your real use case. Maybe there is a better way to do
what you want. Please explain why you want to send a packet back out
the way it came in, with a different IP address.

	 Andrew