Create persistent static routes on the internal interface to all internal networks where clients, Lync Server 2010, and Exchange Unified Messaging (UM) servers reside.If you're not a Windows networking expert, this might stump you a bit. Doing some searches might help, but here's a simple way to ensure that all internal networks are covered, even if you aren't aware of exactly which ones are in use. This can easily happen if you're a consultant doing a Lync deployment for a large, multi-site company.
There are 3 well-known IP subnets that are reserved for internal use. Any networking person can tell you what they are, and should be using these for their internal corporate network. If not, then I would recommend running away. The 3 well-known subnets are 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.
I typically add static routes for all 3 subnets even if they aren't all in use. This will future-proof your deployment in case the company adds or changes their subnetting scheme. To add these static routes on the internal interface of your edge server, do the following:
- Using the Network Connections interface, make sure your NICs have descriptive names that make sense (Ie. Internal and External)
- Open a command prompt in Administrative Mode on the edge server.
- Make sure you know what the internal default gateway should be. In this example, we will use 192.168.100.1
- Type the following commands in the command window:
netsh interface ipv4 add route 10.0.0.0/8 "Internal" 192.168.100.1
netsh interface ipv4 add route 172.16.0.0/12 "Internal" 192.168.100.1
netsh interface ipv4 add route 192.168.0.0/16 "Internal" 192.168.100.1
When you do a netsh interface ipv4 show route, you should see the new routes show up at the bottom of the list. If you make a mistake, you can delete a route by using the same command above, and replace add with delete. Now, your Lync edge server should be able to route to any internal address, both now and in the future.
UPDATE: Apparently, I'm part Amish, and I was using ROUTE ADD instead of the updated netsh commands shown above. Thanks to @twharrington on Twitter for pointing out the error to this ol' timer. I'M DOIN' IT OLD SKOOL!
UPDATE: Apparently, I'm part Amish, and I was using ROUTE ADD instead of the updated netsh commands shown above. Thanks to @twharrington on Twitter for pointing out the error to this ol' timer. I'M DOIN' IT OLD SKOOL!
Great post Ken.
ReplyDeleteBut does the Route ADD command still OK to use?
Mart
Yes, ROUTE ADD still does work just fine. At least I hope so, because that's what I've been using up until now. So, I guess its not technically an error.
ReplyDeleteThe point about narrow static routes is the whole reason they have dual-homed edge deployments, keep the traffic patterns to a minimum for security. Adding every possible client-side subnet blows the whole reasoning for this secure interface out of the water. If you're not familiar with Networking, don't touch the static routes and ask. It's bad enough the edge server has the ability to be publicly routeable via the external interface and giving the internal a giant tunnel probably violates most corporate DMZ directives...
ReplyDeleteHey Chase,
DeleteI'm not sure I agree with your statement. Just because I configure static routes for the internal interface does not mean I'm opening a huge tunnel into the internal network. There is still an internal firewall that would have to be breached. In my experience, it is easier to do what I suggest rather than go through the exercise of determining every internal subnet in use at what can be a large company.
Ken
Chase - being that the edge has to able to talk to any internal network why is this method any more "insecure" as you indicate? its not like your giving away info about internal addresses as this is the defined internal address space
DeleteId argue the opposite and say that an attacker looking at a route table with narrow subnets is LESS secure as youd actaully see the address space in use
All Ken's method does is make it do you never have to go back and add routes to the edge even as an enterprise grows...
or am i missing the point
1 good thing this will avoid is Audo/video issues between Internal/External endpoints. I came across such an issue recently where App sharing and A/V were failing and adding a static route from Edge server to the clients resolved the issue.
ReplyDeleteAre there any other issues we can avoid by implementing this ?
The biggest issue you'll avoid by implementing this is exactly what you mentioned. A/V won't work unless there is a static route between the edge and all internal participants. This is actually part of the required setup for edge servers, and can't really be considered optional.
DeleteKen
hi Ken need your help...
ReplyDeletehttp://social.technet.microsoft.com/Forums/en/ocsconferencing/thread/15015166-a20b-43ed-87f3-a2a08f5c5fde
well badly stuck in a deployment.. pls help...
Regards,
Farrukh Qazi
I got one entered in and the other two fail with "The following command was not found: interface ipv4 add route 192.168.0.0/16"
ReplyDeleteHey Pat,
DeleteIf you copied/pasted the content from the blog, maybe something didn't translate well. Try typing it in manually.
Ken
For those on Server 2012 the new powershell goodness is:
ReplyDeleteNew-NetRoute -DestinationPrefix 10.0.0.0/8 -NextHop 192.168.100.1 -InterfaceAlias 'Internal' -AddressFamily IPv4
Hey, all... As the 'guy' who actually wrote the docs for the Edge product, I wanted to be certain that there was absolute closure on one comment made by Chase Abbott in Jan 2012. Chase's concern, and a smart concern is that the route add statements look to be a security problem because, well - you're turning your Edge into a router, right?
ReplyDeleteWell - no, you aren't. A route add statement only tells traffic that is already looking for how to get from one place (in this case - somewhere between the internal interface and the internal side of the Access Proxy, Data Proxy or AV Relay) to another. These statements are no different that a default gateway set on the internal. Except, you can't have two DfGw on the box. Might look like it works, but it's going to fail and will fail mysteriously and randomly.
Remember that the Edge services are really (at a most base level) proxies. And, they dump off data from the external to the internal with no innate knowledge of where that data has to go next - except for a Next Hop. The Next Hop name is all the Edge has to go on. You need/must provide name resolution and a network route to get to the next hop (or, return traffic sent to the Edge...).
Complex corporate networks will and often do use public IP address ranges for internal networks. This presents a more interesting problem: How to make sure that traffic destined for 169.0.0.0/24 is really meant for internal or is that going external? If your network engineer defines that this traffic is hosting clients or servers, you must define the internal interface index number as well as the network, mask, gateway, etc. Otherwise, default route will send the traffic external.
One final note in regards to Mr. Abbott's concern: On the Edge Server, unless you have installed RRAS, or some other routing components - the Edge Server CANNOT become a router simply by adding persistent (or even dynamic) routes. No way, no how... It is simply a road map on how to get to the next informational element (router, network, host) in the path to a destination.
Finally, wouldn't it be great if all networks used summary routers (routers that know everything about everything internal) instead of a hodge podge of route statements? Yeah, let's keep dreaming of this new Nirvana...
Rick