|
Posted by Fred Marshall on October 24, 2007, 6:56 pm
If you were Registered and logged in, you could reply and use other advanced thread options
>>
>>>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
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map