Return route not added on demand dial router

  • Thread starter Thread starter GeorgeR
  • Start date Start date
G

GeorgeR

I have two servers. I have created a demand dial environment between
the two servers using modems. When server A initiates a conversation
with server B the modem on A is activated, the connection is made and
authenticates successfully. Both machines indicate a successful
connection. The routing table on Server A looks correct and it is
possible to see the route to server B. On Server B we do not see a
route back to Server A. Because of this we cannot make anything work
between the two servers. On Server A we have a static route to Server
B and it is obvious by the fact the modem dials and a connection is
made the the static route is being used. On Server B we have a static
route back to Server A in the event Server B were to initiate the
traffic. When Server A connects with Server B the routing table on
Server B does not indicate the route back to Server A. All traffic on
Server B continues to use the default gateway. Everything looks OK
configuration wise but obviously we have missed something. Does anyone
have any ideas?

Thanks,

George
 
No routing is set up by default. You need to set up static routes and
link them to the demand dial interfaces at both ends. To activate the route
on the answering router, you must connect to the demand dial interface. You
make this happen by using the name of the demand dial interface as the
username when you make the connection.

What happens is this. If a RRAS router receives an incoming connection
where the username matches one of its demand dial interfaces, it connects to
that interface and activates any static routes linked to that interface. If
the username does not match a demand dial interface's name it is assumed to
be a simple client-server request, and only a host route is established back
to the caller through the link.
 
We reviewed the configuration and verified all is a described here.
The name of the interface on the receiving end matches the user name
on the initiating end. In viewing each system I can see the static
route has been added to the routing table but the problem appears to
be in the gateway associated with that static route. The gateway is
always identified as 0.0.0.0 instead of pointing to the ip address of
the "way back" to the other system. Since we have no access to the
gateway when setting up the static route it seems as if the OS should
be updating the gateway to reflect the information available once the
connection has completed.

George
 
That is odd. The address should be the IP address allocated to the
demand-dial interface. Are you sure you have the static route linked to the
demand-dial interface?
 
What follows is an excerpt from the routing table on the receiving end
once the connection has been made. I have only included the entries
for the demand dial interface items.

192.168.101.0 255.255.255.0 0.0.0.0 dd_dsi1
192.168.101.255 255.255.255.255 0.0.0.0 dd_dsi1
224.0.0.0 240.0.0.0 0.0.0.0 dd_dsi1
255.255.255.255 255.255.255.255 0.0.0.0 dd_dsi1

and the following entry appears relevant as well and is the ip address
of the modem after the connection has been made

192.168.101.82 255.255.255.255 127.0.0.1 loopback

The receiving end machine is on a 192.168.0 subnet

Once the connection is made it is obvious that the receiving end
machine
has some knowledge of the calling interface. It went to the trouble of
adding the above routes to the routing table. But how does it know how
to make it's way back. When I ping or tracert on the receiving end
something along the lines of tracert 192.168.101.242 (a server on our
end)
the tracert goes right out the default gateway on the receiving
machine
it behaves as if the entry is not in the routing table. What I do not
understand is given the above entries how does it know to make it's
way
to the modem (192.168.101.82)? Nothing about that entry in any way
ties
to the dd_dsi1 interface information.

George
 
As you say, you have no access to the gateway until you set up the
connection. In fact the gateway doesn't exist until you make the connection.
That is why you use the demand-dial interface name as the symbolic name for
the connection. You can link the routes to this interface, and the system
will then make the necessary links when the connection is made. Have you set
up these routes from the New Static Route wizard, and selected the
demand-dial interface from the dropdown interface list (and left the gateway
address blank)?

Where do you see these routes you describe? From the RRAS console?

What do you see if you do a route print from a command prompt? The
subnet route to the calling router's subnet should have the IP adress of
the VPN connection as the gateway address and the IP address of the
demand-dial interface as the interface address.

The routers at both ends of the connection must have a subnet route to
the "other" subnet through the VPN tunnel. They should be "real" IP
addresses, not things like 0.0.0.0 or 1.1.1.1 .
 
Sorry for the delay in the follow up here. We reinstalled service pack
4 on the server on the receiving end of the calls. Sorry for the
confusion as well on the previous post. The route table I was
referring to is the table visible through the graphic user interface
associated with the RRAS application. The routing table as visible
using route print yields a different story.

I have had multiple people examine this and all say it is set up fine.
We have checked the user and interface names. They match. The static
routes we have added have been by using the wizard in the RRAS
application. All appears OK. Despite all this the difference is
clearly identified as the routing table on the machine initiating the
call being correct and the routing table on the machine receiving the
call being wrong.

On the machine receiving the call the problem is clearly that the
static route back to the calling machine is not added. The routing
table on the receiving machine changes once the call is connected to
add the following entries in the routing table. An entry is added for
the modem on the receiving end ... An entry is added for the modem on
the calling end. Beyond that we do not have the most critical entry
which is for us an entry which would point back to the calling
network. That is 192.168.101.0 with a mask of 255.255.255.0.

This is bit frustrating as it seems likely people do this kind of
stuff everyday and we seem to have no way forward now. Any other ideas
are appreciated.

Thanks,

George
 
The only time I have seen this is if the connection does not bind to the
demand dial interface on the answering router. From the RRAS console, can
you check that the dd interface actually changes to the "connected" state?

If it doesn't, that explains why the static route isn't added. If it
does, it is an odd malfunction and you will probably need to lodge a call
with Microsoft.
 
The resolution turns out to be a bit odd. We modified the
configuration of the RRAS service to use a static address pool. Once
we did that everything worked fine. I can only guess as to why things
work with a static address pool but not with dhcp but seems to have
made a difference. I am trying to find out now where the dhcp server
is in this network. Maybe that will yield some clues.

George
 
Back
Top