[asterisk-users] Asterisk behind Sonicwall firewall

[Rich Adamson]

Barry Fawthrop wrote:
> Hi all
> 
> I didn't change anything that's my point
> It has be running and working just fine then at 4:32 pm yesterday I 
> could not make or recieve VoIP calls via our VoIP Provider
> They say the Invite packet was being rejected and thus there was no 
> "real" connection  even though SIP SHOW PEERS has us registered
> 
> They also say it's due to the Sonicwall which has changed port 
> assignments and thus blocking ports.
> I see in the Sonicwall log UDP Packet Dropped with the Providers IP 
> Address but it talks about port 36612 which is not SIP
> 
> They say along with the log that SIP is using 36612 why when all the 
> VoIP SIP setting are enabled/configured and SIP is packet forwarded to the
> Asterisk Box due to Sonicwall NAT

Are you sure that you're not confusing the SOURCE vs DESTINATION port?

Your system would send a sip packet to your provider with a destination 
port of udp/5060, but your source port can be anything greater then 
1024. (That's likely to be 36612 in your notes, above.)

Your provider would reverse those in its response, sending their packet 
to the destination port of udp/xxxx (the same greater then 1024 
mentioned above), and a source port of udp/5060. That's just standard IP 
stuff.

The nat function within the firewall keeps track of every udp and tcp 
conversation by building a table entry that includes source IP and 
source port (associated with the internal lan device that created the 
packet), and a destination IP and destination port (associated with your 
provider's device. That table entry is constantly referred to for every 
packet that passes through the firewall in either direction, translating 
private addresses into public addresses, etc.

If the conversation is "udp" based, that table entry will timeout (and 
disappear) after some period of time. I don't recall what the default 
sonicwall timeout value happens to be, but its typically some number of 
low minutes (as opposed to low number of seconds).

If the conversation is "tcp" based, that table entry will disappear when 
the tcp session is closed by the end devices. I can only guess that a 
tcp timeout value exists as well, however it would oriented around 
timing out a table entry where the end devices mysteriously disappeared 
(without closing the tcp session).

Sonicwall sells their products with 10 user, 25 user, and other limits 
that would imply the above nat table size might have limits (or changes) 
when that maximum is reached. Are you sure you've not exceeded the 
license limit associated with your sonicswall?

Sonicwall also has a problem handling udp packets that are greater in 
size then 1458 bytes (I think I have that value correct) when its wan 
interface is configured for PPPoE. Packets larger then that value are 
simply dropped on the floor, and no log entries are created to hint that 
has happened. Are you using PPPoE?

Finally, sonicwall has implemented some sort of sip fixup that attempts 
to analyze the contents of a sip packet to determine which udp ports are 
to be used for rtp packets. I wouldn't think this function would have 
any impact in your case since it sounds like the problem is sip oriented 
and not rtp oriented. You could turn that option off just to ensure it 
isn't the problem.

To diagnose this any further really requires a packet sniff (eg, 
ethereal) from the outside edge of the firewall, along with an asterisk 
'sip debug'. That would help determine what might be happening in terms 
of port mapping, etc.