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 as its gateway with a netmask of while the GUEST VAP will end up with as its gateway and a netmask of 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.

11 responses to “Sonicwall Virtual Access Point (VAP) Configuration

  1. Do you need to configure the switch with the same vlan id’s you set in the sonicwall. I am trying to configure VAP’s on a NSA 2400. I see the SSID and when trying to connect, it shows as limited access and I get an ip of 169., so it doesn’t appear to be getting an IP from the internal Sonicwall DHCP server

  2. I’m assuming you mean you have put a switch downstream from the Sonicwall between it and the SonicPoint(s). If that is the case then, yes, the switch ports would need to pass through the VLAN tag from the Sonicwall. I’m also assuming that you have set VLAN’s on the Sonicwall because if you have not then there would be no need to set VLAN’s on the switch. The other thing to check is to ensure that the DHCP server on the Sonicwall has, in fact, been enabled for the specific wireless network. Normally, the DHCP server is given a basic configuration when you define the network on the interface (physical or VLAN) but it is not normally enabled by default. I know I’ve been caught by that one in the past and have spent more time than I’d care to admit to trying to find the problem only to discover that I hadn’t enabled DHCP. And, if all else fails, you can force the SonicPoint to reload all its settings, I’ve seen situations where everything is set properly on the Sonicwall and the SonicPoint screws up. Forcing a full reload usually fixes the problem.

    Hope this helps.

    1. I have the same problem as Gumartinez80. i cannot obtain an IP address from my NSA 240’s internal DHCP. However, the primary interface (X4) can, the sub-interfaces cannot.

      1. As I said in my previous reply to Gumartinez80, the VLAN’s have to be passed through all the way to the SonicPoints from the Sonicwall (in your case your NSA 240). So, as an example, I’m looking at a TZ215 that I have setup that supports multiple SonicPoints off the X6 interface. I have setup X6 as the “corporate” wireless LAN with network of 192.168.251.X and its gateway IP is I have created the guest wireless LAN as a VLAN on X6:V2 (I picked VLAN ID 2, yours might be different but the :V# has to match your selected VLAN ID) with the network of 192.168.127.X and its gateway IP is I have TWO DHCP scopes — a DYNAMIC scope on X6 passing out IP’s from to (completely arbitrary on my part) and a DYNAMIC scope on X6:V2 passing out similar number of IP’s from to Now, in this particular case, I have X5 and X4 PortShielded to X6 and the SonicPoints are connected directly to one of those three ports (PortShield creates a “mini-switch” internal to the Sonicwall). That means the VLAN is passed out across the three Sonicwall ports to the SonicPoints. However, I have another customer with a similar config but more SonicPoints and we only had one port available on the Sonicwall to handle the SonicPoints. It is set up the same way with the VLAN on the port and the Sonicwall port is connected to a switch as are the SonicPoints. The switch passes the VLAN traffic out to the SonicPoints because it honours the VLAN’s.

        So long as you have your config set up in a similar fashion AND you have confirmed that you have your DHCP scopes set up and properly (*and enabled, check each one) you should be good. One other thing to check is in your VAP setup. In the Virtual Access Point Group (top of screen in the Virtual Access Point settings) you add in the VAP’s into your groups. Each VAP in this section has a VLAN ID that has to be set. Make sure you set the VLAN ID here to match the :V# that you set for your network. If you don’s set it here then the VAP will not pick up the network and, by definition, you won’t get an IP on a wireless client that connects to the VAP.

        Let me know if you need more help.


        1. That’s what it was… The SonicPoints were connected via a Switch. Since there were only 3 AP’s I created a Portshield group on unused ports on the Sonicwall and connected the AP’s there. Thanks!

  3. Would it also be possible in this setup for the corporate wireless LAN to get an IP-adress from an external DHCP server and for the Guest wireless network to use the Sonicwall’s internal DHCP server?

    1. Hi, Alex:

      You bet! You simply do NOT set up (or enable) the Sonicwall DHCP server on the subnet configuration in the Sonicwall. So long as there is a DHCP server on the subnet in question it will all work the way you want. This is pretty standard practice if you are actually extending the corporate network via wireless.


  4. Is it possible to do the following:
    Add a terms of service splash screen to the guest network
    Limit the session length to 30 minutes (or some other number)

    -Thanks in Advance!

    1. You should be able to do all this via the Guest Services profiles. The basic idea is you “force” authentication at the firewall (it throws up a splash page) and the guest profile controls the lifetime of the session. To be fair, it has been about a million years since I set this kind of thing up so you are best to look at the Sonicwall KB’s for explicit instructions!


  5. Hi Robert,

    We have a NSA 2600 (main) and a TZ215w. The TZ215 is, essentially, dormant (emergency backup). Currently we have two CISCO wireless APs for corp wireless traffic, but we’d like to turn our TZ215w into an AP for a guest network. Separate IPs (via DHCP). Is this possible?



Comments are closed.