Sonicwall TZ210 to Corporate Net, Tunnel is up, No traffic, can't work out why

I'm hoping someone can point me in the right direction, or at least help me track down the problem.

I'm using a TZ210 to connect to a clients network. Previously i was using the mobile vpn solution which works but not all the time, so i got a sonic wall in to get around this.

They have other offices that are using sonic wall successfully.

We have set up the connection and the tunnel is up and running

However i don't get traffic across it. I can see in the tunnel overview that packets are being sent too the VPN but there's no traffic back. I can see in the logs that i get a TCP Connection reject received; TCP Connection Dropped, from the destination IP to my network.

In the VPN settings i have my network locally which is 192.168.2.x and two networks remotely, one is a network (subnet / and one is a range192.168.200.0 ->

The tunnel is up though.

I've tried selecting the remote address group as WAN and VPN but the same issue

The firewall seems to be set to allow traffic in and out of the VPN.

What can i do to troubleshoot this as i'm stuck now.

Who is Participating?
Blue Street TechLast KnightCommented:
Good to hear you consolidated your network!

Let's go back to basics...there are three basic scenarios to investigate if the IKE VPN tunnel fails to establish:

A. No Response to IKE Initiation Request - not the case, correct?
B. IKE Negotiation Fails - not the case, correct?
C. IKE Negotiation Completes, but No Traffic is Passing - the main issue
A common reason for this failure is that both sides of the site-to-site network connection are on the same network ID. The solution is to change the IP addressing scheme on one or more networks so that all networks joined by the site-to-site VPN are on different network IDs.

If the tunnel is up but will not pass traffic, then the IKE negotiation was successful. If you have verified that the above is not the issue, then something might be blocking IPSec protocol or the IPSec NAT traversal. First, verify your ISP does not block the IPSec protocol. Note also that the subnet configuration cannot use a range in SonicOS Standard or Firmware 6.X which can affect a VPN to LAN/DMZ in Transparent Mode.

If your tunnel is stable but connections made through the tunnel are dropping, check your rules inactivity timeout. In SonicOS Enhanced, rules are applied to all VPN traffic. The default rules are set with an inactivity timeout of 5 minutes. SonicOS Standard and Firmware 6.X do not apply rules unless selected in the Advanced VPN settings.

Factory Reset & Root Cause.
A factory reset may be the final solution as this by default works flawlessly but we still need to isolate the device having issue (or have you already narrowed that down, if so how did you arrive at that conclusion?).

Interestingly the mobile VPN doesn't always work. But if the tunnel is up then it will connect. This points to routing issues perhaps?
This is interesting, because as I said before the SonicWALL Mobile Connect does not work off of a Site-to-Site VPN therefore you are directly accessing one of the SonicWALLs via SSL-VPN. It is interesting because that might be playing a part in this if it is down continually. Again, SSL-VPN (Mobile Connect) has nothing to do with a Site-to-Site VPN. Mobile Connect establishes a tunnel with one firewall whereas a Site-to-Site establishes a continuous tunnel with both firewalls. Therefore, if you test both firewalls with Mobile Connects and one side goes down the other will still be up, conversely if you test Site-to-Site VPN and one side goes down, obviously the entire tunnel goes down.

Default Gateways.
On the remote site what is the Default Gateway now since you consolidated,
What is the Default Gateway of the central site?

AV Enforcement.
It is normal, even advisable, to enforce the Security Services of the SonicWALL on the VPN zone. An exception to this would be AV Enforcement on the VPN zone. If this is enabled, SonicWALL would drop traffic from any host communicating to another host over the VPN if Mcafee Client AV is not installed in it. Unless this is a requirement it is advisable to disable Client AV Enforcement on the VPN zone.

IPS Blocking.
The most common way to test whether traffic is passing through the VPN tunnel is using the ping command. However if Low Priority Attacks under SonicWALL Intrusion Prevention Service is globally enabled or ICMP / Ping is individually enabled for prevention, ICMP packets would be dropped by the SonicWALL. Check the logs for a message indicating the same.

If Ping is working that would suggest networking is functional - take a look at the devices trying to communicate (servers, pcs, etc.) and make sure their AV clients and software firewalls are disabled to fully test this. Ping can be blocked by personal firewall applications like Windows Firewall and by Anti-virus applications.

Access Rules.
SonicWALL GUI provides easy-to-configure VPN Policy interface which enables users to define VPN parameters without having to worry about the access rules and routes which are created automatically behind the scenes. However, on rare instances these rules don't get automatically created and needs to created manually. There should be LAN > VPN (allowing Local Network to Destination Network) and VPN > LAN  (allowing Destination Network to Local Network) rule.

What are you seeing in the logs on either side related to the tunnel?

If all of the above fail to resolve the issue, the following could be tried:
1. Upgrade both units to the latest firmware if not already done.
2. Disable the VPN policies on both sides, reboot the SonicWALL and re-enable the policies.
3. Delete the existing policies and re-create them.
Let me know how it goes!
Blue Street TechLast KnightCommented:
Hi paulinventome,

Is the SonicWALL SonicOS up-to-date? If not update the firmware and re-test.

Can you ping the other firewall from the SonicWALL (System>Diagnostics)?

What is the other firewall make/model?

On the VPN Network tab what option have you selected?

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

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.

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.

Let me know how it goes!
paulinventomeAuthor Commented:
The Sonic Wall is on SonicOS Enhanced which i believe to be the latest version?

Yes i can ping the IP address of the other firewall (the public IP address)

The other firewall is a SonicWall, it's an older NS model but there are other offices using a TZ180 to access this network okay.

The VPN Network tab (VPN -> Settings -> Edit Config -> Network) shows a local network 'localnet' and a remote network 'remotnet', these are address groups/objects.

The localnet is defined as an address object, Zone assignment is LAN, it's a Network and, subnet, this corresponds to my local network here.

The remotenet is an address group, which holds two objects for the two remote networks. One is a network and is set to VPN, and the other is a range - set to VPN as well. (These have been set to WAN in the past with no difference)

I've not set up any static routes. Network -> Routing shows Simple RIP Advertisement, X0 is my LAN, X1 is my wan. X2 is n/A. The status for these interface (zone) is Disabled. There are 6 routes defined (IPv4)

Any ->    Gateway:    interface X0
Any -> X1 Default Gateway    Gateway:     interface X1
Any -> Lan Primary Subnet    Gateway:   interface X0
Any -> WAN Primary Subnet   Gateway: interface X1
Wan Primary IP -> Any      Gateway: X1 Default Gateway            interface: X1
Any ->            Gateway      interface X1

My WAN is plugged into a hub on a 192.168.1.x network which physically plugs into an ADSL router. The Sonic Wall WAN has an IP of on this network and the gateway is which corresponds to the hub driving the router. So my LAN is 192.168.2.x then the WAN is on the 192.168.1.x network. I cannot plug the sonic wall into the adsl router so there's a hub there. I have no issues with internet traffic. It is wrong to have two network ranges? Should i put all my network on the 192.168.1 network as well?

For Find Network Path, i test an IP on the 172 network and it tells me it's located on the X1, reached through the router at Testing an IP on 192.168.200 gives the same path. So i think this is correct?

All the computers are pointing to the SonicWall as the default gateway, everything on the 192.168.2 network

I don't believe there are any issues with the remote servers.

I can use SonicWall Mobile VPN to VPN is successfully. My issue with that is that only my workstation it doesn't like my 10gbe network card and it stops traffic to my local net when it's active. It does not do this with the built in 1gbe network connection. So the Sonicwall was a solution to allow me to use 10gbe within my network.

Does this make sense?

thanks for the help so far

WEBINAR: 10 Easy Ways to Lose a Password

Join us on June 27th at 8 am PDT to learn about the methods that hackers use to lift real, working credentials from even the most security-savvy employees. We'll cover the importance of multi-factor authentication and how these solutions can better protect your business!

Blue Street TechLast KnightCommented:
My WAN is plugged into a hub on a 192.168.1.x network which physically plugs into an ADSL router. The Sonic Wall WAN has an IP of on this network and the gateway is which corresponds to the hub driving the router. So my LAN is 192.168.2.x then the WAN is on the 192.168.1.x network. I cannot plug the sonic wall into the adsl router so there's a hub there. I have no issues with internet traffic. It is wrong to have two network ranges? Should i put all my network on the 192.168.1 network as well?
I'm not sure why you need a Hub in between the Modem and the Firewall...Hubs are L2 devices! Keeping everything on the same network will only improver operations specifically related to routes and VPN issues.

Mobile Connect relies on NetExtender through an SSL-VPN not a Site-to-Site...there is a difference not only in execution and design but specifically routes.
paulinventomeAuthor Commented:
Hi, thanks for replying.

I simplified my network now, although still no joy. My next step is to factory reset the sonic wall and configure from scratch with my simplified network.

Basically the ADSL modem goes through the BT Hub which is in bridge mode to the Sonic Wall, so the sonic wall WAN is now PPoE and direct as it can be. Everything is now on my 192.168.2.x subnet. I can see the tunnel, but still no traffic.

Interestingly the mobile VPN doesn't always work. But if the tunnel is up then it will connect. This points to routing issues perhaps?

Blue Street TechLast KnightCommented:
Any update on this one?
paulinventomeAuthor Commented:
I've still not managed it (although been unable to work on it for a while). I have just posted another related issue that if i can solve then i don't need to solve this one!

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.

All Courses

From novice to tech pro — start learning today.