Clients can still access Internet while in Web Auth Pending state

[lawrence.allhands]

Running a WLC-9800-80 running Cisco IOS-XE 17.9.5 in my lab, testing Web Auth Redirect for a simple consent page (Not collecting any email or data) on our open guest network.

Clients can successfully connect to the guest WLAN and are presented the proper consent page while being placed in a "Web Auth Pending" state. If I click the accept button, client move to Run. So that all works properly. The problem I have is that while still in the Web Auth Pending state, my clients can reach the Internet successfully by opening another browser tab, pinging Internet addresses, etc. Is this expected behavior for a device on an open network? I have tested this with Windows 10/11 clients, Apple devices, and Linux PCs. All exhibit the same behavior. Windows actually shows that the device is connected without Internet access, yet it does have Internet access! 

Thanks in advance

[marce1000]

                       - FYI : https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu72447
    Regardless of the bug report , relevance w.r.t current ios-xe version used , from a support point of view ; it becomes more relevant if someone can repeat the problem on that version as you are observing and or testing it , 

 M.

[Jerome BERTHIER]

Hello

I assume that you use LWA with type consent. Right ?

Can you share your preauth ACL ?

Regards

[lawrence.allhands]

Correct. And I have the LWA address set to 192.168.199.199 for the test in my lab. Here is my pre-auth ACL

ip access-list extended utguest_preauth
10 permit ip any host 192.168.199.199
20 deny ip any any

[Jerome BERTHIER]

I think this is the point.

AireOS and IOS-XE WLC do not behave the same with preauth ACL :

- on AireOS, use deny statement to trigger redirect

- on IOS-XE, use permit statement to trigger redirect

So to my understanding, you ACL should be the opposite :

ip access-list extended utguest_preauth
10 deny ip any host 192.168.199.199

11 deny udp any host <your DNS resolver> eq 53

! not sure about these two next entries but you may have to open for DHCP. I don't know

12 deny udp any eq 68 any eq 67

13 deny udp any eq 67 any eq 68

! final permit to trigger for all traffic except previous entries
20 permit ip any any

Hope this helps

Regards

[lawrence.allhands]

Thanks for that - tried it and got the same results

[Jerome BERTHIER · Accepted solution]

OK so maybe you hit the bug pointed out by marce1000

Open a support case. That's the best way in your case.

Regards

[lawrence.allhands]

Yes I have a TAC case open. Thanks all!