Unable to ping the tunnel address of a Demand Dial Connection on Windows Server 2008 RRAS

Unable to ping the tunnel address of a Demand Dial Connection on Windows Server 2008 RRAS

  • Comments 5
  • Likes
Problem Description

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.

A Quick Review – Setting up a RRAS 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)

  1. The RRAS service is setup for VPN and LAN/Demand Dial Routing.
  2. A pool of addresses is assigned to the RRAS server out of which it will pick one to hand out to a connecting client. This can be a static pool kept on the server or an internal DHCP server can be used to supply the addresses. The static address pool can be on the same subnet as the internal address of the RRAS server or not.
  3. A DoD connection is defined in the Networks folder of RRAS. This connection will define the public IP of the remote RRAS server to contact, whether this is a persistent connection or will go up and down based on activity and retry attempts, and define network properties of the connection. The name given to the DoD connection must be the same on both RRAS servers and the account name used to authenticate the connection must match the connection name.
  4. A RRAS static route must be added to the local RRAS server that defines a route to the internal subnet of the remote RRAS server.

Example setup for workaround:

 2008 RRAS Workaround

Following are the parameters of our DoD connections.

RRAS1 – Server 2003 on domain corp1.local

  1. Local subnet – 192.168.1.0/24
  2. Local IP address – 192.168.1.30
  3. Public IP address – 172.16.0.141
  4. Static address pool – 192.168.1.240 – 192.168.1.249
  5. DoD connection –
    • name:corp9corp1
    • account name:corp9corp1@corp9.local
    • Connection Type:Demand Dial with no idle time and no retries
    • Require Security Password
    • Network Settings:IP address set to 192.168.9.250 – This is required for this workaround to succeed. This address is one from the same subnet that the pool the RRAS server for corp9 will use. Preferred DNS server set to 192.168.1.11 (DNS server for corp1). Leave all other settings at default.
  6. RRAS Static route –
    • Interface:corp9corp1
    • Destination:192.168.9.0
    • Subnet Mask – 255.255.255.0

RRAS2 – Server 2008 on domain corp9.local

  1. Local subnet – 192.168.9.0/24
  2. Local IP address – 192.168.9.23
  3. Public IP address – 172.16.0.149
  4. Static address pool – 192.168.9.240 – 192.168.9.249
  5. DoD connection –
    • name:corp9corp1
    • account name:corp9corp1@corp1.local
    • Connection Type:Demand Dial with no idle time and 99 retries
    • Require Security Password
    • Network Settings:IP address set to 192.168.1.250 – This is required for this workaround to succeed. This address is one from the same subnet that the pool the RRAS server for corp1 will use. Preferred DNS server set to 192.168.9.11 (DNS server for corp9). Leave all other settings at default.
  6. RRAS Static route –
    • Interface:corp9corp1
    • Destination:192.168.1.0
    • Subnet Mask – 255.255.255.0
  7. THIS IS THE KICKER THAT MAKES THIS WORK - Add a persistent static route – At a command prompt enter this command:
    • Route Add 192.168.9.250 mask 255.255.255.255 192.168.1.250 -p
    • Generally this can be worded as: add a static persistent host route for the IP address of the remote endpoint using the IP address of the local endpoint as the gateway.
    • The IP address of the remote endpoint will be the one assigned in the remote DoD properties, in this example 192.168.9.250.
    • The IP address of the local endpoint will be the IP address assigned in the local DoD properties, in this case 192.168.1.250.

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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 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!

  • Thank you very much for the solution. It is the only one I have found. We have 12 Windows 2003 vpn servers and there is a need to upgrade the hardware as well as the OS. This solution will allow us to do that within our budget.