Communications Server Mediation Server: Dual NIC Issue
Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
There have been several great blog posts on the Internet concerning the Mediation Server dual NIC configuration or single NIC with multiple IP addresses in Communications Server 2007 R2. In this article, Greg Anthony shares an additional scenario that explains why both Mediation Server network interfaces need to be on physically distinct and separate subnets.
Author: Greg Anthony
Publication date: March 2010
Product version: Microsoft Office Communications Server 2007 R2
There have been several great blog posts on the Internet concerning the Mediation Server dual NIC configuration or single NIC with multiple IP addresses in Communications Server 2007 R2. I wanted to share an additional scenario that explains why both Mediation Server network interfaces need to be on physically distinct and separate subnets.
The issue as reported was that outbound calls from Office Communicator to the PSTN were delayed up to 10 seconds before connecting Communicator to the external called party. Basically, when the person receiving the call answered the phone, the Communicator user did not hear the called party answer. Then the called party would hang up because they did not hear a response from the calling party.
When I first started troubleshooting the issue, the topology and configuration of the Mediation Server looked correct. It had two network adapters each with a separate IP address configured for separate and distinct subnets. This topology is shown in Figure 1.
Figure 1. Topology
A Wireshark trace showed that the external party call was established with basically no delay and audio was established to the Mediation Server gateway interface. Then, about 10 seconds later, audio would be established on the Communications Server listening interface of the Mediation Server to Communicator as shown in Figure 2.
Figure 2. Wireshark VoIP call statistic
The network trace taken on the Mediation Server showed that the Communicator client was making a Simple Traversal Underneath NAT (STUN) binding request to the Mediation Server gateway listening interface as shown in Figure 3. The Mediation Server does not reply as the default gateway, and the route back to the Communicator client was through the Mediation Server Communications Server listening interface and not the Mediation Server gateway listening interface on which the STUN binding request was received.
Figure 3. Client STUN binding request
The Mediation Server NIC binding order was changed to no effect. Through additional testing it was discovered that the Communicator client, regardless of whether it was internal or remote, could access the Mediation Server directly due to the publically routable IP scheme.
Now the issue was clear. Subnet C to which the Mediation Server gateway interface was connected needed to be isolated from receiving traffic from any Communications Server entities on Subnets A and B. Changes were made to the firewall access control lists to deny traffic from the subnet with the Communication Servers and clients to the subnet connecting the Mediation Server gateway listening address to the VoIP gateway. After this was completed, the STUN binding request from the Communicator client never reached the Mediation Server gateway interface because the firewall reset or blocked the connection request. This resulted in a re-invite from the Mediation Server that didn’t include the gateway side interface instead of the delay timeout that was received before and then the re-invite.
In conclusion, even when the Mediation Server is configured in the typical manner with two NICs and each NIC is configured with an IP address each on separate subnets, entities on the Mediation Server Gateway interface subnet should be isolated so that they cannot be reached by Communications Server and Communicator client entities on the other subnets. If this is not feasible, a single NIC and single IP address must be used to connect to the Mediation Server. TLS and SRTP should be used for secure communications.
To learn more, check out the following articles:
Managing a Mediation Server, https://go.microsoft.com/fwlink/?LinkId=186120
Don’t use multiple IPs on the same NIC, https://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=20
OCS Mediation Server NIC Configuration, https://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=55
Communications Server Resources
Visit the Communications Server main page at https://go.microsoft.com/fwlink/?LinkId=132607.
View the complete Communications Server documentation library at https://go.microsoft.com/fwlink/?LinkId=132106.
Download the Communications Server content as Word documents at https://go.microsoft.com/fwlink/?LinkId=133609.
Download the Communications Server documentation as a compiled help file at https://go.microsoft.com/fwlink/?LinkId=160355. (Scroll down to the Additional Information section and download OCSDocumentation.chm.)
Read weekly articles for Communications Server IT professionals on NextHop at https://go.microsoft.com/fwlink/?LinkId=181907.
Read NextHop articles in the Technical Library at https://go.microsoft.com/fwlink/?LinkId=185344.
Subscribe to NextHop feeds on the OPML List for NextHop page at https://go.microsoft.com/fwlink/?LinkId=185345.
Read weekly articles for Communications Server developers on UCode at https://go.microsoft.com/fwlink/?LinkId=177892.
Follow tweets from the Communications Server team at https://go.microsoft.com/fwlink/?LinkId=167909.