VPN - RV042 - Does anyone understand it? Documentation?

Author

RV042 - Does anyone understand it? Documentation?

Fred Marshall

2007-06-07, 1:14 am

I'm using RV042s for VPNs and general routing. Often there are questions
but seem to be no place for answers.

For example: if one is using an RV042 for VPN, then what affect does the
routing table have on the VPN packets?

Is there any place where this sort of thing is reasonably described? Or, is
the answer to this one question supposed to be obvious?

Fred

Mike Drechsler - SPAM PROTECTED EMAIL

2007-06-07, 1:14 am

Fred Marshall wrote:
> I'm using RV042s for VPNs and general routing. Often there are questions
> but seem to be no place for answers.
>
> For example: if one is using an RV042 for VPN, then what affect does the
> routing table have on the VPN packets?
>
> Is there any place where this sort of thing is reasonably described? Or, is
> the answer to this one question supposed to be obvious?
>
> Fred

apparently it's supposed to be obvious.

It does help to have prior experience with setting up IPSEC VPN tunnels
and a good understanding of how it works.

Routing tables will have limited use when you are trying to move
traffic. A routing table will not affect the contents or intended
contents of an encrypted packet.

If you want to give an example of what you are attempting to setup then
perhaps you will find some help.

--
WARNING! Email address has been altered for spam resistance.
Please remove the -deletethispart-. section before replying directly.
Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)

Fred Marshall

2007-06-07, 7:14 pm

"Mike Drechsler - SPAM PROTECTED EMAIL"
<mike-newsgroup@-DELETETHISPART-.upcraft.com> wrote in message
news:paK9i.248353$oS7.31459@fe04.news.easynews.com...
> Fred Marshall wrote:
>
> apparently it's supposed to be obvious.
>
> It does help to have prior experience with setting up IPSEC VPN tunnels
> and a good understanding of how it works.
>
> Routing tables will have limited use when you are trying to move traffic.
> A routing table will not affect the contents or intended contents of an
> encrypted packet.
>
> If you want to give an example of what you are attempting to setup then
> perhaps you will find some help.

Mike,

thanks for the reply.

I can envision the VPN "block" running in series or in parallel with the
routing table "block". In the first case, on the incoming / post-decryption
end. In the second case, totally independent. Not much else makes sense to
me but I sure can be enlightened.

What I've been trying to do is like this:

Launch a packet destined for a "foreign" private subnet.
Route such packets at their source to the LAN address of the RV042 VPN
router.
From there over the internet.
When the packet is received at the other end of the tunnel, it will still be
destined for a "foreign" private subnet.
i.e. the packet is destined neither for the local nor the remote subnet.

So, I add a route on the receiving RV042 that points such packets to a
gateway on the remote LAN. If this works then such packets should be
directed to that gateway. But, it doesn't seem to work.

Here are the addresses involved:

Source: 192.168.113.130 Destination 192.168.1.4
255.255.255.224 Route for destination: 192.168.113.157 the RV042
VPN

(I guess at this point there is no route in the RV042 for this address
range. Can the RV042 routing table route packets into its own VPN? I don't
see how). So, this could be a problem I guess. The destination *is not* in
the VPN remote LAN range.

(internet)

RV042 VPN 192.168.113.198 w/Route: 192.168.1.0 /24 > 192.168.113.254
255.255.255.192 255.255.255.192
has port
on:192.168.1.0/24

It appears that the packets don't arrive at the destined router on the
remote LAN.

If the RV042 routing table does not deal with unencrypted packets coming out
of the VPN then this method wouldn't be expected to work. It would really
help to know what to expect without running a bunch of experiments.

Or, maybe the VPN-initiating RV042 doesn't accept packets thus destined - as
they are on different subnets? My confusion here is that there's a remotely
managed cisco router on site that does pretty much the same thing. It takes
the packets and routes them to appropriate ports just fine (and for a lot
more $$).

Fred

Mike Drechsler - SPAM PROTECTED EMAIL

2007-06-08, 1:14 am

