VPN - Setting up site to site VPN with RV042s

Author

Setting up site to site VPN with RV042s

Fred Marshall

2007-04-21, 7:13 pm

I'm working to set up a VPN between sites using RV042 at each end. I've set
up a "lab" that emulates a simple version of the intended setup as follows:

Site 1 / LAN1: Site 2 / LAN2:
192.168.1.192 192.168.1.128
255.255.255.192 255.255.255.224
i.e. .193-.254 i.e. .129-.158

LAN 1 host 1: LAN 2 host 2:
192.168.1.213 192.168.1.137
gateway: 192.168.1.198 gateway: 192.168.1.157

RV042#1 RV042#2
LAN LAN
192.168.1.198 192.168.1.157
255.255.255.192 255.255.255.224
WAN1 WAN1
223.111.2.009 223.111.2.008
255.255.255.248 255.255.255.248
- internet-
(emulated by a hub)
So, there is one computer on each LAN that points to the RV042 LAN interface
as its gateway.
The RV042s connect directly using the WAN1 ports using their assigned public
internet addresses through a hub.
That's about as simple as one could make it.

There are complementary tunnels set up in each of the RV042s that identify
both LAN ranges and both public IP addresses of the RV042s.

The VPN tunnel doesn't "connect" even under these simple circumstances.
So, I'm looking for typical RV042 setups that *do* work as I must have done
something wrong. I just can't figure out what it might be! Is there
anything obviously wrong above?

The LAN IP ranges are different so that traffic on one LAN can be routed to
the other LAN through the VPN when the time comes. In the mean time, I just
need to make the VPN work.

Any suggestions or pointers to URLs appreciated.

Fred

Roy Hills

2007-04-22, 7:12 pm

On Sat, 21 Apr 2007 11:21:52 -0700, "Fred Marshall"
<fmarshallx@remove_the_x.acm.org> wrote:
>I'm working to set up a VPN between sites using RV042 at each end. I've set
>up a "lab" that emulates a simple version of the intended setup
>
> [snip]
>
>The VPN tunnel doesn't "connect" even under these simple circumstances.

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

Fred Marshall

2007-04-22, 7:12 pm

"Roy Hills" <royhills@hotmail.com> wrote in message
news:v4cn239chkn63ctnl4gkv21grijp66v3do@
4ax.com...
> On Sat, 21 Apr 2007 11:21:52 -0700, "Fred Marshall"
> <fmarshallx@remove_the_x.acm.org> wrote:
>
> 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,

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

Roy Hills

2007-04-23, 1:12 pm

On Sun, 22 Apr 2007 16:39:44 -0700, "Fred Marshall"
<fmarshallx@remove_the_x.acm.org> wrote:

>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.

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).

>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.

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
4500 if you're using NAT Traversal. Once the VPN is established, you
shouldn't see much IKE traffic other than the occasional re-keying (maybe
once every hour).

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

Fred Marshall

2007-04-23, 7:12 pm

"Roy Hills" <royhills@hotmail.com> wrote in message
news:eaop239i3p3aoirrg3n7840n34c0uasmr8@
4ax.com...
> On Sun, 22 Apr 2007 16:39:44 -0700, "Fred Marshall"
> <fmarshallx@remove_the_x.acm.org> wrote:
>
>
> 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
> 4500 if you're using NAT Traversal. Once the VPN is established, you
> shouldn't see much IKE traffic other than the occasional re-keying (maybe
> once every hour).
>
> 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