Everything You Wanted to Know About Microsoft Lync and Sonicwall Firewalls


sonicwall and lync

Note: This article is as of Sonicwall Firmware version: SonicOS Enhanced

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 I suspect) Another challenge is that most Sonicwall engineers are not spending their days thinking about VoIP, much less Microsoft Lync and SIP over TCP.

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 with 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. (shown below)

why ALG no worky for lync

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.

why don't lync calls show in call status

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 warnings on forum posts 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

voip settings

[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?

According to this forum post notes this:

”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 it 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.

  1. Go to Firewall Settings | BWM
  2. Check “Global”
  3. Set how you want your Priorities to act
  4. Click “Accept” button.


Below is an example/sample of what BWM Settings may look like:


Next configure an Interface to have BWM enabled:


On the next  screen you designate what bandwidth is available on this interface. (To ensure you didn’t switch egress/ingress numbers do a quick bandwidth check using


Next go to Firewall | Access Rules and Edit your LAN > WAN and WAN > LAN rules for Lync media (and other) ports. (You will want to assign the “Realtime” priority to these rules)


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)

bwm monitor1


How Do I test that Ports Are Actually Open?

Please see my article “How to Verify Lync Edge Server Ports Are Open”:

Is My Sonicwall Device Correctly Sized to My Environment?

If you are noticing that your Sonicwall limits download speeds it could be that the Sonicwall device CPU cannot handle that bandwdith while doing DPI and you may need to upgrade to a unit with more CPU. You can check CPU on below screen. (And momentarily turn off DPI and/or IPS to test if unit can do full bandwidth then)


SIP Trunks Consistently Disconnect After Specific Amount of Time: Reinvites (Keep Alive) May Be the Culprit

SIP trunk providers will send a RE-INVITE (KeepAlive) after a specified amount of time. (For Intelepeer this is 15minutes if you don’t have Lync and 90 minutes if do have Lync). If you are noticing consistent disconnect at 90 minutes this means your Lync Server is not responding to this RE-INVITE and disconnecting the call. You can resolve this by having Intelepeer increase the RE-INVITE timer to a longer period. (preferably higher than what your longest calls are)

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 tells Lync to do this
  • Appears SIP signaling uses Sonicwall WAN>LAN rule

SIP Trunk Traffic Examine Notes

Typicall SIP trunk traffic: Note solid RTP from remote user to Lync user. (first arrow represents 1 SIP trunk call and second is second SIP trunk call.)image

SIP trunk call put on hold by Lync user: Note that traffic stops from remote party and Lync MOH creates solid RTP to remote party.image

Sonicwall Firmware Notes

SonicOS Release Notes youtube for schools support, fixes

MAC Address Manufacturer Look Up:
PSTN Echo Test:+1 703-376-ECHO (3246)
Sonicwall Now Categorizes Lync Traffic as VoIP-APPS IPS signature category : Click Here


  1. thanks for this post. we have our lync mediation server behind a sonicwall firewall. i called intelepeer and had them turn off ALG. that fixed my one way voice issue right away.

  2. @Viet Ao, glad this blog article was helpful!

  3. Hey Matt,

    I am facing Inbound calling issue with my Cisco ASA. I am using dedicated Mediation server two Network cards. One facing Internal Network without Gateway & other facing my DMZ network with gateway.
    I have added required routes on mediation server for Internal network traffic.

    I do not have any issue with Outbound calling but inbound calling fails intermediately.

    Do you have suggestion on the same.

    Thanks in advance.

    1. Santosh, I'm not a cisco Asa expert, i suggest posting to the cisco or Lync forums to have people weigh in. thanks for contributing

  4. Matt - Two quick questions - is the scenario above for a Lync Server inside the firewall with Lync clients connecting from outside or is this for Lync clients inside the firewall connecting to a Lync server outside, like with an Office 365 scenario?

    Also - you mention Lync Media Ports and and have a LYNC-SIP-TRUNK-GRP service group defined. Can you share what's included in that group?

    1. @rob lync server is inside the firewall. this blog is generally talking about your lync datacenter.

  5. This comment has been removed by the author.

  6. Matt,
    I've followed the suggestions in your blog. After two days of testing with Intelepeer, and escalating the issue with Sonicwall, it appears that I will have to find a new SIP provider (or firewall, which won't happen.)
    Sonicwall claims:
    The NAT policies and access rules are configured properly. The NAT'ing happens in the network layer but on the application where the SIP lies the server is sending the request out (to Intelepeer) using its private ip address rather than the public ip. So please make sure that the server is doing the transformation for SIP.

    Just wanted to make sure others don't waste a lot of needless time if they are planning on using Sonicwall with Intelepeer, unless I am missing something...but I have no higher up to go with either vendor.

    1. Mike, what sonicwall model and firmware version are you using?


    2. Matt,
      I finally fixed the issue. I had to uncheck the Enable Central Media Processing option and everything started working.

      We are using a Sonicwall NSA 2400.
      Firmware SonicOS Enhanced

      I appreciate all your valuable information!

    3. @mike,

      Glad you got your Lync Server properly configured. I note now that this post largely focus' on getting the firewall configured correctly.

      For the benefit of others: If you have Lync configured to do media bypass, "centralized media processing" is often also configured.

      More on "cnetralized media processing":

  7. I read through your blog post on Lync, SonicWALL and IntelliPeer with keen interest. We are suffering through a Lync installation now.

    We have occasional (10%) one-way audio. We contacted IntelliPeer and asked them to turn off ALG. Now we have 100% one-way audio. Our 'partner' is advising us to install a SBC, but it feels like that is based on the 'if you have a hammer, every problem appears as a nail' philosophy.

    Our installation is standard, perhaps with the exception of SonicWALL. We have monitoring installed and configured.

    Can anyone help us minimize our audio difficulties?

    1. @Nicholas one way audio indicates improperly configured firewall rules.

      1 trick is to clean house: remove all rules AND related objects and reconfigure them.

      Also, you might try the "How do i test ports are open" section, substituting edge ports for your SIPtrunk IP & ports.

      Also, are you on the latest sonicwall firmware?

      ps-If this works, just send wendell payment. thanks.

  8. Matt,

    I am in the same boat as Nicholas with about 10% one way audio. I am not doing any outbound blocking on the SonicWall NSA3500. Someone on the Microsoft support forum advised me to a) turn off Central Processing (done) and b) buy an SBC.

    Given that this an intermittent problem, I am not sure how to track it down.

    For a supported configuration and light usage (fewer than 10 trunks) an SBC does not make financial sense.

    Any ideas?

    Thanks in advance!

  9. This comment has been removed by the author.

  10. We have a situation where we are using NAT with a Sonicwall. We have configured everything it seems correctly because we can receive and make calls to Intelepeer (sip provider). Now the problem comes when we setup call forwarding to an outside number in Lync. The call initiates but there isn't any rtp traffic flowing, and we don't get audio either way. Does anyone have any idea what is going on? Any advice?

    1. Hi, I seen some people talking here that they have a SIP Trunk through NAT using a SonicWall Firewall. That's amazing, I would like to know how you do that.
      I have the Centralized Media Processing Off, and my Lync environment still send the invite to the SIP trunk using a Contact or Via with a Private IP.
      In the SonicWall I have the Consistent NAT and the Sip Transformations turned off.
      I'm wondering if the only solution for that is to get an SBC to handle the communications with the sip trunk.
      Thanks in advance.

  11. Hi, I would like to know how to configure reverse proxy server in sonicwall NSA2400 for Lync 2010.As now we r using dedicate reverse proxy server for the same.

    Thanks in advance


Note: Only a member of this blog may post a comment.