06-05-2023 07:24 AM
Hello everyone,
I'm having troubles writing a proper pre.auth ACL for our guest portal.
We use a custom HTML page with a script that sends 1812 authotrizations to a radius server.
Now, with a "free-for-all" ACL where I open every TCP port towards any address, it works fine; but when trying to reverse-engineer the ports needed I find myself unable to do so.
I get the correct IP address from DHCP, and while in the pre-auth phase I am able to resolve the DNS of the captiveportal (it is a public DNS). But then I am unable to navigate to the portal.
so far my ACL looks like this :
======
ip access-list extended Test2_Guest_WGA
5 permit udp any any eq domain
6 permit tcp any any eq domain
7 permit tcp any eq domain any
8 permit udp any eq domain any
10 permit tcp any any eq www
15 permit tcp any eq www any
20 permit tcp any any eq 443
25 permit tcp any eq 443 any
30 permit icmp any any
I thought that permitting any 80/443 traffic would have been enough, but it clearly isn't.
now with this completely open ACL made for tests of course the web portal is reachable, so I think the other pieces of the config are working and the issue lies in the ACL
======
ip access-list extended Test_Guest_WGA
10 permit tcp any any
20 permit udp any any
30 permit icmp any any
here's the webauth config
parameter-map type webauth global
type webauth
sleeping-client timeout 7200
virtual-ip ipv4 192.0.2.1 virtual-host captiveportal2.reti.it
custom-page login device bootflash:/bundle_20230524_new/login.html
trustpoint WLC_9800_WLC_TP
can anyone help me understand what is needed in the preauth ACL?
Thanks in advance
Fabio
06-05-2023 04:18 PM
Hi
it is interesting that the second ACL works because usually for guest we need to deny those traffic that need to be redirected. Cisco call it punt ACL. And we permit traffic that run on the data plane which is internet traffic
"Note: For the redirection ACL, think of the deny
action as a deny redirection (not deny traffic) and the permit
action as permit redirection. The WLC only looks into traffic that it can redirect (ports 80 and 443 by default)."
06-06-2023 05:46 AM
I do not know I was able to correctly explain myself.
The idea is that all traffic gets denied until you complete web authentication; after authenticating, you are allowed http/https traffic towards internet.
The only things that I need to allow pre-authentication are the captive portal and the credential self-request portal in our internal DMZ.
A good starting point for me would be understanding why a captive portal on 192.0.2.1 is reachable when you apply the "Open" ACL (called "Test_Guest_WGA") and not applying the "Test2_Guest_WGA".
If there's any test someone might suggest, or further config pieces I need to provide to help in the analysis... any advice would be greatly appreciated.
Thanks
06-06-2023 03:35 PM
Check your config with https://cway.cisco.com/wireless-config-analyzer/ using output of "show tech wireless"
Check out https://wifininjas.net/2019/10/24/wn-blog-017-cisco-c9800-local-web-auth-config/
and https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKEWN-2014.pdf
As Flavio said your pre-auth ACL is purely to allow access to DHCP, DNS and captive portal and any other resource required for login. Also remember you should add your portal URLs to the URL list.
Presume you're using up to date code version like 17.6.5 or 17.9.3 - refer to TAC recommended below.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide