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.<div><br></div><div>Your points are good guides for future problem diagnoses.</div>
<div><br></div><div>Thanks again,</div><div>Bruce<br><br><div class="gmail_quote">On Thu, Sep 23, 2010 at 1:56 PM, Dave Platt <span dir="ltr"><<a href="mailto:dplatt@radagast.org">dplatt@radagast.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
> I don't think it's an endpoint issue. I think the SIP packet headers get<br>
> over-written by the tunnel (openvpn) protocol.<br>
<br>
I'd be rather astonished if OpenVPN itself were responsible for this.<br>
As far as I know, OpenVPN doesn't do higher-level-protocol rewriting<br>
of any sort. It just provides the "bit pipe" through the tunnel.<br>
<br>
I'd suggest several other possible culprits:<br>
<br>
(1) Server B might be doing higher-level protocol rewriting (i.e.<br>
SIP border gateway stuff) prior to routing the SIP packets<br>
through the OpenVPN tunnel.<br>
<br>
This might happen if Server B were configured to use the<br>
Linux "iptables" features, with a SIP protocol module and<br>
Network Address Translation features.<br>
<br>
The fix would be to disable NAT and boundary processing in<br>
Server B's routing functions.<br>
<br>
(2) The SIP endpoints (phones) might be configured to "discover<br>
their external address", via STUN or a similar mechanism.<br>
<br>
The fix would be to change the endpoint device configuration.<br>
<br>
I think you'll need to use Wireshark or a similar sniffer, to see<br>
what the SIP traffic looks like at several points along the path,<br>
so you can locate the earliest point at which the wrong address is<br>
in the SIP packet payload.<br>
<br>
Several examination points come to mind:<br>
<br>
- Right after the packet leaves the endpoint device. I'd suggest<br>
using a laptop running Wireshark as a passive packet sniffer...<br>
connect the endpoint device and the laptop to an Ethernet hub<br>
(not a switch!) and sniff the packets before any router gets<br>
its hands on them.<br>
<br>
- As the packets enter Server B - use Wireshark on Server B and<br>
have it tap into the incoming Ethernet interface.<br>
<br>
- As the packets are pushed out of Server B's routing layer into<br>
the OpenVPN tunnel. Use Wireshark to monitor the "tap" or<br>
"tun" virtual interface, to which the kernel transmits the packets<br>
that OpenVPN is to convey.<br>
<br>
- As the packets come out of the tap/tun device on Server A.<br>
<br>
In scenario (1) I described above, you'd see the packets be correct<br>
at the first and second Wireshark sniffing points, and incorrect at the<br>
third and fourth (i.e. the modifications are being performed in<br>
Server B's routing/NAT'ing layer).<br>
<br>
In Scenario (2), they'd be incorrect at every point, including just<br>
after they come out of the IP-phone.<br>
<br>
In the scenario you described, they'd be correct at the first, second,<br>
and third points, and wrong at the fourth.<br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br></div>