Inleiding
In dit document worden tips beschreven voor het oplossen van problemen met webverificatie in een WLC-omgeving (Wireless LAN Controller).
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
-
Controle en provisioning van draadloze toegangspunten (CAPWAP).
-
Hoe u Lightweight Access Point (LAP) en WLC configureert voor basisbediening.
-
Basiskennis van webverificatie en hoe webverificatie op WLC's te configureren.
Raadpleeg Webverificatieconfiguratie van de draadloze LAN-controller voor informatie over het configureren van webverificatie op WLC's.
Gebruikte componenten
De informatie in dit document is gebaseerd op een WLC 5500 waarop firmwareversie 8.3.121 wordt uitgevoerd.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Verwante producten
Dit document kan ook worden gebruikt met deze hardware:
-
Cisco 5500 Series wireless controllers
- Cisco 8500 Series wireless controllers
-
Cisco 2500 Series wireless controllers
-
Cisco Airespace WLAN-controller uit de 3500-reeks
-
Cisco Airespace 4000-reeks draadloze LAN-controller
-
Cisco Flex 7500-reeks draadloze controllers
-
Cisco Wireless Services Module 2 (WiSM2)
Webverificatie op WLC's
Webverificatie is een Layer 3-beveiligingsfunctie die ervoor zorgt dat de controller geen IP-verkeer toestaat, met uitzondering van DHCP-gerelateerde pakketten / DNS-gerelateerde pakketten van een bepaalde client totdat die client correct een geldige gebruikersnaam en wachtwoord heeft opgegeven, met uitzondering van verkeer dat is toegestaan via een toegangscontrolelijst (ACL). Webverificatie is het enige beveiligingsbeleid waarmee de client een IP-adres kan ophalen voordat de verificatie wordt uitgevoerd. Het is een eenvoudige authenticatiemethode zonder de noodzaak van een aanvrager of client utility. Webverificatie kan lokaal op een WLC of via een RADIUS-server worden uitgevoerd. Webverificatie wordt meestal gebruikt door klanten die een gasttoegangsnetwerk willen implementeren.
Webverificatie begint wanneer de controller het eerste TCP HTTP (poort 80) GET-pakket van de client onderschept. Om de webbrowser van de client zover te krijgen, moet de client eerst een IP-adres verkrijgen en een vertaling van de URL naar IP-adres (DNS-resolutie) voor de webbrowser uitvoeren. Hierdoor weet de webbrowser welk IP-adres de HTTP GET moet verzenden.
Wanneer webverificatie is geconfigureerd op het WLAN, blokkeert de controller al het verkeer (totdat het verificatieproces is voltooid) van de client, behalve voor DHCP- en DNS-verkeer. Wanneer de client de eerste HTTP GET naar TCP-poort 80 verzendt, stuurt de controller de client door naar https://192.0.2.1/login.html (als dit het virtuele IP is dat is geconfigureerd) voor verwerking. Dit proces brengt uiteindelijk de inlogpagina naar boven.
Opmerking: Wanneer u een externe webserver gebruikt voor webverificatie, hebben WLC-platforms een pre-authenticatie-ACL nodig voor de externe webserver.
In dit gedeelte wordt het proces voor het omleiden van webverificatie in detail uitgelegd.

