Disclaimer: All postings are provided "AS IS" with no warranties, and confer no rights. This weblog does not represent the thoughts, intentions, plans or strategies of Microsoft. Because a weblog is intended to provide a semi-permanent point-in-time snapshot, you should not consider out of date posts to reflect current thoughts and opinions.
When a demand dial connection is setup between two RRAS servers each server receives an address from the pool of available addresses located on the server it is connecting to. When Server 2003 servers are used on both ends of the demand dial connection you are then able to ping from each server to the assigned IP address on the other server. When a Server 2008 server is used on either or both ends of the demand dial connection this ping will fail. This is due to 2008 RRAS not adding a host route to its local routing table that 2003 server adds to its routing table.
As a best practice recommendation a server hosting RRAS should contain two NICs and be hosted on its own server. This helps keep the networking simple and if the server is compromised it keeps it a step away from sensitive data that may exist on other servers. However in reality this is not always done and Microsoft does support most single NIC and multiple-role servers where RRAS is involved. However, if there is a dependency on the demand dial connection to access resources located on the RRAS server when Server 2008 is used this dependency will fail. This write up supplies a workaround to this to make those resources available across the demand dial connection.
To setup a Demand Dial (also known as Dial on Demand, or simply DoD) connection the general steps below are followed: (More information can be found at http://technet.microsoft.com/en-us/network/bb545655.aspx, http://technet.microsoft.com/en-us/library/cc779726.aspx, and Knowledge Base article 159684)
Example setup for workaround:
Following are the parameters of our DoD connections.
RRAS1 – Server 2003 on domain corp1.local
RRAS2 – Server 2008 on domain corp9.local
Summary: The route that is added in step 7 is the route that 2008 RRAS leaves out by design. Steps 5e for RRAS1 and RRAS2 are used to assign a static IP address to the DoD interfaces to guarantee the route added in Step 7 will work. Steps 5e and 7 are required to make this setup work to allow you to access resources on the 2008 server from the 2003 server. Without these steps if you do a ping from the 2003 server to the 2008 server you will see a response of “Request timed out”. If you try to connect to a file share on the 2008 server the response will be a pop-up with the message of “No network provider accepted the given network path.”
- Barry McGugan
PingBack from http://mstechnews.info/2008/11/unable-to-ping-the-tunnel-address-of-a-demand-dial-connection-on-windows-server-2008-rras/
203 Microsoft Team blogs searched, 88 blogs have new articles in the past 7 days. 252 new articles found
The explanation for the reason why the route should not be added automatically by Windows 2008 (security) is completelly wrong here.
Using 2 or 1 NICs does not change anything. The problem is not that anybody from corp9.local would like to access the resources on the RRAS1 server (normally nobody even knows the IP that RRAS2 assigns to RRAS1).
The real problem is that RRAS1 Server itself has to access resources inside corp9.local behind the server RRAS2 (either it has to contact AD servers there, deliver e-mail by SMTP, replicate DFS folder, RDP,...). As soon as that is necessary RRAS1 will always initiate the IP connection to corp9.local subnet using as source IP its IP from corp9.local subnet that was assigned to it by RRAS2. However as RRAS2 has not added the route to that IP nobody from corp9.local can reply to RRAS1. So RRAS1 is not able to contact corp9.local subnet even though it has a route to there available.
So the "feature" that should prevent using resources on RRAS1 from the other side actually prevents RRAS1 of accessing resources on the other side. What was intended to be prevented is however still possible. Anybody from the other side of DoD connection can access resources on RRAS1 using its normal fixed IP inside of the corp1.local subnet (192.168.1.30 in the example above).
No security improvement at all but many problems caused.
This is like saying that nobody will enter into my house through the garden door so I will make the door in the way it will not be possible to enter there. OK, but I like to go out to the garden through that door. Now that the door is shut down for entry, as soon as I go out I can not return into my house anymore.
I hope that the automatic addition of route can be implemented again. Alternativelly Windows 2008 could be teached to never use the IP assigned by another RRAS server as source IP in TCP/IP communications.
SBS setup wizard disables the second NIC as an unsupport senario, How's that for logic!
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using RSS