Wireless Access

I am attempting to have 2 guest WLANs with different authentication methods use one gre tunnel.  Currently I have a DMZ controller and several local/master controllers at sites. 

Each site currently has a WLAN using a gre tunnel to a DMZ controller using a captive portal web auth page.  This guest WLAN has rotating login credentials that our help desk can give out to guests as needed.  

A 2nd guest WLAN has been requested for certain approved guests that will be PSK auth.  The logic is this way a user’s machine can remember the WLAN network and they don’t have to bother with the web login every day….before you ask, I’ve already been there and this is what’s wanted.

The problem I’m having is that all traffic through the gre tunnel to the DMZ controller ends up being sent to the captive portal login page.  I want the new WLAN to authenticate via PSK only.  I can setup the 2nd WLAN but no matter what I try the traffic is forced to captive portal one joined.

Do I need to setup a 2nd tunnel for the new WLAN?  Will I need an additional VLAN to accomplish this since I can’t assign multiple IPs to one VLAN in the controller?

Thanks in advance.

If i understand correctly you are automatically redirected to the captive portal even on the new PSK guest SSID. Is this right?  If so,what is the role assigned to the users connecting to the PSK guest WLAN. If you are using the same AAA profile used for the original guest WLAN you will always be redirected to the captive portal page. Any user who authenticates to a PSK SSID is assigned the role specified in the initial role field of the AAA profile.  Make sure that the role assigned to the PSK guest users doesn't have the default captive portal policy  in it ( this predefined policy is called captiveportal ) and also ensure that there is no captive portal profile attached to this role.

Cause is role related it would seem, but perhaps simply due to the tunnel being 'untrusted' on one end of the link. 

If the untrust is on the DMZ controller side then we users are directed there (whether or not they have PSK'ed already) they will all get a pre-authentication role.  You can view this from the 'show user' output on the DMZ controller... have a look at the role on a PSK and a non-PSK guest and see if they are the same as a starting point.

A seperate tunnel with trust on both ends would facilitate a PSK enabled network to flow right 'through' without a captive portal.

The DMZ end of the tunnel is untrusted currently.  Could it be that it was designed this way on purpose to force all traffic coming in from the tunnel to use captive portal?  The captive portal page is served up from the DMZ controller, and the local controllers do not have captive portal configured at all, they just pass guest traffic to the tunnel.  If I trust the tunnel the existing captive portal WLAN just authenticates the user through the same as the PSK WLAN.

The clients do get the same role regardless of what I specify in the individual aaa profiles on the DMZ controller.  Could I trust both ends of the tunnel then configure captive portal on the specific WLAN on the local controllers?

Im hoping theres a way accomplish what Im trying to do without a major re-design or would that be best since the scope of the original design has changed so much?

Sure, you could move all authentication (whether its captive portal or PSK) onto the internal controller, and then once folks have supplied the proper credentials your PEF (Firewall) rules simply read:   "Redirect to tunnel xx " for all traffic to send down the (now trusted at both ends) tunnel.   

Thanks for your help, looks like Im going to be doing at least little redesigning.  You've definitely helped me to confirm my results and theories though.

This is definitely role related, do a show user and check the role you are getting for the machine using PSK and trace it back with the rules.