I need to route packets coming from a standalone switch port which is a mirror ("tap") of another port ("source"). I can't seem to forward packets whose MAC address is for a different device (the actual "target" of "source"). My device is in promisc mode, I can see the incoming packets in tcpdump and Wireshark. The only packets which get forwarded are those which have my MAC destination address (I changed the wiring to come straight from source and not the mirror port, to get "my" MAC address in the packet). My routing table is configured to forward and I have ip_forwarding enabled, obviously (otherwise packets sent to my MAC wouldn't route). By the way, the incoming packets are all VLAN tagged and I have matching subinterfaces.
Q1 - is this inherent, that packets won't get "passed up" to the IP layer unless the MAC addresses match?
Q2 - Would ebtables be a good solution, i.e. rewrite the dest MAC address to my own MAC addr and send to the INPUT target?

Why would you want to forward this data you are collecting promiscuously? By design a mirrored port is like a spy sitting on a perch it never does anything, just observes. Further in the LAN MAC addresses are very important and are a inherent part of the network. It is how things get routed in the network if a local IP address is requested an arp request is sent out and a MAC address matching that IP is received back, hopefully, then the data is sent. The switches, etc... have an arp MAC table that they have built which tells the switch what port to send the data out to in order for it to get to the recipient. A mirrored port shouldn't send anything for a specific machine out on it.

Thanks for replying, I understand your puzzlement over my questions. You actually answered your own question sort of. This is a traffic monitoring application, packets from the mirrored port are being routed to analysis equipment elsewhere in the network. Because they were originally destined for another device, the MAC addresses do not match the router they are being monitored by. I tried ebtables, following some ideas on http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html. I managed to redirect (rewrite actually) the ingress MAC addresses to that of the monitoring device, but they still don't get routed for some reason. I tried various approaches including using brouting and nat. I am still hoping for an answer to my questions.

I am not familiar with routing the traffic like this through another machine to a monitoring machine. I have always run my monitoring directly connected to the port that is mirrored As I understand networking you can't really re-route that data, you could capture it like Wireshark and send the captured packets to another machine for analysis. I don't think what you are trying to do is going to work.If I get you right you are wired like this:

All monitoring setup I have ever seen or heard of are wired like below:
I suppose you could try bridging the promiscuous NIC and the LAN NIC on the PC with an iptables forward all rule for the bridge. Lackign that you may want to take a look at iproute2 I still don't think it will do what you want, but it is much more advanced than the standard tools. Most Kernels all ready support it and most distros have the package with the iproute tools.

Thanks again, I solved it finally. Here is the correct diagram. My problem was there was no route specified for the return path to the port mirror. Even though no packets will ever get received by the mirror, my promiscuous router" would not forward pings from the mirror port without knowing how to send them back I guess. I ended up using ebtables broute table and its BROUTING chain to "redirect" the mac addresses of incoming packets to the physical device on my machine. Interesting lesson.

Here's how to rewrite the incoming MAC addresses to match eth0. eth0 has to be bound to a bridge device even if the bridge has no other devices. This allows ebtables to hook into it.

ifconfig eth0 X.X.X.X
brctl addbr br0
brctl addif br0 eth0
ip link set br0 up (or ifconfig br0 up)
ebtables -t broute -A BROUTING -i eth0 -j redirect --redirect-target DROP
ip route add y.y.y.y dev eth0 (have to do for all expected incoming addresses/subnets)

The missing step for me was the last one.

The second to last last command "broutes" all packets to the IP stack after first modifying the incoming MAC addresses to eth0's. so we can accept them.

Interestingly, eth0 doesn't even have to be explicitly in PROMISC mode, the redirection seems to take care of it. I find this odd since I'd expect the NIC (programmed in non-promisc) would drop packets not bound for me in this case before the redirect rule can take effect.

Glad you got it worked out, and I learned something new today. Don't forget to mark the thread solved so that anyone else trying to do this can come across the thread and learn how to do it.

May this solution not work?
In my scenario I dont see packets forwarded..