Allow access between Vlan's

[campus install]

We installed Cisco 1100 AP's in the lobby and cafeteria of a campus in upper Michigan. We would like the staff people to have access to our internal network and the internet. We would like the student to have access to the internet only. We installed the AP’s on the same vlan as the internet. Vlan’s were created on Dell 3348 switches. The internal network, with internet access rights, is on a different vlan. We have a Linux Free Radius installed for authentication. My question is does your product allow us to determine which vlan a user belongs on based on there login?

[alan]

Currently, FirstSpot does not aware of nor insert VLAN tag. The problem of segregating Intranet and Internet access based on FirstSpot user login is a frequently asked requirement so we would definitely like to explore more.

Can you give me a bit more details? What is your current network topology? Note that FirstSpot will act as a gateway, so the most probable solution is that FirstSpot will add a VLAN tag to all outgoing packets (based on user login) so that the switch behind FirstSpot will know how to give out the correct access right. Does this sound reasonable to you?
_________________
~ Patronsoft Limited ~

[TeQiE]

I'm sorry - having written all of this I realise its a little off topic but... and it's also a bit of a War and Peace effort but bear with it. Thanks.

As one thought, because this is something I am possibly planning to do, if you switches and APs support 802.1x port security, you can have the VLANs defined based on either the MAC address or the username, via a RADIUS authentication. Have a read up on 802.1x and Tunnel-Private-Group-ID; the following link runs you through both for MAC-based www.alliedtelesyn.com/datasheets/mac-based-auth_sd_a.pdf Windows XP and MAC OSX (some specific ver) also supports it.

VLAN tagging is something slightly different to VLAN participation. Tagging is where the frames are tagged with which vlan they belong to, and is typically used where you join 2 switches together, both running VLANs, you would only need to use 1 port on each to pass traffic for many VLANs between them. Typically devices (PCs, Printers etc) do not support tagging, and so are said to be 'untagged' in a specific VLAN. This means that they are a member of specified VLAN but that the port is not passing them tagged frames; I suspect that all of your device ports are currently untagged. You can only be untagged in ONE VLAN.

In order for a device to use tagged frames, the network card must support it. On the one instance that I saw this setup, the physical NIC was setup to accept packets on 3 VLANs, thus the port it was attached to was 'tagged' (ie passing tagged packets). The NIC presented virtual network cards and thus virtual LAN connections to Windows; Windows then thought we had 3 LAN connections, each with different IP addresses. You can be Tagged in several VLANs at once (not necessarily all), AND untagged in one (I think you can be untagged, anyway). Thus you will be able to communicate on the VLANs you are tagged for, if your network card is setup for this VLAN (i.e. looking out for frames tagged on that VLAN). If it is not set up and you make the switch port a tagged member of a VLAN, the NIC will just ignore the packets.

Now, what you want to do is have non-802.1Q (the Tagged VLAN standard) aware devices automatically be untagged in the correct VLAN, a process which generally requires either a MAC-based VLAN (which requires the MAC addresses of all devices and their associated VLANs to be defined on every switch), or a port-based VLAN which requires you to change the ports each time a user moves. The ideal situation would be to have a central database, like Active Directory, stating which users or MAC addresses are part of each VLAN - oh what do you know, Microsoft IAS server allows your switches to make RADIUS requests to do just that! :-)

Wirelessly, you would be looking for an AP that supports VLAN Tagging; this way you can put the AP onto a tagged VLAN switch and define each wireless client in whichever VLAN is correct; again within the contstraints of MAC-based, or RADIUS (802.1x) based. You could then put students in the 'public area' VLAN (the default VLAN, if you are extending access to visitors also), and staff in the 'campus' VLAN, for example. Firstspot can sit between these 2 VLANs, requiring login for students and visitors but not for staff; in fact staff will be able to access their home folders etc.

RADIUS based authentication CAN use or require a certificate authority, which is a bit of a pain, so consider it carefully and play with in the lab before going live.

