One sided communication

This is really strange, I posted this same problem on the Asterisk forums but know answer. I am running 2.5 with latest updates of FreePBX, but this problem has been around for some time now.

No this is not what normally people have as a problem in one sided communications. I will be on a call and during the call for around 10 seconds, I will not be able to hear the person on the other end of the call. They can hear me and continue to talk but I can hear them.

I am not sure where things stopped working but seemed to be a problem after I had upgraded from 1.4.16 of Asterisk. I am presently running 1.4.21.2.

I have changed hardware for the phone server, configured and reconfigured the firewall for bandwidth controls and without. Replaced firewalls and hardware. Replaced all of the switches from unmanaged to managed. Nothing so far has worked to resolve this problem.

I am running kernel 2.6.26-1 on Debian-unstable 1.6GHZ AMD64 with 2 G of memory, before this the box was a 2.4GHZ 32bit machine with 1G of memory.

So I am at a loss as to what may be causing this and I have no idea how to debug this kind of problem.

If I could get some direction on this. It would be much appreciated

Thanks

Have you properly configured sip_nat.conf?
Can you confirm that the RTP media ports are opened and pointed to the correct IP address?

My system is directly connected to the Internet with an actual dedicated ip address. My firewall has rules allow 10000-20000 to the asterisk server.

What about local calls exten to exten are they effected???

As it appaers from your post you are using your box without a hardware firewall between you and few million wannbe hackers
any attacks from outside will be dealt with by your PBX … not a smart thing to do.

If someone is hammering your box with a brute attack on SIP / SSH or whatever you will “hear it” by the silence of lost packets.
check the systems logs which by the way you should have emailed to you and go everyday or ANY box exposed to the Inet.

Nothing but sip is allowed, running a firewall. This system has has snort running on it. This setup is no different than anyone that does not want to deal with natting SIP and uses a proper firewall.

Just to say… this does not have problems with any brute attacks. Just your everyday internet connection could be having going through brute attacks. Just because I chose to have a firewall connected with a 5 other servers that I run directly connected between the firewall. 5 other machines are natted because there was no need for a direct connection.

So outside of monitoring bandwidth daily with CACTI and monitoring of services with Nagios. I never see anything that looks out of the ordinary for bandwidth. I never see more than 700K of upload out of my 2 MB up. Download depending on my usage, is about 8 to 9 MB down at max. On the average my download usage is about 1MB overall.

So to state that my PBX will be dealing with attacks is unrealistic. My separate firewall that does only firewalling for about 25 total machines within this network alone and is connected to 4 other VPN’s Asterisk supports about 3 other companies connected via DUNDI and we have not had problems until the last few months.

My point is I am not an amateur at this. I have made sure that this system is monitored closely along with all of the other servers that are running on this network.

So back to the problem I am running into. Is there anyone that may have a clue as to what I may have done to cause this?

Thanks

does it allow UDP port 5060? and 10000-20000 are also UDP correct? you don’t mention that and with SIP you’ll need it.

You said that your system is directly connected to the internet. Does that mean you have one NIC for the ‘inside’ and one NIC for the public IP. Or are you forwarding one public IP to your internal IP?

This setup has not changed from the point of the firewall. I have been using the same rules for over a year now.
This seemed have occurred after upgrading from 1.4.16.

Local calls seem to not be affected, that also if I remember is calls over DUNDI and the VPN. I think it is only calls that go directly over the Internet that seem to have this problem.

But it is really strange when this problem only occurs on the other side of the call, the call side that is going out, not coming in. This is why I am stumped. None of the normal problems related to this apply.

I am leaning toward some firewall rule that has been in place that was affected only after I upgraded from 1.4.16. This problem has continued with 1.4.21.2.

Most of my rules are for bandwidth control and managing. I am concerned something with those rules could cause this.

I don’t allow anything in to the phone server except UDP/TCP 5060 and UDP/TCP 10000-20000.

So I am kinda lost here…

Thanks for the help

Bubba’s first statement/question is important. Does the local extension to extension calls also have the same issue?

don’t allow in tcp port 5060 and tcp 10000-20000. The sip protocol does not use TCP just UDP. Having those TCP ports open is a good way to potentially get your system hacked.

I have a firewall with a DMZ and a local network.

The DMZ is connected to a bridge on the firewall. I manage the firewall rules to the DMZ bridge. I have a public IP address that is used on this server so that I do not need to do any type of NAT.

And yes I do have a NIC that is attached from the inside for management and the other is for the external network.

So basically I have a local address on eth0 of 192.168.1.x and another from my ISP on eth1 of 97.x.x.x. This address from the ISP connects to the switch that is attached to the DMZ and the other nic to the internal networks switch.

Thanks

What subnet are the local phones on (address range please) and which interface do you expect them to be communicating on (eth0 or eth1)?

This is quickly looking like a default route issue…

For the local net 192.168.x.x /255.255.0.0 and on eth0.

The firewall does not allow anything from within to talk through the DMZ. This is the only machine that has a second interface on it. It was safer to do that than allow access to the server via DMZ.

I know this is not the most perfect way to configure a DMZ. But this is what worked out best.

This is what my route looks like

97.x.x.x 0.0.0.0 255.255.255.248 U 0 0 0 eth1
192.168.0.0 192.168.1.1 255.255.0.0 UG 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 97.x.x.x 0.0.0.0 UG 0 0 0 eth1

Thanks for the help

Ouch, ugly and BAD!!!

Ok you didn’t answer an important question. so I’m rewording it. Which subnet are the phones on? with this screwed up setup I can see why you are having problems. to be more specific what is a IP and it’s subnet mask of a phone? as that determines which subnet it truely belongs to.

Next and most important: You should never EVER reuse/re-purpose a IP like that in a multiple subnet setup, no wonder you are having problems and at this moment you are lucky that you are not having more problems then this. to properly do subneting an supernetting you need a router to do the merging and translation, you NEVER EVER assign a duplicate IP with different subnet masks to a given system it will confuse the heck out of everything.

If you have a subnet defined on a interface as one large block you can’t then on that same interface again take a smaller slice of the same address space and use it with a different mask. It causes all kinds of issues from broadcast storms, to icmp redirect floods, etc. I’ll bet you have a huge volume of network chatter going on so that things can just try and figure out what is going on. I’m suprised that the phones even work with all that traffic going on.

You need to go learn proper networking and subnetting principals, those are way beyond free support here.

Here is why it’s a problem a device with a IP of 192.168.1.100 wants to talk. It send out a broadcast message and uses it’s subnet mask to determine it’s broadcast address and broadcast listening address for things like arp, etc. each other system on the network are also listening on those addresses. But when you have different subnet masks they don’t see/hear the broadcast messages in the right place and get missed on the simple end and cause HUGE problems on the bad side of things…

when you get it streightened out your route table should be a grand total of 3 lines.

97.x.x.x 0.0.0.0 255.255.255.248 U 0 0 0 eth1
0.0.0.0 97.x.x.x 0.0.0.0 UG 0 0 0 eth1

The above two will be in there and only one for the 192.168.x addresses based on how you fix your problem.