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

[Dave Platt]

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