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

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

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