Setting up site to site VPN with RV042s

There are many possible issues here, but there are in essence two ways to solve the problem:

a) The "black box" method: get some example router configs that are known to work, adapt them to your situation, and see if that works; or

b) The investigative method: see what's going wrong and try to fix it.

If you want to understand what's going on, then option (b) is by far the best. However, if you just want to get it working and don't care how, then option (a) might be faster if you can lay your hands on some sample configs.

That said, I'm going to give you some basic advice for option (b), which should help you to narrow down the problem if you go down this route.

Your first step should be to determine where it is failing. There are a number of possible points, depending on how far the VPN connection process gets along before something fails:

1. There is no IKE communication at all between the routers;
2. IKE Phase-1 (Main or Aggressive Mode) fails;
3. IKE Phase-2 (Quick Mode) fails; or
4. IKE Phases 1 and 2 complete, but no ESP traffic flows.

I'd set up a sniffer on the hub that connects the two VPN devices (and make sure its a hub and not a switch so you can see the traffic), and watch the communication between them to see how far it gets.

Roy Hills

Roy,

Thanks! Well, at this stage I have the VPN connecting and can ping through it. However, I can't map drives using the IP addresses of their hosts.

All I see on the hub are pretty much ISAKMP Informational packets of 126 bytes each - going one way and then the other. Occasionally there's a ping from one VPN device public address to the other VPN device public address - and a reply.

Fred

If you can ping then the VPN is working, assuming that the ping packets (ICMP echo and echo reply are actually going over the VPN and not just being routed of course).

That's weird. What you should see is some IKE (or ISAKMP, it's the same thing) activity when the VPN connects. This will use UDP port 500 or maybe

When you send data over the VPN (like the ping packets), then you should see ESP (Encapsulating Security Payload) traffic, which is IP protocol 50. You should see one ESP packet for each ping request and reply. Most sniffers will decode ESP to show the SPI numbers, but they won't be able to decode what's inside because it's encrypted.

You shouldn't be seeing plain ping going over the wire, because that suggests that it's not going over the VPN.

Roy

Roy,

Thanks. Well, I set up firewall rules in the VPN routers of all possible combinations: inside IP to inside IP inside IP to outside IP outside IP to inside IP outside IP to outside IP entered each of these rules for the WAN interface and the LAN interface for a total of 8 rules Then, denied all traffic. Any of these can be disabled so I've been trying with them and without them and selectively so.

I found that LAN interface inside IP to inside IP was *necessary* for the VPN to work. That makes sense to me as the LAN interface is unencrypted / outside the tunnel.

I found that WAN interface outside IP to outside IP when enabled caused those outside/outside pings to show up. But, I found no failures when the outside/outside rule was disabled. Yes, this would be outside the tunnel.

I have no explanation for why I see the packets I do with the sniffer I'm using (Ethereal) . I should think the results might vary according to which set of security features are set up.

Thanks,

Fred