Cisco WLC Eksternal WebAuth Perilaku Acak yang Jelas


10

Pada Cisco 5508 v7.2.103.0, saya memiliki beberapa WLAN yang dikonfigurasi. Sebut mereka ABC dan XYZ demi pertanyaan ini. ABC menggunakan 802.1X dan mendorong URL pengalihan halaman splash. XYZ menggunakan PSK dan menggunakan konfigurasi eksternal WebAuth untuk mendorong URL pengalihan halaman login. Kedua halaman splash dan login disajikan di bawah basis yang sama (server web eksternal) URL seperti http://webauth.example.com/splash.html dan /login.html.

WLAN ABC - Splash-Page-Web-Redirect[WPA + WPA2][Auth(802.1X + CCKM)]
WLAN XYZ - Web-Passthrough[WPA2][Auth(PSK)]

Saya melihat perilaku yang tampaknya tidak konsisten saat URL pengalihan ditampilkan di perangkat, status webauth / NAC RUN, dan kemampuan untuk benar-benar mendapatkan akses Internet (atau tidak mendapatkannya saat saya seharusnya).

Saya mengerti bahwa halaman login memerlukan penerimaan (tidak perlu nama pengguna) sebelum mengizinkan lalu lintas untuk lewat dan WLC hanya harus berpikir bahwa halaman pembuka dilihat oleh perangkat (penerimaan tidak perlu) agar lalu lintas mengalir di sini.

Saya telah melihat hampir semua kondisi yang mungkin terjadi , tetapi kasus di mana arus lalu lintas tidak selalu masuk akal.

  1. Pengalihan Splash atau halaman Login terjadi saat menjelajah ke URL teks biasa yang tidak aman; webauth menunjukkan Diotentikasi dengan status NAC RUN, arus lalu lintas. Inilah yang diharapkan terjadi, tetapi tidak sering terjadi.
  2. Pengalihan Splash atau halaman Login tidak terjadi saat menjelajah ke URL teks biasa yang tidak aman; webauth menunjukkan Diotentikasi dengan status NAC RUN, arus lalu lintas (tetapi tidak seharusnya setelah menghapus klien dari WLC untuk memaksa pengalihan webauth yang tidak ditampilkan).
  3. Pengalihan Splash atau halaman Login tidak terjadi saat menjelajah ke URL teks biasa yang tidak aman; webauth tidak diautentikasi dengan status NAC WEBAUTH, arus lalu lintas (tetapi tidak boleh).
  4. Pengalihan Splash atau halaman Login terjadi saat menjelajah ke URL teks biasa yang tidak aman; webauth menunjukkan Tidak Diauthentikasi dengan status NAC WEBAUTH, lalu lintas tidak mengalir (tetapi harus jika WEBAUTH ditunjukkan saat berlalu).
  5. Pengalihan Splash atau halaman Login tidak terjadi saat menjelajah ke URL teks biasa yang tidak aman; webauth tidak diautentikasi dengan status NAC WEBAUTH, lalu lintas tidak mengalir (seperti yang diharapkan).

Dalam semua kasus, detail klien menunjukkan URL pengalihan diatur.
Dalam dua kasus di mana semuanya bekerja seperti yang diharapkan dengan redirect, webauth / run state, dan arus lalu lintas (diizinkan atau ditolak), saya tidak berpikir ACL adalah masalahnya. Tidak ada hal lain yang ditekan dari ACS selain dari redirect URL. Dua WLAN dikodekan ke VLAN yang berbeda.

Mungkinkah ini perilaku acak atau apakah mata saya hanya mempermainkan saya? Saya melihat perilaku yang sedikit berbeda dengan perangkat yang berbeda - beberapa lebih acak, beberapa kurang.

Apa pendekatan terbaik untuk mempersempit masalah ini?

Pembaruan : DNS bukan masalah. Jangkauan IP umum secara acak berfungsi di browser. Terlepas dari status webauth (RUN vs WEBAUTH-REQD), terkadang browser melewati dan terkadang tidak. (Permintaan awal selalu berupa HTTP teks biasa.) Saya bahkan pernah melihat traffic biasa untuk aplikasi non-web seperti SMTP, jadi saya benar-benar berpikir Webauth sedang mempermainkan ini, tapi saya tidak melihat ada yang jelas salah . Saya memiliki ACL preauth yang cukup liberal dan ACL tamu . Saya bahkan telah menambahkan izin apa pun kepada ACL yang tidak membuat perbedaan.


Saya akan memeriksanya, karena saya tahu bahwa beberapa instalasi telah menggunakan pengendali jangkar tamu untuk melakukan apa yang Anda inginkan. Saya juga tahu bahwa beberapa tempat saya mencoba menggunakan nirkabel dengan cara yang sama memiliki masalah yang sama. Kadang-kadang itu tidak mengarahkan, dan kadang-kadang itu hanya membuat saya aktif! Saya akan mengatakan ini masalah umum.
Artanix

WLAN ABC untuk karyawan dan menggunakan 802.1X. Hanya WLAN XYZ untuk tamu yang menggunakan PSK dan saat ini tidak ditambatkan ke pengontrol tamu. Saya telah melakukan tes dengan ACL preauth terbuka lebar dan masih mendapatkan perilaku acak yang sama.
generalnetworkerror

Apakah ada jawaban yang membantu Anda? jika demikian, Anda harus menerima jawabannya sehingga pertanyaan tidak terus muncul selamanya, mencari jawaban. Atau, Anda bisa memberikan dan menerima jawaban Anda sendiri.
Ron Maupin

Jawaban:


3

Saya telah melihat masalah serupa dua kali di masa lalu.

Pertama kali, itu berkaitan dengan resolusi DNS. Saya melakukan pencarian DNS pada klien yang mengalami masalah, dan menyadari bahwa klien tidak mampu menyelesaikan URL yang saya lewati untuk halaman login. Ini karena saya melewati server DNS eksternal. Periksa dulu. Saya mengatasinya dengan melewatkan IP di URL, meskipun Anda bisa membuat cname yang memutuskan ke 1.1.1.1.

Kedua kalinya, itu adalah masalah sertifikat. Beberapa browser default tidak akan menampilkan layar splash jika pengguna harus menerima sertifikat yang ditandatangani sendiri. Saya akan mengujinya dengan menjelajah secara manual ke layar splash atau halaman login dari klien yang tidak secara otomatis menampilkannya.

Semoga salah satu dari mereka membantu Anda keluar. Saya tahu bahwa saya siap mencabut rambut ketika saya melihat ini pertama kali.


Tolong jangan gunakan 1.1.1.1. Ini ruang alamat yang diiklankan yang valid . Saya tahu Cisco masih menggunakannya dalam contoh mereka, tetapi ketika Anda menggunakannya, Anda menyembunyikan sebagian ruang alamat Google.
LapTop006

Tampaknya perilaku acak untuk klien yang sama tanpa perubahan apa pun yang membunuh saya. Saya setuju dengan @ LapTop006 bahwa kita seharusnya tidak menggunakan 1.1.1.1. Saya menggunakan nama DNS yang memetakan ke addr pribadi / 32.
generalnetworkerror

@JD terunggah. Saya memegang karunia. Jika dia menerima jawaban saya akan memberikan hadiah di sana. Kalau tidak, Anda akan mendapatkan hadiah untuk usaha tersebut. : ^)
Craig Constantine
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.