To tighten security I set up iptables INPUT policy to DROP and allowed all expected traffic to go to my Asterisk server. Initially, I had the INPUT policy set to ACCEPT which was the default during the installation. Running Raspbx behind my ISP gateway and the gateway only allows SIP packets from my VSPs.
I can set up calls without any issues but I noticed that a few seconds (may be 1 or 2) of incoming audio always gets cut out. I repeated the test many times with many voice mail boxes and the problem is consistent - ie. the first few audio packets never get through. Then audio is OK but there is a slightly noticeable jitter now compared to when I had INPUT policy to ACCEPT.
If I restore the original iptables rules the problem goes away suggesting that this could be caused by delay in processing iptables rules?
Hi.
If you want, you could post your current iptables ruleset here as an attachment, may there is something obvious.
Please point out, which changes you made compared to the one which works.
*filter
:INPUT DROP [209:41426]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2171:455842]
:f2b-sshd - [0:0]
:fail2ban-asterisk - [0:0]
-A INPUT -p tcp -m tcp --dport 5060 -j fail2ban-asterisk
-A INPUT -p udp -m udp --dport 5060 -j fail2ban-asterisk
-A INPUT -p tcp -m tcp --dport 5061 -j fail2ban-asterisk
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s isp1 -p udp -m udp --dport 5060 -j ACCEPT # isp ip address
-A INPUT -s vsp1 -p udp -m udp --dport 5060 -j ACCEPT # vsp’s ip address
-A INPUT -s vsp2 -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 20000:21000 -j ACCEPT # ports used on Asterisk and phones
-A f2b-sshd -j RETURN
-A fail2ban-asterisk -j RETURN
I had more INPUT filtering rules including string matching which I removed to rule out that they probably could cause delays but it made no difference. If I change INPUT policy to ACCEPT everything is OK - ie. not audio clipping, crackling audio. I can set the INPUT policy to ACCEPT and add many rules to drop unwanted packets (such as accept rtp port range and drop all other unused udp ports etc) and the problem goes away.
What I have not tried out yet is, to stop fail2ban and see what impact it has.
Hi.
Order matters for iptables. I am not sure, but I would guess the order of your rules could cause this. I would try and change all accepts for dport 5060 with specific IPs to the beginning, --dport 20000-210000 also. At the very top --cstate RELATED,ESTABLISHED.
@_fuz, Thanks very much for the link - I have been looking around for tutorial on iptables but could not find something that is easy to read like this one.
I did more testing on my iptables - you are right, the order appears to be critical. I moved my rule for rtp ports to the very beginning just below fail2ban lines and the audio seems a lot better but still not as good as when the default input policy is set to accept.
I thought of manually moving the rtp rule to the very top and see whether it would make any difference - the only problem is when fail2ban starts it automatically overwrites the iptable rules and places itself at the very beginning.
I will go through the tutorial and see whether I can improve on this.
*filter
:INPUT DROP [209:41426]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2171:455842]
:f2b-sshd - [0:0]
:fail2ban-asterisk - [0:0]
-A INPUT -p udp -m udp --dport 17000:17200 -j ACCEPT # my rtp ports
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p udp -m udp --dport 5060 -j ACCEPT # allow my phones
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 80 -j ACCEPT # web access from local pc
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 22 -j ACCEPT # ssh from local pc
-A INPUT -s 192.168.1.0/24 -p tcp -m tcp --dport 69 -j ACCEPT # tftp from local phones
-A INPUT -p tcp -m tcp --dport 5060 -j fail2ban-asterisk # run fail2ban chains
-A INPUT -p udp -m udp --dport 5060 -j fail2ban-asterisk
-A INPUT -p tcp -m tcp --dport 5061 -j fail2ban-asterisk
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -s -p udp -m udp --dport 5060 -m string --string “sip:(myuserid)@” --algo bm --to 65535 -j ACCEPT # only accept if ISP sends SIP Requests bearing my id
-A f2b-sshd -j RETURN
-A fail2ban-asterisk -j RETURN
This hopefully will block SIP requests from other sources - of course, if someone hacks into my ISP and gets my credentials then this will not help.
By moving rtp traffic to the top it did make a significant difference to the voice quality.
Hope this will be useful.
Thanks very much @_fuz for your help and for @Hockeychap for sharing the solution to use the --string option to filter out undesired SIP Registration requests (How to limit SIP registrations)
