Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have been able to make a phone calls using the SIP client Pjsua from one Linux computer to another one. In case you have not heard of this user agent, explaining it's functionality is quite easy. It uses IP and port number of each linux to create a unique ID and then calling to this specific ID is possible.

Now I have not studied port forwarding thoroughly but I suppose what it does is to forward whatever data that comes in, to another "port" or "IP and port".

So I thought to myself, if my calling application is using ports and IPs to send and receive voice, I should be able to forward those specific ports to a second or third port (or IP and port) and listen to the conversation on a third computer.

So here is what I did.

Supposing that machine Linux A has the following identification info:

IP:192.168.1.11`  `UDP port# : 1111

The second machine Linux B has the following identification:

IP:192.168.1.22`  `UDP port# : 2222

If I do the following using iptables I should be able to hear that side of the conversation which is being received on Linux B on a 3rd system, Linux C .

The third machine, Linux C has the following identification info:

IP:192.168.1.33`  `UDP port# : 3333

To achieve this, I tried running this command on Linux B:

$ iptables -t nat -A PREROUTING -p udp --dport 2222 -j DNAT
--to-destination 192.168.1.33:3333    //forward port 2222 to Linux C on port 3333

And ran this command on Linux C:

$ aplay | nc -l -u 3333     //listen on the specified UDP port 

However I don't hear anything on Linux C.

Can anyone tell me why this is not working? Other strategies to do something like this are also welcome.

share|improve this question
    
You have a misunderstanding of port forwarding. Port forwarding redirects packets, it does not copy or mirror them. If you succeed in the forwarding you are attempting, the third pc will get packets, but the other pc will not. Additionally, the protocol will probably be broken since the real destination PC will not be getting anything from the source. You need something that will copy packets and send the copies to the third pc. Essentially a man-in-the-middle attack on the protocol. –  casey Jan 3 at 20:28
    
@casey well it would not be a problem if the second PC didn't get any of the incoming traffic , if it only redirected it , it would be sufficient. Think of situation where a headset was connected to a cellphone. it would not be important to get voice at cellphone, it would be enough to hear them on the headset. –  fer y Jan 3 at 20:35
    
@fery If you want C to handle the call you would need to be redirecting traffic to a full client on C and also rewriting the source address on the return traffic to A. Then you have to ask yourself why, as you could just run a SIP registered client on C and do the comms directly. –  mtm Jan 3 at 21:02
    
@mindthemonkey I know you would certainly ask yourself why is he one to call B and then forward it to C, why not call C directly. the case here is like a call in a vehicle.A is the caller , B is the cellphone and C is the Wi-Fi call handler of the vehicle.Car cannot connect to the caller directly because it has not access to the network(has no SIM ) and it has to connect through the cellphone –  fer y Jan 3 at 21:12
    
@fery in that case C would be on a separate subnet and B would be the gateway between the two networks A - B - C. You would need to fully NAT the connection via B or use an RTP proxy to forward the data between the two networks. –  mtm Jan 3 at 21:51

1 Answer 1

NAT port forwarding will redirect the packets rather than duplicate them. In your example, the call traffic should not even arrive at the application layer on B:2222 but be redirected straight to C:3333.

You probably want to look at the TEE target for iptables and do the duplication on an intermediate host along the network route from A.

        C
      /
A - X - B

On X, duplicate the packets:

iptables -t mangle -A PREROUTING -d B -p udp --dport 2222 -j TEE --gateway C

On C, redirect the duplicated traffic to the local listener:

iptables -t nat -A PREROUTING -d B -p udp --dport 2222 -j DNAT --to-destination C:3333

The reason for the intermediate host is that usually linux won't let you mess with the route for traffic destined for a local interface. I've not tried this TEE setup specifically but normally traffic for a local interface will short cut routing rules so will never make it out to --gateway C. I'm assuming you would hit the same issue with the TEE trying to route traffic for B out but ymmv.

The next problem may be the application itself. Are you sure the protocol supports simply tapping onto and playing the duplicated network stream? If the RTP stream can be picked up by aplay on C, then it looks like you have your pipe the wrong way around as well. You want nc to pipe into aplay.

nc -l -u 3333 | aplay
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.