9800L - Guest WLAN - MAC Filtering / external site for WebAuth

[perrymcgrew]

9800L-F running 17.10.1.  We are moving off a 5508 running 8.5.182.105.   I can not seem to get the Guest WLAN to work on the 9800L.

On the 5508 Security Tab:

L2: MAC Filtering

L3: Web Policy, On MAC Filter failure

Preauth ACL:  is set to ACL that allows access to the web server's IP that has our https WebAuth page.

Override Global Config is checked.

Web Auth Type: External (redirect to external server)

Redirect URL: https:<webserver/login.aspx

AAA Servers: Authentication servers (Read Only DC and NPS) & Accounting server. 

I have just can't get the 9800 to even display the external web page.  I have the ACL defined etc.   I've been reading Configure and Troubleshoot External Web-Authentication on 9800 WLC - Cisco but have not found where the problem lies.   I've found that navigating the WebUI is like a walking through a house of mirrors!   Unfortunately, all I have to test Guest WLAN is an iPad. 

Thx

[Scott Fella]

First off, there is a translator on the Cisco site to help with conversion from AireOS to IOS-XE.  Hopefully you did this and understood what doesn't come over and what has.  As far as WebAuth, try the default and work your way to the custom.  You might have to download the 9800 custom webauths so that you can see the html code that is required.  I'm not 100% sure you can use the same webauth that you have used on AireOS.

[perrymcgrew]

I have used the AireOS translator for a reference.  Not the easiest output to go through and pick out the parts.  

We don't use the Cisco provided webauth bundle.  We redirect to the external webserver for the auth page.  Have not read anywhere that the 9800 required specific coding.  On the DCs we use soely for Guest, if the client's MAC address is entered as the ID and its PW, the client never sees the WebAuth page.  We do this to support the devices that can't display web pages and for certain external customers who need to access the Guest WLAN.  If the MAC address is not entered, that is where the L3's On MAC Filter Failure kicks in and displays the the WebAuth page.   We have a custom process that user calls the phone number displayed and is presented options. The end result is the system generates a ID/PW that the user then enters on the displayed WebAuth page to gain access to the Guest WLAN.

[Scott Fella]

Nothing is easy to read, but that is the additional effort folk have to go through when they plan on migrating from AireOS to the 9800's.  It's not the same so never expect it to work without making changes.  Also, there is specific coding for the reply to come back to the controller and that is why they supply templates for users to reference, modify or use.  You must of used this in AireOS and modified the html to your liking with the specific code required.  That is the same with the 9800's.  Anyway's I think you need to also look at any changes that might be required on your NPS and what logs do you see.  There are things that others might use like what @Flavio Miranda mentioned.

Maybe a good time to also open a TAC case.. I do see you have other questions on the forum also.

[perrymcgrew]

I'll look into @Flavio Miranda suggestion tomorrow.  The 9800 WLC config is obviously radically different than AIreOS.   My 1st time seeing it.  All my experience is with WiSM v1 up to the 5508 8.5 AireOS. Some of the 9800 config is easy.  Other screens not so much.  I just did not anticipate the Guest WLAN config to be "complicated" or possibly need changes to NPS which currently work with the 5508 Guest WLAN.  I may open a TAC case to see if they can help if I can't make any headway this week.

-Perry

[Flavio Miranda]

Hi

 The problem can be the apple device. Try to disable captive bypass portal.

Step 1	Choose Configuration > Security > Web Auth.
Step 2	In the Webauth Parameter Map tab, click the parameter map name. The Edit WebAuth Parameter window is displayed.
Step 3	Select Captive Bypass Portal check box.
Step 4	Click Update & Apply to Device.

[Rich R]

Have you done a radioactive trace and packet capture on the client to see where it's failing?
Also packet capture on all the web traffic and radius traffic.
Have you configured "aaa server radius dynamic-author" (with your radius IPs) to allow CoA requests from radius?
Make sure radius source IP and routing are as you expect - 9800 simply follows global routing table and uses outbound interface by default unless you explicitly configure the source.

[perrymcgrew]

Update -- I've spent entire afternoon with TAC.   He has not been able to figure it out either.   We took radioactive traces and checked logs in NPS.  We see the 9800L passing the MAC up to the NPS and the 9800L sees the MAC being sent.  

wncd_x_R0-0}{1}: [mab] [20719]: (info): [4c2e.b486.4bb7:capwap_90000005] MAB received an Access-Reject for 0x37000027 (4c2e.b486.4bb7)
2023/03/29 14:55:53.705239101 {wncd_x_R0-0}{1}: [errmsg] [20719]: (note): %MAB-5-FAIL: R0/0: wncd: Authentication failed for client (4c2e.b486.4bb7) with reason (Cred Fail) on Interface capwap_90000005 AuditSessionID FD03000A0000004F2EB9FD66

