Sean Wallbridge
I made an earlier post about Sonicwall wireless issues here, this is a bit of a follow up to that post (or follow on).
All Sonicwall firewalls come with a number of predefined security Zones that get applied to individual network interfaces on the box. Some of the standard zones are Trusted, Public and Wireless. Be aware that the Wireless zones is specific to Sonicwall wireless which encompasses both the built-in wireless on wireless models as well as Sonicpoint access points. It is NOT meant to be used as security zone for any other wireless devices. Traffic from any device that is NOT Sonicwall will be tagged as being from a “rogue” device and the firewall will eventually lockdown any network segments within the Wireless zone.
If you are going to hang another vendor’s access points behind a Sonicwall and you want to have the network segregated from the regular LAN by firewall rules then you will have to create a custom Zone and tag the interface that is the gateway for the AP’s with the custom zone. This way you get to apply the same tricks with the firewall and/or VLAN’s that you can with Sonicpoints and the Wireless zone but you won’t end up with a zone lockdown.
I had this happen at the customer where the Sonicpoints were ripped out and replaced with a pricey Cisco wireless controller and access points. The new AP set up worked brilliantly for a few hours then the whole network shutdown. I went around in a number of circles trying to figure it all out until I saw entries in the logs that indicated traffic from “non-Sonicwall” devices was being blocked on the network segment supporting the Cisco AP’s. Once I backed out everything and created a new zone things went back to being “perfect” on the Cisco wireless. And, yes, the Cisco AP’s (and the work performed by the company that installed the Cisco system) solved all of the issues we were having in the customer’s warehouse. In this case the customer definitely got what they paid for (the Cisco goodies were considerably more expensive than the Sonicwall wireless access points).
So, keep all of this in mind if you are going to build out a non-Sonicwall wireless infrastructure behind your Sonicwall firewall. A little up front work will save you a lot of grief.
Dear Admin,
I have been through your blogs and post, I got lot of things to learn from it even I am new to sonicwall devices.
I would like to seek your kind attention as I want to make VPN setup between 2 sites where site-A has SonicWall NSA240 and Site-B has TZ205 and both has licenses for them.
now for VPN setup over sonicwall I am new, further we have dynamic IPs at both the ends with dyndns accounts(2 accounts).
kindly provide me the steps and landmarks for the configuration part, I will be thanks for your support.
thanks
Hi, Mohammed:
I’ve never actually built a VPN under those conditions but I have found documentation at Sonicwall support that describes the process. First, here’s actual document: https://support.software.dell.com/sonicwall-tz-series/kb/sw3256 Now here is the section that describes what you want to do:
Scenario Two – Site to Site VPN with dynamic WAN IP addresses
Sample Diagram
Figure 6 – WWW Server on DMZ interface
Tasklist
Address SonicWALL interfaces
Create DynDNS.org account and confirm to activate
Create DDNS entries and wait until SonicWALLs update records
Get UFIs from both SonicWALLs
Configure VPNs
Adjust VPN Advanced settings
Test connectivity and ability to reach WWW server via DDNS record across reboots
Before You Begin
Make sure you have all necessary info from each side’s Internet Service Provider (ISP) and that the SonicWALL security appliances are running SonicOS Standard 3.0.0.3 or newer. This section assumes that the SonicWALL is using its default IP addressing information for its LAN interface. You will also need a valid
email account in order to successfully create and activate your DDNS records.
Setup Steps
1. Connect your first management station to the first SonicWALL’s LAN interface. Assign the first management station an IP address of 192.168.168.200, a subnet mask of 255.255.255.0, a gateway address of 192.168.168.168, and a DNS server as provided to you by your ISP (if you do not know this, you can temporarily use 4.2.2.2). Reboot.
2. Connect the second management station to the second SonicWALL’s LAN interface. Assign the second management station an IP address of 192.168.10.200, a subnet mask of 255.255.255.0, a gateway address of 192.168.50.1, and a DNS server as provided to you by your ISP (if you do not know this, you can temporarily use 4.2.2.2). Reboot.
3. On the first and second management stations, open a Web browser (IE, Opera, Firefox, etc) and log into the SonicWALL’s management GUI using the admin name and password (default is admin name of ‘admin’ and password of ‘password’).
4. Go to the ‘Network > Settings’ page on each SonicWALL and select the type of dynamic IP addressing scheme your ISP uses from the drop-down next to ‘WAN’ (NAT with DHCP Client, NAT with PPPoE Client, NAT with PPTP Client, or NAT with L2TP Client). Then, click on the ‘configure’ icon at the far right. In the pop-up screen that appears, enter all necessary information as provided to you by your ISP. When done, click on the ‘OK’ button to save and activate the changes.
5. On the ‘Network > Settings’ page, click on the ‘Connect’ button to force each SonicWALL to obtain its dynamic WAN IP address. If this does not work, reboot each SonicWALL and log back in.
6. From the first management station, test basic public Internet connectivity from a web browser by logging into a site (for example, http://www.sonicwall.com).
7. From the second management station, test basic public Internet connectivity from a web browser by logging into a site (for example, http://www.sonicwall.com).
8. Go to pages 5-6 of this whitepaper and follow steps 10-12 to create and activate an account on DynDNS.org. Create a separate record for each SonicWALL (in our example, one side is named ‘ash.shacknet.nu’ and the other side is named ‘kodiak.ath.cx’). When done, return to this step.
9. From the management stations, log into each SonicWALL’s management GUI and go to the ‘Network > Dynamic DNS’ page. Click on the ‘Add…’ button. In the pop-up that appears, leave checked the boxes next to ‘Enable this DDNS Profile’ and ‘Use Online Settings’, name the profile “Primary”, choose “DynDNS.org’ from the drop-down next to ‘Provider:’, enter your DynDNS username/password, and enter the fully-qualified domain name you created on DynDNS’s site in the previous step. Leave all other settings at their default. When done, click on the ‘OK’ button to save and activate the changes. For an example, see Figure 7 below.
Figure 7 – Creating the DDNS entries on both SonicWALL devices
10. Wait a few minutes, then check the ‘Network > Dynamic DNS’ page. In the status field, it should list as ‘On-line’ and show the WAN IP address of the SonicWALL device. You should also be able to see this in the SonicWALL’s logs.
11. Log into both SonicWALLs and go to the ‘VPN > Settings’ page. At the top of the page, you will see both SonicWALL’s ‘Unique Firewall Identifier’ (UFI). Write each UFI down as you will need them in an upcoming step.
12. On the first SonicWALL, go to the ‘VPN > Settings’ page. Click on the ‘Add…’ button to create a VPN tunnel to the other site. On the pop-up that appears, choose ‘IKE using preshared secret’ from the drop-down next to ‘IPSec Keying Mode’, enter the other SonicWALL’s UFI in the field next to ‘Name’,
enter the other SonicWALL’s DDNS name in the field next to ‘IPSec Primary Gateway or Address’, and enter a complex shared secret in the field next to ‘Shared Secret’. This complex shared secret will need to be entered on the other SonicWALL as well. Then, click on the ‘Add…’ button in the ‘Destination Networks’ area and create an entry for the other SonicWALL’s LAN IP range. Click on the ‘OK’ button to return to the VPN pop-up. For an example, see Figure 8 on the next page.
Figure 8 – VPN Tunnel ‘General’ tab for each side
13. On the VPN pop-up page, click on the ‘Proposals’ tab. From the drop-down next to ‘Exchange’, select ‘Aggressive Mode’. Leave all other settings to their defaults. For an example, see Figure 9 below.
Figure 9 – VPN Tunnel ‘Proposals’ tab for each side
14. On the VPN pop-up page, click on the ‘Advanced’ tab. Check the box next to ‘Enable Windows Networking (NetBIOS) Broadcast’. Leave all other settings to their defaults. When done, click on the ‘OK’ button to save and activate the changes. For an example, see Figure 10 below.
Figure 10 – VPN Tunnel ‘Advanced’ tab for both sides
15. On the second SonicWALL, go to the ‘VPN > Settings’ page. Click on the ‘Add…’ button to create a VPN tunnel to the other site. On the pop-up that appears, choose ‘IKE using preshared secret’ from the drop-down next to ‘IPSec Keying Mode’, enter the other SonicWALL’s UFI in the field next to ‘Name’, enter the other SonicWALL’s DDNS name in the field next to ‘IPSec Primary Gateway or
Address’, and enter a complex shared secret in the field next to ‘Shared Secret’. This complex shared secret will need to be entered on the other SonicWALL as well. Then, click on the ‘Add…’ button in the ‘Destination Networks’ area and create an entry for the other SonicWALL’s LAN IP range. Click
on the ‘OK’ button to return to the VPN pop-up. For an example, see Figure 8 on the previous page.
16. On the VPN pop-up page, click on the ‘Proposals’ tab. From the drop-down next to ‘Exchange’, select ‘Aggressive Mode’. Leave all other settings to their defaults. For an example, see Figure 9 on the previous page.
17. On the VPN pop-up page, click on the ‘Advanced’ tab. Check the box next to ‘Enable Windows Networking (NetBIOS) Broadcast’. Leave all other settings to their defaults. When done, click on the ‘OK’ button to save and activate the changes. For an example, see Figure 10 above.
18. On each SonicWALL, go to the ‘VPN > Advanced’ page and uncheck the box next to ‘Disable all VPN Windows Networking (NetBIOS) Broadcasts’. When done, click the ‘Apply’ button at the top-right of the page to save and activate the change. For an example, see figure 11 below.
Figure 11 – VPN Advanced settings for both SonicWALLs
Testing/Troubleshooting
1. From the management system behind the first SonicWALL, open a command-prompt and attempt to ping the management system behind the second SonicWALL. If the VPN tunnel between the two SonicWALL devices has been configured as noted in the previous steps, it should miss a few pings, then respond.
2. From the management system behind the second SonicWALL, open a command-prompt and attempt to ping the management system behind the first SonicWALL. If the VPN tunnel between the two SonicWALL devices has been configured as noted in the previous steps, it should miss a few pings, then respond.
3. If neither system can ping each other, review all previous steps and try again. Check the logs on both SonicWALLs, as they should list at what point during the IKE/IPSec negotiation the SonicWALLs are experiencing a failure.
I hope this helps. If you have a support contract with Sonicwall you can also call into support for help with the configuration. (The above information is quite old so I’ll update this comment if I find newer documentation.)
Let me know how it works out for you. Always interested!
Robert
I’m back… I have used your write-up for the site-to-site VPN and it has worked out great (so far) and we are planning a deployment tomorrow at the slave site. However, this Bear and Fish article is better for my current problem. We are using a NSA2600 with X3 bridged to X0, with DHCP being doled out from a central server on the LAN for all clients (except servers and printers). We have an ACe connected to X3. In addition to that I also have an ACi connected to X7 and zoned for WLAN where the NSA2600 is doling out DHCP to a different subnet, the DNS for that subnet is being taken from the WAN but I am not running Guest Services. The ACi is performing well and the NSA is doing exactly what I want with that traffic: it is separated from the LAN and they get straight internet access. But the ACe or the bridged connection or something else is giving me problems. All devices connected through the ACe are working great (acces to the LAN, internet access, etc…)except for my iphone (5s, OS 8.3). My phone will get an IP address from the ACe but will not connect to the internet. As soon as I switch over to the ACi I can get internet access. I tried the same thing with another iphone but they were able to get internet access while connected to the ACe. Have you seen this behavior before? I have tried forgetting the network and restarting the phone but nothing seems to help. I have read several articles about it but most solutions involve reboot NSA, which is something I do not want to do and I do not think the NSA is the problem…
Sean:
I have no experience with the new ACe and ACi SonicPoints so I can’t comment authoritatively. However, I do know that iOS devices like to march to their own drummer with WiFi and there can be all sorts of weirdness with the iOS devices depending on the type of encryption you use (TKIP, AES). They really don’t like connections that allow both (not sure if you can do this with the AC units). You can try setting as just TKIP or AES and see if things get better. iOS likes the WiFi “simple”. The ACe and ACi aren’t supposed to be wildly different internally so I can’t really see how one would connect and the other wouldn’t. Is there any way for you to swap them around and see what happens? If the NSA was the problem then it should be happening on both ACe and ACi. Also, the bridge is just that, X3 becomes and extension of X0 so that really shouldn’t have any bearing, either, as it just becomes a “2 port switch”. But I’d bet on slightly different settings between the ACe and the ACi causing you your grief.
All of that said, if the NSA is providing the DHCP on X7 I’d take a look at it, as well. I’ve had a few issues with Sonicwall DHCP not actually passing all required parameters to a client (like gateway and DNS server). Have you checked on the phone to see that ALL settings are in place? If you set X7 to allow ping, can the phone ping X7’s gateway IP? As this is WLAN, have you set up VLAN’s on X7? I have been told by Sonicwall in the past that on WLAN you should always have VLAN’s for traffic to/from SonicPoints and only pass management traffic on the main interface. All of this can affect certain iOS devices.
That’s it, you have got all my suggestions. Hope something works. I have pretty much given up on SonicPoints and moved to enGenius but they ALL have their “issues”. Let me know how it goes.
Robert
Robert,
Sorry it has taken so long to get back to you. I have not had a chance to swap the ACe and the ACi, but as you say: internally they are the same. One thing I did not make very clear is that the ACi on X7 does give out DHCP on a completely different subnet and inherits DNS from the WAN. That connection is fine, which uses external sources to find my mail server and DNS for nternet traffic. When an iOS device is on the X3 the device does not see the mail server and it does not see the internal DNS so it does not get anywhere on the internet as well. When I look at the parameters the iOS device picks up from the X3 wireless it all looks correct but does not behave correctly. I downloaded a simple ping app for my phone and it cannot ping the internal DNS machine.
I have not set up any VLANs. Both wireless interaces are set up for AES and I have switched it over to TKIP with no difference in results. I am going to contact SonicWall today to see if they can sort it out. I will let you know what they suggest as the solution and if it works.
Hi, Sean!
Thanks for all of this. I know there have been issues in the past with iOS devices and older SonicPoints and, for that matter, with many other vendor’s access points. Our friends at Apple do like to march to their own drummer … Let me know if Sonicwall is able to provide you with a fix as I’m sure everyone will need it at some point. And good luck! Ain’t WiFi troubleshooting just the bestest thing? 😉
Robert