4402 change VLAN/interface on web auth

[rafamiga12]

Is there any way to change/assign a VLAN/interface combo to web-auth'ed node? From what read, Cisco's NAC appliance can do it using SNMP but it seems it's an undocumented feature, proprietary to Cisco. Reading MIBs doesn't help -- AIRESPACE-WIRELESS-MIB.mib doesn't define a way to do it and 4402 does not implement CISCO-VLAN-MEMBERSHIP-MIB.mib.

What I'm trying to achieve is to be able to assign diffrent VLANs for users using web authentication mechanism. I've tried to pass VLAN information in the reply to web-auth request to Radius [by setting all the required attributes, namely Tunnel-Medium-Type, Tunnel-Type, Tunnel-Private-Group-ID, Airespace-Interface-Name, Airespace-Wlan-Id] but the 4402 ignores this [although it honours these attributes when doint 802.1x but that's not the solution I'm looking for].

Ideally, web-auth users will be assigned an "isolation" VLAN, where they can only access the controller authentication form and a local info-portal. If they authorize, by default they will be assigned a VLAN with limited internet access but those who use an one-time-password access should be assigned a different VLAN with some access to internal systems.

I've read the sample configuration examples, including "Guest WLAN and Internal WLAN using WLCs Configuration Example" but they doesn't really fit my securirty requirements because a node in WEBAUTH_REQD state can still access DNS and besides that, I need at least two access levels there, for two groups of users, most of which won't have a supplicant installed to be able to do WPA2/802.1x [I've implemented this access mode with no problems].

[Tiago Antunes]

Hi Rafal,

Wireless WEB Auth security mode does not support VLAN assignement.

To achieve that you have to use a L2 auth method that uses RADIUS authentication, like WPA or WPA2 with 802.1x.

HTH,

Tiago

--

If  this helps you and/or answers your question please mark the question as  "answered" and/or rate it, so other users can easily find it.

[rafamiga12]

I know, I've configured WPA2/802.1x and it works allright.

But I need guest/frast internet access with no supplicant installed and WPA2/802.1x is no option since it forces users to tweak their (WLAN/network/certificate) settings first.

I could implement WPA2/802.1x guest access, I'm using Packetefence wchich handles this task very well, but Windows-based computers fail to accept self-signed certificate (with extensions) to use it to set up TTLS part of PEAP sesion. OK, nice and subtle way of forcing users to pay $350/yr for a "wireless certificate" which is nothing more than a simple $50 certificate but with extensions addedd.

So I decided to go with open SSID and web auth.

[Tiago Antunes]

Then it looks like you reach to a dead end...

Wireless WEB AUTH security mode in WLC simply does not support VLAN assignment...

HTH,

Tiago

--

If  this helps you and/or answers your question please mark the question as  "answered" and/or rate it, so other users can easily find it.

[rafamiga12]

OK, but what will suit me is to prevent users access real-world DNS servers before they authenticate. This way I can define several WLANs with the same web auth radius database but diffrent access rights. But it seems pre-auth ACL does not allow to prevent DNS access and this really sucks, security-wise.

[Tiago Antunes]

I guess you are missing the concept of WEB auth.

DNS traffic is a MUST in web auth.

The way WEB Auth works is the following:

1 - Client associates.

2 - Client gets IP address.

3 - Opens Web browser.

4 - User types url.

5 - PC needs to resolve URL using DNS.

6 - After getting the IP address of host in URL, it send HTTP traffic.

7 - WLC intercepts HTTP traffic and redirects client to the login page.

Now, WLC will only redirect the client to the login page if it "sees" HTTP traffic from th eclient IP address.

If you open a browser and type an URL, if it cannot be resolved, the client will never know the ip address and will never know wehre to send the HTTP packets, and will not be redirected to the login page.

If there is no DNS traffic allowed, the only way to get to the login page is if the clients try to access an URL based on ip address rather than hostname like for example:  http://66.102.13.105 instead of http://www.google.com.

HTH,

Tiago

--

If  this helps you and/or answers your question please mark the question as  "answered" and/or rate it, so other users can easily find it.

[rafamiga12]

Not really. I know DNS is required for web auth to intercept user's request. It wouldn't be any traffic if there was no DNS available.

But enabling users to communicate using DNS protocol [53/udp] before they authenticate opens a security hole, where you can bypass the authorization requirement and create a "small-but-efficient" tunnel between your node and a speciailly configured DNS server on the net. This way you wouldn't see any abnormal traffic passing and yet, hacking/bypassing could be perfomed easily.

Just take look at http://www.dnstunnel.de/. Even script kiddies can bypass web auth with no DNS filtering.

So I decided to pass three nameservers in DHCP OFFER packets. The first two are actual DNS servers but they are disabled by pre-auth rule, and the third one is a "fake" DNS which returns the same IP for every request, with TTL set to 0 so nodes won't cache the "fake" answers.

When an user is authenticated, the pre-auth ACL disappears and the two nameservers start to deliver replies to the client. Nodes never query the third one unless both "real" nameservers go down.

But for some reason, the controller is allowing DNS traffic despite me putting a "deny" rule in pre-auth which completly invalidates the idea of authorising an acces. I wouldn't mind if the "default deny" rule would allow DNS, but implicit "deny DNS requests to DHCP nameservers" rule gets overriden by controller, which is a very bad idea -- as an administrator if I put such a rule I know what I'm trying to achieve and 4402 shouldn't try to be smarter.

[Tiago Antunes]

Ok, then your config makes sense and the pre-auth ACL should work.

Here is an example of ACLs in the WLC in case you want to make you did it properly:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00807810d1.shtml.

If you want we can take a look into the config and assist you on the configuration.

Another option is to open a SR if you believe the WLC is behaving not as expected.

HTH,

Tiago

--

If  this helps you and/or answers your question please mark the question as  "answered" and/or rate it, so other users can easily find it.