This needs to then display the custom Webauth Page we spec in the Redirect URL for login host on an external web server via On MAC Filter Failure

It's a bit frustrating as it was easy to setup in the 5508 AireOS and seems it should be straightforward here in the 9800 IOS-XE. 

[Scott Fella]

AireOS and IOS-XE are not the same. I too wish everything worked as is, but that is not the case. So the 9800 sends the info to NPS, NOS has logs to show accept or reject and a packet capture shows that info is coming back to the controller? The only thing I would check is if the controller is sending the information (MAC address) in the correct format that NPS is looking for and also what is being sent back.
TAC can alway lab this out without having to use NPS just to make sure the process is working.

[perrymcgrew]

Yeah.  The aireos to ios-xe converter spit out 1500 lines.  I have been going thru the AAA / Radius sections to see if there are differences.  In 9800 AAA Global config, the Radius Attributes match what is specified in the 5508.   MAC-Delimiter is hyphen.  NPS logs see the request and the radioactive trace shows the client info being sent to the NPS on the Domain Controller.  If the MAC address is in the DC as the userid/password, it should authenticate and NOT display the external WebAuth page.  I am testing with an iPad.  When trying to join the guest SSID on our production 5508, I get the WebAuth page as expected where I can enter our IT Dept "backdoor" ID/PW we use for testing.     Trying it on the 9800, I get an IP address but no external WebAuth page.   If I open a web browser and manually enter the URL, the page will display but the ID/PW Authentication does not work.

-Perry

[Rich R]

We've got it working fine on 17.6.4 and 17.9.3 so unless it's a new bug in 17.10.1 then it must be a mistake in your config.

Why did you use 17.10.1 - is there a feature you needed?  Otherwise you should stick to 17.9.x as it's the extended support release - maybe switch to 17.9.3 to be sure?

Maybe you can share a sanitised version of your full config (all relevant parts) to check?

So does the WLC send the redirect after it gets the MAC reject from NPS? (you've said what it should do, which we know,  but not what it did do)
What exactly happened after that?
Which point does it fail at?

[perrymcgrew]

the 9800L came in with 17.6.   We had AP join issues - one of the TAC suggestions was to upgrade the IOS.   I mentioned that we wanted to acquire some 9166 6e APs so he mentioned trying17.10.  The upgrade did not fix the AP problem anyway.  We just stayed on 17.10.  So far, TAC has not mentioned any bug relating to the External WebAuth.

I took the aireos-to-ios conversion output and searched for and did not find any "aaa server radius dynamic-author" stmts.  

We can see the MAC failure in the radioactive traces and can see the information in the NPS Event Logs.   The WebAuth page on the external WebServer just will not display.  It works perfectly on the 5508.  I'll see where we get today with TAC and will post logs etc here if we get no progress.  

Thx

-P

[Rich R]

17.9.3 supports the 916x APs:
 https://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html#c9800-ctr-ap_support

17.10 features - in case you require any of them: 
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-10/release-notes/rn-17-10-9800.html#Cisco_Concept.dita_602a09ee-0ce9-407a-b548-043c53fd8255

I'd recommend using 17.9.3 and stay on 17.9.x for now as 17.10 will not get any bug fixes.  When 17.12 is released start planning a move to that.

[perrymcgrew]

Update.  We finally got External WebAuth to work. It was a combination of the Pre-Auth ACL coding and having a Trustpoint which we stumbled over (re)reading a ton of docs.   Don't know why TAC missed this as they looked at all this during the many sessions of troubleshooting.

One hurdle seeming out of the way.

I next disconnected the PASSIVE 9800L to move it out of my office to its permanent location.   As soon as I disconnected it, the 3 associated APs "dropped off" the network -- LEDs started the red-green cycle.   After the PASSIVE member was reconnected, the show chassis listed both as "Prioroty 1".  The APs still were no longer associated.  I rebooted the entire system from the WebUI.  The 2 9115's joined the 9800L -- took longer than I expected.  But the 2802i took over 2 days (!!) before it re-joined the 9800.    I have 277 2802i's that will have to move from the 5508 over to the 9200 when we go into production.  

Side note -- the 9800L logs are filled with what appears to be bug CSCvt96686.  The MAC is the ACTIVE 9800L and Prime reports it trying to "communicate" with the current 5508 - which is on a completely separate, non-overlapping Mgt subnet.  

-PM

[Rich R]

CSCvt96686 is supposed to be fixed in 17.10.1
I still think you need to move to and extended support code train like 17.9

When you talk about passive and active presume you're referring to active and standby HA-SSO?
How did you "disconnect" it?
Removing standby shouldn't have any effect at all and even if you disconnected the active by mistake it should seamlessly switchover to standby.  You must have some other problem there because it should never take that long to join - are you sure the AP wasn't joining another controller?