VLAN for Secure WiFi  

Recently, we implemented wireless LAN in our head office's conference rooms. We wanted to make the office's wired network and the Internet available to our visiting branch-office employees, and the Internet (but not the office network) to any outside guests. 

One way of granting network access on the basis of users' identities is to know their wireless cards' MAC addresses. But, this poses two problems. One, though we could have found out the MAC addresses of our employees, it would have been difficult to do so for each visitor. Two, with MAC-based filtering, users are either allowed complete access or no access; there is no provision for giving access to different users to different parts of the network. So, we resolved the issue by setting up Virtual LANs or

VLANs. 

A VLAN is a logically segmented network mapped over physical hardware. It is like breaking the switched network into parts and creating separate Virtual LANs over a single physical LAN. Machines in a particular VLAN can communicate with machines in that VLAN only and not with machines in other VLANs. Inter-VLAN communication is possible through a router or through layer 3 switching. However, a particular machine can be a part of more than one VLAN, making it talk to all the VLANs of which it is a part. But, this doesn't mean that it can facilitate

inter-VLAN communication.

VLANs can be configured in several ways on the basis of switch ports, MAC addresses, IP addresses, IP subnets and even a mix of all these. Having said that, let's come to the solution that we adopted. 

Denying guests access to the wired LAN



The prerequisite here is a manageable switch that supports configuring VLANs on the basis of a mix of its ports and end stations' MAC addresses.

We have a 24-port manageable Intel 510T switch. The access point is connected to port 13 of the switch, while the gateway, DHCP server, mail server and the file server are connected to ports one to four, respectively. User machines acquire the rest of the ports. Our switch has a default VLAN that includes all ports of the switch to enable communication among them. To configure the switch for security, we followed the following steps.

• First, we removed the port (port 13, in our case) to which the access point was connected from the default VLAN. This stops all communication between the wired and wireless machines, in effect cutting out the wireless machines from the wired network. 
• Next, we reconfigured the default VLAN and made the MAC addresses of trusted users a part of the default VLAN. This way, though the access-point port on the switch is disconnected from the default VLAN, the users whose MAC addresses are a part of the default VLAN can communicate with the rest of the machines in that VLAN. This happens because once the switch determines that a particular MAC is a part of a VLAN, it does not care to which port it is connected. Hence, in our case, port 13 is not a part of the default VLAN. But, data coming from the MAC addresses listed in the default VLAN can easily flow to and from port 13 to other machines in the VLAN. The fact that data from
  
  these MAC addresses is coming and going out of port 13 is now immaterial for the listed MAC addresses. 

Now, if a guest whose MAC address is not a part of the default VLAN connects wirelessly to the access point to access other machines on the VLAN, the switch, on finding that its MAC address is not a part of the default VLAN, will check the port it is connected to. That port will be port 13 as the guest is connected via the access point, which is connected to port 13 of the switch. Since port 13 is not a part of the default VLAN, the switch will not allow it to send and receive data on this

VLAN. 

This way, while employees can access the full network, guests can't access any part of it. But, how can guests access the Internet? Read on.

Add the MAC addresses of trusted users in the default VLAN on the switch

Providing guests Internet access 



For this, guests will need access to the gateway and the DHCP server to get dynamic IP addresses. For that we created a second VLAN called 'guest' VLAN. Then we added port 13 , the port of the gateway, port 1, and the port of the DHCP server, port 2, to this VLAN. In such a situation, when a guest connects to the access point and tries to access the wired network, the switch will check which VLAN it is a part of. The guest machine is certainly not a part of the default VLAN (as explained above), but as it's connected to port 13 via the access point it certainly is a part of the 'guest' VLAN. Because of this, it can access the DHCP server to get an IP address and connect to the gateway to access the Internet. This way guests can connect to the gateway and the DHCP server but not to any other machine, as those are not a part of the 'guest'

VLAN. 

This way, all trusted users will be resolved to be a part of the default VLAN and can access the entire network. Guests, however, will be resolved as a part of 'guest' VLAN and can access only the DHCP server and the gateway. One thing to remember here is that when you make port 1 and 2 a part of the 'guest' VLAN, they should also remain a part of the default VLAN, that is, the gateway and the DHCP server have to be in both the VLANs. Also, remember the fact that having some machines as a part of two VLANs does not mean they can allow communication between the two

VLANs.

While the above solution can provide a high level of security to your network, there is nothing like complete security. For example, our solution can be easily fooled by MAC-address spoofing. But, then our solution is for people like you and me, who don't expect rogue visitors coming in to our meeting rooms.

Anoop Mangla