![\"clip_image001\"](\"https:\/\/thebeagle.itgroove.net\/wp-content\/uploads\/thebeagle\/2012\/07\/clip_image0012.png\" "\\"clip_image001\\"")
<\/a><\/p>\nExpand SonicPoint:<\/p>\n
This is an already configured SonicPoint so I’ll have to do a bit of deconstruction to set the stage.<\/p>\n 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:<\/p>\n And as you can see the profile indicates there is an active and operational SonicPoint operating on the profile.<\/p>\n 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.<\/p>\n As we know that we are using VAP’s on this profile we’ll go and look at the Virtual Access Point section.<\/p>\n Again, this is an already configured system so I’ll have to perform a bit of deconstruction.<\/p>\n 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.<\/p>\n CORP looks like this:<\/p>\n 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.<\/p>\n We do the same thing for GUEST:<\/p>\n 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.<\/p>\n This is what CORP looks like:<\/p>\n Note that the settings on the ADVANCED tab auto-filled because we selected our CORP profile that we created in the previous step.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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.<\/p>\n 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:<\/p>\n And just like on the CORP VAP, the ADVANCED screen picked up the profile settings from the GUEST profile we set up.<\/p>\n 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.<\/p>\n Configuring a VAPG is simple:<\/p>\n You just attach the VAP profiles you want and accept.<\/p>\n 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:<\/p>\n And here is what is in its configuration:<\/p>\n 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\u2019t have much to do with the networks.<\/p>\n 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).<\/p>\n 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.<\/p>\n 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):<\/p>\n Within our Firewall section we can see that there is a matrix of rules that covers traffic between the zones:<\/p>\n Clicking into the matrix we can see and set\/modify our desired rules.<\/p>\n So, from WLAN to LAN (this will be CORP wireless back into the LAN) we see the following:<\/p>\n 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:<\/p>\n However, when we look at the firewall rules for the Guest WLAN to the LAN we see the following:<\/p>\n 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:<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n