Freigeben über

Fire(wall)fighting Lync and Service Bus

  • Artikel

I once went to a security conference presentation where the speaker explained that blocking ports in your firewall was fine, but developers simply get round this limitation by making everything work over HTTP through port 80. And it seems, in most cases, he was correct. However, I sometimes encounter situations where something that should just work doesn't and I end with my head in the server cabinet, swearing profusely as I analyze my ISA Server logs to figure out what I need to do to fix it.

I suppose my natural paranoia that requires firewall rules set up to block outbound traffic except for the standard required ports doesn't help. I even had to set up extra rules that allow traffic out to Team Foundation Server (TFS) over the various ports that we use here at MS. However, most stuff just works as it should. Until I installed Lync, that is.

We use Lync for all of our conferencing, phone, sharing, and interactive online meetings. It's a great environment, and generally works well unless my wife is watching the latest YouTube viral video at the same time. The client (kind of) works OK over just HTTP through the "normal" ports. However, to get the best audio quality, it seems that you need to open some extra ports. There's several lists on MSDN, though most include all of the server ports as well. So I braved the server cabinet once again and came up with the following firewall configuration that works well for me:

Access to Lync Server from Lync Client

  • Rule Type: Allow
  • Rule From value: Internal
  • Rule To value: a Domain Name Set containing:
    • *.your_Lync_server_domain
    • *.your_email_domain
  • Rule Protocols list:
    • IKE Client (pre-defined rule)
    • Port 3478 UDP, Send Receive
    • Ports 50000 to 59999 UDP, Send Receive
    • Ports 50000 to 59999 TCP, Outbound
    • HTTP (pre-defined rule - required only if not enabled in default client access rules)
    • HTTPS (pre-defined rule - required only if not enabled in default client access rules)

Note that this configuration does not allow for some peer-to-peer connections that can reduce the load on the Lync server.

So having fixed my Lync with the outside world (sorry), I start playing with an example application for our forthcoming guide "Integrating Applications with the Cloud". It uses Azure Service Bus Queues and Topics, which also need some packets to be able to escape though the firewall. I guess it was no surprise to find that this failed to work without some additional rules.

Having perused the MSDN docs and some blog posts, it seems that there are several differences of opinion on this. The MSDN docs say that Server Bus Queues use ports 9350 - 9353, but the first time I ran the example it decided to use port 9354. In the end I opened 9350 - 9355 outbound for TCP, but the error messages you get tell you which port it tried to use so you'll know if you need additional ones open (you don't need to open any ports inbound - which is, of course, the whole reason for using Service Bus!). If you use Service Bus Relay, you need to open ports 808, 818, 819, and 828 for TCP outbound, though so far I haven't been able to confirm that this is all you need.

If a request is blocked, the error message shows the port number that was used. You should not attempt to limit the IP address ranges in a firewall rule as these will change over time for the different Azure datacenters. A list of the current IP addresses for the datacenters is available on this blog. Here's the rule I set up:

Access to Azure Service Bus Queues and Relay

  • Rule Type: Allow
  • Rule From value: Internal
  • Rule To value: External
  • Rule Protocols list:
    • Ports 9350-9355 TCP Outbound
    • Port 808 TCP Outbound
    • Ports 818-819 TCP Outbound
    • Port 828 TCP Outbound
    • HTTP (pre-defined rule - required only if not enabled in default client access rules)
    • HTTPS (pre-defined rule - required only if not enabled in default client access rules)

So everything is looking good until I hit the part where I log in with Windows Live ID and ACS redirects me back to the Orders website running in the local Compute Emulator environment so I can place my order for a High Mass Directional Coil Type 176HS and a dozen Cycloalutanium Tube Connectors. At which point in blows up.

Windows Azure Tools are clever in that they map your local website to an unused port. So if you have IIS or some other software installed that's using ports 80 and 443, the redirection back from ACS fails because Azure mapped your website to port 444 (or higher). To fix this without having to mess around with the ACS configuration, you can open IIS Manager, right-click the Default Web Site, click Edit Bindings, and change them so that ports 80 and 443 are not used.

Sometimes I get the feeling that the Known Issues doc will have more pages than the finished guide...