Re: VPN and Routing in one box
- From: "Fred Marshall" <fmarshallx@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 11 Sep 2007 18:56:16 -0700
"Mike Drechsler - SPAM PROTECTED EMAIL"
<mike-newsgroup@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:q2EFi.66317$CK1.20976@xxxxxxxxxxxxxxxxxxxxxxxxx
Fred Marshall wrote:
"Rome On Crestes" <romeoncrestes@xxxxxxxxxxxxxxxxxxx> wrote in message
news:e9SEi.16757$gR1.5033@xxxxxxxxxxxxxxxxxxxxxxxxx
Fred Marshall wrote:
I need a router that can be a VPN end point AND will route packetsLinksys RV042 will do that.
coming out of the VPN.
Any suggestions for a simple router that will do this?
Thanks,
Fred
Oh! How I wish that were true as I have a number of them on hand! I
have done a number things to make them do it and have become convinced
that they can't. I'd be very happy to be found deficient in my thinking
/ testing or configuration.
Here is the scenario:
Subnet 1 < VPN > Subnet 2 > [router] > Subnet 3
192.168.1.0 192.168.2.0 192.168.3.0
Packets originate in Subnet 1, destined for Subnet 3.
The VPN (Subnet 1 end) is the first hop.
When packets arrive via the VPN at Subnet 2, they have to be routed to a
particular router / IP address on Subnet 2, which is the next hop in
order to be futher routed to Subnet 3.
Thus, a route has to be effective at the Subnet 2 end of the VPN that
sends packets destined for Subnet 3 to the router on Subnet 2.
(The return path is already taken care of separately).
That route might look like this:
192.168.3.0 255.255.255.0 192.168.2.199 where .199 is the
address of the router on Subnet 2.
Here is the setup I used:
Subnet 1 < RV042 VPN > Subnet 2 > [router] > Subnet 3
192.168.1.0 192.168.2.0 192.168.3.0
The RV042 Tunnel goes from 192.168.1.0 to 192.168.3.0
The Subnet 2 RV042 VPN end LAN is on subnet 2.
The static route in the Subnet 2 RV042 points packets destined for Subnet
3 to the [router] on Subnet 2.
Packets destined for Subnet 3 are routed to the VPN on Subnet 1.
When they come out of the VPN, there needs to be something to tell them
to go to the [router] as the next hop.
Thus the static route.
I have rather conclusively shown that the static route does nothing. So,
I wonder what I'm missing?
---
What one can't do is to have the "forward" VPN Tunnel defined between
Subnet 1 and Subnet 2. Then packets destined for Subnet 3 won't *enter*
the tunnel at the source end. Thus, it appears a static route at the
receiving end is necessary. Then a separate tunnel between Subnets 1 and
2 can be used as the return path without this kind of problem.
Thanks,
Fred
You can NEVER forward packets through a VPN unless there is a valid
security association for them. A security association includes the source
and destination of the packet even if that destination is for another
subnet. Source and destination do not include intermediate points or next
hops unless there is a router doing network address translation and
rewriting the packet.
SUBNET 1 (192.168.1.0) < SUBNET 2 (192.168.2.0) < SUBNET 3 (192.168.3.0)
So you have a VPN between subnet 1 and subnet 2 and then a router on the
link between subnet 2 and subnet 3 right?
Simple case: So you want packets to go from subnet 1 to subnet 2. Very
easy you create a VPN entry where the source network is 192.168.1.0 and
the destination is 192.168.2.0.
Case 2: You want packets to go from subnet 1 to subnet 3 via the VPN
gateway on subnet 2. So the way you are trying to force this to happen is
to create a static route on the VPN routers that says that packets for
192.168.3.0 should be sent through the VPN gateway at 192.168.2.0 and you
expect those packets will be sent through the existing VPN link but they
don't work that way. This is entirely correct and expected behavior for
every implementation of IPSEC. You need to create another VPN between the
very same 2 routers as before but with a different destination. Create a
second VPN entry: source 192.168.1.0 destination 192.168.3.0 the remote
gateway will still be the VPN router on subnet 2. This will allow the
packets to get to the remote network. Now your static route on the vpn
router at subnet 2 will be able to work to send those packets over to the
router to get to subnet 3.
On the linksys routers when you add a VPN gateway to gateway entry for the
link from subnet 1 to subnet 3 it will look like this:
Local group setup:
Local security gateway type: IP Only if you have static IP's on both
ends.
Local security group type: Subnet
IP Address: 192.168.1.0
Subnet mask: 255.255.255.0
Remote Group setup
Remote security gateway type: IP Only
IP address: Give the public static IP of the VPN Router on subnet 2 here.
Remote security group type: subnet
IP Address: 192.168.3.0
Subnet mask: 255.255.255.0
IPSec Setup:
All of these settings need to match between the two gateways. I trust
you can figure this part out.
For the link on the router at subnet 2 the corresponding entries for this
VPN link will look like this:
Local group setup:
Local security gateway type: IP Only if you have static IP's on both
ends.
Local security group type: Subnet
IP Address: 192.168.3.0 <- THIS IS THE SETTING YOU HAVE BEEN MISSING
Subnet mask: 255.255.255.0
Remote Group setup
Remote security gateway type: IP Only
IP address: Give the public static IP of the VPN Router on subnet 1 here.
Remote security group type: subnet
IP Address: 192.168.1.0
Subnet mask: 255.255.255.0
IPSec Setup:
All of these settings need to match between the two gateways. I trust
you can figure this part out.
On the VPN router at subnet 2 you will add a static route in the
Setup->More->Advanced routing screen.
Destination IP: 192.168.3.0
Subnet mask: 255.255.255.0
Default gateway: 192.168.2.??? Whatever the IP of the router that is
moving packets to subnet 3 is.
Hop count metric: 1
Interface: LAN
No static route entries will be required on the router at VPN 1. The
router for the link between subnet 2 and 3 will need to either use the VPN
gateway on subnet 2 as it's default route or it will need static a static
route entry for subnet 1 to point to the VPN gateway on subnet 2.
So on both VPN routers you will now have 2 nearly identical VPN entries
created but with a small change in the IP address of the subnet.
Mike,
Thank you so much for the reply! You understand the situation perfectly.
And, the approach you describe is exactly what I've done and tested fairly
well. I can add a couple of things:
1) You cannot set up this 2nd tunnel using the same pair of RV042s as
support the subnet 1 to subnet 2 VPN. The RV042 complains that there is a
conflict when the remote subnet is repeated among tunnel definitions. To
get around this limitation I use another pair of RV042s. (Although I guess
it's only a problem at one end and can probably combine the tunnels at one
end into a single box). Fortunately I have enough public IP addresses to
play with!
2) For the RV042 VPNs to work, it has to be set to Mode:Gateway and *not*
Mode:Router. I'm not sure if this has any implications so I simply mention
it. Learned this the hard way.
3) In the receiving RV042 that terminates the tunnel for 192.168.3.0 and is
homed on 192.168.2.0, static routes appear to do nothing with packets that
emerge from the VPN. Thus, while there is a way to specify the next hop on
192.168.2.0, the table entry appears to do nothing. And, there is no LAN
Gateway setting that I can determine.
So, I'm looking for one of two things:
- Someone who has actually made RV042s do this application and can tell me
how to do it.
- Suggestions for other boxes that will do the job.
Thanks again. It's good to have the approach confirmed in such detail! And
the comment about VPN security associations is helpful in understanding
what's going on.
Fred
.
- References:
- VPN and Routing in one box
- From: Fred Marshall
- Re: VPN and Routing in one box
- From: Rome On Crestes
- Re: VPN and Routing in one box
- From: Fred Marshall
- Re: VPN and Routing in one box
- From: Mike Drechsler - SPAM PROTECTED EMAIL
- VPN and Routing in one box
- Prev by Date: Re: VPN and Routing in one box
- Next by Date: Correct response to Aggressive Node if not supported
- Previous by thread: Re: VPN and Routing in one box
- Next by thread: Correct response to Aggressive Node if not supported
- Index(es):
Relevant Pages
|
