Re: Return route not added on demand dial router

From: Bill Grant (not.available_at_online)
Date: 08/20/04 

Date: Fri, 20 Aug 2004 15:33:31 +1000

   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

Relevant Pages

  • Re: routing problem
    ... in site B) you will need subnet routes at both ends of the connection. ... each router has a subnet route through ... the VPN connection must actually bind to the demand-dial interface ... the connection is made to that interface and any static routes ...
    (microsoft.public.windows.server.networking)
  • Re: MultiHomed Workstation - Which NIC is being used?
    ... interfaces have routes out to the Internet, you will be using only one interface. ... Which interface gets used depends on how you've configured the stack. ... varying metrics, but that usually makes sense only if you're trying to make ... metric for faster connections then *all* your traffic will go out that connection. ...
    (microsoft.public.win2000.networking)
  • Re: Server 2003 RRAS Routing
    ... disable the "use default gateway" switch, ... they only get routes for the subnet local to the RRAS server. ... to create post-vpn connection batch files they have to run each time. ... You should not need any routes on the client. ...
    (microsoft.public.windows.server.networking)
  • Re: Using multiple gateways simoultaniously in Win2k Server
    ... Configure a default gateway only on the NIC connected to the DSL router. ... Cisco already has the routes for the remote networks in it. ... from the default gateway on the server, ... >> Only the DSL connection is a default gateway. ...
    (microsoft.public.win2000.networking)
  • Static (incorrect) ARP entry
    ... The below is actually public addess space, just using 10 for clarity's sake: ... Default Gateway: 10.8.16.1 ... Interface: 195.8.23.121 on Interface 0x1000003 ... Persistent Routes: ...
    (freebsd-questions)
Quantcast