is anyone running Asterisk pbx on a sonicwall.i currently use a Sonicwall tz300 and although once working i am now unable to receive incoming calls.i can make outgoing calls therefore i am now thinking this is firewall related, the pbx server sits on the lan but then routes out through a seperate gateway.is anyone able to provide a screenshot of their firewall/nat rules to highlight where i might be going wrong.?
I think someone posted an article about getting SonicWALL and FreePBX working a couple of months ago. Use the search function and see if you can find it.
Me, and it’s here:
I have literally hundreds of phones deployed behind MANY SonicWALL’s - Ask me anything - but read the article - all the settings are there - but read all the responses - the “Disable Source Port Remap” is ONLY for specific setups.
2 Likes
That is awesome, looks like you have felt this pain before, i’ve set a new isolated network up with a clean Sonicwall i’ll try these settings in the morning and report back my results, thank you
What is the quickest way to confirm call is passing though sonicwall and hitting pbx (without the obvious off receiving a call)
Look at the Asterisk CLI and see what is happening there.
asterisk -vvvvvr
Or do a packet capture on the Sonicwall and see if packets are forwarded to PBX.
ok wasted more time on this today.
some background so setup is Sonicwall TZ300 using main gateway on interface X1 (public 91.xx.xx.xx)
we then have our Voip providers Gateway connected into interface X3 this sits on our lan with an ip of 172.130.xx.xxx (public ip 51.xx.xx.xx)
i created the service objects for port 5060 and 10000 - 2000 and added them to a service group
i then ran the wizard to create the rules - quick point here when asked for the public ip i added the sonicwall’s not the voip gateway???
this created the nat and firewall rules:
i edited the disable port re map (tried with both options)
set enable consistent Nat
connected to pbx with command asterix -vr
made an incoming call and sat back.
output
as you can see only the maintenance requests nothing else - weirdly i got nothing showing for outgoing either even though the call does go through.
so at this point is the issue with the firewall rules ie as stated above i need to use the voip gateway public ip in wizard although tried this and no joy.
or is something else afoot?
packet monitor on sonicwall shows the following - i’m not convinced i have this configured correctly if anyone can provide some guidence.
There is your problem - When you run that rule, you are selecting X1 as the Inbound/Outbound interface - Here:
When you run the Wizard, you need to pick the IP of X3 as the Public IP - then the rules will reference X3 as the route to go out through.
If the ITSP is the only outside SIP Source/Destination, switching it to X3 will fix the problem - If you have SIP clients connecting to the the PBX through X1 (Outside -> X1-IP -> PBX) then you are going to have to get trickier and create Static Routes on the SonicWALL that say when any traffic is destined for the ITSP, use X3.
You are almost there!
thanks Greg
ok removed nat settings and re ran the wizard using X3 public ip
still no incoming.
i wish i was nearly there spent weeks on this.
No. you are close - it’s just frustrating - from the CLI on the box, do a traceroute to your ITSP’s IP and post the results - it will tell us if it is using the proper gateway.
ok so ran it from ssh and got the following
so that is a traceroute to the internal ip of the gamma router
i can run a straight ping to same address and get a reply
Double Natting? No, something’s not right - What is your Internal Subnet and what is the IP of the ITSP you are trying to connect to?
So the following IP’s:
IP of the PBX.
IP of X0 of the SonicWALL
IP of X3
IP of the ITSP’s SBC (The IP you are connecting the trunk to)
If that is an IP on your internal LAN, the PBX should not be going through the SonicWALL at all - you should set a static route on the PBX to use the Gamma Router (?) as the gateway to get to the IP’s associated with your ITSP.
Sorry Greg just to Clarify
so the pbx server sits on our Lan and has a gateway of the gamma router. which has an internal ip on our lan
IP of the PBX. - 192.168.30.251
IP of X0 of the SonicWALL 91.xx.xx.xx
IP of X3 - connected to the providers router which has an internal ip of 192.168.30.253 and public ip of 51.xx.xx.xx
IP of the ITSP’s SBC (The IP you are connecting the trunk to)
Ok - That was weirding me out there - so from your PBX, do a traceroute to the IP of the TRUNK you are sending the traffic to - for example, for Vitelity in my trunk definition for the outbound leg, I have
so from that PBX, here is what a traceroute to that address looks like:
[root@pbx-bdc ~]# traceroute outbound.vitelity.net
traceroute to outbound.vitelity.net (64.2.142.106), 30 hops max, 60 byte packets
1 xx.xx.xx.xx.bigleaf.net (xx.xx.xx.xx) 0.732 ms 0.802 ms 1.066 ms
2 100.90.39.1 (100.90.39.1) 27.298 ms 100.90.38.1 (100.90.38.1) 40.929 ms 100.90.39.1 (100.90.39.1) 27.294 ms
3 162.219.101.57.bigleaf.net (162.219.101.57) 41.270 ms 41.366 ms 27.930 ms
4 162.219.102.33.bigleaf.net (162.219.102.33) 28.056 ms 39.865 ms 41.685 ms
5 208.184.31.181.available (208.184.31.181) 26.804 ms 28.665 ms 42.145 ms
6 ae11.cr1.dfw2.us.zip.zayo.com (64.125.20.65) 41.613 ms 39.466 ms 41.171 ms
7 ae27.cs1.dfw2.us.eth.zayo.com (64.125.30.180) 63.991 ms 63.980 ms 63.968 ms
8 ae0.cs2.dfw2.us.eth.zayo.com (64.125.28.123) 51.211 ms 64.600 ms 64.672 ms
9 ae7.cs2.dfw2.us.eth.zayo.com (64.125.31.236) 64.239 ms 50.575 ms 64.419 ms
10 64.125.30.117 (64.125.30.117) 62.753 ms 64.587 ms 50.749 ms
11 208.185.155.210 (208.185.155.210) 64.977 ms 64.976 ms 64.836 ms
12 * * *
13 * * *
14 66.241.99.254 (66.241.99.254) 64.588 ms 64.580 ms 62.680 ms
15 64.2.142.106 (64.2.142.106) 64.315 ms 62.692 ms 50.976 ms
I have obscured my Bigleaf Gateway but this will show that I clearly can get to the IP I am trying to get to, and how I am getting there - in yours, the very first hop should be the Gamma Router or it’s gateway - if it’s your X1 IP or it’s Gateway, the traffic is not going where it should…
Post yours - obscure the first IP if you need to, but show the first octet so we know where it is going.
no worries sorry i confused myself reading it back.
so just to clear up.
pbx server connected to Lan - ip 192.168.30.251 - Gateway set to 192.168.30.253
Gamma Router - public ip 51.xx.xx.xx - private ip 192.168.30.253 - connected to X3 on Sonicwall
Trunk settings - host 88.215.63.3
our lan is 192.168.30.1/23
i bow to your knowledge if that is a crazy set up, (this is what i inherited and surprisingly did once work)
Traceroute to Trunk Host
Couple of things - A traceroute to that IP from my end dies on the same final hop:
164.39.240.77 (164.39.240.77) 128.897 ms 142.523 ms 144.356 ms
Although you have a much better Round Trip Time to it than I do - so that dedicated router is working, and moreover, your SonicWALL is routing the traffic that direction - so I think your LAN and Firewalls are working correctly and are correctly set up - Congrats.
Saying that, I think you have a simple authentication problem between your box and their SBC’s - because you have connectivity to their network from yours through the right devices.
So the next step would be a simple Packet Capture - Start capturing on the PBX, initiate a call out to them and then stop the capture and open it up in Wireshark - look at the SIP Flow and I am willing to bet you are going to see a reject from them for either a bad secret, or a rejected Source IP.
ok million dollar question here:
how do i do this?
i’m familiar with wireshark but happy to be guided here.
when you say an authentication issue - would this affect traffic both ways? or just incoming?
i can make outgoing no problem.
Ugh - been reading this thread so long I missed that it was only inbound - still though, I think your network is right and a Packet Capture will show what your PBX is seeing when you call it:
It’s a pretty through tutorial on using TCPDUMP to get the packets - then it is just a matter of opening them in Wireshark on your Desktop/Laptop and look and see what is happening.
So start the capture, call your box, stop the capture and open it up in Wireshark and look at the VoIP Calls and then the FLOW - You will see what your box sees and what it is sending back - simple guess (since Outbound is working) is that incoming traffic is coming from an IP you are not expecting - ITSP’s have LOTS of devices for traffic sourcing - might have changed since it was set up.
I am beginning to think this was NEVER a SonicWALL thing…