Note: This article is as of Sonicwall Firmware version: SonicOS Enhanced 220.127.116.11-43o
I’ve been spending the last couple days on and off getting familiar with Sonicwall VoIP features. since there are lot of Sonicwall devices in the field you most likely are going to meet up with one sooner or later. (and this will only get worse with Dell’s acquisition of Sonicwall) (grin) Another challenge is that most Sonicwall engineers are not spending their days thinking about VoIP, much less Microsoft Lync and SIP over TCP. (smile)
What is a Good Way to “Ramp Up” understanding the Sonicwall NAT Configuration process?
This is the exact question I had. I’ve noticed that googling seems to often return old Sonicwall HowTo’s that are a bit hard to follow since the older Sonicwall firmware is just a little different looking. I came across this short PDF manual that I think encapsulates doing simple tasks in Sonicwall well:
Can Sonicwall do SIP ALG for Microsoft Lync? No.
The simple answer is that Sonicwall firewall VoIP features only work on SIP UDP traffic, not TCP traffic that Microsoft Lync uses. (This does not mean that Sonicwall will not work Lync, it just means that there is no need to try to use the Sonicwall VoIP features with Lync at this time.)
Want a source? Open this document and notice on page 15 that you can set another SIP signaling port if it is not the standard 5060…but only for UDP traffic…and Microsoft Lync uses TCP for signaling.
If you want to do some more reading about the Sonicwall VoIP module click here.
Why are Lync Calls Not Shown on the “Call Status” Screen?
The reason Lync calls are missing from the “Call Status” screen is because Sonicwall (as noted above) only displays UDP VoIP calls here and Microsoft Lync uses TCP for call signaling.
How Shall I Configure the the VoIP Settings Screen?
“SIP Transformations” is Sonicwall’s language for what many others call ALG. Should this be turned on or off?
Actually, it doesn’t matter at ALL how you set these items because Sonicwall firewalls can only do “Enable SIP Transformations” (aka ALG, or VoIP/SIP ALG) on UDP traffic and Lync only uses TCP.
So don’t sweat it and you can ignore all the dire warning on the on forum that tell you to turn these settings off. (grin) Well, just to be safe…let’s uncheck them. (just in case some future firmware upgrade does enable them)
- Enable Consistent NAT = Off/Unchecked
- Enable SIP Transformations = Off/Unchecked
[NOTE: If you are using a SIP trunk provider like Intelepeer you will want to make sure you let them know that you have ALG turned Off. They will change a setting on their side to compensate for this.]
Is Sonicwall Planning to Add TCP Support to It’s VoIP Features?
”The Current Implementation of SIP Transformations only affects UDP and not TCP hence we cannot transform SIP over TCP. There is an Enhancement Filed for the same and can be expected in future. No ETA.”
In my opinion this is not urgent as Lync can work fine without Sonicwall SIP Transformations, but would show initiative on Sonicwall’s part.
Something Doesn’t Work Right and I’m on an Old Firmware, Do I Need to Upgrade?
Yes. This is a security device, if you aren’t up to date---you are not being responsible.
Can I Use Sonicwall AppFlow Monitor To Display Microsoft Lync Signaling and Media Traffic?
Absolutely. The Sonicwall AppFlow Monitor lets you easily setup a filter to show in realtime just the traffic you want to see: For example you can easily see SIP Trunk traffic from your Lync Mediation Server, or your Lync Edge Server traffic through your Sonicwall.
Below we have a screenshot of the AppFlow Monitor showing the traffic to a Lync Mediation Server. As you can see, at first there was merely SIP signaling traffic, then 1 SIP trunk call and then after a bit a 2nd SIP trunk call. At any time you can hover over the traffic types (lower left corner of chart) to get how much traffic is passing using that port/ports.)
If Lync Traffic is DSCP Marked Will Sonicwall Prioritize This Traffic Going LAN to WAN/ISP? No
Sonicwall devices can tag traffic with DSCP tags, but the Sonicwall device itself will not prioritize traffic based on DSCP if it is going LAN > WAN. So if you have a Lync Mediation server that is sending traffic to your ISP (and ultimately to a SIP Trunk provider), even if the Lync Mediation server tags this traffic with DSCP, the traffic will not be prioritized through the Sonicwall Firewall Rule. (Use Sonicwall Bandwidth Management to achieve this.) If the ISP honors DSCP the packets will be prioritized once it reaches the ISP.
NOTE: Sonicwall can prioritize DSCP traffic traveling through a Sonicwall VPN.
How to Setup BandWidth Management? (referred to as BWM)
Here are the steps to get BWM working with your Microsoft Lync Traffic.
- Go to Firewall Settings | BWM
- Check “Global”
- Set how you want your Priorities to act
- Click “Accept” button.
Next go to Firewall | Access Rules and Edit your LAN > WAN rule for Lync media ports.
Now click on “Ethernet BWM” tab and
- check/Enable Outbound Bandwidth Management and set Bandwidth Policy to “0 Realtime”
- check/Enable Inbound Bandwidth Management and set “Bandwidth Policy” to “0 Realtime”
Now everything should be setup. Below you can go to Dashboard | BWM Monitor and see our traffic. The to graph will show Real-Time traffic and the bottom graph (note this picture is photo-shopped together) shows the Medium priority traffic (in our case everything else)
How Do I test that Ports Are Actually Open?
Please see my article “How to Verify Lync Edge Server Ports Are Open”: http://windowspbx.blogspot.com/2013/01/how-to-verify-lync-edge-server-ports.html
How to Setup 1 to 1 NAT?
This is a blog post all in itself. Watch for a post coming…
Bottom Line: Sonicwall and Lync work together just fine, but you need to understand both well.
Sonicwall will do 1 to 1 NAT’s just fine. Sonicwall currently does not do ALG but Lync Certified SIP trunk providers should be able to configure their side to avoid the need for ALG on your firewall. The biggest take away is that Sonicallwall VoIP features do not work on TCP traffic at this time.
Footnotes & Misc Links
SIP Trunk Traffic Notes:
- RTP seems to always use Sonicwall LAN>WAN rule. (Egress=From Lync Server; Ingress=From SIP Trunk/Remote Party)
- SDP tell Lync to do this
- Appears SIP signaling uses Sonicwall WAN>LAN rule
Sonicwall Firmware Notes
|SonicOS 18.104.22.168||Release Notes||youtube for schools support, fixes|
Some helpful Tools when investigating rogue traffic:
MAC Address LookingUp: http://aruljohn.com/mac.pl
PSTN Echo Test:+1 703-376-ECHO (3246)