Re: VPN routing


"Gordon Montgomery" <gordon@xxxxxxx> wrote in message
news:13hv78vr96c0771@xxxxxxxxxxxxxxxxxxxxx
In article <eomdnfT8uKgHD4PanZ2dnUVZ_umlnZ2d@xxxxxxxxxxxxxx>, "Fred
Marshall" <fmarshallx@xxxxxxxxxxxxxxxxxxxx> wrote:

"Gordon Montgomery" <gordon@xxxxxxx> wrote in message
news:13h7m9u90d2nre4@xxxxxxxxxxxxxxxxxxxxx
I have a client that has the following network setup.

A remote site connected by a point-to-point T1.
The remote site is on 10.0.3.0/24, with a router 10.0.3.1 internal
and 192.168.0.2 external ( the P-t-P T1 ) to 192.168.0.1 external
and 10.0.1.7 internal router at the main site. The main site is on
10.0.1.0/24
with a firewall (and default route ) at 10.0.1.1 and then connected to
the
internet. We can connect with a VPN directly to the firewall's external
address, but still can't directly access anything on the remote (
10.0.3.0/24)
site. The main firewall does have a static route for 10.0.3.0/24 through
10.0.1.7. Everything works for the remote site, we would just like to
be able to directly connect to the remote site when connected with
the VPN. When I am actually at the main site, I have no problem
connecting to the remote site. I have tried adding a static route once
the VPN client is connected, but I can't add the route. The firewall
is a Watchguard SOHO 6TC, and the VPN client is Watchguard's
Mobile User VPN Version 7.3. I don't see any obvious places either
in the client or the firewall that I can specify routes for the VPN to
use.

Gordon,

You want to get to computers on 10.0.3.0/24 from some arbitrary internet
node via VPN.
The immediate problem I see with that is the return path - that is
certainly
necessary.

Let's take a bit simpler situation first. Assume that the VPN is
site-to-site. Then the public IP addresses of both ends are known and the
private IP address ranges are also known. Maybe this distinction doesn't
matter as long as the remote VPN subnet is known - because it will need to
be known I do believe.

Let's assume the VPN remote site subnet is 10.0.4.0/24.

From the VPN remote site, launch a packet destined for 10.0.3.0/24 - the
T1
remote site.
When the packet arrives at the VPN main site inside subnet, it has to be
routed to 10.0.1.7. Something like:
route add -p 10.0.3.0 255.255.255.0 10.0.1.7
This would be a route in the machine terminating VPN at the main site.
That's the *only* place you can add the route.
So, the VPN device must be able to take and act on such a route on packets
emerging the VPN.
I presume that this route doesn't exist at the moment ...... ?

I don't know how you route from the remote T1 subnet to the main T1
subnet.
So, I'm going to assume there are two-way routes that accomplish this.

Then, you need for there to be a return route from 10.0.3.0 to 10.0.4.0.
It might go like this:
Launch a packet from a host on 10.0.3.0 destined for a host on 10.0.4.0
with next hop 10.0.3.1 ... the next hop generally has to be on the same
subnet.
Presumably the router on 10.0.3.1 has a route like this already:
Destination 10.0.1.0 255.255.255.0 gw 192.168.0.1.
Then, since the packet isn't destined to any old 10.0.1.0 host, when the
packet hits 192.168.0.1, there has to be a route on that router like this:
Destination 10.0.4.0 255.255.255.0 gw 10.0.1.1.
Presumably this route doesn't exist yet......... ?

Fred


Thanks for your response. I did get this working by setting up a
new VPN connection that did not split the routing, i.e. when connected
by VPN to this new connection, the remote computer routed *all* packets
through the VPN, not just those headed for the 10.0.1.0/24 network. As
I explained, routing within the 10.0.x.0 networks works fine, it was just
that when we connected to the 10.0.1.0 network through the VPN, we
couldn't hit any of the other 10.0.x.0 networks.

I'm glad to hear you got it working. I realized that my post had an error
in it.

To get to 10.0.4.0 via a VPN, you have to have a VPN that terminates with
the destination subnet in the definition of the VPN. You didn't have that
before.
This means there have to be two VPNs. One between the remote VPN and the
main site and one between the remote VPN and the remote/non-VPN site/subnet.
Then you need a route on the latter main VPN termination (which is on the
main subnet) that sends packets to the router that gets the packets to the
remote/non-VPN site/subnet.

Then the return path has to have a route that points to the VPN termination
address on the main subnet.

Fred


.

Relevant Pages

  • Re: VPN & FTP Question
    ... that the remote client is XP Pro SP2. ... I'm guessing that it is somethint to do with retaining the "route add" ... > default gateway will be changed to the VPN connection once the VPN ... > simply turn off the Use default gateway on remote host in the TCP/IP ...
    (microsoft.public.windows.server.sbs)
  • RE: Requesting data from Microsoft Exchange Server.
    ... First the VPN is a hardware VPN, so there's nothing really to configure on ... The router at the remote site was originally set at MTU 1500 ... I tried it both with and without the MTU on the client PC set. ...
    (microsoft.public.exchange2000.clients)
  • Re: Route an external IP address via site to site vpn
    ... setup the site-to-site VPN connection thru 2 ISA 2004 servers? ... but the remote ISP not. ... We only need to add a static IP route on local ISA server to let the ISA ... Router add ExternalIP RemoteISAInternalIP ...
    (microsoft.public.windows.server.sbs)
  • Re: VPN and Domain
    ... I can remote connect to the remote site (one of the computer at least, ... If the VPN is setup between the 2 sites using Linksys, ... SBS uses 2 NIC's, internal and external. ...
    (microsoft.public.windows.server.sbs)
  • Re: VPN routing
    ... A remote site connected by a point-to-point T1. ... We can connect with a VPN directly to the firewall's external ... The main firewall does have a static route for 10.0.3.0/24 through ... by VPN to this new connection, the remote computer routed *all* packets ...
    (comp.dcom.vpn)