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?

 

[janni78]

It's pretty simple, but since you can't see what they've actually done in the FW it can be hard.

In IPO you set the RTP range to 46750 to 50750.
Set the public IP in network topology and set FW Type to Static Port Block.
Set SIP trunk to use Network Topology on LANx.

In the Sonicwall they port forward UDP/5060 (or TCP if the SP uses that) from the SIP providers IP to the IP Office.
They also port forward UDP/46750-50750 to the IP Office, it the service provider can say which server their RTP originates from only those should be allowed in the FW.
All SIP transformation / ALG / Policy-Inspection or whatever they call it should be turned off.

If they block outbound they need to open for traffic on 5060 and the RTP ports used by the service providers.

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

 

[C0mmUN1cAt0r]

Hi janni,
its as you say, we can only presume features on the firewall have been disabled (9/10 they haven't and something somewhere is causing issue!!)

The only thing we cant do to what you mention above, is set Static Port Block - as soon as we do, we get 1 way audio, same if we turn off the stun - everything else you mention has been requested

We did have different ports configured initially and since these have changed things look better.

My gut instinct on this one is that the firewall isn't sitting purely on public internet, and something else could be causing the issue further down the line which we have no visibility of.

one other thing of note on this is that they played around with consistent nat - switching it off caused 1 way audio, switching it back on fixed, so maybe one for people to watch out for

 

[C0mmUN1cAt0r]

still having problems, have managed to capture the issue on monitor (IP address masked for obv reasons)

is the firewall going to be causing this slight packet loss?

14:51:49 81691335mS H323Evt: SESS 29: RTP(END): 192.168.x.x/46750 x.x.x.x/21718 CODEC=Alaw64K(4) PKTSZ=160 RFC2833=on AGE=35551 SENT=1224 RECV=1582 RTdelay=0 jitter=0 loss=256 remotejitter=0 remoteloss=0