Sonicwall Virtual Access Point (VAP) Configuration

I’ve been attending a Windows 8 "Beta Teach" course at Microsoft this week. At some point we were discussing wireless networking in class and I casually tossed out a comment about "Virtual Access Points" (VAP) which is something I’ve been dealing with in the Sonicwall world for some time now. My new friend and classmate — Travis Graham — asked what I meant by a VAP. I tried to get out to a Sonicwall so configured to show him but couldn’t (Microsoft won’t let us go just anywhere on their wireless network). This blog post is for Travis, and for anyone else interested in the whole idea of a VAP.

So, just what is a VAP anyway? In Sonicwall terms as VAP is a security profile and access point configuration that is overlaid on top of a physical Sonicpoint access point OR on top of the Sonicwall built-in access point on any Sonicwall "W" model which provides all of the connectivity (and security restrictions) of a physical access point. (Whew! Long sentence!!). A given Sonicwall or Sonicwall W model can support multiple VAP’s over the same physical hardware (the number varies according to the Sonicwall itself as well as the Sonicpoint model).

So, why would you want to use VAP’s? That’s a good question with a pretty straightforward answer — you want to provide multiple types of wireless connectivity, say GUEST and CORPORATE, that would normally be provided by multiple physical AP’s and multiple physical networks over a single Sonicpoint, group of Sonicpoints and/or the AP built into the Sonicwall W model. This is sort of the "buy one get one free" school of AP’s but why not? The stuff works and works well. And for those of you that aren’t in the Sonicwall world I’m fairly certain that a number of the other UTM (Unified Threat Management) firewall vendors as well as some of the networking vendors provide similar capabilities. My experience and expertise is with Sonicwall so I’ll stick with what I know for this post.

OK, so what do you need to construct a VAP? First off you need a Sonicwall/SonicPoint combination or a Sonicwall W model. For purposes of this post I’ll be focusing on Sonicpoints but the concepts are identical for the internal AP in the W models. A Sonicpoint is a Sonicwall-specific access point that requires a Sonicwall firewall in order to do any useful work. All Sonicpoints are initialized by and controlled from their parent Sonicwall firewall. A Sonicpoint without a parent Sonicwall firewall is just so much circuitry and plastic and about as useful as your average door stop. There are a few different types of Sonicpoints but they all work on the same basic principles so I won’t elaborate on their differences here.

Second, you need to design your wireless network and define what your various VAP’s are going to do (who is their user audience and what are the security constraints that are required by those audiences) so that you can then define "security profiles" for each VAP. We (itgroove) deal with lots of smaller companies and their usual profile requirement is what I mentioned earlier, they require on set of AP rules for CORPORATE and another for GUEST. In almost all cases the needs are pretty clear — CORPORATE will provide secured wireless access on the inside of the CORPORATE LAN for authorized corporate users while GUEST will provide Internet-only access on it’s own separate network segment (subnet) to guests within the office. At no point will the GUEST wireless network be granted access into the corporate LAN.

Obviously you need to decide on your security preferences (WPA-2 and so forth) for the two networks but that is no different from any other AP configuration.

OK, so now comes the fun part, the configuration!

Log into your Sonicwall and navigate to the Sonicpoint section:

Expand SonicPoint:

This is an already configured SonicPoint so I’ll have to do a bit of deconstruction to set the stage.

Within the SonicPoint section there are a number of settings that can be made. Within the SonicPoints section you can set up the top-level provisioning profiles for the types of SonicPoints that are or can be connected. The different models can have different provisioning profiles based on the ability of the model. In the case of this SonicPoint it is a SonicPoint Ni which takes its settings from the SonicPoint N provisioning profile:

And as you can see the profile indicates there is an active and operational SonicPoint operating on the profile.

The profile provisions the underlying physical SonicPoint so you will see an entry like the one above if you provision the SonicPoint as a simple physical access point OR if you provision with VAP’s. The general giveaway as to whether or not you are provisioned using VAP or physical is in the entry to the immediate right of the displayed IP address. If it is labeled simply as SSID then the SonicPoint is provisioned as a physical AP. If it is labelled as MSSID then it is provisioned with one or more VAP’s.

As we know that we are using VAP’s on this profile we’ll go and look at the Virtual Access Point section.

Again, this is an already configured system so I’ll have to perform a bit of deconstruction.

You actually start from the BOTTOM of the screen – Virtual Access Point Profiles — to start the build out of your VAP. In this case there are two profiles — CORP and GUEST — that do exactly what you would surmise; they set the security basics for each of our desired VAP’s.

CORP looks like this:

As you can see we set the Profile name, the authentication type, the ciphers , the max number of connected clients supported for this VAP, the security passphrase and the group key interval.

We do the same thing for GUEST:

Once these are set we move up the Virtual Access Point screen to Virtual Access Points. It is this section where we define the network characteristics we want for each VAP.

This is what CORP looks like:

Note that the settings on the ADVANCED tab auto-filled because we selected our CORP profile that we created in the previous step.

