SIP behind sonic wall firewall 2

[C0mmUN1cAt0r]

site running sip behind sonic wall and mikrotik router. Relevant ports setup but whenever stun is run, it returns the wrong port of 13265 instead of 5060
have manually set the UDP port and switch run stun at start off, this then gets calls working however, customer complaining that occasionally the calls drop out for a second - not sure if this would relate to the port issue seen on stun.

have tried multiple stun servers but exactly the same result, maintainer of the sonic wall claim they see the stun request go out on port 10000, but return back in on 13265. They have put a route in to push this to port 5060 which allows SIP to work, but still stun returns the wrong port.

We have requested all nat helpers have been switched off on the Sonic Wall/Mikrotik e.g. SIP ALG, but still no luck.

Any ideas?

 

[Pepp77]

Turn off STUN and network topology on the IPO and turn on SIP transformations and consistent NAT on the VOIP Tab of the Sonicwall. Works for us.

| ACSS SME |

 

[janni78]

You shouldn't need STUN on a Sonicwall if the right ports are open, I never use STUN for SIP trunks.

Using SIP transform in Sonicwall will limit the trunks for how many the Sonicwall can handle and could be less than the number of SIP trunks you have.

"Trying is the first step to failure..." - Homer

 

[Pepp77]

Janni, how do you get the public IP address to the provider then, using network topology translates the internal IP address to the address in the network topology tab within the SIP packets if you use it, if not the provider receives the internal IP address and thus calls fail. SIP transformations does the same thing. Or are you saying set the trunk to use network topology but leave the STUN field blank and if so what do you set the firewall type to?

However what I would say is the simplest solution is to stick a nice sonus SBC in place and make it so simple to configure SIP trunks.

| ACSS SME |

 

[janni78]

I set the Public IP in Network Topology, set Firewall/NAT Type to "Static Port Block" and turn off "Run STUN on startup".

"Trying is the first step to failure..." - Homer

 

[Pepp77]

Ah that is what I thought you had done, does that work okay if you are using one-x mobile?

| ACSS SME |

 

[janni78]

We never use One-X Mobile =) Only place I ever tried One-X Mobile was in lab.

In Sweden we have a service in the mobile network that let you route all mobile calls through the PBX, we also use a 3rd party mobile app that does that and a lot more.

"Trying is the first step to failure..." - Homer

 

[C0mmUN1cAt0r]

thanks for the replies, just prior to us requesting the change, would you say this could highlight the cut offs in the calls?
Currently SIP works inbound/outbound full audio paths but with the occasional cut off.

 

[C0mmUN1cAt0r]

also @ janni, do you manually set port 5060 UDP in the public port under network topology, or leave it blank?

 

[C0mmUN1cAt0r]

have tried this now, I am using FNE mobile to test, now when I dial in, I get dial tone, but cant break it with DTMF - if I swap back to how it was with Stun it allows me to dial out ok..

 

[janni78]

I set the public port to 5060.
With this settings they need to port forward 5060 from the SIP provders adress and the IPOs RTP ports.

Make sure you use the RTP range descibed in the 9.1+ Manager help files and not the old 49152-53246 range ss those ports are used for other IPO services.

"Trying is the first step to failure..." - Homer

 

[C0mmUN1cAt0r]

if stun is changed to nothing, then it goes to one way audio. Putting the stun back fixes after reboot, though I don't have stun run at startup and set the port 5060 manually.

 

[DavidCT]

Here's a document my company wrote for SonicWALLs using Flowroute SIP. You can use it as a guide.

https://support.flowroute.com/customer/en/portal/articles/1852982-configure-sonicwall-firewall-

Note: you may need to ENABLE the options in step 2, not disable. Test and determine.

On the IPO, as others said, turn stun off. Also set network topology to none.

 

[janni78]

The RTP range in this document should not be used.
IMPORTANT: The RTP Port Range will vary depending on your PBX. Please do NOT use Port Range 49152-65535 unless you have an Avaya system.

Recommended ports are as stated in Manager help

Port Range (minimum) IP 500 v2 default = 46750. Range = 46750 to 50750.
Linux default = 40750. Range = 40750 to 50750

Port Range (maximum) IP 500 v2 default = 50750. Range = 46750 to 50750.
Linux default = 50750. Range = 40750 to 50750

"Trying is the first step to failure..." - Homer

 

[DavidCT]

Janni,

I had an open ticket with ipo support about vmpro audio issues, and they told me to infact change the rtp range to pre 9.x settings.

 

[janni78]

Why would that fix VM Pro audio issues?
And it doesn't mean it's good advise =)

"Trying is the first step to failure..." - Homer

 

[DavidCT]

I took the advice with a grain of salt. However, it did solve the problem we were having, so tough to call it bad advice.
Also, we've had no issues with our SIP trunks, which is the goal of the original poster.

I guess we wait and see if C0mmUN1cAt0r updates us with his findings.

 

[jamie77]

STUN and Sonicwall don't like each other, this has been confirmed by Sonicwall themselves. I've never been able to get our Gamma SIP working with STUN over a SW, but OXM works fine!! SIP ALG on Sonicwall works fine 99% of the time!!

Jamie Green

[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer

 

[janni78]

The issue with that RTP range is that it includes other IPO ports that can be used for hacking, that's why they changed it =)

"Trying is the first step to failure..." - Homer

 

[C0mmUN1cAt0r]

update is currently still looking into, if we make changes one side then it seems to break something else (mainly 1 way audio)

I thought the port remap setting providing in the document that DaveCT sent over could have been relevant though on the sonic wall the option is only available for inbound routes to change the source IP. In this scenario, I don't know how this could help? - sonic wall documentation on this below

When this option is selected, SonicOS preserves the source port of the connection while executing other NAT mapping. This option is available when adding or editing a NAT policy if the source IP address is being translated. The checkbox cannot be selected if the Translated Source is set to Original.