Fred Marshall wrote:
> "Mike Drechsler - SPAM PROTECTED EMAIL"
> <mike-newsgroup@-DELETETHISPART-.upcraft.com> wrote in message
> news:paK9i.248353$oS7.31459@fe04.news.easynews.com...
>
> Mike,
>
> thanks for the reply.
>
> I can envision the VPN "block" running in series or in parallel with the
> routing table "block". In the first case, on the incoming / post-decryption
> end. In the second case, totally independent. Not much else makes sense to
> me but I sure can be enlightened.
>
> What I've been trying to do is like this:
>
> Launch a packet destined for a "foreign" private subnet.
> Route such packets at their source to the LAN address of the RV042 VPN
> router.
> From there over the internet.
> When the packet is received at the other end of the tunnel, it will still be
> destined for a "foreign" private subnet.
> i.e. the packet is destined neither for the local nor the remote subnet.
>
> So, I add a route on the receiving RV042 that points such packets to a
> gateway on the remote LAN. If this works then such packets should be
> directed to that gateway. But, it doesn't seem to work.
>
> Here are the addresses involved:
>
> Source: 192.168.113.130 Destination 192.168.1.4
> 255.255.255.224 Route for destination: 192.168.113.157 the RV042
> VPN
>
> (I guess at this point there is no route in the RV042 for this address
> range. Can the RV042 routing table route packets into its own VPN? I don't
> see how). So, this could be a problem I guess. The destination *is not* in
> the VPN remote LAN range.
>
> (internet)
>
> RV042 VPN 192.168.113.198 w/Route: 192.168.1.0 /24 > 192.168.113.254
> 255.255.255.192 255.255.255.192
> has port
> on:192.168.1.0/24
>
> It appears that the packets don't arrive at the destined router on the
> remote LAN.
>
> If the RV042 routing table does not deal with unencrypted packets coming out
> of the VPN then this method wouldn't be expected to work. It would really
> help to know what to expect without running a bunch of experiments.
>
> Or, maybe the VPN-initiating RV042 doesn't accept packets thus destined - as
> they are on different subnets? My confusion here is that there's a remotely
> managed cisco router on site that does pretty much the same thing. It takes
> the packets and routes them to appropriate ports just fine (and for a lot
> more $$).
>
> Fred
>
>

The VPN endpoints will not encrypt any traffic that is not included in a
security association. In other words the range of IP's you are trying
to reach and the range of IP's the traffic is coming from MUST be
included in the subnets for the encrypted tunnel. You cannot use the
encrypted tunnel as a route where arbitrary packets can enter on one
side and exit the other side. IPSEC is meant as an end to end ecryption
mechanism so it will refuse any traffic that is not specifically
included in the subnet ranges that were used to build to the tunnel.

So I'm looking at the VPN Tunnel settings on an RV082 which I assume has
the same user interface as the rv042. Where it says Local and remote
security group type, IP address, and subnet mask. These will define the
range of IP's that will go through the tunnel connection. The solution
would be to either create a larger range of IP's to include in the local
and remote subnets or if that is not practical then create a second
tunnel with a different set of remote and local IP's that will be sent
encrypted to the other router.

I'm sorry I cannot comment on your specific examples. I have no clue
what you are trying to do with the IP's you listed, it's simply not
clear to me the way you wrote things down.

Here is a simple example.

So the basic case is you create a VPN tunnel that connects the
192.168.100.0/24 subnet in your estern office with the 192.168.200.0/24
subnet on the other site at your western office. This is the simple
case and you would simply follow the examples in the documentation.

192.168.100.0/24(east)->RV042->Internet<-RV042<-192.168.200.0/24(west)

Now you are saying that you have multiple subnets in each office and you
want to route the traffic to the tunnel. So you are assuming that you
can just create a static routing table entry to point the traffic to the
IP of the router on the other end of the tunnel and you expect that the
packet would end up inside the tunnel as a result

So you have built a tunnel using the simple case example above.
Now you create a static route in the east that looks something like this:

You want:
192.168.101.0/24->192.168.100.1->INTERNET->192.168.200.1->192.168.201.0/24

On the east side you create a static route that says Destination ip:
192.168.201.0/24 (a subnet in the other office) uses gateway
192.168.200.1 (Internal IP of the router on the other site)
On the west side you create a similar static route that says Destination
ip: 192.168.101.0/24 uses gateway 192.168.100.1

But this will not work because these source and destination IP's are not
part of the original subnets of the tunnel they will not be encrypted or
sent across the tunnel.

