• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 7097
  • Last Modified:

Sonicwall TZ205 Site to Site VPN

Hi Guys,
              I am setting up a Site to Site VPN with 2 Sonicwall TZ205's and i cannot get them to work correctly.  The Tunnel is connected, but the clients on either side cannot talk to each other.  If i ssh in to the Sonicwall's i can ping the gateways and the clients from the Sonicwall's themselves, but no other traffic is going across the VPN.
  • 5
  • 4
  • 2
1 Solution
Blue Street TechLast KnightCommented:
Hi pvnpvn,

Can you ping the firewalls from the clients?

Are you seeing anything in the logs when you try to ping from PC to PC (across the VPN)?

Make sure to enable all log categories...go to Log > Settings, make sure Logging is set to Debug and that all Categories are checked under log. Then test and post results.
pvnpvnAuthor Commented:
I see the successful pings when pinging from the sonicwalls
09:40:50 Nov 02      171      VPN      IPsec Dead Peer Detection                    xxx.xxx.118.1      50585      xxx.xxx.113.110      4500                                  RECEIVED<<< ISAKMP OAK INFO (InitCookie:0xb400790b9ab5a107 RespCookie:0x15a24b1929d0...
09:37:50 Nov 02      171      VPN      IPsec Dead Peer Detection                    xxx.xxx.113.110      4500      xxx.xxx.118.1      50585                                  SENDING>>>> ISAKMP OAK INFO (InitCookie:0xb400790b9ab5a107 RespCookie:0x15a24b1929d0...
09:36:02 Nov 02      171      VPN      IPsec Dead Peer Detection                    xxx.xxx.113.110      4500      xxx.xxx.118.1      50585                                  SENDING>>>> ISAKMP OAK INFO (InitCookie:0xb400790b9ab5a107 RespCookie:0x15a24b1929d0...

But I do not see anything else in the log.  My remote sonicwall log is showing this though.

10:17:15 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      64531      ff02::1:3      5355      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:17:10 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      65087      ff02::1:3      5355      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:16:08 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      65219      ff02::c      1900      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:16:05 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      65219      ff02::c      1900      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:16:02 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      65219      ff02::c      1900      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:15:15 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      50626      ff02::1:3      5355      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:13:56 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      59188      ff02::1:3      5355      17                           Unhandled link-local or multicast IPv6 packet dropped      
10:13:22 Nov 02      1233      Firewall Settings      Link-Local/Mult
icast IPv6 Packet      W0      X0      fe80::a6:b401: 86e6:4356      65219      ff02::c      1900      17                           Unhandled link-local or multicast IPv6 packet dropped
Did you enable dhcp over VPN, then reboot the clients behind the sonicwall that is connecting to the other sonicwall?
The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

Blue Street TechLast KnightCommented:
Are you running IPv6?

Can you ping from PC to PC through the VPN?

Your logs indicate a NULL source IP address.
pvnpvnAuthor Commented:
I am not using IPv6.  I cannot ping PC to PC, that is the whole problem.
Well, your logs do reflect some IPv6 traffic. So if you're not using IPv6, then turn it off. But you still have not mentioned whether you turned on DHCP over VPN. You will need to at a minimum do that, so that machines on the remote Sonicwall can start receiving IP addresses from the main Sonicwall. Machines with static IP addresses will also need to be entered. I was just dealing with this kind of issue recently.
pvnpvnAuthor Commented:
Why would the machines need to receive a DHCP address from the main Sonicwall?  I have a Sonicwall in another situation with DCHP enabled locally.
pvnpvnAuthor Commented:
So I took the static sonic wall from the site and brought it home.  brought it back to defaults and set it up on my cable modem, I am still having the same issue.  I can get the VPN to connect and see the correct stuff in the logs, but I cannot ping across the VPN.  I tried enabling DHCP over VPN, but it doesn't work since the remote router cannot see the local ip of the static router.
Blue Street TechLast KnightCommented:
Let's see if we can't get'r done with this assault:

1. Local & Destination Network mismatch

The most common reason for traffic failing to traverse a VPN tunnel is Local and Destination Network mismatch. This is accompanied by an error in the SonicWALL Log. The following errors can be seen in the log:

* Proposal does not Match
* Invalid Cookies

When configuring the VPN, the Local and Destination Network needs to be defined on each device. Make sure that the Local Network chosen matches the Destination Network chosen on the other site.Local & Destination Network mismatch

2. The Zone or Type of the Local or Destination Network is incorrectly configured

Make sure the Address Objects are setup correctly.

The zone assignment of a local or destination network is crucial for traffic to be routed through the tunnel. Although creating an Address Object for a local network is scarcely required, if a requirement arises to create an Address Object, ensure the zone assignment is LAN or DMZ as the case maybe.

When creating Address Objects for destination network/s ensure the zone assignment is VPN. If selecting more than one subnet add them to an Address Group. When creating an Address Object for an entire subnet for either local or destination network, it is advisable to have the Type set as Network rather than range. Make sure the subnet mask is correctly configured.Local Network mismatchDestination Network mismatch

3. Static Route

Sometimes a tunnel does not come up or it comes up but no traffic passes through, if a static route is defined in the Network > Routes page which conflicts with the Local or Destination Network defined in the VPN Policy. By default, Static Routes on a SonicWALL will overrule VPN Tunnel routes. If a Static Route has been defined for the Destination Network, the SonicWALL will use this route instead of passing the traffic on to the VPN Tunnel.

With the introduction of SonicOS Enhanced 4.0, a new option "Allow VPN path to take precedence " has been introduced.

By means of the Diagnostic utility "Find Network path" on the System > Diagnostics page, it can easily be determined if the SonicWALL has been configured with an overlapping route. Note all VPN destination networks defined in the Network tab of the VPN policies. Test each network using the Find Network Path diagnostic tool. If the network is not a static route that may override the VPN tunnel, the utility will report that the network is located on the WAN, either behind the Remote Gateway IP address, or behind your Default Router. This test may not be conclusive if the overlapping Static Route is pointing to the Default Gateway.

4. Default Gateway not pointing to the SonicWALL

In some networks, there are multiple paths to the internet from the LAN, and a host whose Default Gateway is not configured or wrongly confgured will be able to participate in the VPN traffic. The problem computer may not have a Default Gateway set at all (common on platforms which don't offer GUI methods for setting gateways like Windows, and when the server historically has only been reached by local hosts on the same network).

The answer is simply to configure a Default Gateway on the computer (or a route of last resort in a LAN router) pointing to the SonicWALL LAN IP address.

5. Multi-homed computers or computers with dual NICs

Certain servers could have multiple NICs installed in them to communicate with multiple networks. At times this could pose problems for a host on the other side of the VPN tunnel to communicate with the server over the VPN tunnel. The request from the host may reach the server but the reply may go out through the NIC not participating in the VPN tunnel. To rectify this behavior make sure the routes in the servers are configured properly.If all of the above fail to resolve the issue, the following could be tried:
Upgrade both units to the latest firmware if not already done.
Disable the VPN policies on both sides, reboot the SonicWALL and re-enable the policies.
Delete the existing policies and re-create them.

Forgetting Ping for a sec...have you test passing traffic through the tunnel?

Let me know how it goes!
pvnpvnAuthor Commented:
Thanks for the help, the issue with the VPN was i needed to enter the IP address of the remote router into the default gateway box on the advanced tab on both routers

After that I was able to ping across the vpn fine.  

I still am having one last issue.  I need to use wireless as well as wired on one side, the other side will only have wired clients.  I can ping wired clients from the wireless and vise versa on the local router, but only the wired clients can ping across the VPN the wireless clients time out.
Blue Street TechLast KnightCommented:
Yes, traffic not passing to or from a Wireless Type Zone is due to Access Rules NOT auto created (By Design).

After setting up a VPN policy in to tunnel interface mode, ensure a route has been created on both sides to route traffic to the appropriate network. Then proceed to check access rules on the side of the tunnel which has the wireless network.

When creating route policies in which the source is any and traffic is set to pass to a non-trusted zone, the access rules are not auto-created.

The rules will need to be added in two places. From VPN > WLAN and from WLAN > VPN.

They will be similar to rules that are created from VPN > LAN and LAN > VPN where the VPN network is the remote network.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

  • 5
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now