Automatic configuration of direct routes behind NAT

[Pedro Côrte-Real]

On Wed, Feb 22, 2012 at 6:20 PM, Benjamin Henrion <bh at udev.org> wrote:
> Is there a special reason why you want to route the SIP traffic
> through the Tinc vpn?

>From what I've seen SIP has pretty poor security and doesn't play
nicely with NAT. Add to that the fact that 3G networks sometimes block
SIP and having a VPN that traverses NAT and doesn't take over the
default route or force everything to be routed through a central node
(adding a bunch of latency) seems great.

Here's the setup I had envisioned:

- Get yourself a VPS (linode, rackspace, EC2,etc) with a public IP
- Install tinc as the central node here
- Install some PABX software (e.g., Asterisk or yate) on the same
server and have it listen on the VPN interface only (now your PABX
software isn't exposed to the internet at all)
- Install tinc on a few Android phones and configure them to connect
to the central node
- Configure the builtin Android SIP client to connect to the PABX through tinc

So now when you make a call through the PABX, SIP will figure out that
both clients are on the same network and do a handover from
Phone1<->PABX<->Phone2 to Phone1<->Phone2 (at the VPN level) and get
out of the way. tinc will then figure out the best way to route the
two phones together. If they're on the same network it will be
directly and if they're on two diferent NAT's it will STUN them
together, avoiding the potentially horrible
London<->California<->London routing SIP would do otherwise. Worst
case scenario you're routing through the PABX machine which you would
anyway with SIP, only now you have and encrypted call.

Cheers,

Pedro