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 dpl...@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
--
_
-- 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
