1. Home
  2. Virtual Private Networks
  3. VPN routing

VPN routing

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.

Any ideas would be greatly appreciated. Even if it is a definitive 'That can't be done.'

Thanks,

Gordon Montgomery Living Scriptures, Inc snipped-for-privacy@lsi.com (anti spam - replace lsi with livingscriptures) (801) 627-2000

Reply to
Gordon Montgomery
Loading thread data ...

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

Reply to
Fred Marshall

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.

Thanks again.

Gordon

Reply to
Gordon Montgomery

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

Reply to
Fred Marshall

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.