TIPS Incoming calls blocked. Is it a firewall issue?

[paulnye]

IPBX21 on Vultr. 1 Vitelity DID routed to IP of PBX. 1 Yealink phone registered fine. However incoming calls dont reach PBX. Vitelity says they sent 4 INVITES to the IP but did not receive a response, and then timed out. I had asterisk -rvvv open and didnt see any action neither. I then stopped the IPTABLES service. Still nothing. What can I try next?

 

[idho0618]

Port forwards set on router firewall? Firewall on pbx whitelisted sip providers ip?

 

[ostridge]

I then stopped the IPTABLES service. Still nothing. What can I try next?

Log in to the linux CLI by ssh
type

 iptables-restart
[/code=bash]
Wait while iptables is restarted. then check the rules for your provider by typing
[code] iptables -nL

This gives a listing of IP addresses which have active rules some of the rules look like this:

ACCEPT     udp  --  64.62.236.143        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  24.211.64.206        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  199.30.56.194        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  209.216.15.70        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  209.216.2.211        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  184.154.97.11        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  81.23.228.150        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     tcp  --  81.23.228.150        0.0.0.0/0            tcp dpts:5060:5069
ACCEPT     udp  --  65.254.44.194        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  65.254.44.194        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  74.81.71.18          0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  50.22.101.14         0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  67.212.84.21         0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  176.9.39.206         0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  72.9.149.25          0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  50.22.102.242        0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  98.254.157.185       0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  178.63.143.236       0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  98.254.157.185       0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  64.2.142.26          0.0.0.0/0            udp dpts:5060:5069
ACCEPT     udp  --  64.2.142.26          0.0.0.0/0            multiport dports 5060,5061,5062,5063,5064,5065,5066,5067,5068,5069,4569

etc.

Check the list to make sure your providers IP addresses are all there.

 

[krzykat]

You need to check what port they are sending the traffic to and where you expect to receive it. Also - you need to know what format they are sending the call to you. Are they sending with or without country code. Then Yes, make sure you have their IP's that they are sending traffic to you included on your list to accept traffic from.

 

[Eliad]

Did you whitelist vitelity server in the incrediblePbx by using ./add-fqdn?

 

[Halea]

Either your port forwarding for UDP 5060 & 10000-20000 is not properly set on your main router or on your router you have firewalling which prevents that forwarding from working.
What kind of router/gateway do you have?

 

[Eliad]

If I understand correctly the pbx is on Vultr. Then the only firewall between Vitelity and Pbx is the firewall build into the pbx.

 

[Halea]

Thanks @Eliad ! I completely overlooked that part, I should stop reading only every other word . So indeed probably there is no other router or firewall. What made me think about it was that he turned off iptables and the problem didn't go away and an earlier reply which alluded to a main router/firewall.

So, back to square one. It sounds like the PBX is not seeing the call.
@paulnye : Are you getting your calls from Vitelity through registration or IP forwarding?

 

[dicko]

'Only' by your choice, you can easily deploy https://www.vultr.com/docs/vultr-firewall, it's not very flexible, but if for example you decide not to us UDP/5060 for SIP (a good thing IMHO) then you can mostly relax.

 

[paulnye]

Thanks @Eliad ! I completely overlooked that part, I should stop reading only every other word . So indeed probably there is no other router or firewall. What made me think about it was that he turned off iptables and the problem didn't go away and an earlier reply which alluded to a main router/firewall.

So, back to square one. It sounds like the PBX is not seeing the call.
@paulnye : Are you getting your calls from Vitelity through registration or IP forwarding?

Yes I had turned off Iptables service and still nothing hits the PBX
Calls from Vitelity are routed by IP
Vitelity Tech support is saying the calls are sent but timing out

 

[jerrm]

Use sngrep to monitor traffic(apt-get install sngrep). sngrep sees traffic BEFORE iptables processes it.

If you see the traffic in sngrep but not asterisk, then it is likely a bad iptables ruleset. Less likely could be asterisk config, but for any asterisk config issue I would expect some noise in the asterisk logs.

If you don't see the traffic in sngrep, the 99% probability is the problem is upstream of the server - possibly the vultr firewall or misconfigured at vitelity.

 

[Eliad]

Yes I had turned off Iptables service and still nothing hits the PBX
Calls from Vitelity are routed by IP
Vitelity Tech support is saying the calls are sent but timing out

Did you whitelist vitelity inbound server? Vitelity uses several inbound servers. You will find yours in the vitelity account information.
Also, if by any chance you customized IncrediblePBX firewall you probably you hosed it. @ward keeps stating, don't touch the firewall installed in the incrediblePbx.

 

[krzykat]

Yes I had turned off Iptables service and still nothing hits the PBX
Calls from Vitelity are routed by IP
Vitelity Tech support is saying the calls are sent but timing out

Agreed you need to see the SIP packets that come in and then you can analyze and see what's going on. A common one I see is that people expect the call to come in without country code, yet the call comes in WITH country code, or vice-versa.

Again, as others have said, look at the packets and you can know for sure. It will tell you what port, what DID, what Codec, everything. Sngrep will work fine, I personally use VoIPMonitor. If you're unable to analayze the packets - I could give you a server to send it to that I could then analyze the packet for you. Can even be coming from an IP that you didn't expect.

 

[wardmundy]

Turn off Fail2Ban temporarily and see if that solves the connection issues. I suspect the Vitelity IP address has been blacklisted. You can add it in the ignoreip line under [DEFAULT] section of /etc/fail2ban/jail.conf.

 

[krzykat]

Turn off Fail2Ban temporarily and see if that solves the connection issues. I suspect the Vitelity IP address has been blacklisted. You can add it in the ignoreip line under [DEFAULT] section of /etc/fail2ban/jail.conf.

He already turned off iptables ... doesn't that supersede fail2ban ?

 

[paulnye]

Yes, I did turn off iptables. Is there a separate command to turn off fail2ban ?

 

[paulnye]

I just noticed that even when iptables service is stopped, anonymous IPs are not allowed to access the gui
I thought that if I did 'service iptables stop' then I could access the gui from any IP. Am I wrong?

 

[krzykat]

Depends on how you have things set, but you probably have your website limited to access via the proper URL. If you are trying to access via IP - then it may lock you out.

 

[jeffmac]

Is this a Debian installation? Because I don't think SERVICE IPTABLES STOP actually DOES anything on Debian.
On Centos it will load IPTABLES policy of "allow" anything. I don't see the same thing on Debian (which I admit I'm kinda new to).
After issuing SERVICE IPTABLES STOP, try listing your rules again "iptables -nL" - if the all the rules are still there you'll see what I mean.

Jeff

 

[jeffmac]

I'll add that I have just confirmed what I said on one of my IPBX21 installs.
I listed iptables before and after service iptables stop - and in both cases all my "whitelisted" entries are there following the "CHAIN INPUT Policy(DROP)"

I've actually done a little seaching for a script for Debian that does what service iptables stop does on Centos - but as yet I haven't found anything except some info that might allow me to do it myself - and I haven't felt that confident yet.

Jeff