Now things start to get interesting. We have defined an SSID that we want for the CORP VAP and we have NOT selected a VLAN. This will mean that the VAP will use the base WLAN network subnet that has been defined on the Sonicwall itself. All SonicPoints MUST be connected to a network port on the parent Sonicwall that has been designated as being part of the WLAN zone (there can be multiple ports included in a Zone). The WLAN Zone will define a firewall boundary such that firewall rules are put in place between the WLAN zone and, say, the LAN zone. A picture is probably worth a thousand words at this point, here is a screen shot of the top-level network set up on the parent Sonicwall:

For those of you that have not seen networking on a Sonicwall before the names X0, X1 and so on identify physical ports on the unit. By default the X0 port is always on the LAN zone (so it is the local gateway on the LAN); the X1 port is always connected to the WAN (so it always has at least the primary WAN IP bound to it) and the other ports, X3 and up can be bound to whatever zone you want. In this case I elected to bind port X4 to the WLAN zone as that is the port to which the SonicPoint (or SonicPoint’s if you have more than one) is attached. The really interesting item on this screen is the entry X4:V2 that represents a VLAN that I have created off the same X4 port (VLAN 2 hence the V2 moniker). The VLAN is necessary as I need to have a separate subnet to use for the GUEST network as I don’t want CORP and GUEST traffic on the same wireless network as I want to create specific firewall rules for each of those networks. You could say that the physical network on the port is VLAN 0.

You should also know that Sonicwall will serve up DHCP addresses for the clients that connect on each VAP and that the IP address listed on this screen is the local GATEWAY address for the listed subnet. Therefore, the CORP VAP will end up with 192.168.10.1 as its gateway with a netmask of 255.255.255.0 while the GUEST VAP will end up with 10.0.0.1 as its gateway and a netmask of 255.255.255.0. The network addresses are totally arbitrary, BTW, pick whatever you want so long as they are PRIVATE.

Anyway, the point here is that I now have two separate networks that can be used by my VAP’s so my settings for the GUEST VAP will make use of my VLAN 2:

And just like on the CORP VAP, the ADVANCED screen picked up the profile settings from the GUEST profile we set up.

OK, we now have our two VAP profiles in place. Now we have to build a Virtual Access Point Group. A VAPG provides the mechanism to combine on or more VAP profiles into a working configuration that can be laid down over top of a physical SonicPoint. A VAPG can consist of one or more VAP profiles but you must configure at least one VAP profile into the group as it is the VAPG that gets laid down over top of the SonicPoint, you cannot overlay a profile itself.

Configuring a VAPG is simple:

You just attach the VAP profiles you want and accept.

OK, we have completed our VAP and VAPG configuration, now it’s time to overlay the VAPG on our physical SonicPoint. This is done from the SonicPoints section. In that section we will have an entry for the particular SonicPoint that we wish to provision with the VAPG. The provisioned entry looks as follows:

And here is what is in its configuration:

We have all of the settings we need to provision the VAPG in place. The first screen shows the physical network to the SonicPoint and as we did NOT choose a VLAN for CORP this is the network that is applied to CORP. We also define a VAPG as being applied (TM-VAP) so its settings will be overlaid as required. This means that we are also provisioning the VLAN2 subnet over this physical SONICPOINT. The rest of the settings on the 802.11n Radio and Advanced tab’s simply control the radio settings which are applied to the SonicPoint itself and really don’t have much to do with the networks.

At this point the VAPG is operational on the SonicPoint and there will be two, distinct wireless networks made available from the SonicPoint just as if there were two physical AP’s configured — one for CORP and one for GUEST. Browsing with a wireless enabled device will confirm the existence of both networks (VAP’s).

The final piece of the puzzle is to ensure that you have firewall rules in place to keep traffic where it is supposed to be.

If you think back to the earlier discussion about our network zones (and reference the screenshot) you’ll recall that I said that Zones setup the boundaries for firewall rules to be put in place. Traffic that traverses form one zone to another will pass through the firewall so we can control what traffic gets to where via firewall policies. You might also recall that we have the following Zones: LAN, WLAN, Guest WLAN and WAN (there are more but these are the ones that are germane to this discussion):

Within our Firewall section we can see that there is a matrix of rules that covers traffic between the zones:

Clicking into the matrix we can see and set/modify our desired rules.

So, from WLAN to LAN (this will be CORP wireless back into the LAN) we see the following:

We DENY any sort of SMTP traffic from a wireless client on CORP but allow any other traffic from CORP into our corporate LAN. We also allow WLAN to get out to the WAN (Internet) as follows:

However, when we look at the firewall rules for the Guest WLAN to the LAN we see the following:

Traffic from GUEST to the LAN is completely denied so there is no access available whatsoever to corporate LAN resources from the GUEST VAP. We do allow the GUEST VAP to access the Internet:

So, there you have it. We have used a single SonicPoint to provide two completely separate and firewalled wireless networks for concurrent use by corporate and guest users by configuring Virtual Access Points (VAP), combining the VAP’s into a Virtual Access Point Group (VAPG) and then applying the VAPG to a SonicPoint provisioning profile. A quick and elegant way to provide wireless connectivity to two VERY different user groups using one physical access point.

Travis, I hope you find this helpful (as I hope it is helpful to others out there). I think it provides an elegant solution to a problem that everyone faces in terms of providing secure access for corporate users while also providing access to your guests.