(This is a simplified version of this: Can Linux do "source MAC based routing?")
I have an appliance that needs to route egress packets back to the MAC interface where the ingress packets were received. This is considered "source-MAC based routing" or "return-to-sender" since only the source MAC address will be used to determine where to send the packets. The Layer 3 IP addresses and Layer 4 ports will not be able to identify the correct next hop.
The network flow will look like this:
client1
| NET-A
v 1.
+---------+ 2. +---------+
| | ----> | |
| router1 | NET-B | myapp |
| | <---- | |
+---------+ 3. +---------+
| NET-C
v 4.
server1
There will be several instances of the router (router1, router2, router3, etc), and myapp (which is a transparent proxy meaning it does not alter the L3/L4 components) needs to choose the correct router instance to return the packets to. myapp can't do normal destination-based routing since the L3 destination will not identify which router sent it the traffic in the first place.
I'm hopeful that nftables will be able to do this, but I have very little experience with nftables (much more with iptables, but so far it seems inadequate). Here is my pseudo logic for myapp with eth0 connected to NET-B
Packet inbound on eth0
- Is packet part of a previously seen flow?
NO: Map this L3/L4 flow to the source MAC and continue to step 2
YES: Continue to step 2
- Process packet and send packet out
Packet outbound on eth0
Look up flow in table to find the target MAC
Forward packet to the target MAC
Is this something nftables can do? Any pointers on getting started are appreciated.