VPN<-->VPN via hub (Sonicwall & Draytek) help

VPN<-->VPN via hub (Sonicwall & Draytek) help

Post by ryanjjone » Wed, 10 May 2006 01:20:07


Hi

We have a sonicwall pro 2040 enhanced OS hub, and draytek vpn remote
routers.

VPN is set up fine and works well for traffic from remote VPN to hub.

But - we want VPN to talk to VPN.

e.g.:
Hub 192.168.1.0/24
Site1 192.168.2.0/24
Site2 192.168.3.0/24

The drayteks are set up to know the hub and the other site networks are
available over the VPN.

Pinging 192.168.3.1 from site1 sends the packet over the VPN - but then
gets lost (or appears to). Pinging 192.168.4.1 from site1 and the
packet goes to the router default gateway and fails (obviously).
Bascially, this says to us that the draytek is configured okay,.

The sonicwall should have the right config to allow VPN to VPN site
connections.

We have followed the documentation sent by Draytek and Sonicwall tech
support.

Not much config onteh drayteks, and draytek say it looks okay.

Sonicwall tech support say quote: "Sir, First of all, we normaly do
not support 3rd party VPN's. Anyway this don't seams to be a Sonicwall
issue....."

Does anyone have this setup working? Any tips or thoughts?

I can provide more information if required.

MANY THANKS!

(PS do not email direct - this email address is not in use)
 
 
 

VPN<-->VPN via hub (Sonicwall & Draytek) help

Post by Somebody » Wed, 10 May 2006 19:51:47


How?

There are 3 basic issues here.

1. The tunnels must be set up with Proxy-ID's that support both remote
networks. Otherwise those packets will not be able to travel over the
tunnel regardless of what is done at each end. Different boxes support one
or more of these methods:
a) Two phase 2's bound to a single phase 1, each of which supports a
different /24 to cover both remote sites
b) One phase 2 with proxy ID's with a wider netmask to include all remote
networks -- in this case site 2 can use 192.168.1.0/23 but site 2 can only
use 192.168.0.0/22, which will encompass 1 extra network *and* the local
addresses which it should be smart enough not to put in the tunnel... this
is likely a problematic method.
c) Open or wildcard proxy id's of 0.0.0.0/0 to allow anything in each
tunnel, controlled then by some other sort of routing on the box. Your best
bet option. Sites will need to be either static IP's or will need an extra
identifier to facilitate tunnel selection at the hub.

2. Once the correct proxy ID's are specified, each site box must know how
to put only the correct traffic into the tunnel (especially with option c
above)

3. The hub must know how to route traffic that comes out of one tunnel, in
to another tunnel, and the reverse, when appropriate.

You will have to have addressed all threee of these issues in order to
succeed at this hub-and-spoke vpn.



More detail please. traceroute to 192.168.4.1, should hop out the internet
and die there, not die at the gateway. From any site.

Try traceroute 192.168.3.1 from site1, does it die at site2 gateway (bad
tunnel) hub gateway (bad step 3 above) or site 2 gateway (bad step 2 above
at site 2)?

Same test from site2...

-Russ.