OpenVPN and SIP needs NAT
One new question here at the VPN subforum… wanted to solve the first one before the second question, and so on, but they are stacking up.
I have a SIP Server (FreePBX 12) in a VM.
Locally it works OK.
And I used to have a Kerio Control which did NAT for the ports of the SIP Server to the WAN. I have opened too many ports and because of issues we had I'm now trying pfSense and using OpenVPN and opening no ports to the outside world.
It used to work fine with that config.
Now with OpenVPN:
If I connect from Home (via OpenVPN) using X-Lite client I can use it to call and there is voice on one side only and the call will drop in a few seconds.
If I connect from my Android phone with OpenVPN and CSipSimple from OPT1 (wifi) or 3G the mic works, the speaker doesn't and I can't hang up. It hangs up later by itself because of a time out.
So both clients have issues. They don't behave exactly the same but something is not right.
I had to add this rule to NAT and now it works. (see attachment)
Obviously the rule is too wide open and it could just NAT the specific ports for SIP but it is for testing purposes only.
Why do I have to NAT? Shouldn't it be transparent when I'm in OpenVPN?
Obviously I also have to set the NAT option in the FreePBX extension to "Yes - (force...)" because if it is set to "No" it won't work.
Thanks again for all previous help.
Just saw this thread after posting to your previous one which you solved (Yay!).
Voip via OpenVPN can work well, I use it with a few bare metal FreePBX setups myself.
As with anything, the devil is in the details and SIP has a whole wack of details….
My first suggestion (carrying over from the previous thread) is to get your OpenVPN tunnel off of 10.0.0.0/24.
This may have nothing to do with the current problem, but it's entirely possible that one or more devices in your setup will "think" they know how to handle traffic destined for 10.0.0.0/24 and do something unexpected. Get yourself on a solid footing and change that subnet.
As far as FreePBX coexisting over OpenVPN, I've never had to NAT anything to get it working. As I recall I think I had to tell FreePBX/Asterisk and/or the internal extensions that my OpenVPN subnet was valid for traffic (see why you want to make sure you're not on an overused default?) and it just worked.
Try one step at a time and be forewarned that SIP can be notoriously difficult to troubleshoot. With pfSense in the mix I often go so far as to Reset States between changes on FreePBX/extensions since SIP internal negotiations often "survive" a firewall change until a major state change "sometime later".
Post a screenshot of your WAN/LAN/OpenVPN firewall and your NAT rules and we can see if anything obvious pops up (you knew that was coming didn't you ;) )
The FreePBX forum is also a good place for pointers in solving "one way audio problems over SIP" (a common occurrence unfortunately).
Keep at it and let us know how it goes....
Well I finally got it working.
After I changed the IPs and DNS of the PBX and the Grandstream FXS/FXO it got really awful.
It was a FreePBX 11 that with time updated itself to 12, and in the middle I guess I had to update Asterisk from the console.
Plus, when I configured it the first time, all the NAT was set to No (that was the default for a new extension) and I set them to Yes because I was using NAT with Kerio.
The solution was quite easy. I've created a new VM with a fresh ISO of FreePBX 12 and copied all the Extensions/Inbound/Outbound/Ring Groups (just a handful) and it started working with no extra config.
The default NAT for Extensions in FreePBX 12 is Yes. I don't believe I need it, but it works. So that is all I need.
My experience with SIP has been bittersweet at times (and I know I'm not alone).
I find things have improved between providers and the current releases of FreePBX/Asterisk/pfSense such that mucking about in pfSense is mostly not needed anymore.
No to mention the SIP protocol itself has evolved (somewhat) for the better, although I still use IAX2 with some setups to avois the NAT nightmare that can SIP can be.
Very often it "just works" which is gratifying after years of trying to resolve Voip software/ DID provider/Hardware manufacturer issues when everybody pointed at the other guy as the source of the problem <sigh>.
Glad you're up and running.</sigh>