Microsoft UC & VPN
Let's have a look at how to handle Microsoft Lync and VPN configurations.
====
As I've said previously on my site here I spend most of my time designing Unified Comms systems, now predominantly around Microsoft architectures. There's reasons for that - Why UC? (Update: Also related UC - Why so hard?).
I also get involved in normalising/rectifying/stablising systems that have already been deployed. With UC platforms it's not that hard other a solution to 80% deployed and operational with little UC knowledge…and yet it's that last 20% of deployment that can utterly ruin a user experience.
Anyway, on that ruining a user experience piece, two networking things that I see a lot of that tends to fly under the radar at the design phases are VPNs, and Proxy setups. Media does not play well with a proxy system…but nor do VPNs. I'll talk about the Proxy issues in another post, but lets look at VPNs first.
So, whats the beef with VPNs? It's really down to the fact that operating over a VPN can seriously degrade media performance to the point that it irritates the users. The reason for it is that the process of pushing traffic through an encrypted VPN tunnel seriously impacts jitter and latency figures for the media connection - mainly through the additional workload of additional encryption and decryption. Lync/Skype traffic is already encrypted - signalling via TLS and media via SRTP. so pushing it through a VPN just means you're encrypting already encrypted traffic. Hardly efficient.
Now, Microsoft's architecture has a model in place for just this scenario - the Access Edge topology. Media relayed through the Edge is designed to provide a high quality experience over uncontrolled networks.
The problem is though how do you stop users sending their traffic over the VPN when they want to make a call? It's not as if you can ask them to disconnect from the VPN to accept or make a call can you? Well, there is a way, but it does take a bit of planning - namely configuring a split tunnel VPN configuration.
What you want to achieve is all your normal traffic goes via the VPN except any Skype/Lync traffic - you want that to go to the Access Edge servers. Split Tunnel VPNs are not that unusual and most VPN platforms support the capability - there's something else you need to consider however, and that's the client connectivity logic.
Imagine the scenario where you enable split-tunnel on your VPN so that your Lync clients can connect to the Access Edge servers. The problem you'll run in to is that the Lync client will first check for internal connections to the Front End servers using either LyncDiscoverInternal or other DNS entries - if it find them and the front-end servers then it will connect via the VPN tunnel regardless of the ability to connect to the Access Edge.
So, how do you fix this? Well, explained simply the way to fix it is to ensure that not only do you allow the split-tunnel for the client but you also block access to the Front End Servers. Essentially you need a firewall rule that blocks:
There's numerous ways of achieving this. You can even achieve it using Windows Firewall policies for example, however for the most part it's easier to configure at either a firewall or VPN platform level. The Windows firewall policies for example wouldn't apply to Mac users or people using systems that don't receive those policies.
VPN configurations are one of those things that add to the quality of experience of using a platform, making the user's situation stable, repeatable, and positive. Will the product work through a VPN? For the most part, yes - your users won't thank you for it though.
blog comments powered by Disqus