FOOD FOR THOUGHT Vultr IncrediblePBX 15-16 audio issues with iptables

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
Not sure how to diagnose or go from here. All of a sudden our audio stopped on our extensions today, to our knowledge nothing has changed. Our exentsions are chan-sip and we have tried sip port as 5060 and 5061. NAT is set to yes. All of a sudden our audio on calls has stopped. When I turn off iptables the sound comes back. Any help is appreciated.
 

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
Any idea why using del-acct and then re-adding using add-fqdn fixes the issue?
 
Last edited:

kenn10

Well-Known Member
Joined
Dec 16, 2007
Messages
3,764
Reaction score
2,173
@kmcdaniel I have found that a few minutes after the system is rebooted and settles down, you need to do another iptables-restart to get the whitelisted IP's back. I think this is due to some Centos 7 craziness that is not yet entirely figured out and resolved. I have also found that on an initial add-fqdn, I must also do an iptables-reload for it to take effect after the script finishes.
 

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
@kmcdaniel I have found that a few minutes after the system is rebooted and settles down, you need to do another iptables-restart to get the whitelisted IP's back. I think this is due to some Centos 7 craziness that is not yet entirely figured out and resolved. I have also found that on an initial add-fqdn, I must also do an iptables-reload for it to take effect after the script finishes.
Thanks! It is definitely interesting. I've had this happen a few times. No audio either way, then stop iptables and audio is back up. Even if your currently on a call and disable iptables, two-way audio is restored. Only fix is del-acct and then add-fqdn again.
 

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
2484
Wondered if adding the external address and LAN would resolve? Can someone advise the appropriate Local Network entry if your remote extensions are on 192.168.1.111 through .115? Thanks!
 
Last edited:

tbrummell

Guru
Joined
Jan 8, 2011
Messages
1,275
Reaction score
339
You should have those settings enabled. Click the Detect button and see what it enters for you. We cannot reliable answer your NAT question without knowing your network topology.
Basically, any networks (where phones may reside) that are local/routed to the PBX (not NAT'd) need to be listed as a Local Network, everything else will be treated as a NAT connection. Asterisk needs to know this to correctly form a SDP/Invite for endpoints and trunks.
 

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
You should have those settings enabled. Click the Detect button and see what it enters for you. We cannot reliable answer your NAT question without knowing your network topology.
Basically, any networks (where phones may reside) that are local/routed to the PBX (not NAT'd) need to be listed as a Local Network, everything else will be treated as a NAT connection. Asterisk needs to know this to correctly form a SDP/Invite for endpoints and trunks.
Okay, thanks. I don't think it's an issue with NAT where the phones reside. Phones are at various locations and all audio stops. When you "service iptables stop" two way audio is back. This is a vultr build with a public IP.

My phones reside with a network on 192.168.1.115 , what is the appropriate input for the field?
 

tbrummell

Guru
Joined
Jan 8, 2011
Messages
1,275
Reaction score
339
OK, and no VPN type connectivity to the server, right? It's all public IP traffic.

External IP would be the IP of the server. Local net you can just use the subnet of the server if you want, or possibly leave it blank.

Since it's just an audio issue that goes away when iptables is stopped, I'd probably start looking in to the RTP ports that the server and phones are using. By default, FreePBX will use 10000-20000 I think, which should also match in iptables. Then, make sure your phones also have the same port range.
 

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
OK, and no VPN type connectivity to the server, right? It's all public IP traffic.

External IP would be the IP of the server. Local net you can just use the subnet of the server if you want, or possibly leave it blank.

Since it's just an audio issue that goes away when iptables is stopped, I'd probably start looking in to the RTP ports that the server and phones are using. By default, FreePBX will use 10000-20000 I think, which should also match in iptables. Then, make sure your phones also have the same port range.
Correct, no VPN. However, I am contemplating following this tutorial: https://pbxinaflash.com/community/threads/yealink-openvpn-incrediblepbx.23825/

Maybe this will eliminate it for certain. Thoughts? Thanks for the help!
 

wardmundy

Nerd Uno
Joined
Oct 12, 2007
Messages
19,168
Reaction score
5,199
The firewall comes up in two steps when your server boots. The first is the settings in /etc/sysconfig/iptables. There are no FQDNs in this list. Then /etc/rc.local runs /usr/local/sbin/iptables-custom. This script has all of your add-ip and add-fqdn entries. It sounds like this script isn't getting run. Sometimes moving entries around in rc.local fixes the problem, but it's quirky on CentOS 7 because they've all but stopped supporting rc.local.

An easy test would be to add the following to the bottom of /etc/rc.local and see if the helloworld file ever gets created in /root on a reboot:

echo "howdy" > /root/helloworld

Also check to see if /etc/rc.d/rc.local and /etc/rc.local are separate files. The latter should be a symlink to the former.
 

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
Thanks Ward!
When you say move entries around, do you mean just change the order in the file?

echo "howdy" > /root/helloworld does NOT produce the file in /root upon restart.

I've tried it located here and at the very bottom of the file below exit 0. UPDATE: Placing it here as indicated in the screenshot and upon second server restart does produce the file!
2485

Both /etc/rc.d/rc.local and /etc/rc.local exists and appear identical.

Should I be selecting Centos 6 on Vultr for future builds or is there any reason we should not use PJSIP extensions on Yealink phones for production in this build? Maybe that's the best solution???
 
Last edited:

smarks

Guru
Joined
Jan 7, 2015
Messages
116
Reaction score
26
Are you sure you are not banning yourself because of maybe a bad password on an extension or something? Did you try disable fail2ban?
 
Last edited:

kmcdaniel

Member
Joined
Jan 23, 2008
Messages
416
Reaction score
19
Are you sure you are not banning yourself because of maybe a bad password on an extension or something? Did you try disable fail2ban?
Not sure why banning at one location would stop two-way audio on all phones, even those located at other locations?
 
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top