I'm not aware of any configuration parameters for DFS-R to control the interfaces that it binds to, or to influence how it selects the partner interface to route traffic to. Doing a quick search, I'm coming up with this dirty hack from the Microsoft Storage Team blog (albeit from 2006) that indicates that you should use a HOSTS file on each replication set member to influence their name resoultion such that you effectively "force" them to use the private IP addresses.
This is an ugly hack, and I'm typically violently opposed to using HOSTS files. In this case, though, it may well be the only way to accomplish what you're trying to do.
Rather that doing the HOSTS file hack (which, if you do, you should document so that the next guy who works on it knows why it was done) I have one other idea you might try.
Try putting a host route for the other host on each of the DFS-R replication set computers. If it works, make the the route persistent. I'm about 80/20 in thinking this won't work versus that it will, but it's worth a shot:
Member 1: route add 20.20.0.101 mask 255.255.255.255 192.168.0.100
Member 2: route add 20.20.0.100 mask 255.255.255.255 192.168.0.101
That might just work to get that traffic flowing over the private network. (If I wasn't under orders from The Wife(tm) to get some house work done this morning I'd give it a try myself and tell you if it works... If she catches me writing on Server Fault this morning it will be bad... >smile<)
Have you seen this DFS Server Prioritization document? It sounds like even if both of your servers are in the same "site", you can still set a different "target priority" (according to that document). It sounds like this should prioritize the servers as you would expect from a client point of view.
Best Answer
if it was me, and I don't have DFS-R setup I would do the following:
IF you are really scared, duplicate the setup with a new name space and a new replica set and practice it.