Co-locating Skype for Business Front End and Mediation Roles with Dual NICs

Each and every environment you encounter will always deal unique challenges. Today – it’s co-locating Skype services on a dual homed server.

Why dual homed?
In Australia, some SIP providers supply a SIP trunk via direct IP connect – without the need for a VPN or SBC. This is both a good and bad thing. Good, because it makes configuring enterprise voice cheaper, easier and less complex. Bad, because opening ports to a server inside of your network is a potential security risk.

Stand-alone Vs co-locating
Another way of achieving PSTN connect whilst still keeping things secure is to deploy a stand-alone mediation server (or pool), that has a NIC in your DMZ environment, and a NIC in your internal network. You’d then configure your firewall to only allow traffic from your SIP provider to your DMZ NIC.

A word on routing
It’s vitally important that your internal and mediation networks are on 2 different, non-routable subnets. If both NIC’s are on the same subnet, you’ll run into all kinds of routing issues.

For the purposes of this how-to, here’s my network configuration:

Internal NIC IP:
Internal Gateway:
Internal DNS:

Mediation NIC IP:
Mediation Gateway: BLANK
Mediation DNS:, (google’s DNS servers)

Before we do anything, rename your NICs to help you identify them.

NIC Naming
Open up the properties of your Mediation NIC, and ensure that the NIC has no default gateway. You can enter an External DNS server if your SIP trunk provider uses an FQDN rather than an IP address if you wish.

Ensure that the binding order prioritizes the Internal NIC over the Mediation NIC.

Then, open up the topology builder and ensure that Limit service usage to the selected IP addresses is ticked and that you’ve entered the following:

Primary IP Address: Your internal NIC IP
PSTN IP Address: Your Mediation NIC IP


Publish the topology, then run bootstrapper.exe to publish the changes on your front end server.

Adding static routes
We now need to ensure that by default, all traffic is being routed out the Internal NIC, and that only the traffic destined for your SIP trunk provider is leaving the mediation NIC

Open an elevated command prompt, and then run:

netsh interface ipv4 set interface “Internal NIC” metric=1

netsh interface ipv4 set interface “Mediation NIC” metric=99

Finally, we need to add a static route to route traffic destined for your SIP trunk provider out your mediation NIC:

Run the following command from an elevated command prompt:

route add -p

(where is the IP address subnet range of your SIP trunk provider, and is the gateway address for the mediation server NIC)

Once configured, restart the Skype for Business Mediation Server service, and you should be up and running!

Fixing the control panel “page cannot be displayed” issue
One thing to note is that ticking Limit service usage to selected IP addresses breaks access to the
Skype for Business Control Panel from any front end server.

To fix this, open IIS on the front end server, expand Sites then right click on the internal web site and click Edit Bindings

Then, select HTTPS and set the IP Address to All Unassigned and click OK

You’ll then be able to open the Skype for Business control panel.

0 0 votes
Article Rating
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
James Arber
6 years ago

Interesting solution. I’d be very cautious with this in a production environment to ensure there is *something* between the SIP provider and your Mediation Server and shutting down your lab when not in use. I’ve worked for a SIP carrier and know how most of the carriers networks are constructed. It’s unlikely, but possible for other customers to hop from their network to yours, thats the point of the SBC. Your fix for the Skype4B control panel opens it up to the SIP interface. This can be very simply solved with Windows Firewall or your hardware firewall. However what most… Read more »

James Arber
6 years ago

In saying that. if your looking at a hardware firewall between you and the SIP carrier. It would be simple enough that you could lock down the IP traffic to only come from the SIP provider.. as long as they dont have a broken SIP ALG (I’m looking at you Watchguard) that opens it to the world.