Firstspot will not be able to determine or redirect users/devices to the correct VLAN as this is set at the switch, and by definition you would already have to BE in a VLAN if you can contact your Firstspot server. The 802.1x standard uses the switch as a proxy to the authentication server (RADIUS), thus your device, until authorised (and put in a VLAN, if supported/required) can only communicate with the switch. If no VLAN is returned, you are put in the default VLAN.

I hope that answers your questions, at least in part.

Now - the point of all that is this;
On the project I am planning, (which is a building split into several rented offices) I am planning to implement this 802.1x port security on the switches ( = users can plug into any LAN port in the building, and still be part of their own company LAN, e.g. in shared conference room) and am looking to extend this wirelessly. The setup is to include the option for Internet access. Some users will be permanent subscribers i.e. they rent an office, an want to access the Internet on a regular basis. Some will be regular visitors, and will want to access the Internet on an intermittent basis (maybe once a week?). Others will be visitors, and will only occasionally or once ever access the internet.

My questions are this;
I know V.3 does not support pass-through with accounting (i.e. MAC address on a list, automatically assumes you are user X and counts up data transfer on your account) - will V4 support something along these lines, for my permanent and semi-permanent users?

Will this extend to RADIUS users, or just in the local database? I am having to set up RADIUS anyway, seems easier to use it for everything.

Is there a limit on the number of 'multiple network segments' - so if I used the scenario descrbied above and had one virtual NIC in my firstspot server for each VLAN, how many virtual NICs can Firstspot handle? (It was an Intel Server net card I saw do this, by the way).

If the suggested RADIUS implementations are Microsoft IAS and Funk Steel Belted RADIUS server, are there any plans to have the self-signup work with either/both of these? I am pretty sure AD is easy enough to add users into...

For my 'permanent subscribers' is there any way of having Firstspot query the MAC address(es) of the client and passing these to the RADIUS server as both the username and password, as described in the MAC-based Authentication PDF above, thus the user is put onto the internet totally transparently when they plug in or connect? I suspect this will want to be a selectable option within FS as it will take up processor cycles on the client?

I hope this is not all too complicated.

Cheers
Jon

[alan]

Thank you for your comprehensive explanation on VLAN. We now have a much better understanding on your requirement.

One question though, as far as we know you cannot put a MAC address as password in IAS. IAS requires password to have number + alphabet + symbol, which the MAC address format does not satisfy this requirement.
_________________
~ Patronsoft Limited ~

[TeQiE]

That is a very good point - although I believe IAS is basically a RADIUS front end to Active Directory, so in fact the usernames and passwords are stored in Active Directory. This being the case, the complexity of the passwords would be based on the Password Policy settings in the Group Policy applying to the Active Directory domain in which IAS is operating (passing requests).

That is also why I mentioned self-signup integration with IAS, as Microsoft provide a whole programming model named ADSI for programmatically accessing the Active Directory.

But by default, you are correct, Windows enables a complex password requirement, but it can be turned off. If anyone needs help on this, let me know.

And I am not the same person who originally raised this post, I just thought I'd give him/her a hand and ask a couple more questions in the process :-)

Also - have you had any problems reported using Firstspot on Windows 2003 Server SP1? I tried it briefly and it blue-screened with IRQL_NOT_LESS_OR_EQUAL memory dumps, which is usually related to driver issues. But it is possible it was conflicting with the AD on the machine so further investigation would be required.

Thanks

[alan]

We probably won't support self-signup in RADIUS Authentication Mode as changing the directory is not part of the RADIUS protocol and this will require coding catering to individual RADIUS server.

We will address some other issues you mentioned shortly.
_________________
~ Patronsoft Limited ~

[alan]

We evaluate your opinion in details.

Note that we will have the feature "use MAC as username" in v4. However, this new feature won't support RADIUS Authentication Mode (i.e. only available in ODBC Authentication Mode). The reason is that:

1) due to internal login flow of FirstSpot, it is actually not easy to support this feature in RADIUS Authenetication Mode

2) if RADIUS is used, the user probably won't put MAC as username anyway

BTW, do you still have difficulty using 2003 SP1?
_________________
~ Patronsoft Limited ~