Sonicwall TZ200 Blocking SIP Port 5060 50% of the Time when I have rules open to forward them to the Asterisk Phone System
I am having a problem with my SIP based phone calls getting through my Sonicwall TZ200 to my TrixboxCE Phone System. I only get my phone system's automated attendant to answer around half the time, the other times the packets are justed dropped.
I am not sure why some UDP port 5060 packets are dropped and other times they are allowed through and forwarded to the Phone system like the NAT Policies are configured.
I have used the Sonicwall's Packet Capture page to capture all packets from my SIP Providers IP Address. As you can see the first two were dropped and therefor the first two calls never made it to my phone system to initiate the call. Then packet 3 and 4 were successful port 5060 packets being forwarded to the phone system to set up the call.
Any Ideas?
*Packet number: 1*
Header Values:
Bytes captured: 1445, Actual Bytes on the wire: 1445
Packet Info(Time:12/05/2010 19:47:34.480):
in:X1*(interface), out:--, DROPPED, Drop Code: 37, Module Id: 26, (Ref.Id: _4193_txGsIboemfJqQlu), 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:1f:e1:7e:7c:92], Dst=[00:17:c5:3f:32:25]
IP Packet Header
IP Type: UDP(0x11), Src=[SIP Provider], Dst=[My WAN IP]
UDP Packet Header
Src=[5060], Dst=[1366], Checksum=0x9949, Message Length=1411 bytes
Application Header
Not Known:
Value:[0]
*Packet number: 2*
Header Values:
Bytes captured: 1445, Actual Bytes on the wire: 1445
Packet Info(Time:12/05/2010 19:47:36.528):
in:X1*(interface), out:--, DROPPED, Drop Code: 37, Module Id: 26, (Ref.Id: _4193_txGsIboemfJqQlu), 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:1f:e1:7e:7c:92], Dst=[00:17:c5:3f:32:25]
IP Packet Header
IP Type: UDP(0x11), Src=[SIP Provider], Dst=[MY WAN IP]
UDP Packet Header
Src=[5060], Dst=[1366], Checksum=0x9949, Message Length=1411 bytes
Application Header
Not Known:
Value:[0]
*Packet number: 3*
Header Values:
Bytes captured: 739, Actual Bytes on the wire: 739
Packet Info(Time:12/05/2010 19:48:44.448):
in:--, out:X1*, Forwarded, 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:17:c5:3f:32:25], Dst=[00:1f:e1:7e:7c:92]
IP Packet Header
IP Type: UDP(0x11), Src=[MY WAN IP], Dst=[SIP Provider]
UDP Packet Header
Src=[1366], Dst=[5060], Checksum=0x5367, Message Length=705 bytes
Application Header
Not Known:
Value:[0]
*Packet number: 4*
Header Values:
Bytes captured: 436, Actual Bytes on the wire: 436
Packet Info(Time:12/05/2010 19:48:44.480):
in:X1*(interface), out:X0, Forwarded, 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:1f:e1:7e:7c:92], Dst=[00:17:c5:3f:32:25]
IP Packet Header
IP Type: UDP(0x11), Src=[SIP Provider], Dst=[MY WAN IP]
UDP Packet Header
Src=[5060], Dst=[1366], Checksum=0xab3e, Message Length=402 bytes
Application Header
Not Known:
Value:[0]
I am not sure why some UDP port 5060 packets are dropped and other times they are allowed through and forwarded to the Phone system like the NAT Policies are configured.
I have used the Sonicwall's Packet Capture page to capture all packets from my SIP Providers IP Address. As you can see the first two were dropped and therefor the first two calls never made it to my phone system to initiate the call. Then packet 3 and 4 were successful port 5060 packets being forwarded to the phone system to set up the call.
Any Ideas?
*Packet number: 1*
Header Values:
Bytes captured: 1445, Actual Bytes on the wire: 1445
Packet Info(Time:12/05/2010 19:47:34.480):
in:X1*(interface), out:--, DROPPED, Drop Code: 37, Module Id: 26, (Ref.Id: _4193_txGsIboemfJqQlu), 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:1f:e1:7e:7c:92], Dst=[00:17:c5:3f:32:25]
IP Packet Header
IP Type: UDP(0x11), Src=[SIP Provider], Dst=[My WAN IP]
UDP Packet Header
Src=[5060], Dst=[1366], Checksum=0x9949, Message Length=1411 bytes
Application Header
Not Known:
Value:[0]
*Packet number: 2*
Header Values:
Bytes captured: 1445, Actual Bytes on the wire: 1445
Packet Info(Time:12/05/2010 19:47:36.528):
in:X1*(interface), out:--, DROPPED, Drop Code: 37, Module Id: 26, (Ref.Id: _4193_txGsIboemfJqQlu), 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:1f:e1:7e:7c:92], Dst=[00:17:c5:3f:32:25]
IP Packet Header
IP Type: UDP(0x11), Src=[SIP Provider], Dst=[MY WAN IP]
UDP Packet Header
Src=[5060], Dst=[1366], Checksum=0x9949, Message Length=1411 bytes
Application Header
Not Known:
Value:[0]
*Packet number: 3*
Header Values:
Bytes captured: 739, Actual Bytes on the wire: 739
Packet Info(Time:12/05/2010 19:48:44.448):
in:--, out:X1*, Forwarded, 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:17:c5:3f:32:25], Dst=[00:1f:e1:7e:7c:92]
IP Packet Header
IP Type: UDP(0x11), Src=[MY WAN IP], Dst=[SIP Provider]
UDP Packet Header
Src=[1366], Dst=[5060], Checksum=0x5367, Message Length=705 bytes
Application Header
Not Known:
Value:[0]
*Packet number: 4*
Header Values:
Bytes captured: 436, Actual Bytes on the wire: 436
Packet Info(Time:12/05/2010 19:48:44.480):
in:X1*(interface), out:X0, Forwarded, 0:0)
Ethernet Header
Ether Type: IP(0x800), Src=[00:1f:e1:7e:7c:92], Dst=[00:17:c5:3f:32:25]
IP Packet Header
IP Type: UDP(0x11), Src=[SIP Provider], Dst=[MY WAN IP]
UDP Packet Header
Src=[5060], Dst=[1366], Checksum=0xab3e, Message Length=402 bytes
Application Header
Not Known:
Value:[0]
digitap
login to the sonicwall and got to VoIP > Settings. what's configured there? is SIP and H.323 enabled?
ASKER
Consisted NAT is enable on VoIP Page. I have not enable the SIP Transformation portion of that page. I had problems with my calls getting in at all about a year ago when I set all this up. Just now though, I am having problems with some calls getting through and other not. I could try to enable this setting again and find out I guess.
when i worked on video conference equipment last month, i had opened the firewall with the appropriate ports. it should have worked, but i discovered the h.323 function was not enabled. when i enabled it, it worked perfectly.
Did this problem just start?
ASKER
Actually yes, this all started because I moved the Phone System from location to another. Both have a TZ200 Firewall with site to site VPN tunnel connecting them. Tomorrow I will just have to strictly analyze the NAT Forwarding Policies on both Sonicwalls to see if there is a small difference somewhere. I will let you guys know.
Digitap: I enable the SIP Transformations and it stopped all calls from coming in. As soon as I disable it, I was able to get calls every now and then. My system does not use the H.323 protocol, so that would not affect anything. I am purely SIP based products.
Digitap: I enable the SIP Transformations and it stopped all calls from coming in. As soon as I disable it, I was able to get calls every now and then. My system does not use the H.323 protocol, so that would not affect anything. I am purely SIP based products.
ok...perhaps the timeout for UDP (possibly TCP) needs to be increased. when you confirm the NAT policies, also check these settings under the Advanced tab for the VPN > LAN and LAN > VPN firewall access rule(s) being utilized. default is TCP 15 seconds and UDP 30 seconds.
Yes, sounds like h.323 is the answer, but pull up both sonics and do a side by side run through. Look at everything. I assume both are same firmware as well?
Ahh.. ok h.323 is not the answer :-) I spoke too soon!
yikes! forgot about firmware!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
great! glad you got it.
ASKER
I came across the solution myself.. Thanks for all the help trying to solve my problem.