[Rtcomm] [Rtcomm] [Bug 1860] Won't pass through VPN

[From: bugzilla-daemon at maemo.org]

https://bugs.maemo.org/show_bug.cgi?id=1860


dplatt at radagast.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dplatt at radagast.org




------- Comment #25 from dplatt at radagast.org  2008-12-03 03:29 GMT+3 -------
A big glowing Thank You for mentioning the local-ip-address tweak to the
configuration.  This hack has enabled me to work SIP through every NAT-enabled
router/firewall I've tried.  Without the use of a VPN, my success had been
poor... STUN doesn't always seem to work out all that well in practice.

I now have an OpenVPN tunnel available from my N810, which terminates in a new
IP subrange I've set up on my home server (firewall, mail router, and Asterisk
server).  The additional overhead of the VPN encryption and validation doesn't
seem to bother either the N810, or the home server (a lowly 200 MHz Pentium).

Thanks to the flexibility of OpenVPN, I've been able to automate the process of
switching a Telepathy SIP account configuration back and forth between VPN'ed
and non-VPN'ed operation.  This trick also eliminates the need to "hard-code"
the Maemo-side VPN IP address into the SIP account configuration, and it can be
extended to control other aspects of the SIP configuration dynamically.  I
suspect that a similar trick may be possible with other VPN clients, although I
haven't tried any.

Here's what I did.  In my /etc/openvpn/nokia.conf configuration file, I added
the following stanzas:

# Our up script will establish proper SIP bindings 
# once the VPN is alive.
up /etc/openvpn/nokia.up

# Our down script will dismiss the SIP bindings to
# the VPN once they're no longer required (or usable)
down /etc/openvpn/nokia.down

OpenVPN passes a bunch of parameters involving the VPN connection to each
script when it's executed.

The /etc/openvpn/nokia.up script reads:

#!/bin/sh
# Force the VPN SIP account to bind itself to the
# VPN address we have just been allocated.
mc-account set sip2 string:local-ip-address=$4
# Use the VPN host's address as the SIP proxy,
# since we can't count on any other being reachable.
mc-account set sip2 string:proxy-host=vpn-host.example.com 

This adjusts the SIP account configuration to bind to the IP address just
assigned by OpenVPN, and to use an "inside the VPN" endpoint on my server as
its SIP proxy.

These settings are deleted when the VPN is torn down.  The mc-account shell
utility doesn't have an "unset" option (even though the underlying library does
support this) so I do it the clumsy way via the gconftool utility:

#!/bin/sh
# When the VPN goes down, remove the forcible binding
# of the SIP account to our VPN IP address (since it
# no longer exists) and remove the requirement to use the
# host-side VPN host address as the SIP proxy.
gconftool --unset /apps/telepathy/mc/accounts/sip2/param-local-ip-address
gconftool --unset /apps/telepathy/mc/accounts/sip2/param-proxy-host

Similar tweaking can be done to other parameters in the configuration... e.g.
external-address discovery can be enabled and a STUN server specified when the
VPN connection is torn down, and discovery and STUN can be disabled when the
VPN  starts up.

It'd be nice to have a user-friendly UI to manage these sorts of settings
changes, but I'm not at all sure how such a UI can be created... "simple" and
"user friendly" don't always get along well with an intricate collection
of settings-adjustments.


-- 
Configure bugmail: https://bugs.maemo.org/userprefs.cgi?tab=email
Replies to this email are NOT read, instead please add comments at
https://bugs.maemo.org/show_bug.cgi?id=1860
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.