asked on

Multiple Sonicpoints on one interface (NSA 2400)

I have 5 Sonicpoints I will be connecting to our NSA 2400. Not enough free interfaces on the Sonicwall, so I'm going to connect them all into a gigabit switch and plug that into the X2 interface. I'm familiar with creating the provisioning profile, zone and interface. I bridged X2 to X0 so the wireless traffic will pass to the LAN. All of this worked just fine, however, the first (and only one connected at the moment) Sonicpoint scooped up an IP address that wasn't even with the DHCP scope. I'm not able to change the IP since the box is greyed out, and it will eventually conflict with another device that has that IP.

Is there a better way of going about this?

Blue Street Tech

Hi hindsight,

Yes, the SonicWALL best practice deployment for SonicPoints is to break the L2 WLAN bridge. SonicWALL sets up the WLAN on a separate subnet for many reasons but primarily because of security and manageability reasons. Plus, WPA support is not available in Bridge Mode.

You can have the LAN talk to the WLAN and vice versa via Access Rules. WLAN > LAN Allow All and the same rule on LAN > WLAN.

You should setup a WLAN Interface, Zone & corresponding PortShielding Port for the SonicPoint. Then configure SonicPoint Provisioning Profile on the UTM.

This way you will have two DHCP Dynamic Pools removing any conflict and everything is clean.

Here are some best practices & considerations:
----------------------------------------------------------------------------
Layer 2 and Layer 3 considerations for SonicPoints

SonicWALL uses two proprietary protocols (SDP and SSPP) and both *cannot* be routed across any layer 3 device. Any SonicPoint that will be deployed must have an Ethernet connection back to the provisioning SonicWALL UTM appliance, in the same broadcast domain/network.

SonicWALL UTM appliance must have interface or sub-interface in same VLAN/broadcast domain as SonicPoint.

SonicPoints must be able to reach the DHCP scope on the SonicWALL; make sure other DHCP servers are not present on VLAN/broadcast domain.

Sharing SSIDs across SonicPoints attached to multiple interfaces may case connectivity issues as wireless client roams to different SonicPoint subnet.

Tested Switches

Most Cisco switches work well; however SonicWALL does not recommend deploying SonicPoints using the “Cisco Express” switch line.

SonicWALL does not recommend deploying SonicPoints using Netgear PoE switches.

If you are using D-Link PoE switches, you will need to shut off all their proprietary broadcastcontrol/storm control mechanisms, as they will interfere with the provisioning and acquisition mechanisms in the SonicPoint (see section regarding this).

Dell; make sure to configure STP for fast start on SonicPoint ports.

Extreme; make sure to configure STP for fast start on SonicPoint ports.

Foundry; make sure to configure STP for fast start on SonicPoint ports.

HP ProCurve; make sure to configure STP for fast start on SonicPoint ports.

Troubleshooting.

When creating a Wireless zone and interface, make sure to configure the interface for the number of SonicPoints you wish to support -- new interfaces are set to ‘No SonicPoints’ by default. If you do not do this, the UTM appliance will not create the necessary DHCP scope and will not acquire any SonicPoints added to the interface.

If you added SonicPoints and only a certain number were detected and acquired, check interface settings as noted above, as it might be set for too few SonicPoints.

If throughput seems sluggish, check to see how many SonicPoints you have on an interface – in large deployments it’s advisable to spread them across more than one. Try to limit the interfaces to a 4-to-1 oversubscription ratio. For example, if you have a 100Mbps, you can safely attach up to 20 SonicPoints to it and expect reasonable performance.

Given throughput on SonicPoints only 20-22 Mbps at best – this is a limitation of the 802.11a and 802.11g and not the SonicPoint.

If you are still experiencing throughput issues, please upgrade to SonicOS 4.0.1.0 or newer, as it contains several fixes that will help.

Make sure your security zone (the default WLAN, or your own custom wireless zone) has the right settings – they might be blocking traffic for various reasons. The ‘WiFiSec Enforcement’ setting is enabled by default, and because of this it will not pass traffic in the clear until this feature is disabled.

If the SonicPoints are not acquiring, check DHCP scopes; they might be off, or missing entirely.

It is NOT advisable to use the same SSID for the 802.11bg and the 802.11a radios, as clients with tri-band cards may experience disconnect issues – name them separately.

Stuck in provisioning mode? Unplug, clear from config, reboot and plug back in.

The most current version of the SonicPoint Administrator’s Guide can be found here: http://www.sonicwall.com/downloads/SonicPointAdministratorsGuide.pdf.

Please note that SonicPoints have a ‘Standalone Mode’ which they will transition to if they can’t find a SonicWALL UTM appliance. If you have more than one SonicPoint, you may have issues as all of the SonicPoints will revert to the same default IP address of 192.168.1.20/24.

When troubleshooting wireless issues, logging, Syslog, and SNMP are your friends – SonicWALL’s Global Management System (GMS) package can centralize all of these for all of your SonicWALL devices, regardless of location. A free alternative is Kiwi’s Syslog Daemon, which can accept Syslog streams and SNMP traps from all SonicWALL UTM appliances. The most current version can be found here: http://www.kiwisyslog.com/kiwisyslog-daemon-download/.

Let me know how it goes!

hindsight

ASKER

I was going to go with the portshielding route, but I don't seem to have the option. The NSA2400 is not the latest firmware (since the latest crippled our network). Currently on 5.0.2.10

Blue Street Tech

So you are one version behind?

You should still have PortShielding options! Can you send a screenshot of the PortShielding page?

hindsight

ASKER

Pretty sure the ability to portshield stopped with the 240s

hindsight

ASKER

Or rather the NSA2400 and greater do not have the option.

ASKER CERTIFIED SOLUTION

Blue Street Tech

membership

This solution is only available to members.

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

Start Free Trial

Blue Street Tech

Any update on this?

hindsight

ASKER

Sorry, didn't have a chance to get back to this. I'll be trying once again tomorrow and will let you know. Thanks!

Blue Street Tech

OK. Sounds good!

Blue Street Tech

I'm glad I could help and thanks for the points!

HungerMountain

Well, we had the same issue. And it does appear that it is not possible to directly set the IP address of the SonicPoints. HOWEVER, if getting rid of bridging doesn't work for you, it is important to know that you can influence which IPs the SonicPoints will grab. As you point out, the Management IP assigned to the SonicPoint has nothing to do with any DHCP setting, as far as we can see. In our case we WANT bridging so a wireless device can get a DHCP address in our LAN subnet and be able to authenticate on the domain, for example, a wireless laptop. We worked with SonicWALL tech support to set this up and didn't want to start all over, and don't know of another solution anyway.

The IP addresses allocated to SonicPoints is determined by the NUMBER of SonicPoints you tell the SonicWALL you have. Go to Network / Interfaces / WLAN Configure button. In the General tab see the "SonicPoint Limit:" dropdown list. Depending on the number of SonicPoints, the SonicWALL will assign IP addresses beginning with 255-X, where X=the number of Sonic Points you select. For example, although we expect to have only a maximum of 4 SonicPoints eventually, IP addresses 251-254 were inconveniently in use on our LAN. Selecting "16 SonicPoints" puts the first SonicPoint IP at .239. (255-16=239) The other two we currently have were assigned to IPs .240 and .241. If and when we purchase a fourth, we expect it to be assigned IP .242.

Hope this helps.