Telegram calls via Dante socks5 proxy server not working

Question

I've confugured Dante 1.4on Ubuntu 16.04 as a socks5 proxy for Telegram.

Chats are working, but voice calls are not, failing at "Connecting".

Is there something special I need to configure in order to proxy Telegram voice traffic?

I'm using a single non priveleged (>1024) TCP/UDP port + login + password for connection.

Thanks!

UPD: Thats piece of log while i am trying to call somebody:

Apr 15 23:05:38 (1523736338.510915) danted[22977]: info: pass(1): udp/udpassociate [: username%[email protected] 192.168.1.30.36562

Apr 15 23:08:33 (1523736513.020190) danted[22989]: info: pass(1): udp/udpassociate [: username%[email protected] 192.168.1.30.49065

I can answer the call at destination device but connection is looping and getting error after 30 seconds.

Answer 1

Proxying UDP with socks is a bit more complex than it might seem, so let's start from the beginning.

Telegram calls use UDP with socks. Socks5 RFC1928 defines the following sequence for relaying UDP:

1. Client instantiates a TCP socks5 connection.
2. Client sends a UDP ASSOCIATE request, containing the client's source address and port, which will be used to send UDP datagrams to the socks5 Server. They might be zeros (in Telegram they are) (section 4).
3. Socks5 Server binds a random UDP port for relaying datagrams for this TCP socks5 connection and sends a UDP ASSOCIATE response, containing the address and port where the client should send the datagrams to be relayed (section 6).
4. To send a datagram, the Client must add a header to the payload, containing a destination address and port, where the server should relay that datagram (section 7).
5. Server will keep the UDP port bound until the TCP socks5 connection terminates.

As you can see, opening a single TCP port is not enough. For UDP to work correctly, the automatically bound UDP port must be reachable by client. NATs and Firewalls might further complicate the situation.

UDP relaying configuration with Dante

1. Telegram calls are Peer-to-Peer, so the udpassociate command should be allowed to 0/0:

    socks pass {
        from: 0.0.0.0/0
        to: 0.0.0.0/0
        # udp.portrange: 40000-45000
        command: udpassociate
        log: error connect disconnect
    }
   

2. udpreply (that's for the actual relaying, the 4'th step above) should also be allowed to everyone as well:

    socks pass {
        from: 0.0.0.0/0
        to: 0.0.0.0/0
        command: udpreply
        log: error connect disconnect
    }
   

3. If your socks5 Server is behind a firewall, open a range of UDP ports (say 40000-45000) and add the udp.portrange: 40000-45000 line to the udpassociate block (see the commented out example in the first point). Then Dante would bind UDP ports in that range only.

4. If your socks5 Server is behind a NAT, then the returned destination address in the response to UDP ASSOCIATE request would be a local IP, rather than the external one. That local IP is unlikely to be reachable by the client, so the sent datagrams would be silently dropped.

   Unfortunately, Dante uses the destination address of the TCP connection as the one where the client should send UDP datagrams to (see the comment in the source code). NAT mangles this address from an external to a local one, so the Dante's assumption that the client can reach the proxy using that destination address is broken.

   A possible solution, which doesn't involve patching Dante, would be to use iptables to change the destination address from a local to the external one (assuming that it's known and doesn't change):

    # 203.0.113.12 – the external IP
    # 1080/tcp - Dante TCP port
    # 40000:45000 – Dante UDP portrange
    iptables -t nat -A PREROUTING -p tcp --dport 1080 -j DNAT --to-destination 203.0.113.12
    iptables -t nat -A PREROUTING -p udp --dport 40000:45000 -j DNAT --to-destination 203.0.113.12
   
    # If external address is not added to any network device on that 
    # machine, then add it to the loopback interface, so the kernel 
    # would know where to route the DNATed packets:
    ip addr add 203.0.113.12/32 dev lo