-
Open de webbrowser en typ een URL in, bijvoorbeeld http://www.example.com. De client stuurt een DNS-verzoek voor deze URL om het IP-adres voor de bestemming te krijgen. WLC geeft het DNS-verzoek door aan de DNS-server en de DNS-server reageert terug met een DNS-antwoord, dat het IP-adres van de bestemming www.example.com bevat, dat op zijn beurt wordt doorgestuurd naar de draadloze clients.
-
De client probeert vervolgens een TCP-verbinding te openen met het IP-adres van de bestemming. Het verzendt een TCP SYN-pakket bestemd voor het IP-adres van www.example.com.
-
De WLC heeft regels geconfigureerd voor de client en kan dus fungeren als een proxy voor www.example.com. Het stuurt een TCP SYN-ACK pakket terug naar de client met als bron het IP-adres van www.example.com. De client verzendt een TCP ACK-pakket terug om de drievoudige TCP-handshake te voltooien en de TCP-verbinding is volledig tot stand gebracht.
-
De client verzendt een HTTP GET-pakket naar www.example.com. De WLC onderschept dit pakket en verzendt het voor omleidingsbehandeling. De HTTP-toepassingsgateway bereidt een HTML-body voor en stuurt deze terug als het antwoord op de HTTP GET die door de client is aangevraagd. Met deze HTML gaat de client naar de standaard webpagina-URL van de WLC, bijvoorbeeld http://<Virtual-Server-IP>/login.html.
-
De client sluit de TCP-verbinding met het IP-adres, bijvoorbeeld www.example.com.
-
Nu wil de client naar http://<virtualip>/login.html gaan en dus probeert hij een TCP-verbinding te openen met het virtuele IP-adres van de WLC. Het verzendt een TCP SYN-pakket voor 192.0.2.1 (wat hier ons virtuele IP is) naar de WLC.
-
De WLC reageert terug met een TCP SYN-ACK en de client stuurt een TCP ACK terug naar de WLC om de handshake te voltooien.
-
De client verzendt een HTTP GET voor /login.html bestemd voor 192.0.2.1 om de aanmeldingspagina op te vragen.
-
Dit verzoek is toegestaan tot de webserver van de WLC en de server reageert terug met de standaard aanmeldingspagina. De client ontvangt de aanmeldingspagina in het browservenster waar de gebruiker verder kan gaan en zich kan aanmelden.
In dit voorbeeld is het IP-adres van de client 192.168.68.94. De client heeft de URL opgelost naar de webserver waartoe hij toegang heeft gekregen, 10.1.0.13. Zoals u kunt zien, heeft de client de drieweg-handshake gedaan om de TCP-verbinding op te starten en vervolgens een HTTP GET-pakket verzonden dat begon met pakket 96 (00 is het HTTP-pakket). Dit werd niet geactiveerd door de gebruiker, maar was het besturingssysteem geautomatiseerde portal detectie triggers (zoals we kunnen raden van de gevraagde URL). De controller onderschept de pakketten en antwoordt met code 200. De code 200 pakket heeft een redirect URL in het:
<HTML><HEAD>
<TITLE> Web Authentication Redirect</TITLE>
<META http-equiv="Cache-control" content="no-cache">
<META http-equiv="Pragma" content="no-cache">
<META http-equiv="Expires" content="-1">
<META http-equiv="refresh" content="1; URL=https://192.0.2.1/login.html?redirect=http://captive.apple.com/hotspot-detect.html">
</HEAD></HTML>
Vervolgens sluit de TCP-verbinding via de drieweghandshake.
De client start vervolgens de HTTPS-verbinding met de redirect-URL die deze naar 192.0.2.1 stuurt, het virtuele IP-adres van de controller. De client moet het servercertificaat valideren of negeren om de SSL-tunnel te openen. In dit geval is het een zelf ondertekend certificaat, dus de klant negeerde het. De inlogpagina wordt verzonden via deze SSL-tunnel. Pakket 112 begint de transacties.

