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