<div><br><br>On Thu, 1 Aug, 2013 at 1:47 PM, E.J.C. Lindner <office@fordior.net> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Hi Paul,
I saw you emails regarding 30 seconds call drop. I have exactly the
same issue when I want to connect my client over OpenVPN to my FS
server, which is also the vpn server at the same time (server is
on a public IP).
All my calls are dropped after 32 seconds... very annoying and I can't
find the solution. So I'm constantly switching config for standard vs vpn
for my client and FS (the standard config is just connecting to the
public ip which is unencrypted).
Did you find a solution in the mean time? Please inform me, cause it's
really killing me. :=|
I hope you can inform me on a short term; really appreciated!
<div>--
</div>Yours sincerely,
E.J.C. Lindner
</div></blockquote><br></div><div>Yes I found a solution to my problem.</div><div><br></div><div>My case differs a little bit from yours in that my openvpn server is on the router, not on the PBX, in your case it's probably even a little simpler.</div><div><br></div><div>So here is what I can advise you,</div><div><br></div><div>1. Ensure NAT is working properly over openVPN, so to test that all you need to do is have 2 phones on the same PBX able to call each other internally (extension 100 to extension 101 for instance).</div><div><br></div><div>If that works then your VPN NAT is probably good.</div><div><br></div><div>2. Ensure that your PBX is reporting the correct external address to your vendor upstream (this is where it was messing me up).</div><div><br></div><div>For example, for me my PBX was 10.0.0.40 (itnernal address) which the router was NATing to 24.38.231.4 (just a sample external address) and the same on the way back, when a request would come in for 24.38.231
.4 it would translate it to 10.0.0.40.</div><div><br></div><div>Because my PBX was not aware of 24.38.231.4 as it's external address, it was only listening on 10.0.0.40, it wasn't responding to the SIP ACK packets correctly, and the call was being perceived as finished and therefore hung up.</div><div><br></div><div>To fix it in FreeSwitch I had to edit external.xml and insert the proper IP address for sip_ext_ip and rtp_ext_ip (this is from memory)</div><div><br></div><div>I hope this helps you out cuz it cost me hours of frustration :)</div><div><br></div><div>Paul</div>