U hebt de mogelijkheid om de domeinnaam te configureren voor het virtuele IP-adres van de WLC. Als u de domeinnaam voor het virtuele IP-adres configureert, wordt deze domeinnaam teruggegeven in het HTTP OK-pakket van de controller als reactie op het HTTP GET-pakket van de client. U moet dan een DNS-resolutie uitvoeren voor deze domeinnaam. Zodra het een IP-adres krijgt van de DNS-resolutie, probeert het een TCP-sessie te openen met dat IP-adres, dat een IP-adres is dat is geconfigureerd op een virtuele interface van de controller.
Uiteindelijk wordt de webpagina door de tunnel naar de client gestuurd en stuurt de gebruiker de gebruikersnaam/het wachtwoord terug via de SSL-tunnel (Secure Sockets Layer).
Webverificatie wordt uitgevoerd op een van de volgende drie manieren:
-
Gebruik een interne webpagina (standaard).
-
Gebruik een aangepaste aanmeldingspagina.
-
Gebruik een aanmeldingspagina van een externe webserver.
Opmerkingen:
- De aangepaste webverificatiebundel bevat maximaal 30 tekens voor bestandsnamen. Zorg ervoor dat de bestandsnamen in de bundel niet meer dan 30 tekens bevatten.
- Vanaf WLC versie 7.0, als webverificatie is ingeschakeld op het WLAN en u ook CPU-ACL-regels hebt, hebben de clientgebaseerde webverificatieregels altijd voorrang zolang de client niet is geverifieerd in de status WebAuth_Reqd. Zodra de client naar de status RUN gaat, worden de ACL-regels van de CPU toegepast.
- Als CPU-ACL's zijn ingeschakeld in de WLC, is in deze omstandigheden een machtigingsregel voor de virtuele interface-IP vereist (in elke richting):
- Wanneer de CPU ACL geen ALL-regel voor beide richtingen heeft.
- Wanneer er een allow ALL-regel bestaat, maar er bestaat ook een DENY-regel voor poort 443 of 80 met een hogere prioriteit.
- De allow-regel voor het virtuele IP moet voor het TCP-protocol en poort 80 zijn als secureWeb is uitgeschakeld, of poort 443 als secureWeb is ingeschakeld. Dit is nodig om de toegang van de client tot het IP-adres van de virtuele interface mogelijk te maken na succesvolle verificatie wanneer CPU-ACL's zijn geïnstalleerd.
Problemen met webverificatie oplossen
Voer de volgende stappen uit nadat u webverificatie hebt geconfigureerd en als de functie niet werkt zoals verwacht:
- Controleer of de client een IP-adres krijgt. Als dit niet het geval is, kunnen gebruikers het selectievakje DHCP Required op het WLAN uitschakelen en de draadloze client een statisch IP-adres geven. Dit veronderstelt associatie met het toegangspunt.
- De volgende stap in het proces is DNS-resolutie van de URL in de webbrowser. Wanneer een WLAN-client verbinding maakt met een WLAN dat is geconfigureerd voor webverificatie, krijgt de client een IP-adres van de DHCP-server. De gebruiker opent een webbrowser en voert een webadres in. De client voert vervolgens de DNS-resolutie uit om het IP-adres van de website te verkrijgen. Wanneer de client de website probeert te bereiken, onderschept de WLC de HTTP GET-sessie van de client en leidt de gebruiker door naar de aanmeldingspagina voor webverificatie.
- Zorg er daarom voor dat de client DNS-resolutie kan uitvoeren voor de omleiding naar werk. Kies in Microsoft Windows Start > Uitvoeren, voer CMD in om een opdrachtvenster te openen en voer een nslookup www.cisco.com-opdracht uit en kijk of het IP-adres terugkomt.
Open in Macs/Linux een terminalvenster en voer een nslookup www.cisco.com-opdracht uit en kijk of het IP-adres terugkomt.
Als u denkt dat de client geen DNS-resolutie krijgt, kunt u ook:
Wanneer u deze URL invoert, wordt de webpagina dan weergegeven? Zo ja, dan is het waarschijnlijk een DNS probleem. Het kan ook een certificaatprobleem zijn. De controller gebruikt standaard een zelf ondertekend certificaat en de meeste webbrowsers waarschuwen voor het gebruik ervan.
- Controleer of de HTML-code voor de aangepaste webpagina geschikt is voor webverificatie met een aangepaste webpagina.
U kunt een voorbeeld van een webverificatiescript downloaden van Cisco Software Downloads. Kies voor de 5508-controllers bijvoorbeeld Producten > Draadloos > Draadloze LAN-controller > Zelfstandige controllers > Draadloze LAN-controllers uit de Cisco 5500-reeks > Draadloze LAN-controller uit de Cisco 5508-reeks > Software in chassis > Draadloze LAN-controller en download het bestand webauth_bundle.zip.
Deze parameters worden toegevoegd aan de URL wanneer de internetbrowser van de gebruiker wordt doorgestuurd naar de aangepaste aanmeldingspagina:
- ap_mac - Het MAC-adres van het toegangspunt waaraan de draadloze gebruiker is gekoppeld.
- switch_url - De URL van de controller waarop de gebruikersreferenties moeten worden geplaatst.
- omleiden - De URL waarnaar de gebruiker wordt omgeleid nadat de verificatie is voltooid.
- statusCode - De statuscode die wordt geretourneerd van de webverificatieserver van de controller.
- wlan - De WLAN-SSID waaraan de draadloze gebruiker is gekoppeld.
Dit zijn de beschikbare statuscodes:
- Statuscode 1 - U bent al ingelogd. Verdere actie van uw kant is niet nodig.
- Statuscode 2 - U bent niet geconfigureerd voor verificatie tegen webportaal. Verdere actie van uw kant is niet nodig.
- Statuscode 3 - De opgegeven gebruikersnaam kan momenteel niet worden gebruikt. Misschien is de gebruikersnaam al ingelogd op het systeem?
- Statuscode 4 - U bent uitgesloten.
- Statuscode 5 - De ingevoerde combinatie van gebruikersnaam en wachtwoord is ongeldig. Please try again.
- Alle bestanden en afbeeldingen die op de aangepaste webpagina moeten worden weergegeven, moeten worden gebundeld in een .tar-bestand voordat deze naar de WLC wordt geüpload. Zorg ervoor dat een van de bestanden in de .tar-bundel login.html is. U ontvangt deze foutmelding als u het bestand login.html niet opneemt:

