Is there any way currently (or future road map) to have the ability to centralize guest wired access from a H-REAP AP across a layer 3 network?
Can we use the following example to clarify your question? (please modify as needed)
Let's say you have a controller with four WLANs.
#1 = "Jayhawk", which is centrally switched, and PEAP
#2 = "KU-Tickets", which is locally switched, and WPA-PSK for ticket scanners
#3 = "KU-Guest", which is a centrally switched guest network back to the anchor controller in the DMZ
#4 = Wired guest network. This is also centrally switched back to the anchor in the DMZ.. say VLAN 555
The H-REAP AP broadcasts three SSIDs:
One SSID is locally switched for whatever reason.
One SSID is centrally switched to the routed infrastructure.
The guest SSID is centrally switched, however the controller shoves it to the anchor in the DMZ.
The controller is tunneling VLAN 555 back to the DMZ controller.
The guest wireless network uses an AUP webauth bundle on the Anchor controller.
Can we go from here with the discussion?
It appears you are a Kansas fan and for that I am sorry .
In your example I've got a single port at the remote branch office that I'd like to run through the centralized controller (say Vlan 555) as the Guest Wired LAN network and AUP Authentication. Is this possible if the office is connected across a layer 3 network? In other words I'd like Vlan 50 (Wired Guest Network that's Local at the branch) to be tunneled to the Wireless Controller for AUP agreement.
Make Sense? Is this Possible?
Hi Craig ,
Currently we are not supporting the feature you have requested .
Follow these guidelines before using wired guest access on your network:
•Wired guest access is supported only on the following controllers: 5500 and 4400 series controllers, the Cisco WiSM, and the Catalyst 3750G Integrated Wireless LAN Controller Switch.
•Wired guest access interfaces must be tagged.
•Wired guest access ports must be in the same Layer 2 network as the foreign controller.
•Up to five wired guest access LANs can be configured on a controller.
•Layer 3 web authentication and web passthrough are supported for wired guest access clients. Layer 2 security is not supported.
•Do not attempt to trunk a guest VLAN on the Catalyst 3750G Integrated Wireless LAN Controller Switch to multiple controllers. Redundancy cannot be achieved by doing so.
This statement "Do not attempt to trunk a guest VLAN on the Catalyst 3750G Integrated
Wireless LAN Controller Switch to multiple controllers. Redundancy cannot be achieved by doing so."
What exactly is that saying?
Should that really read, "Do not attempt to trunk a guest VLAN on any Catalyst switch to multiple controllers. Redundancy cannot be achieved by doing so"?
I don't understand whtat the first statement says. If I did have a 3750G integrated switch, is it stating that you could not take two 3750G integrated switches and trunk them together for redundancy? If so, why does it specifically state the 3750G integrated swtich and not all switches in general.
Can you please clarify?
Thanks in advance!
Hi Tdennehy ,
As we have discussed previously (Post on 17- Jan),one of the changes requested as per of fixing the statement CSCtw44999 is to correct this statement in the document .
Where it says "Do not attempt to trunk a guest VLAN on the Catalyst 3750G ...", this should read: "Do not trunk a wired guest VLAN to multiple foreign controllers. This is not supported, and will generate unpredictable results."
HI Criag ,
To answer the question , I will need more details on what kind of design you are trying to accomplish .
Can you add more details .
Hi Craig .
We dont have this plan included in any of the future releases .
However we will take this as a ehancement request .Updates will follow
Is there a document with the specifications of the maximun number of guess access users that we support in the different WLC platforms and will also like to know how to manage the users from WCS?
Something I have always wondered is along the same lines as what Lisa asked.
Is there a way to carve a guest anchor controller up so that each controller that tunnels their guest users to it gets a specific range of IP addresses?
Reason I'm asking is many organizations are seeing an exponential increase in the number of guest users. If there was a way to abandon "everyone gets an IP address from this one pool" and carve up the anchor in the DMZ so that each site/controller that tunneled to it gets a specific range of IP address, that would be an awesome document. I would love any suggestions anyone has...
HI Tdennehy ,
You can check this link and let me know if this helps .
In current WLC architecture, it is mandatory to map the WLAN to an interface/VLAN. Default mapping is to management interface. The limitation is that one WLAN can be mapped to a single interface/VLAN. This limitation requires availability of a single large subnet, in dense deployments, which might not be feasible for many customers because of existing network design and IP subnet allocation in their network. Existing features, such as AP Groups
and AAA override, can help to some extent but cannot meet complete requirements and might not be feasible in all kinds of customer deployments. This same limitation also exists to the guest anchor setup where guest clients on remote locations always get an IP address from a single subnet mapped to the WLAN on anchor location. Also, the IP address assignment to wireless guest clients is not dependent on foreign locations and all guest clients on different foreign locations will receive an IP address from the same subnet. Once again, this is not feasible for many customers.
Integration of VLAN Pooling, or the VLAN Select feature, in the 188.8.131.52 release provides a solution to this restriction where the WLAN can be mapped to a single interface or multiple interfaces using interface group. Wireless clients associating to this WLAN will receive an IP address from a pool of subnets identified by the interfaces in round robin fashion.
This flowchart illustrates the DHCP address selection when the round robin mechanism is used in interface or interface group configuration:
Note: If the DHCP lease time is high, there is a possibility of DHCP IP leakage if the clients frequently de-authenticates and re-authenticates.
Note: With Inter-Release Controller Mobility (IRCM), controllers in releases before 184.108.40.206 cannot understand the VLAN list payload. Therefore, sometimes a L3 mobility is performed where L2 mobility could have been done.
Note: If you want to downgrade from the 220.127.116.11 release to a previous release, make sure that all WLANs are mapped to interfaces and not interface groups, and multicast interface is disabled.
Note: Cisco does not support an interface group being returned from AAA, only interface.
Note: Interfaces can be added to an interface group but cannot be deleted when it is mapped to the WLAN/AP Group.
Note: One VLAN or interface can be a part of many different interface groups.
The VLAN Select feature also extends current AP group and AAA override architecture where AP groups and AAA override can override the interface the WLAN is mapped to. This feature also provides the solution to guest anchor restrictions where now wireless guest user on foreign location can get an IP address from multiple subnets based on their foreign locations/foreign controllers from same Anchor WLC.
This flowchart indicates WLAN selection when AP group and AAA override are configured on the controller and WLAN has been mapped to an Interface or Interface Groups:
Hi Lisa ,
Welcome to the discussion .
The local database on the WLC stores entries for these items
Local management users (including lobby ambassadors)
Local network users (including guest users)
MAC filter entries
Exclusion list entries
Access point authorization list entries
The local user database is limited to a maximum of 2048 entries. The valid range is 512 to 2048, and the default setting is 2048. Together they cannot exceed the configured maximum value.
The database size can be configured using the WLC CLI or the GUI.
In order to configure the local database using the CLI, enter this command:
config database size
(Cisco Controller) >config database size ?
Enter the maximum number of entries (512-2048). Please save the configuration and reset the system ("reset system") for the change to take effect.
Regarding guest user management using WCS ,you can check this link .
You can use the Cisco Lobby Ambassador feature to create guest user accounts in WCS. A guest network provided by an enterprise allows access to the internet for a guest without compromising the security of the host. The web authentication is provided with or without a supplicant or client, so a guest needs to initiate a VPN tunnel to their desired destinations.
The system administrator must first set up a lobby administrator account, also known as a lobby ambassador account. A lobby ambassador account has limited configuration privileges and only allows access to the screens used to configure and manage guest user accounts. The lobby administrator has no access to online help.
This account allows a non-administrator to create and manage guest user accounts on WCS. The purpose of a guest user account is to provide a user account for a limited amount of time. The lobby ambassador is able to configure a specific time frame for the guest user account to be active. After the specified time period, the guest user account automatically expires. This section describes how a lobby ambassador can create and manage guest user accounts on WCS.
I hope this is the right place for this question as it is related to allow guest (i.e. limited) access to the network.
I have an SG300-20 here for testing (firmware: 18.104.22.168, boot version: 22.214.171.124, language version: 126.96.36.199 English). Everything seems to work on it, except, that if I choose Radius authentication by mac address only, then the switch does not honor the Idle-Timeout and Session-Timeout attributes from the Radius server (freeradius).
The setup is the following: I have a no name access point plugged in to switch port gi1 (I know this discussion is about wired net, but from the switch's point of view it is a wired access). The port gi1 is set up for Radius authentication by mac address only. The access point itself is authenticated, no problem with that. If I connect through the access point by (say) a mobile phone, it is authenticated, no problem. The radius server does send the Idle-Timeout and Session-Timeout attributes, I checked it by running "freeradius -X", both are set to 30 seconds. Then I turn off the wireless card in my mobile phone and check the dot1x users by "show dot1x users". My mobile phone's mac address remains there for 5-10 minutes, so the Idle-Timeout and Session-Timeout does not work.
Another way I could resolv this problem is by explicitely asking the switch to reauthenticate the user. Unfortunately there is no CLI command to do just that, I can do however a reauthentication on a port using "dot1x re-authenticate gi1" (for example). But it does not work as it is expected: the switch uses the stored mac-address to reauthenticate the user, so nothing changes on the port (unless something changes in the radius server). I think it should work like the following: remove the authenticated user from the port, and whenever that mac address makes some network traffic, then reauthenticate as if it were a completely new connection. BTW: it would help me also if I could just remove an authenticated user from a port, but I did not find a command to do that.
As a last resort I can simply shutdown the port, bring it up again ("shutdown" and "no shutdown" in the interface config), then all users are removed from the port and they all must reauthenticate. But it causes a network outage for a couple of seconds for all users on that port, on a busy access point it is quite disturbing, and it is not an elegant way to do this.
So my actual question is: is there a way to remove an authenticated user either automatically (Idle-Timeout and Session-Timeout) or manually from this switch?
I enclose the relevant part of the running config.
Thank you very much in advance.
interface range gi1-2
dot1x host-mode multi-sessions
interface vlan 3
interface range gi1-2
interface range gi1-2
dot1x mac-authentication mac-only
interface range gi1-2
dot1x radius-attributes vlan
interface range gi1-2
dot1x guest-vlan enable
dot1x port-control auto
dot1x port-control auto
radius-server host 192.168.33.195 key testing123 priority 1 usage dot1.x
aaa authentication dot1x default radius
Thank you for the reply.
I did a post in the "Small Business Switches" section (https://supportforums.cisco.com/thread/2128103), because it is not a problem with the wireless part (it was just easier for me to test it that way), but rather a problem of how the firmware handles radius reply attributes. But I am looking forward of any answers in any sections .