We have began setting up endpoints with TCP connections, as they seem to be much more resilient behind NAT. Setting a high frequency on Qualify, like 10 seconds, also keeps the connections open on all the firewalls we’ve tested. Point being things work great like this, but on the popular 5060 port.
Aanyway, when we use tcpbindaddr=0.0.0.0:7775, we can connect phones to that port, and they register. But when phones on the same server call each other, they have one way audio.
Any idea what could be causing this?
NOTE that calls to and from that extension from an outside source, like my cell phone, have audio both ways. There’s something not fully changing with the tcpbindaddr=0.0.0.0:7775, OR because our UDP is still on 5060, FPBX is confused?
This is true. What I can’t figure out though is why everything works fine when I allow port 5060 top through on our firewall, with 5060 Bing the bind port, BUT when I change to a more obscure port, like 7775, we have the above mentioned issue.
I guess then, other than observing ‘asterisk -vvvvvvvvvvr’ (insert more v’s for more verbosity) and ngrep to watch the network traffic [insert appropriate paramters to filter the respective ports] I don’t have more other ideas… IAMNOTAPRO
Gotcha. On the server end, we have a Cisco ASA 5510 with “inspect SIP” disabled, as it is know to cause issues. The only other SIP lines in the config are these two:
On the server side, there is a Cisco ASA 5510 in front, but with a static 1-to-1 NAT, so all traffic to Public IP->LAN IP. We have traffic go through the ASA though so we can protect the server with ACLs. We of course allow TCP 7775 through when we change the bind port.
On the endpoint side, NAT is also taking place, but no special port forwarding is setup. The idea is that the endpoint could be plugged in behind most consumer routers and work just fine. And this does work just fine, but only when the TCP bind port is left alone to it’s default, port 5060.
Even if you have a 1:1 NAT, you should inform Asterisk about it by setting up the NAT parameters in Asterisk SIP Settings and setting NAT on in the extensions. Have you done that?
Hi. Yes. NAT is set to yes in Asterisk SIP Settings, as well as on the extension. Also, in asterisk sip, under the chan sip tab (which is the driver we’re using, pjsip is turned off) IP Configuration is Static IP and override External IP defaulted to the correct Public IP of the box, as setup per the 1 to 1 NAT on the ASA firewall.
With this information in your Cisco router, the only time it will work is if there is SIP traffic on 5060. That’s how it triggers the timers. Moving the SIP port to another port disables these rules. You will have to set them up manually, or find a way to set the “SIP” port in the router to use “not 5060”.
So from what I can tell, because I’m not using the default “inspect SIP” statement, the 1 to 1 NAT should be working as is. Those other lines are simply timeouts and shouldn’t be the cause of the one way audio. I unfortunately can’t test that theory until after hours this weekend sometime.
If you are using the standard port configuration (minus 5060 port) you should be allowing UDP 10000-20000 in through the firewall and making sure they get sent to your box.
Normally, your firewall would block these otherwise “unknown” packets.
In your PBX, you need to make sure that NAT is turned on (so that the right address gets written into the packets).
If you can, run a wireshark capture of the data on the external interface and make sure that all of your addresses and ports are getting set right. If, for example, you are not correctly identifying your external IP address in the server, the traffic will be defined to go to your local address, which is cool, except that your NATted address is probably not well advertised outside your network.
In fact, your assumption in the inverse of what is correct. If putting it on 5060 makes it work and moving it away from 5060 breaks it then something is mangling the traffic going through it, because it’s seeing 5060 and going ‘Oh, I know how to fix this’. And fixing it.
If you enable TLS you’ll have the same issue, because whatever’s doing the mangling won’t be able to mangle it any more.
Do you mean enabling TLS will fix it…because it “won’t be able to mangle it any more”?
Can you give me some starters on how to fix my NAT settings in Asterisk? You believe the problem is there and not on the ASA? Other than setting the bind port, enabling tcp, having NAT set to yes, and having IP Configuration set to Static IP, with the correct IP under it, what am I missing? OR is it the ASA that’s doing the mangling perhaps? I know a quick bypass of the ASA would maybe answer that question, but for the next couple days I cannot do that.
Maybe it is the ASA seeing unexpected UDP traffic and then blocking it. The only way to find out is to do a tcpdump on the asterisk box and see if traffic is arriving/leaving correctly, and is it getting to the endpoint.
IAMNOTAPRO 