Raadpleeg het gedeelte Richtlijnen voor aangepaste webverificatie van het voorbeeld van de webverificatie van de draadloze netwerkcontroller voor meer informatie over het maken van een aangepast webverificatievenster.
Opmerking: grote bestanden en bestanden met lange namen kunnen een extractiefout veroorzaken. Het wordt aanbevolen om afbeeldingen in .jpg-indeling te gebruiken.
- Zorg ervoor dat de optie Scripting niet wordt geblokkeerd in de clientbrowser, omdat de aangepaste webpagina op de WLC in principe een HTML-script is.
- Als u een hostnaam hebt geconfigureerd voor de virtuele interface van de WLC, moet u ervoor zorgen dat de DNS-resolutie beschikbaar is voor de hostnaam van de virtuele interface.
Opmerking: Navigeer naar het menu Controller > Interfaces van de WLC GUI om een DNS-hostnaam aan de virtuele interface toe te wijzen.
- Soms blokkeert de firewall die op de clientcomputer is geïnstalleerd de aanmeldingspagina voor webverificatie. Schakel de firewall uit voordat u de aanmeldingspagina probeert te openen. De firewall kan opnieuw worden ingeschakeld zodra de webverificatie is voltooid.
- De topologie/firewall van de oplossing kan tussen de client en de web-auth-server worden geplaatst, afhankelijk van het netwerk. Voor elk geïmplementeerd netwerkontwerp/oplossing moet de eindgebruiker ervoor zorgen dat deze poorten zijn toegestaan in de firewall van het netwerk.
Protocol |
Port |
HTTP/HTTPS-verkeer |
TCP-poort 80/443 |
CAPWAP Data/Control Traffic |
UDP-poort 5247/5246 |
LWAPP Data/Control Traffic (vóór rel 5.0) |
UDP-poort 12222/12223 |
EOIP-pakketten |
IP-protocol 97 |
mobiliteit |
UDP-poort 16666 (niet beveiligd) UDP-poort 16667 (beveiligde IPSEC-tunnel) |
- Om webverificatie te laten plaatsvinden, moet de client eerst koppelen aan het juiste WLAN op de WLC. Navigeer naar het menu Monitor > Clients op de WLC GUI om te zien of de client is gekoppeld aan de WLC. Controleer of de client een geldig IP-adres heeft.
- Schakel de proxyinstellingen in de clientbrowser uit totdat de webverificatie is voltooid.
- De standaardmethode voor webverificatie is PAP (Password Authentication Protocol). Zorg ervoor dat PAP-verificatie is toegestaan op de RADIUS-server zodat dit werkt. Controleer de foutopsporings- en logboekberichten van de RADIUS-server om de status van de clientverificatie te controleren. U kunt de opdracht debug aaa all op de WLC gebruiken om de debugs vanaf de RADIUS-server te bekijken.
- Werk het hardwarestuurprogramma op de computer bij met de nieuwste code van de website van de fabrikant.
- Controleer de instellingen in de aanvrager (programma op de laptop).
- Wanneer u de Windows Zero Config-aanvrager gebruikt die in Windows is ingebouwd:
- Controleer of de gebruiker de nieuwste patches heeft geïnstalleerd.
- Voer debugs uit op de aanvrager.
- Schakel op de client de EAPOL- (WPA+WPA2) en RASTLS-logs in vanuit een opdrachtvenster. Kies Start > Uitvoeren > CMD:
netsh ras set tracing eapol enable
netsh ras set tracing rastls enable
Om de logs uit te schakelen, voert u dezelfde opdracht uit, maar vervangt u Enable door Disable. Voor XP kunnen alle logs worden gevonden in C:\Windows\tracing.
- Als u nog steeds geen inlogpagina hebt, verzamelt en analyseert u deze uitvoer van één client:
debug client <mac_address in format xx:xx:xx:xx:xx:xx>
debug dhcp message enable
debug aaa all enable
debug dot1x aaa enable
debug mobility handoff enable
- Als het probleem niet is opgelost nadat u deze stappen hebt voltooid, verzamelt u deze foutmeldingen en gebruikt u Support Case Manager om een serviceaanvraag te openen.
debug pm ssh-appgw enable
debug pm ssh-tcp enable
debug pm rules enable
debug emweb server enable
debug pm ssh-engine enable packet <client ip>
Gerelateerde informatie