C9800 WLC Web authentication DHCP DNS settings

[117222400]

Hi Experts,

About the Web Authentication on C9800 WLC, we are using 17.3.7 IOS XE . And created a DHCP pool on it for Guest user ( push 8.8.8.8 and 8.8.4.4 as DNS server). We also configured the Web Authentication (Captive Portal - Consent), https, and url guestwifi.xxx.com.

I went through carefully about the Web Auth instruction, and it seems there is nothing mentioned about DNS resolution for the url guestwifi.xxx.com to 192.0.2.1, just curious about how did the client resolve the url to the ip address.

I think it can't be solved from 8.8.8.8, and at the same time the client didn't pass the authentication, it couldn't contact with other DNS servers).

That's the scenario we meet at the production practise. We add the DHCP server's IP address as the third DNS server in the DHCP, and by capturing packets on the client, we can see the DHCP sever (WLC) did replied the DNS request (resolving guestwifi.xxx.com to 192.0.2.1)

Any suggestion about this? is it a right setting? 

Thanks very much.

[Rich R]

- Your pre-auth ACL should allow access to DHCP and DNS

- If you rely purely on internet (Google) DNS then you should use a publicly registered domain name, with a public IP which internet DNS will resolve for that domain name. All the Cisco guides say you shouldn't use public IPs but it's fine if it's an actual registered IP which you own and not routable to/from internet.  Your portal certificate must also match that registered domain name,  Otherwise you need to set up an internal DNS which you can use with 192.0.2.1.

[117222400]

Hi Rich,

Thank you very much for your reply.

1. I found it seems there is no pre-auth ACL assigned to the Guest WLAN's policy:

There is a preauth_v4 ACL as below, but it seems the default one, and didn't be used.

Does the setting mean that if the guest user didn't finish web-auth, all traffic will be blocked, including DNS request ? ( But DHCP ACK packet can be receive as the DHCP server is the SVI in the same VLAN , The client did receive the IP address).

2. I checked the guestwifi.xxx.com, it can be solved to 192.0.2.1, so I think using purely Google service should be good in our environment.

Thanks again and much appreciated.

George

[Rich R]

The WLAN ACL is a security/traffic filter ACL - applies to all traffic on the WLAN irrespective of auth state.

The pre-auth ACL is applied on the WLAN:  Configuration -> Tags & Profiles -> WLANs
Edit WLAN -> Security -> Layer3 -> Show Advanced Settings >>> Preauthentication ACL

Personally I don't use the GUI, only CLI, so it took a little while to work out where to find that!

[117222400]

Hi Rich

Thanks again for your reply, and I checked the Preauthentication ACL settings you mentioned in the WLAN, it is blank, which means no any pre-auth ACL applied.

Then, will all the traffic be blocked if the user didn't finish the Web Auth? If yes, maybe the user can't finish the authentication at all, because the captive portal: https://guestwifi.xxx.com can't be resolved to 192.0.2.1. ( needs to send to 8.8.8.8 for resolution.)

But the weird is, I did see the UDP 53 traffic from the client to 8.8.8.8 was allowed on the firewall's log, which means the traffic was not blocked.(Maybe that is the gateway's fault, the gateway is a Checkpoint firewall, not the SVI )

( A work around solution is to add the SVI as the DNS server in DHCP to resolve the captive portal for the client, or for mobile users, they can keep 4G connected to resolve it from 8.8.8.8)

Much appreciated for your reply.

George