Site-to-site VPN connections are very easy to create between Sonicwall devices, almost ridiculously easy.  Here’s how to do it.

Sonicwall let’s you set up site-to-site VPN’s in a number of ways.  I find the easiest and fastest way is to use the procedure that Sonicwall recommends when one of the VPN gateway Sonicwalls receives its WAN address via DHCP even if both of your gateway devices have static addresses.  The reason I do this is the process pretty much never fails, is easy to troubleshoot and can be completed in minutes.

To use this process you have to decide on one Sonicwall as the “master” as it will always “listen” for VPN connections; the other Sonicwall will be the initiator.  If you are going to have multiple remote sites coming back to a main site then it only makes sense to make the main site the master.  If you only have two units involved then pick one as the master.

On the master unit perform the following steps:

Go to VPN –> Settings.  On that screen make sure Enable VPN is ticked and then change the “Unique Firewall Identifier” to be something that is easily identifiable like “MASTER” or “VICTORIA FIREWALL” or whatever and click the Accept button.  This will be the NAME you use in following steps.  Now, click the ADD button under VPN Policies, the following will appear:

SNAGHTML143b7317

Fill in your entries as follows:

  • Leave Policy type as is
  • Leave Authentication method as is
  • For Name fill in the name that you will be giving the OTHER Sonicwall (the one at the other end of the VPN tunnel)
  • Enter 0.0.0.0 for both the Primary and Secondary gateways.  The reason for this is that you are setting up this unit to “listen” for the VPN connection and the remote end will pass this information through upon making the connection.
  • Enter your desired “shared secret” for the encryption key.  Make note of what you enter as you will need to enter the same key on the other Sonciwall.  Longer, more random secrets are better than short, easily “guessed’ secrets.
  • For the Local IKE ID select Firewall Identifier from the dropdown box then enter THIS Sonicwall’s name.
  • For the Peer ID select Firewall Identifier from the dropdown box then enter THE OTHER Sonicwall’s name.

SNAGHTML143afa30

Click on the Network tab:

SNAGHTML143cbc08

On the Local Networks select LAN Subnets from the dropdown list.

On the Remote Networks select Create New Address Object and fill in the info for the LAN at the other end of the VPN similar to the following:

SNAGHTML143fd6c8

You should then have something like the following:

SNAGHTML1440db89

Click on the Proposals tab and set like the following:

image

Click on the Advanced tab and set like the following:

image

Click the OK button to save the settings.

The new policy will be displayed on the VPN Policies page.  Now, switch yourself over to the other Sonicwall and repeat the same steps with the following differences:

image

Enter the WAN IP address OR the FQDN of the master Sonicwall as the Primary gateway.  Remember, the Sonicwall you are configuring is the initiator of the VPN connection so it has to know what it needs to connect to.

On the Network tab you do the same thing as you did the first time around only this time the Remote Network will be the LAN behind the master Sonicwall.

image

The Proposals should match the other side:

image

On the Advanced tab the only change is to ensure the Enable Keep Alive is ticked.

image

Click the OK button to save the policy.

Assuming you’ve made no typo’s and all is well with your WAN connections, the VPN tunnel should come up on both Sonicwalls.  The tunnel is up when both Sonicwalls display the green ball icon on the VPN policy.  You will also see tunnel information appear under the Currently Active VPN Tunnels when a tunnel is established:

image

Once your VPN policies are created you can make modifications that expand what traffic is allowed to flow over the tunnel.  In this case we just allowed traffic on each primary LAN behind each Sonicwall to reach the primary LAN behind the other Sonicwall.  We set this up on the Networks portion of each policy and bound the policies to the LAN subnets at each end.  If you want to expand to allow access to more subnets behind a Sonicwall then all you have to do is create an Address Object  on each firewall that includes the subnets you want to access and reference that object instead of the one used when first setting up the tunnel.  Just remember that whatever you reference as the LOCAL networks on one side of the tunnel has to also be referenced as the REMOTE networks on the other side of the tunnel.  An example of how multiple networks display under a VPN policy follows:

image

As you can see, this tunnel knows about 3 separate networks at the other end.

I use this procedure all the time and have many, many site-to-site VPN’s in the field configured in this manner.  Of course, as I mentioned up front, there are many other methods available to configure the tunnels, including the new IKE v2 process available with the latest SonicOS firmware, and each method has its advantages and disadvantages.  Use the method that best suits your needs but for rapid configuration you can’t beat this!

Sonicwall site-to-site VPN — the “easy” way
Tagged on:         

