Re: [tor-talk] using UDPGW and tun2socks over Tor

[grarpamp <grarpamp@xxxxxxxxx>]

On Tue, Oct 28, 2014 at 9:55 AM, Nathan Freitas <nathan@xxxxxxxxxxx> wrote:
>>> This means we can support SIP calling over Tor, video conference and
>>> streaming, among other applications...
>
>> Tor as a client also needs support for inbound binds for some apps, at
>> least at the single per port level when interacting with internet at the
>> far
>> end. OpenVPN might, or could be extended to arbitrate those port
>> binding requests.
>> Hidden services do support such binds in hs-to-hs mode, at least
>> statically.

You can't *receive* 'calls' without inbound binding capabilities, or using
internet call servers in the middle as meetme proxies. Out of the box,
tor is crippled in that inbound regard when interacting with the internet.
If you refuse to give third party servers [meta]data, then you're stuck
with unidirectional calling. OpenVPN could do inbound TCP/UDP binds
at the exits, tun2socks TCP can't, don't know if udpgw UDP can.

> Thanks for the feedback. We aren't using OpenVPN itself really, just
> standard SOCKS for TCP, and then UDP tunneled inside of that SOCKS
> connection using this udpgw-client/daemon system.
>
> The VPN code that is part of the solution is more of a local loopback
> capability for Android that allows us to intercept that packets.

> Perhaps udpgw instances can be run along
> side all Tor exit nodes?

Tor transports only TCP. You outline running udpgw clients locally
and udpgw daemons on the exits such that badvpn can tunnel UDP
through udpgw client through badvpn over tor to the far udpgw daemon
then out to the internet.
In the linked mail thread I suggested running OpenVPN on the exits
(instead of udpgw daemon), that will give the user general access to
not just TCP and UDP but to all protocols from 0-255, most notably
ICMP and others typically used by network/system admins. As bonus
you also get optional inbound binds which badvpn-udpgw cannot do either.
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

The badvpn-udpgw TUN model presented to the VM is the same. Though
instead of handing all TCP to the local tor client via SOCKS5 and then
UDP to a udpgw exit over a TCP tunnel therein... all traffic gets tunnelled
with OpenVPN TCP connection over tor to OpenVPN on an exit.
Also, it seems badvpn-udpgw would leave each user TCP streams up
to tor client to route at will, but route UDP over tunnel to a fixed udpgw
exit and configuring the two to use the same exit would be complex.
Whereas OpenVPN tunnels everything to a fixed exit over a single
circuit. ('Fixed' could just as easily be random or rotated by the
configuring user as in the linked mail thread.) Unlike badvpn-udpgw,
OpenVPN also works on all relavent client and server platforms.

Hope that's a more comparison of badvpn-tun2socks/udpgw
to OpenVPN models for VM and general use.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk