[asterisk-users] OpenVPN tunnel and one-way audio - Do I still need a SIP proxy? (bruce bruce)

[bruce bruce]

Thanks for the detailed info. Problem was solved by including Server B
subnet as the localnet of the Server A (OpenVPN server) and setting each
extension NAT=NO.

Your points are good guides for future problem diagnoses.

Thanks again,
Bruce

On Thu, Sep 23, 2010 at 1:56 PM, Dave Platt <dplatt at radagast.org> wrote:

>
> > I don't think it's an endpoint issue. I think the SIP packet headers get
> > over-written by the tunnel (openvpn) protocol.
>
> I'd be rather astonished if OpenVPN itself were responsible for this.
> As far as I know, OpenVPN doesn't do higher-level-protocol rewriting
> of any sort.  It just provides the "bit pipe" through the tunnel.
>
> I'd suggest several other possible culprits:
>
> (1) Server B might be doing higher-level protocol rewriting (i.e.
>    SIP border gateway stuff) prior to routing the SIP packets
>    through the OpenVPN tunnel.
>
>    This might happen if Server B were configured to use the
>    Linux "iptables" features, with a SIP protocol module and
>    Network Address Translation features.
>
>    The fix would be to disable NAT and boundary processing in
>    Server B's routing functions.
>
> (2) The SIP endpoints (phones) might be configured to "discover
>    their external address", via STUN or a similar mechanism.
>
>    The fix would be to change the endpoint device configuration.
>
> I think you'll need to use Wireshark or a similar sniffer, to see
> what the SIP traffic looks like at several points along the path,
> so you can locate the earliest point at which the wrong address is
> in the SIP packet payload.
>
> Several examination points come to mind:
>
> -  Right after the packet leaves the endpoint device.  I'd suggest
>   using a laptop running Wireshark as a passive packet sniffer...
>   connect the endpoint device and the laptop to an Ethernet hub
>   (not a switch!) and sniff the packets before any router gets
>   its hands on them.
>
> -  As the packets enter Server B - use Wireshark on Server B and
>   have it tap into the incoming Ethernet interface.
>
> -  As the packets are pushed out of Server B's routing layer into
>   the OpenVPN tunnel.  Use Wireshark to monitor the "tap" or
>   "tun" virtual interface, to which the kernel transmits the packets
>   that OpenVPN is to convey.
>
> -  As the packets come out of the tap/tun device on Server A.
>
> In scenario (1) I described above, you'd see the packets be correct
> at the first and second Wireshark sniffing points, and incorrect at the
> third and fourth (i.e. the modifications are being performed in
> Server B's routing/NAT'ing layer).
>
> In Scenario (2), they'd be incorrect at every point, including just
> after they come out of the IP-phone.
>
> In the scenario you described, they'd be correct at the first, second,
> and third points, and wrong at the fourth.
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100923/dee08bc8/attachment.htm