Apparently, I should have mentioned this earlier.
If you are using FreePBX 13, you have a firewall ON YOUR PBX. The good old days of setting up the firewall and letting the PBX talk through it appear to be over. We are now at the mercy of Sangoma.
So, we now have to rely on the PBX software to get all of the myriad iptables settings and fail2ban settings correct and don’t really get a vote in it. It appears that we do, ecause we have settings pages, but I’m not convinced they work.
There are problems with the integrated firewall, but I don’t see a way to uninstall them. As long as you never start the integrated firewall in the PBX software, you might be OK. The problem really appear to compound with dual-NIC setups, which are actually VERY common (at least, all of my systems are).
If you have started the PBX, I recommend you follow it’s lead. If it wants the external interface to be on eth0 but numbers it 192.168.1.1 (or whatever it randomly decides to do), just play along. Move the cables so that the port with the internal address can see the internal network, and the port with the external address so it can see the external network.
Yes, by the way, I am a little frustrated with the way the integrated firewall is working.
One of my customers has two addresses for they incoming VOIP provider. I ended up rewiring the connections (switching eth0 and eth1) so that the PBX would stop switching them back and forth. I went into the /etc/sysconfig/network-scripts/ directory and tied the eth0 and eth1 config files down to specific MAC addresses and added all of the network routes myself. After that, I still had the system try to switch eth0 and eth1 around WHILE THE SYSTEM WAS UP. Once it did that, I had to drive 30 miles to reset the system and get it back under control.
I think I understand your frustration.
Note that, even though everything else is perfect, the IPtables and fail2ban parts may well screw you up. Remember the customer with two incoming phone systems sources? He can receive calls from one of them, but not the other. Both are whitelisted, neither are in jail, there’s no good reason why traffic from x.x.24.31 should work as well as x.x.23.30. Except that it doesn’t work. Oh, and I had to use Chan_SIP for the connections because PJSIP doesn’t do host-based authentication yet, so that might also be messing with me.
And perhaps you. Check your port mapping and make sure you are using the right SIP interface. PJSIP and Chan-SIP use different ports on your server. PJSIP uses 5060 and Chan-SIP uses 5061 OOTB as I recall. In order to the server half-working, I had to remove the PJSIP driver from the module list entirely.
Good luck.