What you need to do is create 2 parallel tunnels that go between the
same routers with different local and remote subnets.
192.168.100.0/24(east)->RV042->Internet<-RV042<-192.168.200.0/24(west)
192.168.101.0/24(east)->RV042->Internet<-RV042<-192.168.201.0/24(west)

Also the subnet definitions of the tunnel do not need to exactly match
the LAN subnet on the other side. You can make these larger as long as
the range of IP's in the larger subnet range is still correct for the
remote site. Also you can use expanded subnet ranges to create hub and
spoke configurations where one central site creates single tunnels to
each branch office and if one branch office wants to communicate with
another branch office then the traffic flows to the central site first
where it is redirected to another tunnel to the second branch site.
This requires good planning but it saves you from creating a tangled
mess of tunnels for sites that rarely need to communicate directly.

A good example would be:

Central site: 192.168.100.0/24
Branch 1: 192.168.110.0/24
Branch 2: 192.168.120.0/24
Branch 3: 192.168.130.0/24
etc.

To create a hub and spoke configuration you would create a tunnel like this:
Local security group: 192.168.110.0/24
Remote security group: 192.168.0.0/16 (The remote range is for
192.168.0.0-192.168.255.255)

So now you send a packet from branch 1 to branch 2.
eg: source: 192.168.110.15 -> dst: 192.168.120.55

So this causes your router to send any traffic that is not for the local
lan on a private IP in the 192.168.0.0 range off through the encrypted
tunnel. When it reaches the other end that central router will evaluate
the packet after decrypting it and if it is for it's local lan it will
forward it to the LAN. If not then it will evaluate the packet to see
if it matches another tunnel. It will find that a tunnel with a remote
subnet of 192.168.120.0/24 exists and that this packet also matches the
local security group definition so it is to be encrypted in the tunnel.
It resends the packet to branch 2. The branch 2 router decrypts the
packed and finds the destination is for the local subnet so it forwards
it to it's LAN.

You can think of these tunnel definitions as another layer of routing
that happens before the traditional routing table is evaluated.

--
WARNING! Email address has been altered for spam resistance.
Please remove the -deletethispart-. section before replying directly.
Mike Drechsler (mike-newsgroup@-deletethispart-.upcraft.com)

Fred Marshall

2007-07-02, 1:13 am

