Re: Return route not added on demand dial router

From: GeorgeR (grasch_at_dataspecialists.com)
Date: 08/25/04

  • Next message: Robert L [MS-MVP]: "Re: error 20169" 
    Date: 25 Aug 2004 13:15:31 -0700

    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

    "Bill Grant" <not.available@online> wrote in message news:<OBpvSdnhEHA.556@TK2MSFTNGP10.phx.gbl>...
    > 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 .
    >
    > "GeorgeR" <grasch@dataspecialists.com> wrote in message
    > news:ebd75c4d.0408191840.40ecc35c@posting.google.com...
    > > 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
    > >
    > >
    > > "Bill Grant" <not.available@online> wrote in message
    > news:<OxS4gcdhEHA.2540@TK2MSFTNGP10.phx.gbl>...
    > > > 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?
    > > >
    > > > "GeorgeR" <grasch@dataspecialists.com> wrote in message
    > > > news:ebd75c4d.0408181421.35f6d3ac@posting.google.com...
    > > > > 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
    > > > >
    > > > > "Bill Grant" <not.available@online> wrote in message
    > news:<ea7WDOecEHA.1408@TK2MSFTNGP12.phx.gbl>...
    > > > > > 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.
    > > > > >
    > > > > >
    > > > > > "GeorgeR" <grasch@dataspecialists.com> wrote in message
    > > > > > news:ebd75c4d.0407231929.e85d4cb@posting.google.com...
    > > > > > > 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

  • Next message: Robert L [MS-MVP]: "Re: error 20169"

    Relevant Pages

    • Re: Windows 2000 RAS Server and a Cisco Client Router
      ... You need to use the method which a router to router connection uses. ... This involves setting up a demand-dial interface on the server. ... dropdown list as the interface to link with the route. ...
      (microsoft.public.win2000.ras_routing)
    • Re: Cannot get NAT to route in RRAS
      ... ADSL Link was set as the Public interface in NAT, ... The static route also adds in fine using the ADSL Link interface, ... separate DNS server handles client’s requests, ... > Internet connection. ...
      (microsoft.public.win2000.ras_routing)
    • Route through PPP direct connection
      ... that is required to assign the IP address to the embedded controller. ... I have a direct serial interface between an XP box and an embedded ... I need to be able to route packets from the XP box to different IP ... side of the ppp connection was 255.255.255.255. ...
      (microsoft.public.win32.programmer.networks)
    • Re: Return route not added on demand dial router
      ... 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 ... > using route print yields a different story. ...
      (microsoft.public.win2000.ras_routing)
    • Re: Return route not added on demand dial router
      ... > The resolution turns out to be a bit odd. ... >> The only time I have seen this is if the connection does not bind to the ... >> demand dial interface on the answering router. ... that explains why the static route isn't added. ...
      (microsoft.public.win2000.ras_routing)