On the surface everything looks good except for nat-t. If your wan interface is sitting behind a nat router, you have to have nat-t enabled to make it work. I wont go into why just know it assists in making the border (nat) router forward the traffic properly. If you need to set one or both end to any thats no big deal as unless someone has your ip and key and ike setting exactly they will not connect. You can also look at your router logs to determine if someone is trying.

I have tried a similar setup as mbury describes, but with 2 WRV200's. I believe that the WRV200 does not support initiating a VPN tunnel if it is behind a NAT router, like in mbury's case. The reason is that the WRV200 will identify itself to the remote VPN router with its NATted local address. Because of this, the remote router will reject the tunnel.
In your setup with a RV042 directly connected to an WAN address you might be able to get it working by setting remote secure gateway to "all" in the WRV200. In that case, the WRV200 can obviously no longer initiate a VPN tunnel itself, but it will respond to VPN tunnel setup from a remote VPN gateway, in your case the RV042.
You will find some more information about NAT problems with the WRV200 in the following thread Problems using VPN over 2 WRV200 behind NAT

In your setup with a RV042 directly connected to an WAN address you might be able to get it working by setting remote secure gateway to "all" in the WRV200. In that case, the WRV200 can obviously no longer initiate a VPN tunnel itself, but it will respond to VPN tunnel setup from a remote VPN gateway, in your case the RV042.
You will find some more information about NAT problems with the WRV200 in the following thread Problems using VPN over 2 WRV200 behind NAT

Someone in previously mentioned threads suggested to modify firmware to identify itself with public IP address instead of 'local' WAN address (because this is main reason). Any progress here?

Click to expand...

If the RV042 doesn't support 'any', then there seems to be no solution, at least I don't know one. It is quite stupid that those routers don't let you enter the WAN address for VPN identification.
I have the same problem with 2 WRV200's both placed behind a NAT router/DSL modem. After I understood the root cause of the problem, I tried to solve it in a different way by using half-bridge mode in the DSL modem, so that the WRV200 will get the WAN address. In that setup however a new problem emerged: my ISP gives me an IP address and a gateway address that are not in the same network. The WRV200 cannop cope with this! If found some other threads here that this is a common problem with other routers also.
The WRV200 firmware is just a web interface above some standard 3rd party embedded Linux system. Most probably, the underlying Linux system will support all this, but the Web interface just won't let you enter the required parameters or modify the configuration files! I have downloaded all sources from the Linksys website and was able to compile the firmware image without problems, but so far I have not tried to upgrade the WRV200 with this image. The Web interface is the only interface to upgrade the firmware, so the risk that the WRV200 becomes bricked after introducing some bug is substantial. I was still hoping that Linksys or someone else came up with a solution for this. I would image that this is a common problem in the field!

In contrast to what I said earlier in this thread it is possible to use half-bridge mode in the DSL modem if the provider assigns you an IP address and a gateway address that are not in the same subnet.
The trick is that the router does not need to know the real gateway address at all, it just needs to forward all packets with a destination outside the local network to the DSL modem. You can just assign an arbitrary IP address in the same subnet as your IP address to the DSL modem and use this address as the gateway address. For instance if your IP provides assigns you IP address 1.2.3.4/24 you could assign address 1.2.3.5/24 to the DSL modem and use this address as gateway address in the router.
Moreover, I found later that the Speedtouch 546 ADSL modem can even do this same trick automatically by specifying the keyword "localgw=enable" in the half-bridge pool:

The simplest solution would of course be to specify a static ARP entry in the router with the gateway address resolved to the DSL modem's ethernet address (this is how Windows XP does it), but with the WRV200 this is not possible since it unfortunately has no telnet server.

If both VPN routers are behind a DSL modem in half bridge mode, it will be possible to have a VPN tunnel after all!

Speaking from experience, the WRV200 can and does initiate vpn tunnels from behind NAT enabled devices; I've been able to create vpn tunnels behind a CISCO Pix 501 and and SMCBR18VPN Barricade Router. The device on the opposite side was also a PIX 501 (the tester on the other side of the tunnel was Eric.Stewart). Oddly enough, in order for the tunnel to actually come up, I had to set the wrv200 to "static ip." At the time, I was using it on an ADSL connection on its default of "obtain ip automatically," once I configured it for "static ip" my tunnel(s) started working.

To make matters stranger, if you put a wrv200 on a cable modem connection set at it's default "obtain ip automatically," vpn tunnels run fine. Hmmmm *scratch* *scratch*

On another note: I've just discovered an anomaly I've reported to the developers. The issue is when you're running vpn tunnels between a wrvs4400n and another vpn router, the tunnels connect. "BUT," as soon as you connect a tunnel between the wrv200 and the wrvs4400n, the tunnel drops between the wrvs4400n "and" any other vpn device; the tunnel between the wrvs4400n and the wrv200 remains in tact (the developers acknowledged this and are working on fix).

So, if anyone has been having problems running multiple tunnels with various routers, consider this

The WRV200 firmware is just a web interface above some standard 3rd party embedded Linux system. Most probably, the underlying Linux system will support all this, but the Web interface just won't let you enter the required parameters or modify the configuration files! I have downloaded all sources from the Linksys website and was able to compile the firmware image without problems, but so far I have not tried to upgrade the WRV200 with this image. The Web interface is the only interface to upgrade the firmware, so the risk that the WRV200 becomes bricked after introducing some bug is substantial. I was still hoping that Linksys or someone else came up with a solution for this. I would image that this is a common problem in the field!

Click to expand...

Wow. Is the firmware you built identical to the stock firmware? Were you able to include the non-GPL code (perhaps by cutting and pasting from a binary)?

All that is needed to start making progress is access to a shell (ssh would be great). Just using a shell is unlikely to accidentally brick the box.

Wow. Is the firmware you built identical to the stock firmware? Were you able to include the non-GPL code (perhaps by cutting and pasting from a binary)?

All that is needed to start making progress is access to a shell (ssh would be great). Just using a shell is unlikely to accidentally brick the box.

Click to expand...

I have obtained the GPL code from the Linksys site (see here). I could compile the code as is without problems on a Linux system. I obtained a FW image with about the same size as the original FW (a few hundreds of bytes difference). Because it was not exactly identical, I was afraid to flash it, since it might brick the box and there is no way to unbrick it again. That said, it should not be difficult to add the sshd and tftp daemons; this would be a real asset.

I have obtained the GPL code from the Linksys site (see here). I could compile the code as is without problems on a Linux system. I obtained a FW image with about the same size as the original FW (a few hundreds of bytes difference). Because it was not exactly identical, I was afraid to flash it, since it might brick the box and there is no way to unbrick it again. That said, it should not be difficult to add the sshd and tftp daemons; this would be a real asset.

Click to expand...

Other than the unknown issue of if the GPL compiled code will flash. Would it ever be possible to add the WRT-like bootup TFTP flash functionality into the GPL code. I.E. does the hardware interface and memory storage locations appear to be similar? Just an off the wall question.