RV042 - Does anyone understand it? Documentation?

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

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->InternetINTERNET->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->InternetInternet

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

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

I think I've solved *that* problem at least.... It seems I'd switched the RV042s to Router mode - in working on the routing issues. So, switched back to Gateway mode gets the VPN traffic to working.

Now back to the routing question.

I'm pretty well stuck with the existing subnets because of all sorts of 3rd party settings, etc. Changing would be a nightmare because of that. As it stands, the two LAN subnets are parts of the same address range.

- I've determined that you can't construct a VPN on an RV042 that has overlapping subnets at the ends.

I was advised to set up a tunnel that would target the far away subnet (plus add a route to a gateway on the destination LAN): So, the tunnels would look like this:

Source end: Destination hop: RV042#2 RV042#1

**Tunnel 1 **Tunnel 1 216.123.123.4 216.123.123.5 gw 216.123.123.1 gw 216.123.123.1 Local: Local: 192.168.113.128 192.168.113.192 255.255.255.224 255.255.255.192 Remote: Remote: 192.168.113.192 192.168.113.128 255.255.255.192 255.255.255.224

**Tunnel 2 **Tunnel 2

216.123.123.4 216.123.123.5 gw 216.123.123.1 gw 216.123.123.1 Local: Local: 192.168.113.128 192.168.1.0 255.255.255.224 255.255.255.0 Remote: Remote: 192.168.1.0 192.168.113.128 255.255.255.0 255.255.255.224

But, the RV042 also doesn't like to have the same subnet at the remote end of more than one tunnel. Why, I can't figure out because anything destined for it would have to be coming from the designated source subnet wouldn't it? Oh well ..... would still like to understand if there's a fundamental reason why.

So, then I tried this using two RV042s at the source end:

Source end: Destination hop: RV042#2 RV042#1

**Tunnel 1 **Tunnel 1 216.123.123.4 216.123.123.5 gw 216.123.123.1 gw 216.123.123.1 Local: Local: 192.168.113.128 192.168.113.192 255.255.255.224 255.255.255.192 Remote: Remote: 192.168.113.192 192.168.113.128 255.255.255.192 255.255.255.224

same as before..... But now, introduce a second RV042 at the source end with its own public IP address:

RV042#3 (new) RV042#1 (still)

**Tunnel 1 **Tunnel 2 216.123.123.6 216.123.123.5 gw 216.123.123.1 gw 216.123.123.1 Local: Local: 192.168.113.128 192.168.1.0 255.255.255.224 255.255.255.0 Remote: 216.123.123.5 Remote: 216.123.123.6 192.168.1.0 192.168.113.128 255.255.255.0 255.255.255.224

Even though the remote IP addresses are different, the RV042#1 doesn't seem to like the fact that the subnets are repeated at the remote end of two tunnels! It generates an error saying that the remote subnet IP value is in conflict with tunnel 1.

It then seems that one is constrained from having the same private subnet range at two different physical locations, with different public IP addresses, and to support having VPNs to a central site through a single RV042. How unfortunate!

My next step, subject to any suggestions or explanations I may receive, will be to add a 2nd RV042 at the site so that the two tunnels will be supported with completely separate RV042s. This seems a dreadful waste of hardware and public IP addresses! It would look like this:

RV042#3 RV042#4 (new)

**Tunnel 1 **Tunnel 1 216.123.123.6 216.123.123.7 gw 216.123.123.1 gw 216.123.123.1 Local: Local: 192.168.113.128 192.168.1.0 255.255.255.224 255.255.255.0 Remote: 216.123.123.7 Remote: 216.123.123.6 192.168.1.0 192.168.113.128 255.255.255.0 255.255.255.224 with a LAN address of: 192.168.113.xxx with a route for 192.168.1.0 to 192.168.113.yyy

Then, all traffic destined for 192.168.1.xxx on the source LAN will be directed to the LAN IP of RV042#3. It will traverse the tunnel. It will be routed by RV042 #4 (outside the tunnel) to the designated gateway/next hop on the LAN. Return traffic destined for the original source LAN will traverse through the first set of tunnels / through the first pair of RV042s.

Comments?

Thanks,

Fred