Access Edge Static Routes
Static routes for Access Edge servers - they're important!
====
An age ago I wrote about dual-homing Windows servers, and what you need to do with static routing:
Dual Homed Servers
It's interesting that even today I still run in to sites that have issues due to incorrectly configured routing on their Access Edge units. The Edge server plays an important role in Lync & Skype for Business - and not just always for the obvious stuff like remote access and federation. It also can get involved in media calls for internal subnets.
Jeff Schertz has a great article explaining why, linked below. Rather than me make a hash of it, have a read, it's good stuff:
Lync Edge STUN versus TURN
In certain scenarios your internal clients will need to talk to your Access Edge for media - for example if peer to peer communication isn't possible.
This brings me on to the point of static routes on the Access Edge - they're very important! Get them wrong and some subnets may not be able to communicate with the Access Edge, and that'll lead to all kinds of issues. Of course the obvious ones like remote access etc. but also - more confusingly - ones like not being able to make a VoIP call between two clients.
Hopefully your internal network only uses RFC1918 compliant addresses - that is your internal networks are on:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
I usually define static routes on the internal interface for all of the private ranges. It's easy to do with the following commands:
netsh interface ipv4 add route 10.0.0.0/8 "InternalNW" 10.100.0.1
netsh interface ipv4 add route 172.16.0.0/12 "InternalNW" 10.100.0.1
netsh interface ipv4 add route 192.168.0.0/16 "InternalNW" 10.100.0.1
You need to replace the 'InternalNW' with the name of your internal NIC, and of course 10.100.0.1 with your internal next hop gateway, but it's pretty straight forward.
The subnet mask is particularly important - a few sites I've seen configure 172.16.0.0 in the wrong way - they'll use the wrong subnet mask such as 172.16.0.0/255.255.0.0 (172.16.0.0./16)…which is of course wrong, and will miss out a chunk of the private ranges.
Anyway, that's my random musing for the day.
blog comments powered by Disqus