Routing through VPN (with RRAS) = remote network not reachable...

Hi,

I currently trying to connect my local network to a client one through a VPN
connection.
The VPN works fine from my test station and from my isa server (which is
also a RRAS)

now I try to create an automated connection using RRAS.
So, when a internal user try to reach a computer on the remote network, RRAS
connect the VPN automatically. This works fine.

but my internal users cannot reach the remote network!
any ping / tracert etc... commands are stopped at my RRAS server.
but from my RRAS server I can ping the remote network.

any idea?
what I have to configure except my static route to the remote network?

thanks.

Jerome.

 

Your clients are using the RRAS server as a router? Their gateway is set to
the RRAS server?

Matt
MCT, MCSE

 

You have to create a "Site-to-Site VPN" (aka Router-to-router VPN). It is a
whole different model then the Remote Access VPN that you first were dealing
with. Go to http://www.isaserver.org and use "VPN" in their search engine.
You will find many articles concerning VPN. Choose the one that best fits
your situation. Be sure to pick the right one.

 

Yes, my stations use my gateway as the default gateway.

My ISA Server / RRAS Server (with demand dial): 192.168.1.1 (and an static
Internet IP address)
My internal client station: 192.168.1.10 default gateway: 192.168.1.1

Remote VPN Server : <Static IP>; remote netwrok: 168.0.0.0 / 255.0.0.0

So my static route which start the demand dial and the VPN connection is:
168.0.0.0 / 255.0.0.0 ("Use this route to initiate demand-dial connections"
enable)

From my test station, I type:
ping 168.0.0.10 (which is a remote server)
The demand dial detect this correctly and connect the VPN correctly.
but I can't ping the remote server.

I go to my ISA SErver / gateway server, I close the connection, I type the
same ping command, and then all works fine, I can reach the remote server.

In the past the same config has allready worked with another client.

 

Although that needs to be done, that alone won't do it. There is more to it
than that. If has to with how RRAS on the ISA box interacts with the VPN
router on the other end of the link. See my other post.

 

Well,,
I don't see anything special in some of the documents I found on the net.
but because I've not a access of the remote VPN Server, I don't know its
specific configuration, so I can't validate from this side for the moment.
:-(

I'll try again later.

 

As Phillip said, you can't fix this problem simply by making changes at
your end. The other site must have a route to your site through the VPN
link. This is usually set up automatically when you connect (if the remote
server is aware that you are making a router to router connection).

Without this, your server connects as a normal VPN client, and only a
host route back to the calling machine is set up. So the remote site knows
how to reach your server, but not the LAN behind it.

 

ok
in this case, what route is probabling missing in the other side?
I'll contact the I.T. Team...
The remote network is like a 10.x.x.x network, the VPN assign an IP address
like: 192.168.0.X
From my side I've setup the ropute for the 10.0.0.0 network.

When I'm connected by VPN, there is no route added (route print)
automatically, so I ask the IT to create this route.

 

No. I told you,...there are two different types of VPN and you are
confusing the two.

When you initiate a VPN link directly from a client machine that is "Remote
Access VPN" and the client is behaving as a "Remote Access Client" just like
in the old dial-up modem days. Even when you physically sit at the RRAS
Server and initiate the VPN from it you are doing the same thing, the RRAS
box is playing the "role" of a Remote Access Client,...so nothing has
changed.

But if you want clients to connect to the remote LAN over VPN but without
initializing thier own connection then that means your RRAS box and the same
VPN Device on the other end must be *co-configured* to work together to
create a Router-to-Router VPN (Site-to-Site VPN). This is an entirely
different VPN model.

The articles on www.isaserver.org is the first and best place for
information on this when ISA is involved. When ISA is involved you do *not*
want to configure RRAS directly, but you must do it from within ISA and let
ISA configure RRAS "behind the scenes" otherwise they will fall out of sync
with each other and you will have nothing but problems.

 

ok, for the moment I've configured manually (from the RRAS interface)

I'll try to do the config through isa himself.

 

If you use the ISA server wizard, it handles it all for you. If you use
RRAS to set up a router to router VPN, you need to configure the routes to
the "other" site on each server. You link the routes to the demand-dial
interfaces, so that the routes become active when the demand-dial interface
becomes active.

For this to happen automatically, the "calling" router must use the name
of the dd interface on the answering router as its username. This forces the
connection to link to the dd interface (instead of the default internal
interface) and activates the static route.

 

"the "calling" router must use the name
of the dd interface on the answering router as its username"???

what do you mean exactly?
does my Demand dial interface must have a specific name? or the remote VPN
Server must have a specific name?

 

No, I mean exactly what I said. A router may have several different
routers connecting to it (such as different branch sites). Each site will
have a different IP subnet, so it will need to have a demand dial interface
set up for each site. The correct subnet route for each branch is associated
with the appropriate demand dial interface.

When the answering router receives an incoming connection, it has to
have some way to know which branch is calling and which subnet route to use.
The machanism it uses is the username of the incoming call. If the username
matches one of its demand dial interfaces, it knows which branch is calling
and knows which demand dial interface to connect to. This ensures that the
correct routing is set up. If no match is found, the RRAS server assumes it
is not a router calling, but a normal client-server RAS or VPN connection.

So to get routing working, the demand dial interfaces at both ends of
the connection (calling and answering routers) must be bound to the
connection and become active. Only then will the correct routes be added to
the routing tables of the routers.