"Mike Drechsler - SPAM PROTECTED EMAIL"
<mike-newsgroup@-DELETETHISPART-.upcraft.com> wrote in message
news:UB4ai.11534$ds2.9652@fe02.news.easynews.com...
> Fred Marshall wrote:
>
>
> The VPN endpoints will not encrypt any traffic that is not included in a
> security association. In other words the range of IP's you are trying to
> reach and the range of IP's the traffic is coming from MUST be included in
> the subnets for the encrypted tunnel. You cannot use the encrypted tunnel
> as a route where arbitrary packets can enter on one side and exit the
> other side. IPSEC is meant as an end to end ecryption mechanism so it
> will refuse any traffic that is not specifically included in the subnet
> ranges that were used to build to the tunnel.
>
> So I'm looking at the VPN Tunnel settings on an RV082 which I assume has
> the same user interface as the rv042. Where it says Local and remote
> security group type, IP address, and subnet mask. These will define the
> range of IP's that will go through the tunnel connection. The solution
> would be to either create a larger range of IP's to include in the local
> and remote subnets or if that is not practical then create a second tunnel
> with a different set of remote and local IP's that will be sent encrypted
> to the other router.
>
> I'm sorry I cannot comment on your specific examples. I have no clue what
> you are trying to do with the IP's you listed, it's simply not clear to me
> the way you wrote things down.
>
> Here is a simple example.
>
> So the basic case is you create a VPN tunnel that connects the
> 192.168.100.0/24 subnet in your estern office with the 192.168.200.0/24
> subnet on the other site at your western office. This is the simple case
> and you would simply follow the examples in the documentation.
>
> 192.168.100.0/24(east)->RV042->Internet<-RV042<-192.168.200.0/24(west)
>
>
> Now you are saying that you have multiple subnets in each office and you
> want to route the traffic to the tunnel. So you are assuming that you can
> just create a static routing table entry to point the traffic to the IP of
> the router on the other end of the tunnel and you expect that the packet
> would end up inside the tunnel as a result
>
> So you have built a tunnel using the simple case example above.
> Now you create a static route in the east that looks something like this:
>
> You want:
> 192.168.101.0/24->192.168.100.1->INTERNET->192.168.200.1->192.168.201.0/24
>
> On the east side you create a static route that says Destination ip:
> 192.168.201.0/24 (a subnet in the other office) uses gateway 192.168.200.1
> (Internal IP of the router on the other site)
> On the west side you create a similar static route that says Destination
> ip: 192.168.101.0/24 uses gateway 192.168.100.1
>
> But this will not work because these source and destination IP's are not
> part of the original subnets of the tunnel they will not be encrypted or
> sent across the tunnel.
>
> What you need to do is create 2 parallel tunnels that go between the same
> routers with different local and remote subnets.
> 192.168.100.0/24(east)->RV042->Internet<-RV042<-192.168.200.0/24(west)
> 192.168.101.0/24(east)->RV042->Internet<-RV042<-192.168.201.0/24(west)
>
> Also the subnet definitions of the tunnel do not need to exactly match the
> LAN subnet on the other side. You can make these larger as long as the
> range of IP's in the larger subnet range is still correct for the remote
> site. Also you can use expanded subnet ranges to create hub and spoke
> configurations where one central site creates single tunnels to each
> branch office and if one branch office wants to communicate with another
> branch office then the traffic flows to the central site first where it is
> redirected to another tunnel to the second branch site. This requires good
> planning but it saves you from creating a tangled mess of tunnels for
> sites that rarely need to communicate directly.
>
> A good example would be:
>
> Central site: 192.168.100.0/24
> Branch 1: 192.168.110.0/24
> Branch 2: 192.168.120.0/24
> Branch 3: 192.168.130.0/24
> etc.
>
> To create a hub and spoke configuration you would create a tunnel like
> this:
> Local security group: 192.168.110.0/24
> Remote security group: 192.168.0.0/16 (The remote range is for
> 192.168.0.0-192.168.255.255)
>
> So now you send a packet from branch 1 to branch 2.
> eg: source: 192.168.110.15 -> dst: 192.168.120.55
>
> So this causes your router to send any traffic that is not for the local
> lan on a private IP in the 192.168.0.0 range off through the encrypted
> tunnel. When it reaches the other end that central router will evaluate
> the packet after decrypting it and if it is for it's local lan it will
> forward it to the LAN. If not then it will evaluate the packet to see if
> it matches another tunnel. It will find that a tunnel with a remote
> subnet of 192.168.120.0/24 exists and that this packet also matches the
> local security group definition so it is to be encrypted in the tunnel. It
> resends the packet to branch 2. The branch 2 router decrypts the packed
> and finds the destination is for the local subnet so it forwards it to
> it's LAN.
>
> You can think of these tunnel definitions as another layer of routing that
> happens before the traditional routing table is evaluated.

Mike,

Thanks.
Well the point of my question was about how the RV042 works. I'm becoming
rather convinced that if it's being used as a VPN device then the static
routes one might enter will have no affect.

Fred

Fred Marshall

2007-08-16, 1:14 am

"Mike Drechsler - SPAM PROTECTED EMAIL"
<mike-newsgroup@-DELETETHISPART-.upcraft.com> wrote in message
news:UB4ai.11534$ds2.9652@fe02.news.easynews.com...
> Fred Marshall wrote:

Mike,

I'm still working on this project having taken a bit of a nice vacation.
Thanks for your thoughtful reply. I'm going to try the larger subnet range
idea to see if that doesn't help. It may well do what I need.

That does raise a question:

Can one subnet be a subset of the other subnet? Like 192.168.1.192
255.255.255.192 AND 192.168.1.0 255.255.255.0 at the other end?

In the mean time it appears that things have moved sideways as now packets
destined for the opposite LAN seem to "bounce off" the local RV042/VPN
device - even though the VPN shows it's "connected".

If I tracert to a client on the opposite LAN, the trace goes first to the
VPN device IP and then to the default gateway IP - making it appear that the
VPN device didn't respond to that packet at all....
I can't ping through the VPN now - even though it worked "in the lab".

Fred