*Re-posting this article since we have recently had several inquiries about this topic!
This is going to be a brief to the point posting about a configuration issue we’ve been seeing a lot of recently. I am not going to go into any kind of depth as to why this is a problem, just going to explain what it is and offer some advice on how to resolve it.
Edge Server Basics
If you’ve worked with OCS, Lync 2010, Lync 2013 or Skype for Business 2015 you are aware that there are some cardinal rules when installing an Edge server in a supported configuration and following Best Practices:
- You need to assign three (3) Public IP addresses for each Edge server. This is true whether you have a single Edge server or multiple Edge servers. It is true in a multiple Edge server Edge pool whether you choose to use DNS Load Balancing or Hardware Load Balancing. If you use Hardware Load Balancing, you will need three (3) more Public IP addresses above those you have pulled for the Edge servers themselves. These additional IP addresses are used for the Edge’s virtual IP addresses (VIPs)
- The Edge server has to have two (2) network interface cards (NIC), four (4) is better but two (2) works fine!
- On a 2 NIC Edge, each one of the NICs has to be connected to a separate subnet. One of the subnets is defined as being connected to the internal side of the Edge with the other connected to the external side. On a four (4) NIC Edge you would have one (1) NIC on the internal side and the remaining three (3) on the external side.
- You also need four (4) IP addresses, one (1) on the internal NIC and its subnet and the remaining three (3) on the external side NIC(s) and their subnet
- The required firewall rules are split up between those for the external side of the Edge server and those for the internal side. Rules for the external side prescribe ports that should be opened between the Internet and the external side of the Edge. While rules for the internal side prescribe ports that should be opened between the internal user and Skype for Business 2015 server subnets and the internal side of the Edge. This implies that the external side of the Edge should only be able to “hear” traffic coming in from the Internet while the internal side of the Edge should only be able to “hear” traffic coming from the internal users or the internal Skype for Business 2015 servers. Unfortunately, this is only implied and not called out explicitly in the documentation; but we are calling these rules out here:
- There should never be routing that allows traffic to get directly from either the internal user subnets or the internal Skype for Business 2015 servers to the external side of the Edge servers.
- There should never be routing that allows traffic to get directly from the Internet or the external side of the Edge server to the internal user subnets or the internal Skype for Business 2015 servers
If you are guessing that the configuration issue I alluded to in the opening sentence has something to do with these last two (2) bullet points, you’ve won the prize! We have recently seen several deployments where traffic from an internal Skype for Business 2015 user or server has been able to be routed to the external interfaces and IP addresses of the Edge server! We’ve also seen cases where the opposite is true as well!
Folks, the Skype for Business 2015 Edge server is very much a purpose built firewall. One of the main jobs of a firewall is to protect the good guys from the bad guys. By allowing this routing to occur you are almost certainly introducing a security risk that could be potentially exploited against an Active Directory joined and signed on user workstation or Skype for Business 2015 server using a Windows Server operating system. It is also providing the Edge server’s mechanisms access and paths to places they don’t need to be! I said I wasn’t going to get into the nuts and bolts but for those familiar with ICE, STUN and TURN and how the Edge uses them, suffice it to say that candidates offered that shouldn’t work actually may work! If they work, then the parties involved in a media conversation may agree to use these candidates which ultimately lead to problems with the media session.
Determining if you have this Problem
Whether you think that you have this problem or not, you should verify that you don’t! It’s pretty simple to do. Take a look at the as built diagram of your Skype for Business 2015 Edge Server and reverse proxy deployment or similar document and find the IP address assigned to the external Access Edge service of your Edge server. In the diagram below the addresses on the two (2) Edge Servers are 192.168.50.3 and 192.168.60.3:
From your Skype for Business 2015 Standard or Enterprise Edition server, open an Administrator’s command prompt window and type “pathping 192.168.50.3”, and press the return key:
If the result looks like this, your configuration is allowing traffic to get from a Skype for Business 2015 Standard or Enterprise Edition server to the external Access Edge service of the Edge server, which is incorrect and needs to be fixed:
We can see from this result that there is a route from the 192.168.40.0/24 subnet to the 192.168.50.0/24 subnet that should not be there! When we check the second Edge server by typing “pathping 192.168.60.3”, we see that the 192.168.60.3/24 subnet is not routable:
Edge Servers without Network Address Translation
In the example above, we talked about Edge servers that had their Public IP addresses NATted. If you haven’t NATted your Public IPs and assigned them directly to the Edge servers, you could still have this problem. To test, use the “pathping” command against the Public IP address of your external Access Edge server. If the results show that you are able to get to it via your internal networks, you will need to fix this! If the result shows that you can get to this address but the routing shows that you exit your network out to the Internet and come back in to get there, hairpinning, you are OK. If the pathping fails and can’t get you to that address, you are still OK!
Allowing a hairpin for the Skype for Business 2015 Reverse Proxy
Like the Edge server, you should not be able to get to the external side of the reverse proxy via routes over internal networks. This is true whether or not you have NATted the Public IP address on the reverse proxy. You need to be able to successfully “hairpin” the Public IP address of the reverse proxy via the Internet. If you can’t, then the Skype for Business 2015 mobile clients connected to your internal WiFi networks will probably not work!
Resolving the Issue
To resolve the problem, you have to prevent traffic from routing where it’s not supposed to! You will have to put on your network engineer hat or ply you in house network engineer to modify the routing to prevent traffic being routed where it shouldn’t. Another option would be to place firewall rules between the segments but at Enabling Technologies, our view is that the traffic shouldn’t be routing at all. Using firewall rules to solve routing issues is not the best option.
The Bottom Line
If you have this routing problem, you are likely experiencing some issues when communicating with others across your Skype for Business 2015 Edge server. They frequently show up as application sharing issues and they are extremely difficult to troubleshoot. One of the first things we do for these issues is to validate the routing between the internal segments and the external side of the Edge server.
Even if you are not seeing any symptoms, this incorrect routing configuration is a security risk to your firm and needs to be addressed.
Enabling Technologies is ready and able to identify if you have this problem and to resolve it. firstname.lastname@example.org