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: 10.130.1.21
Internal Gateway: 10.1.1.1
Internal DNS: 10.1.1.69

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

Configuring
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

 

Topology
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 125.215.10.0/24 172.16.2.1 -p

(where 125.215.10.0/24 is the IP address subnet range of your SIP trunk provider, and 172.16.2.1 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.

4 comments

  1. James Arber Reply

    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 of these solutions don’t do is understand SIP very well other than “This is a SIP packet! lol!”

    This solution can potentially open users up for Toll Fraud as it would be fairly simple to craft a SIP invite with a remote number only to have Skype4B to hairpin the call (as it doesnt know it) out the mediation server costing the customer a considerable amount of money.

    I say this purely having cleaned up the mess from insecure PBX’es countless times and I’m personally seeing attacks using/involving Skype4b.

    This solution is definatley innovative, but if your not going to use an SBC, at least use a firewall that you can filter SIP invites on.

    • Craig Post authorReply

      Oh absolutely James. These kinds of “hacks” are always not recommended as they go against best practices and introduce all manor of security implications – some of which aren’t immediately obvious! not to mention that an update could break this at any time. Definitely not a recommended approach, that’s for sure!

  2. James Arber Reply

    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.

    • Craig Post authorReply

      Very true, although again you’re relying on one device for security. Definitely not best practice!

Leave a Reply

Your email address will not be published. Required fields are marked *