2

Having UDP messages sent from dynamic public IP periodically to public IP X:20000.

Need a proxy that listens in IP X:20000, then forwards duplicate/clone packets to X:20001 and a different machine located in IP Y:20000. Now, when application listening on X:20001, responds to a message to X:20001, I want that message to be forwarded back to PC A, from X:20000.

How could I achieve this functionality in Linux? (trying to avoid custom script)

Trying to have one application in a headless server responding to messages, and one computer with monitor to debug messages when needed in real time.

jacktrades
  • 612
  • 3
  • 8
  • 15

1 Answers1

4

I think you could pull this off w/ iptables and the samplicator tool if you're using a new enough kernel to support the raw table.

First, why socat won't work: Teeing a packet flow with socat is fairly easy. You'd just do this:

socat - udp4-listen:20000,fork | tee >(socat - udp-sendto:X.X.X.X:20001) >(socat - udp-sendto:Y.Y.Y.Y:20000)

That duplicates the traffic to X.X.X.X:20001 and Y.Y.Y.Y:20000.

That doesn't help you, though, because the service listening on X.X.X.X:20001 is going to "see" 127.0.0.1 as the source address. That's where samplicator can help out. Quoth the samplicator Google code page:

This simple program listens for UDP datagrams on a network port, and sends copies of these datagrams on to a set of destinations. ... Another option is that it can "spoof" the IP source address, so that the copies appear to come from the original source, rather than the relay.

That sounds like exactly what we need re: the source address. (Having said that, I haven't actually tested this tool. The box I'm testing on doesn't have compilers installed and I'm not going to spin up something right now just for Server Fault. >smile<)

The last thing you'd need is to take care of the traffic coming from X.X.X.X:20001, making it appear to come from X.X.X.X:20000.

Then, to NAT the replies from X.X.X.X:20001 to "come from" X.X.X.X:20000:

iptables -t raw -A POSTROUTING -s X.X.X.X -p udp --sport 20001 -j NOTRACK
iptables -t nat -A POSTROUTING -s X.X.X.X -p udp --sport 20001 -j SNAT --to-source :20000

Beware: I haven't tested all of this together. I mocked it up with socat and it worked fine minus the source address "spoofing" that samplicator provides.

Evan Anderson
  • 141,071
  • 19
  • 191
  • 328
  • great answer. I cannot understand how udp ip source spoofing is allowed, Do internet routers allow this? – jacktrades Oct 15 '14 at 21:45
  • 1
    @jacktrades As UDP is stateless, forging the source IP is fine... BUT: a possible problem that you might run on is **egress filtering** on the network (which is considered to be good practice so expect that to be present on well configured/maintained networks). So if the recipient of the spoofed packet is in the same network (same subnet, or different subnet inside your company, etc.) that should be fine. But if the recipient is outside, the packet with a spoofed source IP will probably be filtered out, because such address would not be in the allowed range for the network. – Ale Oct 15 '14 at 21:48
  • @Ale 3 IPs are public, will this work? Do ISP routers normally allow spoofed IPs? – jacktrades Oct 15 '14 at 21:50
  • @jacktrades Generally speaking I would not assume that a ISP will allow packets with spoofed IP addresses (as this is the way some attacks work, e.g. a DNS amplification attack). And even if the packets go trough, the practice might actually be forbidden by the agreement you have with your ISP. So if you really need to spoof IP addresses for your application, check with your ISP if it can be done. – Ale Oct 15 '14 at 21:55
  • 1
    @jacktrades Actually one possibility to make that work, as you control both sides of the thing: you might encapsulate your spoofed packets in a IP tunnel (e.g., see http://lartc.org/howto/lartc.tunnel.ip-ip.html) you create between the machines. The egress filter will not look inside your tunnel (as it is just data), so you can send whatever you want over it, even spoofed UDP packets. – Ale Oct 15 '14 at 22:04
  • @Ale - Tunneling the spoofed UDP... heh heh... This is getting to be a lot of plumbing. – Evan Anderson Oct 15 '14 at 22:04