IIRC ebtables only works for bridges. He probably needs to use nftables (to set ct mark based on ethernet addresses and set meta mark (i.e. fwmark) based on the ct mark for the replies). I think a new table (and a different set of the two marks) are needed for each of the MAC address. Is this for dealing with conflicting IP subnets?

Thanks, I'll look into ebtables. I have a proxy connected to the router's eth1 that will operate on the packets before returning them back to the router's eth1 interface.

It's not for dealing with conflicting IP subnets, but for dealing with transparent proxies before my router, where the IP address of the proxies will not be known, but the source MAC addresses will be used to know which instance of the proxy to return the traffic to.

I added an EDIT to my initial post to illustrate why I need the source-mac based routing

Thanks A.B, I've added some IP addresses and more detailed network flow. The routing tables in the OP are an attempt to solve part of the routing, but are not necessary if there is a better way. myproxy will use tproxy or a similar strategy to intercept the traffic, like what is described here: blog.cloudflare.com/how-we-built-spectrum. My main hurdle now is getting myrouter to route back to the correct instance of routerA, since the L3/4 will not indicate which routerA instance to use, but only the L2 MAC where the ingress traffic was received from.

I should also mention that myproxy does not necessarily need to receive the the L3/L4 of the original packet. myrouter could masquerade or otherwise NAT the traffic to myproxy as long as myrouter uses the original L3/4 when it returns traffic to routerA. I don't know if that simplifies or complicates things, but it's not a strict requirement.

Sorry about the initial post having "mygateway" as the via. I hadn't settled on the name "myproxy" yet, and just recently caught it.

Correct, every client will have a unique IP. It may use any one of the available routerAs, but only one. I.e. one client will not use multiple routerAs.

The 3rd point is the crux of my question. How to have nftables store the IP:MAC from the ingress so it can use that MAC for the egress. The rest of my setup I think I will be able to handle once I get that. Is that something you can help me flesh out?

Also, what feature from Linux kernel 5.16 would help with the egress?

Let us continue this discussion in chat.

Reformulate your question with a simpler problem matching ONLY "source MAC based routing" without having a router traversed multiple times for the same packet (or transparent-proxied packet). Currently, RAx sees the same packet twice in the query, and twice in the reply because it also routes the server. That's just an additional problem in the way of the "source MAC based routing" and if I give an answer, I feel compelled to have it working but not to solve multiple other problems (if they are solvable).

btw: I deleted some other comments and did add some information in the chat.

I'm trying to think how I can simplify the issue. routerA is necessary because it does not own the source IP or destination IP, so its MAC address is the only distinguishing component from the perspective of myrouter. Its existence is the reason I need the source MAC routing. I'm fine with excluding the return traffic from the server.

We could say that return traffic will not route through myrouter, but only through routerA. routerA is proprietary/closed-source, and it will handle seeing the same packet twice. I'm only focused on the "myrouter" part of the equation, to get it to route the packets back to routerA based on the source MAC.

I think if I can understand how to use nftables to map a flow of traffic to the source MAC it originated from, and use that MAC for the forwarding of packets, I can get the rest to work.

I added a couple of items to the end of the post to hopefully reduce the scope.

I feel like knowing how to implement this would greatly help:

I've reformulated a simpler question here: superuser.com/questions/1714551/…