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

[From: bugzilla-daemon at maemo.org]

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





------- Comment #30 from dplatt at radagast.org  2009-08-15 01:00 GMT+3 -------
I think that the previous suggestion would be the right thing to do for some
VPN applications, and the wrong thing for others.

My original automation is just the opposite:  it's the wrong thing for some
VPN applications and the right thing for others :-)

Specifically:  my automation was designed for the specific situation in which
the VPN termination and the SIP server are on the same machine.  Only one
specific SIP account is being "tunneled" through the VPN - the VPN is being
used primarily for this one purpose, and not as a generalized "secure pipe to
the rest of the Universe" tunnel.  My approach has the advantage that the
OpenVPN/SIP server doesn't have to provide routing or NATing of packets
arriving
through the tunnel - they go only to the SIP proxy on that machine.  Return
routing of SIP is easy, and since the SIP server/proxy "stays in the loop" for
calls from the Maemo device (i.e. doesn't reinvite the RTP away) there's no
problem in routing packets back to the Maemo device.

I believe that the most recent suggestion would be what you might want to do
if you're setting up an OpenVPN tunnel which then acts as the *sole* route
between the Maemo device and the outside world (except for the direct, one-IP
address route to the OpenVPN server itself).  In this case, switching all of
the SIP accounts over to use the VPN IP endpoint address makes sense,
because all of the SIP/RTP will be routed through the tunnel.  This approach
*will* require the continued use of STUN and/or NAT, I believe, because the
Maemo device is going to be continuing to send packets to multiple SIP servers.

I have a feeling that even with this approach, any SIP sessions in progress
at the time that the VPN goes up (or down) are still going to be broken,
because the Maemo device's SIP endpoint is going to change its IP address in
the middle of the call, and the packets are going to be routed differently
and may go through a complete different NAT gateway.

Both approaches seem valid... but they appear to serve slightly different
usage scenarios for the VPN.


-- 
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.