Solution to your SonicPoint WLAN woes.admin | Saturday, February 12th, 2011 | 75 Comments »
I recently blogged an article on how to quickly and easily configure a SonicPoint with your SonicWALL firewall. If you haven’t read it, you can read it here before reading further. If you have read it, keep on reading!
Below is an example of a typical but small deployment utilizing a SonicPoint for wireless access.
As you can see, it’s pretty straight forward. Your LAN users are connected to the X0 port(LAN zone) and your SonicPoint is connected to the X6 port(WLAN zone).
This kind of scenario assumes that your firewall and SonicPoint are in close proximity with one another.
There are times where the firewall is in one location, but placement of the SonicPoint is well out of range of your firewall. Below are two scenarios where your Sonicpoint is in another location.
Scenario#1: In this scenario, the firewall is on the first floor while the SonicPoint is somewhere around the 5th floor. You only have one feed that is already connected to the LAN zone.
Scenario#2: In this scenario, the SonicPoint is in a completely different building!
I want to explain why this causes a problem with the SonicPoints. The SonicPoints need a direct connection to the WLAN zone. So if X6 is assigned to the WLAN zone, that means that your SonicPoint needs to connect to that port. If you’re on the 5th floor, or in another building, how can you connect to it?! You can’t run another cable from X6 all the way up to the 5th floor(well I suppose you can but it would be costly) or run another feed to the other building.(again, costly)
You may also think, why not just connect the SonicPoint to the same LAN zone as everyone else, can’t the SonicPoint just obtain an IP address from the LAN zone like everyone else and then broadcast its own wireless traffic? Nope!
SonicPoints use the SDP protocol. It’s a layer-2 broadcast that helps automatically provision SonicPoints. Here’s some info on how SDP works.
- Advertisement – SonicPoint devices without a peer will periodically and on startup announce or advertise themselves via a broadcast. The advertisement will include information that will be used by the receiving SonicOS device to ascertain the state of the SonicPoint. The SonicOS device will then report the state of all peered SonicPoints, and will take configuration actions as needed.
- Discovery – SonicOS devices will periodically send discovery request broadcasts to elicit responses from L2 connected SonicPoint units.
- Configure Directive – A unicast message from a SonicOS device to a specific SonicPoint unit to establish encryption keys for provisioning, and to set the parameters for and to engage configuration mode.
- Configure Acknowledgement – A unicast message from a SonicPoint to its peered SonicOS device acknowledging a Configure Directive.
- Keepalive – A unicast message from a SonicPoint to its peered SonicOS device used to validate the state of the SonicPoint.
So what is the solution when you only have one feed?
Up until SonicOS 5.6, only the NSA class series had the ability to create VLANs. Basically sub-interfaces, or virtual interfaces. With the new release of SonicOS 5.8, SonicWALL is now giving you access to VLAN’s on lower end firewalls, such as the TZ series. What this means is that you now have greater flexibility with your TZ series that once were only available to higher end models!
The trick is to create a new sub-interface off of X0.(LAN zone) But when you create this sub-interface you must assign it a separate VLAN ID and zone. The default VLAN is 1. So we can’t use that. So we’ll use VLAN 10(it can be any number lower than 4095). The zone will be WLAN! How can you have WLAN within the LAN zone?
The rules for SonicWALL zones is that a “zone” cannot be apart of two or more interfaces. So it can only belong to one interface. But by creating a sub-interface, SonicWALL treats the sub-interface as a virtual interface with all the same properties as a real physical interface. This means that the sub-interface can be a separate zone, effectively tricking the SonicWALL!
Check it out!
It doesn’t stop there though! You cannot just plug the SonicPoint into X0 port and expect it to work. The SonicPoint cannot form a trunk! If it can’t form a trunk, then only the default, native VLAN traffic can pass through, and that is VLAN 1, the LAN zone traffic. This means your SonicPoint will not automatically provision itself with SDP.
What you will now need to do is trunk your X0 port(LAN zone) to a switch that understands trunking. In my example, I use a Cisco 2960G switch. The 2960G switch only supports the 802.1Q protocol so it makes creating the trunk a lot easier.
Below I connect the X0 port on the SonicWALL firewall to the GigabitEthernet 0/1 port on the Cisco 2960G switch.
Configure the switchport for trunking and verify.
As you can see, G0/1 is now trunking with SonicWALL’s X0 port.
This means that now you can carry multiple VLAN traffic. The native VLAN and the newly created VLAN 10 are being carried to the Cisco 2960G switch. The final task is to now assign a switchport to VLAN 10 so that the SonicPoint can connect directly to it. Below, I assign GigabitEthernet port 20 to VLAN 10.
As soon as I connected the SonicPoint to port 20, it automatically provisioned and started broadcasting!
Notice what the interface says. It is seen as X0:V10. The X0 indicates the X0(LAN zone) and the V10 indicates your VLAN ID: 10, but the SonicPoint thinks it is connected to the WLAN zone because it doesn’t know any better!
Hope this offers you some ways to continue to use your SonicPoint(s) in your environment. For the multiple building scenario, it’s basically the same concept. Just make sure that the switches you are using to connect to one another are trunked, and that you assigned the proper port to the correct VLAN.
Comments and feedback are welcomed! Thanks again for reading!