How to change destination-IP from packets through iptables?

Question

I managed to duplicate the data through: Sudo iptables –t mangle –A PREROUTING –p udp –d 192.168.2.100 –dport 53260 –j TEE –gateway 192.168.2.80

Linux at 192.168.2.80 receives the packets, however the destination is still 192.168.2.100, but the MAC-Address is correct. I need the destination IP changed to 192.168.2.80 too though in order for my application to work.

I tried DNAT/NETMAP, however couldn't really get it work.

Sudo iptables –t nat –A OUTPUT –destination 192.168.2.130 –j DNAT –to-destination 192.168.2.100 - works, but the problem is packets are not duplicated, so I don't have the packets on my first device. They get forwarded this way.

Thanks in advance.

Edit: (additional information)

The setup is the following: A display and a camera are connected through a switch and the camera streams via udp unicast.

I have to implement a videorecorder which gets connected to the switch. As i was a total newbie when I started I realized/tried multiple things.

• Port Mirror the camera through the switch and connect recorder to Port mirror (Problem: destination ip/mac are different than the recorder device, so I only see the packets on the interface level but don't receive them in my application)

• iptables (this question: Problem: different destination ip-address)

• capturing packets through tcpdump/tshark -> extract payload -> gstreamer -> very inefficient and a lot of steps

• I've also turned on promiscous mode (as I've read that destination addresses do not matter, but still couldn't receive the packets in my application, doublechecked with "netstat -s -u" where I don't get udp packets either)

In order for my setup to work both the display and the camera need to receive the same UDP packets with the respective ip/mac of their own.

UPDATE: After recommendation I tried socat. These are the problems I'm facing here.

socat - udp4-listen:53260,fork,reuseaddr upd4:192.168.2.100

This works perfectly fine to redirect the packets with correct dest ip & mac, no lag.

When I tried the following:

socat – udp4-listen:53260, reuseaddr | tee >(socat – udp-sendto:192.168.2.100:53260) >(socat - udp-sendto:192.168.2.80:53265)

Both streams work with correct dest-ip/mac, but the streams are very stuttery.

The difference from iptables TEE and socat TEE I noticed was the following: socat TEE sends some "Fragmented IP protocol (proto=UDP, off=0, ID=3a96)" packets, which reassembles the UDP packets as far as I've read and consequently the delay after these packets to the next packet is around 15ms, when it's usually 1-3ms.

The delay is still very short, but the only reason I can think of why it's stuttery.

The packetcount which are sent and received are approximately the same. Any ideas how to solve this?

Answer 1

Partial answer:

DNAT only works in the PREROUTING chain, so you need to do DNAT on the machine at 192.168.2.80 (or in separate network namespace). I do not know why this is the way it is, and yes, it's sometimes a pain.

But I'd also question your use case. TEE is fine for logging etc. on a separate machine, but if you want to split a packet into two packets with different destinations, whatever you want to run atop of this is probably going to be fragile, and it will break easily.

Multicasting exists, as do proxies, or load balancers.

---

The aim is to configure a camerrecorder on a unicast setup. So multicasting is sadly not an option. I haven't read into proxies/load balancers, are those an option for me?

(Please add this information to your question the next time - always provide context. And have a look at the XY-Problem).

For using socat to convert UDP unicast to broadcast, see e.g. this question.

For using socat with a multicast destination, see e.g. here.

If your receivers cannot handle multicast, you can also do the "tee" operation in socat.

Alternatives would be to use something that operates on a streaming protocol level, like ffmpeg.

And there are probably a lot more applications you can use as a proxy, search a bit.

What is best depends on the protocol your camera uses.