101 thoughts on “Sonicwall site-to-site VPN — the “easy” way

  • Im trying to deploy a site to site VPN using Sonicwall SOHO3 between two homes. Im trying to figure out where the sonicwall device should actually sit. Between the modem and router or between the router and machine(s) . I would prefer the latter but so far ive been unsuccessful. Any help would be much appreciated.

    1. Kameron:

      I’m not sure how you are laying out your config but the Sonicwalls ARE the routers! (or should be). The site-to-site VPN assumes the Sonicwalls have direct access to the WAN at either end. Then when you create the tunnel config they can find each other and not have any other firewall “in the way” and in between them.

      From the sounds of things it seems you may be trying to put the Sonicwalls behind existing routers. There may be a way to do the set up but it would require front end routers that can be configured a certain way and that is not normally the case with “consumer-grade” routers. Also, the SOHO3’s are ancient and slow and “buggy”; I doubt that you would get the sort of bandwidth you would like to see using a site to site VPN between them. Your better bet might be to look at two newer consumer grade routers that support site-to-site VPN and go down that route or look at finding a couple of TZ100’s or TZ105’s on an auction site and use those instead of the SOHO3’s.

  • Awesome write-up.

    IN following your guide, my tunnel is not working. I’ve read and re-read, but the error I get on my “client side” (PCAELEM) sonicwall is “Received notify: INVALID_ID_INFO” after phase 2.

    On the Master Sonicwall (PCAMIDDLE), I get “IKE Responder: IPSec proposal does not match (Phase 2)”

    I have my local network setup to be 192.168.1.1-192.168.1.254 and my client side is 192.168.100.1-192.168.100.254.

    Can you help?

    1. Hi, Cam!

      Thanks for the kind comments! And, yes, I think I can help.

      There are a few common places to “mess up” when setting the VPN’s up and believe me, I mess up all the time! First thing is to open up the VPN setting page on both firewalls if you can. On the first tab (General) check your Local IKE ID and Peer IKE ID. The LOCAL name is the firewall name on the LOCAL machine, PEER ID is the firewall name on the remote firewall. So, if on the MASTER (as you name it) the name is PCAMIDDLE then the LOCAL ID is PCAMIDDLE and PEER should be PCAELEM. On the REMOTE it will be the opposite, LOCAL name will be PCAELEM and PEER name will be PCAMIDDLE. On both machines reconfirm that the SHARED SECRET is entered the same on both. If any of this is wrong you can get errors similar to what you are seeing. Also, very importantly, make sure that only ONE side of the VPN has the IPSEC Primary Gateway IP entered (this will be the firewall that initiates the connection, the other side should have 0.0.0.0 entered for the gateway.

      On the second tab (Network) of the VPN settings ensure you have the networks identified correctly and, again, the entries should be opposed on the two firewalls.

      On the third tab (Proposals) make sure you are set for AGGRESSIVE MODE and that all the settings are the same on both firewalls. Chances are this is where you have made a mistake. Both sides have to have identical Proposal settings.

      On the fourth tab (Advanced) make sure the firewall that INITIATES the connection (same one that also has an entry for IPSEC Primary Gateway) is set for ENABLE KEEP ALIVE. You can also enable the DEAD PEER DETECTION if you want.

      Doing all of this should solve your problem. I find that I’m usually nailed by a “phat phinger” typo.

      Finally, consider which side of your connection should be the initiator. I’m assuming that PCAMIDDLE is the “master” so I would think of it as the HUB, it should be the one that is listening for the connection(s) request. The remote firewall(s) should be the initiators. This is very much the case if the remote firewalls are on DHCP connections without a static IP but it is a rule I follow no matter what.

      Good luck!

      Robert

  • Thanks for the great info. I found this to be a much faster approach then following the wizard even! I have my tunnel setup and it is working, but I am wondering about my current speed. I assumed this connection would be faster then it is. I have 2 Sonicwall TZ-205’s both running SonicOS Enhanced 5.8.1.15-48o firmware. Both units are way under capacity at only 10-15% cpu usage. I am currently getting real time transfer speeds of 120-150kbps. Is there something I am missing? Thanks, Ty

    1. Hi, Tyler:

      Your speed will always be tied to the UPLOAD speed of your connections. Everyone gets all bogged down on the DOWLOAD speed but that doesn’t come into play in the VPN scenario. Your overall speed on the VPN will be limited to upload speed of the slowest connection on the VPN. I don’t know what kind of connections you have but that is the first place I would look. Also, ensure that you don’t have any scanning services running on the VPN connections themselves. Generally scanning is NOT enabled on the VPN connections but check anyway. If you have scanning enabled on the LAN’s at each end that should be good enough, you don’t need it on the VPN. You might also want to try bumping up to 5.9 firmware as you might see a speed increase there. Finally, make sure that you have NOT enabled bandwidth management (BWM settings) as you can blow your foot off with those settings if you have set them up incorrectly.

      On most of my customer VPN’s I see much better speed than what you are describing as they are mostly on cable connections with up to 5Mbps upload speeds and we normally see between 4 and 5Mbps speeds.

    1. There are two things you have to do. On the REMOTE SITE Sonicwall on the VPN settings for the CENTRAL SITE, the NETWORK tab has a setting under REMOTE NETWORKS, enable “Use this VPN Tunnel as default route for all Internet traffic”. On the CENTRAL SITE Sonicwall in the VPN settings for the REMOTE SITE, the ADVANCED tab has an entry for DEFAULT LAN GATEWAY which is normally 0.0.0.0. You need to enter the LAN GATEWAY IP for the REMOTE SITE LAN as this ensures that all traffic coming from the remote site is correctly tagged with the gateway. These two items in place should force all traffic from the remote site to route over the VPN tunnel and out to the Internet via the central site GATEWAY IP.

      Robert

        1. Frank: Hmmmm. This setting should not affect the tunnel status, per se, as you are telling the Sonicwall’s how to route specific traffic, not how to manage the tunnel itself. What level of firmware are you running and are you at the same level of firmware on both units? I have seen weirdness when there is a gap of more than one or two “dot revs” between Sonicwall endpoints. I have to admit that I have not actually setup in this fashion myself so I might have to lab it to come up with a cleaner answer.

          Robert

          1. well, could not get it to work with my customers setup so I duplicated here in the office. Same result.

            It looks like it should work but it just does not and its got me stumped

          2. Frank: OK, now I am intrigued. I will give it a shot with my lab gear and update you with my status. Question: do you have a valid Sonicwall support contract? If this is a critical issue you might want to just go ahead and place a support call. In the meantime I’ll give it a shot but it will be at least 24 hrs before I can post results.

            Robert

  • Hello! First off, great write-up. I’ve been using SonicWALLs for a couple years now and they’ve been pretty rock solid. I have multiple site-to-site VPNs set up at branch locations and rarely have any issues. I place them all on different subnets.

    We’re about to merge with another company, and they would like to set up a VPN between our site and their site. They use a Watch Guard unit. No big deal, however, their site uses the same subnet as ours. (192.168.x.x /16)

    Is it difficult to set up a site-to-site VPN and access resources across a VPN with identical subnets? Re-subnetting isn’t a problem, just want to know if it’s possible. Thank you for any help you can provide!

    1. Hi! I’ve had site-to-site set up with Watchguard’s in the past but I’ve never had to deal with the “same” subnet one each end of the tunnel. I know that Sonicwall has a way to handle this when both firewalls are Sonicwall but I’m not sure if this can be done with the Watchguard at the other end. I “suspect” that you could cobble something together to make it work BUT if you can change subnet at one end you’ll be in way better shape. Honestly, doing the coding on the firewalls to handle this is just asking for trouble in the long run.

      Robert

  • The problem I cam having is, I have 9 networks on 1 VPN connection. 101.1 – 101.9

    The site to site connects and all looks good. I can ping and see anything at the other end, however I cannot see the 9 subnets, unless I ping the other end from that subnet.

    For example I cant connect to 10.10.9.31 from our shop 192.168.5.x until I ping our shop from the 101.9 address.

    I don’t understand that. There is not any traffic flowing through this connection most of the time. Its just so we can get to the equipment at that site from our shop.

    Any idea?

    1. That does seem odd. Question: do you see the 9 subnets showing up individually in the VPN listing? If you have your network objects set up properly on each side of the VPN the “receiving” side should list the individual nets. So long as the tunnel is up and the subnets are listed on the tunnel there should be nothing stopping you form connecting to devices across the tunnel. In other words, the tunnel is either “up” or “down”, there is no in between. But, if you have not properly described the subnets at each end of the tunnel via your VPN config then you will have trouble accessing devices across the tunnel. Remember, the tunnel is just the encrypted connection between the two Sonicwalls; you can have a tunnel set up just fine but not have traffic flowing across the tunnel due to misconfig in the network info at either end of the VPN.

      I would do two things: 1) Ensure you have KEEPALIVE enabled at the REMOTE end of the tunnel (it should not be enabled at the side that just “listens” for connections”. 2) Revisit your network descriptions at both ends of the VPN and ensure the information is accurate. One thing I would suggest would be to strip out all of the 9 subnets except one and ensure you have traffic flow properly between the two endpoints then add each subnet back into the the config, one by one, and ensure traffic flows correctly. Finally, check ALL of the subnet configs and ensure there are no inconsistencies.

      Let me know how it goes.

      Robert

  • HI.. I have a question.. we have 5 site to site VPN setup just as you instruct and they work great! BUT what bothers me and can cause havoc is, if the VPN connection between them and our Head Office Network goes down for any reason (Ex: No-IP mess up in renewal of dynamic IP). The Local Network is dis-functional and even though the DSL Internet connection is still active/connected on the Sonicwall WAN Network Interface, Workstation connected to the Remote site Sonicwall Router are not able to communicate with each other or the Internet. Appears local network is dependent on the VPN. What have I done wrong to allow this? If VPN goes down, the Local Network should function as if the VPN didn’t exist I would think.

    Note: Workstations have manual DNS settings, primary DNS is the their local Sonicwall router and Secondary is the Head Office DNS/DC Server ( so they can ping us at Head office and mapped drives connect). The DNS setting on their Sonicwall WAN connection are those of the ISP.

    Thank you

    1. Hi!

      I’m not sure what you have done as there should be nothing linking the local LAN’s (behind the Sonicwall) to your VPN so that this situation happens. The only thing that I can think of is you have DNS messed up somehow. If your workstations pick up DNS from the local Sonicwall you should check what you have in the DHCP settings. You might have the Sonicwall itself pulling DNS properly (for its own settings) but have something different in the DHCP scope settings. If, for example, the DNCP scope setting ONLY has the DNS settings for the DNS servers at your head office then you would definitely see the kind of scenario you describe if the tunnels go down as no machine can “see” its defined DNS server. Feel free to leave a message here if you would like me to contact you directly to help sort it out.

      Robert

  • Hi,
    I have a couple of questions regarding the Policy Type. What’s the difference between Site To Site and Tunnel Interface? And when would you use one over the other?

    Thanks in advance!

    1. Hi!

      In a site-to-site VPN policy you define everything the VPN is supposed to know about within the policy itself including the networks on each end of the VPN that are exposed to the other side of the VPN (the routing). So you are defining the tunnel (the VPN itself) and the routes (what can be seen across the VPN) all in one place. This is what I demo in my various blog posts on setting up Sonicwall VPN.

      A tunnel interface is just that, it is just the “tunnel” itself (the encrypted connection) between the two endpoints. There is no routing information included within the VPN policy. When you have a tunnel interface you have to explicitly create routing rules on each endpoint (Sonicwall) to enable traffic to properly route across the tunnel. Up until recently I didn’t know why you would choose one over the other until someone contacted me on my blog regarding a “challenging” VPN configuration. They were using some really wild subnets that used fancy masking (think 255.0.0.0 vs 255.255.255.0) on their nets which caused policies on the site-to-site VPN to crap out as there was no way to enter the network objects to represent the LAN segments without the firewall complaining about “overlapping segments”. Moving to a tunnel interface configuration allowed the user to overcome this limitation.

      I guess you could think of the tunnel interface as much more generalized than a site-to-site VPN. Also, with a site-to-site VPN you actually see multiple tunnels show in the VPN listing if you are routing multiple nets on each side of the VPN itself and those multiple tunnels consume the allocated VPN tunnels that an individual firewall can support. For example, a TZ215 can support a maximum of 20 tunnels. A tunnel interface consumes just one tunnel regardless of the nets routed across it.

      Finally, a site-to-site VPN is pretty “quick and dirty”, there is not a lot of leeway given to you in the policy creation, specially when it comes to routing. Using a tunnel interface gives you the ability to leverage much more “fancy” routing including using OSPF and RIP and much more complex routing rules. In other words, it’s way more powerful but also much harder to build and troubleshoot. My advice is to stick with the site-to-site VPN config unless you really need to leverage the capabilities of a tunnel interface. You can go slightly mad trying to make all the bits fit together if you go the tunnel interface route (no pun intended).

  • Hi,

    I have two sites that are connected as described in your article. Site B and Main Hub A can both talk to each other okay on their main lans but Site B cannot see a second subnet (Site C) connected to the main hub A.

    Main Hub A – 192.168.1.0/24
    Site B – 192.168.2.0/24
    Site C – 10.0.100.0/24

    Main hub A routes traffic through one of its external ports (e.g. X4, direct connect, not VPN) to Site C

    Main Hub A’s network is able to see Site B and Site C
    Site B is able to see Main hub A but not C
    Site C is able to see Main hub A and B

    The VPN policies at main Hub A and Site B both contain the networks for Site C with a green dot next to it under VPN settings.

    There is a route on Main hub A to direct traffic to Site C that has an ‘any’ source.

    While I would certainly consider a tunnel and setting up routing, that option is not easily available to us as only Main hub A has an exposed IP address and exposing an IP address at site B will be politically difficult.

    Any thoughts?

    1. Mike:

      Sounds to me like you need a return route to match the route you have on Main hub A to Site C. I’m not sure but I think you may have to put a route on the Sonicwall as well. In other words, I think Site C has to have a route that says traffic for B and A have to route through A and the Sonicwall needs to know that traffic can come from C though A heading for B. I think you have the VPN itself set up correctly, the problem exists at the inside edge after traffic hits the firewall. The Sonicwall “knows” about all the subnets but it is missing the bit that tells it C has to be accessed through A.

      Let me know how it goes.

      Robert

    1. Hi:

      I’m assuming your question is actually can a Sonicwall make a VPN connection (probably IPsec) to another brand of firewall. If so the answer is “yes”. I have personally configured Sonicwalls to connect to Cisco and Watchguard firewalls and I know they can place nice with a number of other brands. Dell Sonicwall has quite a few KB’s on the process on their support site on the process and many of the other vendors like Cisco also have similar KB’s available. There is a dance that you will have to do because each vendor does things and uses wording a bit differently from every other vendor BUT, if they follow certain standards, it can be done. I will caution you that you may have little success trying to set up VPN between a Sonicwall and a consumer-grade firewall.

      1. Hi,

        Another question regarding the Sonicwall, is it capable of having a dual-engine anti-virus? Like for example, two diff. anti-virus are present in the box?

        1. Hi, Claudette:

          No, I’m afraid not. The default antivirus (so long as you purchase the appropriate support SKU) is McAfee (Sonicwall Anti-Virus). There is a SKU that also gives you a desktop/server version of McAfee, as well. However, there is no “dual engine” option. Our (itgroove) advice has always been to use a Sonicwall UTM device at your gateway with the bundled antivirus (McAfee) and then use a different vendor such as Trend Micro for the internal client antivirus.

          Hope this helps.

          Robert

  • Hi,
    we have a SonicWALL in our Middle East office on 10.3.102.0/24 and I currently have a site to site policy configured to our UK Head Office which has a Palo Alto.
    This is working fine but the Address Object is configured to 10.0.0.0/16.
    I need to set up a 2nd site-site IPsec to a fortigate device in another middle east office. the subnet of this office is 10.3.100.0/24
    When I attempt to set this up it tells me it overlaps with the other policy?
    How do I got them to play ball. I thought these were supposed to sit along side each other and traffic would use the most direct route.
    Many Thanks

    1. Hi, Mark:

      I have hit the same issue in the past (or at least similar). As far as I can tell the problem comes down to how the box treats the overall subnet of 10.0.X.X based on your masking regardless of where the networks actually exist. I have dug through Sonicwall tech documents and I think this *might* help: https://support.software.dell.com/sonicwall-nsa-series/kb/sw7759 This is written specifically with Sonicwalls at both ends but I think you can probably fiddle it to make it work for your case. If you are able to shrink the scope on the “10.0.0.0/16” address object then you might have better luck. Finally, if you get nowhere and have Sonicwall support then best bet is to open a case with them and, if you have to, push hard for it to go to second or even third-tier support. There is a way to make it work but it may take some real dancing to do so.

      Sorry that I can’t be more helpful than this. Let me know how it goes.

      Robert

  • Hey Robert,

    Great write-up. Thank you.

    I’m having a bit of trouble. Within the VPN, I’ve pointed the Remote Networks to an Address Group I created which holds two subnets, A 192.168.0.x and B 192.168.100.x. A is the subnet at our main office. It is working properly over the VPN. However, subnet B is not. Subnet B is handed out when a user uses the VPN Client back into our main office here where Subnet A is. Is this setup correctly? Not sure if I’m missing a route somewhere. I’ve also added the NAT rule on the Cisco ASA here at the main office to allow the traffic out to across the VPN.

    Any thoughts would be greatly appreciated. Thanks!

    df

    1. Hi, Darren!

      Thanks for the compliment, much appreciated! As for your issue it sounds like you have created the configuration correctly. Question: On the Sonicwall do you see BOTH subnets showing in the VPN Policies status display on the VPN settings page (two green dots, one for 192.168.0.X and 192.168.100.X)? That is the first test as that would indicate the Sonicwall has set up both tunnels. This would also indicate that the Sonicwall knows to route traffic to those subnets across the VPN. At the Cisco end (and I apologize as I’m no ASA expert), there should be equivalent tunnel routes set up. In other words, the ASA also needs to know that it needs to route traffic back to the Sonicwall local LAN via the tunnel. The ASA might not know the route to the Sonicwall from the 192.168.100.X network. One test you could do is set the Sonicwall gateway interface to allow PING’s and then try pinging from both 192.168.1.X and 192.168.100.X. If both ping correctly then the tunnel is working as it should and it is just route tweaking that you have to mess with. If not then there is more digging required.

      Let me know if you need any more help. I’ll ping you via email with my contact info.

      Robert

  • Hi Robert,

    Excellent blog post and great site! Thanks for taking the time to share with the rest of the world.
    I do have some firewall experience but never had to work with a SonicWall before! So I followed your post to create a site-to-site with a FortiGate and that worked out well if the remote subnet is a single subnet (counters increase and I can ping).

    However the remote site has 3 subnets as part of it’s LAN.

    So in the last part you said to create the additional firewall subnets, to put them in the VPN zone and add them to the firewall object group that as needed. I did that, and then also went to the remote fortigate and added the 3 subnets as part of it’s local LAN.

    Unfortunately, once I do that, and while I do get 3 green bullets next to each subnet under the VPN page on the SonicWall I can no longer ping to any remote subnets (even the one that was previously working).

    Since I’m not familiar with SonicWall and I’m familiar with FortiGate, I run a debug on the FortiGate and I do see the pings coming in but I can’t tell why I don’t see the response going back to the SonicWall.

    Whenever I had such problems with the fortigate or ASA’s I’d create a separate Phase2 for each subnet. How do I do that with the SonicWall or perhaps you have any tips on what could be wrong?

    If I remove the 2 subnets from the remote site in the VPN configuration (and this leave one one subnet in the group) and do the same on the other firewall, communication is restored.

    1. Hi, Anestis: My original post was all about the simple method of connecting two Sonicwalls with site-to-site VPN and I’m blown away at how many people have used it as a jumping off point to try all sorts of different things. I won’t try to claim the title of “expert” on multi-vendor connections because I’m not. But I’ll try and help if I can.

      The simple Sonicwall connection is predicated on the ability of a Sonicwall to encapsulate the “tunnel info” with the “network info” inside a single VPN policy. Keep in mind that this type of policy is fine for simple connections that don’t have any fancy networking or routing requirements. Most other firewalls seem to work more like what Sonicwall terms as “route-based VPN” where the VPN policy simply defines the tunnel connection (the VPN itself) and then other mechanisms control what traffic can go over the tunnel (the routes). This methodology allows for much more complex settings (network, routes, and so on) but also requires a lot more configuration.

      You didn’t give me any information about the various subnets so I can’t speculate on what might be going on but I’m willing to bet that you might need to modify the VPN to more closely follow the route-based VPN scenario. Sonicwall has a fair amount of information in their knowledgebase about route-based VPN’s as well as some (thin) information about VPN interaction with other vendor firewalls. If you want to provide some more details I’ll be glad to help as I can. Let me know if you want me to PM you and we can take the discussion offline.

      Robert

      1. Hi Robert,

        Thanks for taking the time to respond.

        I was able to figure it out after all. The Sonicwall is creating a separate SA (separate phase2) for each additional subnet that you add to be protected but FortiGate doesn’t do that. So I had to go on the fortiGate and create separate phase2 SAs for each additional subnet.

        Kind Regards,
        Anestis

  • Hi,

    Like others have said, excellent post 🙂 I have a site-to-site VPN to x2 offices in the US from our UK office. Everything works fine however I now have remote users who connect to our network using the SonicWall VPN client. They can see everything on the LAN but they cannot see the x2 remote LANs in the US. I’m assuming this is just a firewall issue but as this is not my area I’m reluctant to ‘play’ about with our SonicWall 2040.

    Do you think you could help with this? I can send whatever information you need about the setup here.

    Thanks.

    Mark

  • Hi,

    Please ignore my previous log. I managed to hack my way around and figured out what the problem was. All I had to do was add the appropriate groups to the VPN user setup.

    Again though, nice post 🙂

    Mark

  • Great post! I was able to follow it using a different version of the SonicWall firm ware.

    I have a problem though, the SonicWall is showing an open VPN tunnel, but I can’t ping machines on the other side (it’s connecting to a CISCO ASA)

    Any suggestions?

    Thanks again for providing this article!

    1. Check the network definitions for the VPN on sides. Chances are you’ve missed something. Also, my post was Sonicwall specific for setting up VPN between Sonicwalls, the process may not work according to plan with non-Sonicwall. You might have to use a more traditional VPN config with the ASA. Sonciwall has a few KB’s on connecting with Cisco, this one might be helpful: https://support.software.dell.com/sonicwall-tz-series/kb/sw5723

  • Just wanted to say a huge thank you for such a great article! Made setting up our site to site a breeze. I did initially struggle getting any traffic to traverse the VPN but after much gnashing of teeth I figured it out. Our set up is this: NSA 3600 connected to an MPLS leased line at HQ and a TZ105 connected to a 4G/LTE router at the branch office. Static IPs at HQ on 192.168.1.* and statics at the branch on 192.168.5.*. The VPN worked straight off the bat but I could get no traffic over it. The culprit was the 4G/LTE router that had been shipped to us preconfigured to give out a DHCP address to, in this case the TZ105. That DHCP lease was on the 192.168.1.* range, the same as the LAN subnet at HQ. As soon as I changed the DHCP range on the 4G/LTE router to 172.168.1.* the traffic flowed! So for me, the key point from all of this is if you have trouble check all your possibilities, look at every bit of networking involved as the setup detailed above is rock solid and just works, great work Robert, thank you

    1. Robin:

      Wow, I’m blushing! Glad my scribbles helped you out. And glad you stated the “rule” … check everything because if you don’t you’ll miss something important! I cannot tell you how many times I have gone through this setup and hit issues only to find I made a typo or something else wasn’t accounted for (like your DHCP server). Thanks for your comment and thanks for reading my blog!

      Robert

  • Robert,

    Thanks for creating this post. I was able to configure my site-to-site VPN will very little trouble but now I am having a name resolution problem. Currently I have a TZ210w on the master side (on the production side currently) and a NSA2600 on the slave side (recently purchased and currently configuring), in the end I am going to reverse roles but for testing this is how I have it set up. On the Master side I have several mapped drives through DFS on a Windows 2008 server (in DFS domain.localfiles = serverData) but when I connected via the site-to-site from the slave side on a domain laptop I cannot connect to the mapped drives from that laptop. However if I do not use the mapped drive and type in the IP address for the file server I can connect to it with no problem and everything functions as I would expect. How can I get my slave to resolve the remote domain names in order to get my mapped drives to work without resorting to IP addresses?

    1. Sean:

      Are you running DHCP on the remote Sonicwall (the one that initiates the connection)? If you are need to set DNS on the scope to look at your domain DNS servers at the central site. Generally, when you have a condition such as you describe, you have not set up DNS correctly on the remote site as you have proven that traffic flows correctly across the VPN. DNS is required for DFS.

      Let me know if this solves your issue.

      Robert

  • So I am trying to get a remote site to connect to azure.
    My main site is connected to azure via static VPN and it works fine. My remote site is connected via Site to Site VPN with main site

    I can get trafic from teh remote site to travel to azure without issue, but sending traffic from azure to the remote site is not working. The main site sonic wall is dropping the packets. I can see this happening in the log.

    To enable the remote traffic to get to azure we just had to add the azure network as a remote destination on the vpn setup. We tried to add the azure network as a local destination on the Azure VPN on the main site, that does not work. Not sure what I am missing but any ideas would be appreciated. Thanks

    1. It’s definitely a routing issue. Are you doing the site to site VPN as per my post (everything including networks is encapsulated in the one policy)? If so you may need to switch to a route-based VPN which means the VPN policy simply handles the tunnel and then you have explicit routing rules that handle the various routing scenarios. Building the VPN this way gives you more flexibility as well as better granular control which *might* solve your problem. The “easy way” for the VPN build handles all of this inside the VPN policy and you have less granular control over the routing. My bet at this point is that the main firewall has no idea how to route the traffic inbound from Azure to your remote site and that’s why the packets are dropped.

      Ping me if you need a better description.

      Robert

  • Robert,

    Thanks for the help. That was exactly it. Changed the DNS for the DHCP scope on that interface and I am getting name resolution through VPN for that interface (LAN). Was having problems with the WLAN interface as well until I bridged it to the LAN interface.

    Thanks
    Sean

      1. Unfortunately not all is fixed. I am feeling like the fish today. After fixing the name resolution problem on the LAN and bridging the WLAN to the LAN interface, I noticed that my iphone 5S could no longer connect to my Exchange 2010 server to receive email on the phone. Thinking it was the phone I tried multiple times to reconfigure account on phone with no success. When I got home I was able to connect to the Exchange server with no problem. The next day I had the same problem so I asked a co-worker to try with his Samsung and he was having the same problem through the SonicPoint. When I unbridge the interfaces (with or without the site-to-site enabled) or disable the site-to-site (with a bridged interface or unbridged interface) I can connect mobile devices to my exchange server. but not when it is a bridged interface . It is a SoincPoint ACe by the way.

        1. Turns out it was not the SonicPoint’s fault. After done a reset on my testing process, I figured out why the bridged interface was not working. Turns out the Site-to-Site connection (whether it was LAN or WLAN) was not working with my Exchange server. I am not 100% sure but my theory is that since my Exchange server does not use the SonicWall as the default gateway it was sending information through its gateway which does not communicate to the Master SonicWall through VPN. That is the reason I could connect to my Exchange server when my WLAN on the Slave SonicWall was not bridged. As soon as I changed the default gateway of my Exchange server to the master SonicWall, I was able to get email traffic (both WLAN and LAN) through the VPN and with the WLAN interface bridged to the LAN. Now I have to change my MX records to point to the public IP address of my Master SonicWall.

  • I’ve set up the site-to-site VPN with Cisco routers on one site and A Sonic Firewall on the other. The lights are all green on the Sonic and the users on the Sonic LAN can access hosts on the Cisco LANs. The problem is that users in the Cisco LANs can only access the Sonic firewall and not hosts in the Sonic LAN.

    1. I suspect a misconfiguration on the Cisco side. Recheck your rules and the config as something would seem to be amiss with the “gateway” if all traffic is terminating at the firewall rather than passing through the VPN. Make sure that the rules on the Sonicwall for the inbound traffic clearly identify the remote side LAN (this is probably in place as Sonicwall users can get to the Cisco LAN but check it anyway) and make sure the rules on the Cisco clearly identify the Sonicwall side of things. It sounds like the tunnel is in place so now it is just routing that probably has to be fixed up. You *might* have to set a routing rule on the Sonicwall if everything else checks out. I don’t have access to a Cisco so I can’t be more explicit than this.

      Robert

  • Quick, to the point article and worked first time.

    I was hoping you could expand upon allowing additional subnets in the tunnel. Address Objects for the additional subnets (Type: Network) have been created. But do I how choose multiple Remote Networks from “choose destination network from list”? In this case there is a data LAN and a VoIP LAN. Thanks in advance.

    1. Hi, Rick:

      You have to clearly define all the subnets that you want seen on each end of the tunnel so this usually means you have to create an address group object then include the subnets in that object. If you are doing Sonicwall to Sonicwall using the quick method you will see that there is a tunnel created for each subnet pairing. So this means you have to ensure that the Local Network includes all the subnets on the local side and the Remote Network includes all of the subnets on the remote side that you want to include in the VPN and this needs to be mirrored on the other device. So if you have 192.168.1.x and 192..168.2.x on Sonicwall1 and 192.168.3.x and 192.168.4.x on Sonicwall2 and you want everything to see everything your settings would be:

      Soncwall1: Local Network (192.168.1.x, 192.168.2.x), Remote Network (192.268.3.x, 192.168.4.x)
      Sonicwall2: Local Network (192.168.3.x, 192.168.4.x), Remote Network (192.169.1.x, 192.168.2.x)

      The info in brackets above would be the Address Group Objects. And each Sonicwall would show 2 tunnels up there is a tunnel created for each subnet (like the last illustration in the post). Hope this helps.

      Robert

    1. Follow my post on setting up the easy way and make the MX2400 the unit that the TZ205w initiates the connection to as the 2400 has the static address. It will work for you as this is the recommended way to set up when one end is dynamic.

      Robert

    1. Maria:

      Follow this post as it is exactly the config you need to work in your situation. The 2400 is the “master” unit (as per my post), the TZ is the other one. Set it up this way and I guarantee your VPN will work. Only thing I suggest is that you ensure the firmware on both units is at the same level or a s close as possible. Having very different firmware levels can cause problems.

      let me know how it goes.

      Robert

      1. Robert good morning, we continue step by step; and still does not work; frimware are the same level of SonicOS Enhanced upgrade 5.9.0.6-3o. The truth, I don’t know what to do.

        1. Hi, Maria:

          Can you give me a little more detail? Can’t really suggest anything as you haven’t included any details. I’m not Sonicwall tech support but I am happy to try and point you in the right direction if you can paint a better picture of how you are set up.

          Robert

  • Great write up and it worked like a charm. I’m having one weird issue though. Master (in Hayward) hosts 192.168.2.x and Remote (Sacramento) hosts 192.168.1.x.

    The remote site can see every thing on the master site. From the master site I can ping the gateway of the remote site (192.168.1.1) and access the printer on the remote site as well (192.168.1.123 via DHCP). But I cannot ping any other IPs on the remote site nor can I access their NAS.

    Both firewalls are SOHOs and have no other configuration other than IP assignment and the VPN tunnel. Thoughts?

    1. Hey, Jay:

      This sounds like a misconfiguration on the Sacramento side. Go back and recheck your “remote networks” on each side of the VPN and verify the entries on each side match the network(s) on the other side. On Sacramento side check gateway settings, if you are settings static IP info on devices (rather than DHCP) check all the settings. Check firewalls on PC’s, maybe you aren’t identifying the Hayward subnet as being part of the allowed domains (printer would not have this issue) so the ping’s are being dropped or ping is not allowed at all. NAS could also be the same thing. The tunnels themselves are fine so it is a routing issue (the gateway thing) or local firewall issue.

      Hope this helps, let me know how you make out.

      Robert

      1. Thanks Robert. I factory reset the Sacramento side and walked through it again. Works now without a problem. I must have missed something originally. Thanks again!

        1. Jay:
          Great to hear it all works! Believe me, I have been there way too many times; I always seem to miss one minor setting on the first go round then I have to go back and find the wretched thing OR discover that I have “phat phingered” some entry. Thanks for touching base, appreciated!

          Robert

  • I am new to SonicWall, and I followed this procedure exactly on both devices. I have a tunnel up, and I can ping the SonicWall devices from each other, but I can’t ping or otherwise access any hosts behind the devices. Any ideas?

    1. Hi, Dan: Recheck your local and remote network settings on each VPN configuration, I’m betting you have messed up something in one of the two. The tunnel is up but one or both of the endpoints is not aware of the networks on the other side; in essence you don’t have routes in place. Go back and check each piece, I bet you’ll find it!

      Robert

  • Great write up. I do have a question though. We are moving to a location where there is no viable data center space so I am moving my servers to a colocation data center. My plan is to use site to site vpn between the office and the data center.

    I have a Sonicwall Pro 4060 that will go on the data center side and a Sonicwall Pro 2060 that will go on the office side.

    Would the setup be the same? We are currently just one location on a 10.0.0.0 subnet.

    Thanks very much!

    1. Hi, Mike:

      If all your nets are on the same 10.0.0.0 subnet and you aren’t going to make changes due to the move to the co-lo then you will probably need to do policy-based VPN rather than my “simple” VPN as things can get a bit messy with a single subnet and routing. IF you can clearly define what segments lie behind one gateway (say the 4060) then you might be able to get away with the simple config methodology.

      The simple config rolls the tunnel and the routing into one “object”, if you will, so there is no wiggle room for routing. Policy-based routing VPN separates the tunnel config from the network config and gives you more flexibility; you can better “describe” the routing so that a given packet can find its way to its intended destination. You might have to do some testing and tuning.

      Robert

      1. Hi Robert,

        Thank you for the reply. I guess I should have said that the current subnet is 10.0.0.0. I’m going to keep that subnet for the colocation (servers) since they are all static. The colocation will be my “main” side. The office with be my “remote” side. I plan to keep one server at the office location to use for Active Directory and DHCP. I can easily change the scope to a different subnet, say 10.0.1.0.

        We have two separate internet connections so I tested the site to site tunnel and got it to work using your instructions. I used a laptop with a static IP of 10.0.1.10 for the “remote” side. However, I can’t reach any of the servers on the “main” side by server name. I can reach them by IP address but then I get asked for credentials to log into the server to see it’s shares. In addition, I can’t get out to the internet from the “remote” laptop. Ideas?

        I did have one question on the setup though. On the remote (office) Sonicwall, the address object for the main (colocation) should also be a VPN object, or is it a LAN object? In your instructions, for the main Sonicwall, the address object for the remote location is a VPN object but it’s not detailed for the remote Sonicwall. Does this make sense?

        Thanks again!
        Mike

        1. Hi, Mike:

          OK, if you got the tunnel up AND each side of the tunnel knows about the networks on the other side of the tunnel then you are over the first hurdle. And, if you can reach servers or devices over the tunnel via IP address then yo know your routing is working. So, it looks like it is a question of tuning some settings. Make sure you have Windows Networking (NetBIOS) enabled on the VPN config on both sides of the tunnel. Also, when you tested with the laptop, where was it pointing for its DNS? Did you point at a server on the main side? In most of my configs, the remote side ALWAYS looks for DNS from servers at the main site and that seems to solve a lot of issues. Finally, in answer to your last question, yes, objects on firewall A that refer to something on the remote side of a VPN tunnel on firewall B should always be VPN objects. That ensures the object is attached to the correct zone and has proper security wrapped around it.

          Hope this makes sense. let me know if you need anything else, ahppy to help.

          Robert

          1. You are a genius! I changed the DNS settings and viola! My logon script runs, I get my mapped drives and printers and can browse the network. Sweet!

            There is one more naggling little issue though. The laptop on the “remote” side still cannot get out to the internet while the tunnel is active. Thoughts?

            Thanks again Robert!
            Mike

          2. Laptop getting DNS correctly? In other words, if you do an nslookup from the laptop for an external site, does the DNS server give the IP address? Also, make sure you do NOT have “Use this VPN Tunnel as default route for all Internet traffic” selected on the VPN config (network tab). Finally, make sure the network settings on the X1 port on the remote Sonicwall are correct and the laptop has the correct gateway IP configured. The laptop should see the IP of the remote Sonicwall as it’s gateway and the remote Sonicwall, in turn should see it’s WAN gateway correctly as well. Then the default routing config on the remote Sonicwall should then handle the access from the laptop to the Internet. Oh, and make sure your firewall rules will allow access from the LAN to the WAN! I’ve blown my brains out in the past only to finally look at the rules and discover ALL outbound traffic was blocked by firewall rule.

            Robert

          3. Robert,

            Yes, it appears the laptop is getting DNS correctly. Doing an nslookup on Google and MSN returned their respective IP addresses.

            I checked the gateway on the laptop and it is pointing to the remote Sonicwall. I checked the gateway on the Sonicwall and it is pointing to the correct IP. The “Use this tunnel…” option is NOT selected, as the destination network is selected.

            Regarding the firewall, the LAN > WAN rule is set to allow all. The WAN > LAN rule is set to DENY. This seems correct, no?

            So it seems that everything is set correctly yet I am still unable to browse the internet. Any other gotchas you can think of?

            Thanks very much…again!
            Mike

          4. Hi, Mike:
            Sorry to be tardy getting back to you …

            I can’t think of anything off the top of my head. What do diags on the firewall give you? Can it ping its gateway and its DNS sites? And, stupid question is the firewall showing as being properly licensed? If it is not licensed there may be an impact on traffic. Finally, have you restarted the remote sides modem and then the firewall? Sometimes that seems to sort everything out. Also, to start, make sure you have no security services enabled then you are just doing “raw” access with only firewall rules in place. Once you KNOW things are working you can start to cut in the security services.

            I can guarantee whatever the problem is that it will be something “silly”, so keep looking!

            Robert

          5. Robert,

            No worries on “being tardy.” I appreciate your help.

            Anyway, all looks fine. That data line I’m testing on is actually for supplying wi-fi to our employees and any guests who might need it. I didn’t want Wi-Fi on my corporate network so that’s why we have two data lines.

            So I plugged the wireless router back in and set the laptop up to connect to that and the internet works fine like it always did.

            I plugged the Sonicwall back in, the tunnel came right up, but then from the laptop I couldn’t get the internet anymore. Same problem.

            So then I remembered we had a newer Sonicwall that wasn’t being used. It is a TZ215 with the Sonic Enhanced OS on it (the Pro 2040 and Pro 4060 also have that OS, albeit older). So I set that up to be the “remote” end of the VPN tunnel. Once it was set up, the tunnel came right up, and viola! The internet works too! So I’m thinking…OK, problem solved, I’ll just used this one.

            I then log off of the laptop and log back on to make sure the logon script runs and I get my mapped drives and printers. Ugh. Nope. I can browse the servers on the other end of the tunnel by name or IP but the mapping done in the script doesn’t work. Argh.

            I’m hoping this is a simple setting somewhere. Any thoughts?

            Thanks again,
            Mike

  • I’m trying to set up a VPN on two sonicwalls, one an older tz100 and one a newer tz105. However, there is no policy type option. When I click “add” in the vpn settings, the first option is authentication, not policy type.

    Why is this? I can’t find anything online. Sorry for commenting on an old article.

      1. There is no attach option in the comment section?

        I get to this step (very early in the process):
        Now, click the ADD button under VPN Policies, the following will appear: [your screenshot]

        But I can’t do this step:
        Fill in your entries as follows:

        Leave Policy type as is

        Because there is no policy type drop down. The first option I can interact with is Authentication Method

  • Hi there – I followed your guide, very well written and easy to follow. Thanks so much for the effort you’ve put into this and the followup answering all these questions.

    I tried getting this going on my own, and have had some success. I have 3 offices (well, actually 8 but focusing on 3 for now). I originally followed your guide and linked two of the offices together, and today I was tackling adding a third to the mix. I added the first office to the third office successfully, I got the green light right away and was able to see network items across the tunnel. I went to tie office 2 to office 3, but after finishing the steps I get a green light saying the tunnel is there, but I’m unable to access any network resources. Figuring I did it wrong, I deleted the address objects and vpn tunnel and started fresh, same thing.

    The only “gotcha” that I could see is Office 1 uses the ip range 192.168.1.0, Office 2 + 3 use similar ranges, 10.1.2.0 and 10.1.3.0 respectively. The only thing I can think is that these are on the same subnet, too similar and not passing traffic. But I’m not sure if that is the case.

    All three devices are Sonicwall NSA2600. Do you have any thoughts? Any advice or direction would be super greatly appreciated. Since adding Office 1+2 were so easy and smooth I kind of oversold managemnt on how quickly I could get this going. haha woops, I should have know. 🙂 Thanks again!!

  • Hi Robert,

    I wish I’d thanked you for this article. Little over a year ago I bought 4 new Sonicwalls for our offices and followed your easy instructions and all worked “perfect”!

    But, for some reason last two days one of my “remote” offices cannot maintain a VPN tunnel to Head Office here in NL, Canada.

    I just don’t understand why. The other two branch offices with exact same settings are fine.

    I’ve not made a single settings change to either SonicWall and we have internet no problem.

    Funny thing is if I delete the VPN Config on the offending SonicWall and re-create exactly as before, the tunnel comes up.. but.. drops again shortly.

    I realize there could be many causes but does anything come to mind that I could try? Maybe I should make Master be the initiator.

    Cheers,
    Steve

    1. Hi, Steve:

      Thanks for the thanks! 😉

      The offending SonicWALL probably has a corrupted SonicOS image at this point (I’ve seen this in the past). Best bet, if you can, is factory restore, relicense (the mysonicwall thing), apply firmware updates if any then apply your saved settings back to the box (you do have settings saved from before the failure, yes???). Second best thing you can do is apply saved settings/firmware image if you have that. If you don’t have saved settings you can export your current settings for reapplication after reset but there is a possibility that the exported settings will also be corrupted.

      I don’t think you’ll have any better luck than current by reversing the master/slave configuration.

      Let me know how it goes.

      Robert

  • Hi Robert,

    Any updates on how to force all traffic from the remote site across the VPN. I have a NSA 2600 and a TZ215. I tried what you said to someone else in the comments but changing any settings just brings down the tunnels. I also tried a route based tunnel with no luck.

  • Great walk through and helped me get started at creating a VPN between two TZ215 SonicWALLS.

    Is there a way to set up so DHCP addresses on the remote side can be determined by a DHCP server on the master side of the VPN?

    1. Hi, Corey:

      Yes, you can have DHCP traverse the tunnel. The SonicWALL admin manuals have the info that you require, the key is to look at the “DHCP helper” functions. This is a link to a SonicWALL article on how to set things up. Ignore all the bits prior to Step 3. Follow Step 3 onwards specifically with the DHCP helper (IP Helper on newer firmware builds) on your remote site TZ215 and you should be good to go.

      Let me know how it goes!

      Robert

    1. Dave:

      The FQDN is defined at your DNS server, either internal or external, and not on the firewall itself. So, you need to set the name in your DNS servers. Best practice is to set you SonicWALL LAN and WAN to static IP’s (if at all possible) and then set an A record to map the desired FQDN to the IP address.

      Hope this helps.

      Robert

  • I keep coming back to your guide time and time again for my setup’s. Great work and ty for making my IT life that little more stressless.

  • Hello,

    I was given the task of creating a site to site, after searching and reading forums and articles. I found yours to be the best and easiest one around. I was able to figure out what you meant about having multiple subnet’s and configured both my routers. I show green lights on both of my subnets, though, I can’t ping nor connect to any of the devices on the other network. I know you have answered a few questions like this, but is there a configuration where I have to let the traffic flow?

    1. Hi, Juan:

      If you followed my setup I’m betting you’ve missed something fundamental on the network piece of the VPN config. Go back and check your settings on each side of the tunnel. The green lights are a good sign as that means the tunnel(s) is up and that the side showing the green lights “knows” about the subnets that you are passing from the other side (Firewall A shows green lights for the nets from Firewall B and vice versa). I’m betting you have missed something in the “Local Network” settings on the VPN policy. This is as critical as having the “Remote Networks” settings correct. What you are doing with these two settings is defining the routing that will be baked into the VPN policy. This is what sets up for you to be able to access devices on the far side of the tunnel (you are behind Firewall A and can ping a device on the subnet behind Firewall B).

      I would recheck the settings for both Local and Remote Networks and verify you have covered your bases. Also, verify settings on your devices on the target subnets and ensure your gateway settings are correct. Your local devices have to go to the correct gateway in order to access the VPN.

      Hope this helps, let me know how it goes.

      Robert

      1. Robert,

        Thanks for the reply. I will go ahead and check my settings again. Also, don’t know if it makes any difference, but the 1 remote machine I need access to on the remote site, is plugged into a Linksys WiFi router. Do I have to add the IP address of the WiFi Router?

        What I did was added the range of the addresses that the WiFi Router could give out as subnets. Hopefully this is not confusing. If you can see my email, can you shoot me a message, so that I can show you pics of my configuration?

  • Hi Robert,

    First let me echo many others in saying it’s a great article!

    I’ve followed your instructions and have setup the VPN tunnel, but have run into a couple of issues.

    In both sites, we have HyperV servers and Qnap NAS devices.

    But I’m finding that some traffic seems as if it is being blocked. HyperV replication between servers doesn’t work , replication on port 8899 between the NAS drives doesn’t work..

    However, active directory replication between 2 DC’s is fine and so is browsing to ADMIN$ shares for example.

    We can ping between the subnets (192.168.1.0/24, main and 192.168.2.0/24 in the 2nd site), by IP and name.

    I’m wondering what I am missing… I know that there are access rules created by default when a VPN is created (as far as I can see it allows all traffic), but I cannot think where else to look.

    Any ideas? Running TZ215’s in both locations.

    Thanks,

    Jamie

  • Hi Sir,

    A year ago I purchased 4 Sonicwall and I did the site 2 site VPN connection with our Head Office but after one exact year first my all SonicWALL default license got expired and the same day all of the VPN setup went down except the new installed SonicWALL to new site. and for all old site setup is fine.So please suggest me for the same ??Is it for the license expiry or any other reason.

Leave a Reply

Your email address will not be published. Required fields are marked *