Start Free Trial

asked on

SIte to Site VPN through internal router

I have two sonicwall tz170's holding a site to site vpn. One end has a hotbrick router holding two WAN connections for failover. I cannot get the VPN to work across the Hotbrick, because I am not sure how to set up the routing so that the subnets know how to find each other. The VPN tunnel shows as up and active but I cannot ping anything through the VPN tunnel. I am getting errors "IKE Responder: IPSec proposal does not match (Phase 2)" ... and ..." IKE Responder: No match for proposed remote network address" ....
Heres a basic diagram

LAN 192.168.1.3
|
sonicwall LAN interface 192.168.1.3
|
Sonicwall WAN Interface
|
VPN Tunnel
|
Sonicwall WAN interface
|
Sonicwall LAN interface 192.168.3.1
|
Hotbrick Router WAN1 at 192.168.3.3
|
Hotbrick Router LAN interface at 192.168.2.3
|
LAN 192.168.2.0

Appreciate any advice. Thanks!

Assuming the VPN is properly connected between the two Sonicwall units:
-At the 192.168.1.x site you either on the LAN PC that wishes to connect to the remote site or on the Sonicwall itself add a route such as :
route -p add 192.168.2.0 mask 255.255.255.0 192.168.3.3
-Assuming the Hotbrick is the default gateway for the 192.168.2.0 network and the Sonicwall is the default gateway for the Hotbrick, you shouldn't need any other routes.

ASKER

Hi RobWill,

You are correct in your assumptions. The Hotbrick is the Def Gateway for the 192.168.2.0 network, and the Sonicwall at 192.168.3.1 is the Def Gateway for he Hotbrick. I added a similar routing rule to what you suggested on the 192.168.2.0 end but not on the 192.168.1.0 end. I tried adding your rule. I am still unable to ping anything at either end of the tunnel from the sonicwalls, although the VPN tunnel has a green light and says it is Up.
When I tracert from a client in the 192.168.2.0 network to 192.168.1.3, it finds its way to the Hotbrick's LAN interface (the gateway at 192.168.2.3) but goes no farther.

>>" I added a similar routing rule to what you suggested on the 192.168.2.0 end but not on the 192.168.1.0 end."
The latter is very important.
In order to ping, routes in both directions must exist. It is possible to have a route in place that allows the ping packet to reach the remote end, but it cannot be returned and is lost unless it knows the return route.

Because of the VPN, assuming it is working, the 192.168.1.0 network knows the route to 192.168.3.0 network and visa versa. The 192.168.2.0 should know/find the route to the 192.168.1.0 network because it's default gateway is the 192.168.2.0 network, and that network/route,r due to the VPN knows the necessary next hop to the 192.168.1.0 subnet. However, the 192.168.1.0 network does not know the whereabouts of the 192.168.2.0 subnet because it is 2 hops away, so it needs to know the route/ next hop.

Jumping in on the tail end of this but don't forget you need to specify your destination networks in your VPN policy. "No match for proposed remote network address" could mean you need to place the 192.168.2.0 subnet as a destination network in 192.168.1.3 sonicwall. Just my two cents :-)

ASKER

RobWill,
Thats exactly what I am thinking, so the fact that it still isnt finding it's way through is confounding me. I am going to do some more testing on it this evening... If i run a tracert from a client on the 192.168.2.0 network and it stalls at the gateway, looks to me like the hotbrick doesnt know where to find the 192.168.3.0 network which makes no sense to me at all. The most odd thing about it is that if i go to the Diagnostics tool in the Soncwall and use the ping utility, it cant ping across the VPN to the other sonicwall.

DDano, thanks for your input, I found info indicating that that error could mean a mismatch in the destination subnets. To me it looks correct, but perhaps when I am able to get out there this evening I will post the destination network configuration. Maybe one of you guys will see something obvious that I am missing.

Thanks a ton for the replies so far.

I am not very familiar with Sonicwalls. Do they have utilities that you can use to ping from the unit itself? Might be a good place to start if so. That way you can confirm the tunnel 192.168.1.0 to 192.168.3.0 is at least working.

By the way one issue that can cause problems similar to yours with VPN's is if the VPN local network is defined as an IP rather than a subnet, such as 192.168.1.3 255.255.255.255 rather than 192.168.1.0 255.255.255.0

BBstaff,
If you can't ping across the VPN from sonicwall to sonicwall, it appears as though your tunnel isn't working. You need to at the very least be able to raise the tunnel and talk between the two sonicwalls. DO you have the sonicwall Perhaps you can post the log concerning the negotiations and let us take a look at that.

Oops accidentally posted to soon. Do you have the subnets for both sonicwalls in your policies??

ASKER

RobWill.. Yes the Sonicwall has a diagnostics toolset that includes dns resolution, ping, and trace route tools along with a couple others. I have been using these extensively to test to see if any of the changes I make are making any difference.

ddano - Yes thats exactly how it looks, although the Sonicwall is reporting the tunnel as open. The tunnel on both ends has a green light, and indicates successful connection with the other end. I get errors as reported above if I remove the 192.168.2.0 subnet from the destination networks. I do have the subnets in my polices. This setup was working before with no problems, until i had to add in the 192.168.3.0 subnet on one end. I will be happy to post log info as well as the destination network config info as soon as i can break away and log into those devices.

