We're trying to switch our PRI lines to SIP lines but I'm getting one way communication and everything seems to be pointing to NAT issues. Our phone system is ShoreTel v13.1 and out firewall is a Sophos UTM 9. Supposedly it is supposed to be able to handle the dynamic NAT ports for VoIP but it is failing. I've been on with their support and the issues is still unresolved. I've read a little about getting an SBC or VoIP proxy. Do anyone know a good place to start to get the NAT issue fixed.

35 Replies

If this were Asterisk, I would say setting nat=yes should do the trick.

The inherit problem with NAT is it modifies the src/dest address in the packet headers. I'm not familiar with the ShorTel solution, but you need to get it sending out the external IPs of your network on the SIP headers. In asterisk, setting nat=yes solves this. I'm assuming ShorTel has a similar setting on their trunks.

Your NAT and Firewall rules on your Sophos needs to allow SIP and RTP traffic back in that's been initiated from the inside. You also need to port forward SIP appropriately so you can accept incoming SIP messages from the trunk that weren't initiated by your PBX.

1st Post

What exactly do you mean by one way communication? Is the SIP registering? Usually running something like WireShark will tell you exactly what is wrong. In my scenario all we had to do was create a Static NAT for the connection. A bit more information from you would give me a better idea of the issue you are having.

When I call in from my cell phone I can connect and it rings the phone and recognizes when I pick up the office phone. I guess this is showing that SIP is working great. I can the talk in the office phone and hear myself in the cell phone but not the opposite way. If I talk or punch buttons on the cell phone nothing can be heard on the office phone. To me it looks like an issue with RTP that carries the actual voice packets.

I think that this is the problem area that I'm having issues with. Anything in our internal network is being allowed out but we have fairly few things explicitly allowed in from the internet. I think I may have just had one of those famous aha moments. I'll try some settings in the firewall to allow these ports and forward them correctly.

I don't think I can over state how excited I am that I finally got it to work! Well so far so good. I'll do a lot more testing tomorrow. It all boils down to NAT. You nailed it on the head that it was NAT but I had to dig into SIP to figure out how it worked to realize that the SIP was working great. It initiated the call and connected both ends but it died after that. It was the 1:1 NAT, compromised of a DNAT and SNAT, that I had set up incorrectly. Therefore everything getting sent back to my 172.29.0.198 address was sent back to our ShoreTel box but needed to be sent back to the correct User Agent on the call instead. Once I got the correct masquerading and NAT settings, it worked. So far the firewall is performing like it should and tracking the dynamic ports correctly. Call conferencing, music on hold, transfers, and receiving calls all work. I'll test all the other use cases that I can think of.

SIP will often do one way calls if the firewall mangles the SIP traffic. This is extremely common. Normally this is caused because SIP-ALG (or whatever that vendor calls it) is turned on. You universally want any SIP management on the router shut off and NAT should be handled by the PBX without anything more than STUN settings in the clients.

We just finished deploying Shoretel 13.1. Same problem you have going through a Sonicwall in regards to our mobility router. Even with SIP magic enabled on the Sonicwall, it just did not work. Signaling was fine (ringing, connecting call, etc) but media was either non-existent or one-way. In the Shoretel logs you could see that it took 3 or 4 attempts for the signaling to even succeed.

On the Sonicwall it only occurs when going from an untrusted interface to a trusted interface. So the inbound NAT for mobility was on the DMZ (untrusted interface), then mobility needed access to the private voice network (trusted interface). It just would not work, Shoretel and myself spent a few hours on this.

Much to my dismay we are NAT'ing directly into the private voice network, but at least using an uncommon port. All the problems have gone away.

We just finished deploying Shoretel 13.1. Same problem you have going through a Sonicwall in regards to our mobility router. Even with SIP magic enabled on the Sonicwall, it just did not work. Signaling was fine (ringing, connecting call, etc) but media was either non-existent or one-way. In the Shoretel logs you could see that it took 3 or 4 attempts for the signaling to even succeed.

On the Sonicwall it only occurs when going from an untrusted interface to a trusted interface. So the inbound NAT for mobility was on the DMZ (untrusted interface), then mobility needed access to the private voice network (trusted interface). It just would not work, Shoretel and myself spent a few hours on this.

Much to my dismay we are NAT'ing directly into the private voice network, but at least using an uncommon port. All the problems have gone away.

Can you elaborate on how you have you NATing set up currently? Are you using SIP? If so is you provider ShoreTel certified?

To my understanding ShoreTel uses a more proprietary flavor of SIP and doesn't play well with others. Version 13.1 made ShoreTel much more compatible with industry standards but it is still causing me grief. A certified provider is one that supports ShoreTel's proprietary SIP service .

To my understanding ShoreTel uses a more proprietary flavor of SIP and doesn't play well with others. Version 13.1 made ShoreTel much more compatible with industry standards but it is still causing me grief. A certified provider is one that supports ShoreTel's proprietary SIP service .

Makes me glad, I have what I have. SIP is all the same to my understanding, aside from codecs and things of that nature, its just a matter of the path. Well of course the SLA for each company would be different.

I think it comes down to the carrier. Unlike PRI which is standardized, each carrier has their own specific SIP settings. We use Windstream who is certified, but in the Shoretel we selected the AT&T profile because it matched those settings. Go figure.