Thanks again fellas.

ASKER

Did you mean Firewall policy?...Now that you mention it, Im not sure if a firewall policy was successfully created for the 3.0 subnet. I was thinking that the VPN policy took care of that part. It did at initial setup. I willl check that as soon as possible.

Yep thats what I was talking about sorry about that. Since it was working before and you've got a green light probably no need to post the logs.

ASKER

There is nothing in the firewall allowing me to create policies specifically for the onboard VPN. There are no other firewall policies created that deal with that in the Sonicwall. Considering this, and since the VPN tunnel worked fine before, I have to assume that is not the problem, although it certainly was worth the look. I think its a routing problem, and I just lack the knowledge to get to the bottom of it. Still working on it though.

Let me throw this in here then. Have you defined the 192.168.2.0 subnet in the LAN properties of the 192.168.3.1 Sonicwall ? Your sonicwall needs to know all of the possible subnets that are available on the LAN. If you haven't defined the 192.168.2.0 subnet in the LAN Properties then the sonicwall is basically saying I don't know where this subnet is. Give that a try.

ASKER

i checked into that. There is a place in LAN settings to define a "network gateway". I thought that might be the ticket, but I dont know what address it is looking for. The WAN side of the device has its WAN gateway defined already. It seems to me that it would want to know the gateway to the .2.0 network resides which would be 192.168.3.3 (the address of the hotbrick router that is connected to the LAN side of the Sonicwall. I attached an image here. When i try to use that address i get an error as shown (Error: Add Range Pair).
sonicwall-network.gif

Thats not what you want to place there. Try this, Open Sonicwall then go to Network- Routing. Check the routes in there. If no route exists for 192.168.2.0 then add
Destination network = 192.168.2.0
Subnet Mask = 255.255.255.0 (I assume Class C)
Default Gateway = 192.168.3.3

And see if that works.

ASKER

Yeha thats one of the first things I did. I thought that was going to be all that was necessary to make it work.. I attached a pic of the routing table as it stands. I whited out the WAN addresses. The entry for the 192.168.2.0 network is one I placed there.
sonicwall-routing.jpg

ASKER

Fellas, I now believe this problem to be caused by the Hotbrick router rather than the Sonicwall. After further investigation I have found that if I connect a wireless access point to the sonicwall which exists on the 192.168.3.0 network, any wireless clients are also unable to ping anything on the 192.168.2.0 network.

I assume then the hotbrick is acting as a gateway/firewall rather than a simple router and blocking all incoming traffic.

ASKER

RobWill,

It should just be acting as a simple router. I cant find anything in its config that would suggest it is blocking anything. It just doesnt make sense to me that i can ping the Sonicwall from a LAN client but cant ping hte same LAN client from the Sonicwall. The Hotbrick's LAN address is the gateway address for clients on the LAN to get to the Internet.

By default the Hotbrick will allow outgoing connections/pings and not incoming. Sounds as if it is still acting as a firewall.

ASKER

RobWill,

Do you know where in the Hotbrick to disable the blocking? I have looked it over it with a fine tooth comb and dont see anything that is blocking.

I have never seen a Hotbrick to be honest.

Why is the Hotbrick in place? You say 2 WAN connections. Does one have the VPN as it's connection and a different public IP as the second?
Many gateway routers will not properly function as basic routers. Also if it is acting as a dual WAN router do yo u want to disable the firewall features, it would expose the users if they were using the second connection.

ASKER

We are using it as a dual WAN router, set up to failover if WAN1 goes down. WAN2 only connects in the event that WAN1 is down. The client uses citrix connections to keep their employees busy so even one hour of down time is very bad since they would have 50 people sitting there twiddling their thumbs. If it fails over to WAN2, the device that holds that connection provides some basic firewall protection good enough to get through a short amount of downtime. If an outage looked like a long drawn out event i could easily move the sonicwall to the other connection. The VPN tunnel being down during an outage is something we are aware of and can deal with. So far we have only had a couple of very short outages, knock on wood.

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

Let me look into that, that may be the whole problem. I am able to ping the Sonicwall from inside the lan, but I cannot ping anything in the LAn from teh sonicwall, and the Hotbrick is between the LAN and the Sonicwall. Ill get back to ya.

OK, let us know how you make out.
--Rob

ASKER

You are correct. I plugged another device directly into the hotbrick router and connected a client to it on the 192.168.3.0 network. i can get internet on that client but still cannot ping anything on the 192.168.2.0 network. Regardless of the configuration, the hotbrick will not allow anything to go IN to the network.

ASKER

I did not know that as a "gateway appliance" that device would not work like a normal standard router and allow data to be routed both directions. Thanks.

That may be a default, and not change-able.

Sorry missed the accepted comments when I made my last post. Sounds like it may not be the proper router for the job.
Thanks BBstaff.
Cheers!
--Rob

ASKER

I should clarify. It will allow something I define as a special service to go in but I cannot maintain connectivity to it from a separate LAN.

You really cannot allow inward connections for all services such as a VPN. You should be able to configure a specific service using port forwarding such as RDP. You might also be able to connect the Sonicwall to the DMZ of the Hotbrick, which would allow all traffic, but that would likely disable your dual/fail-over WAN feature.