[MEGOLDVA] FreeRADIUS supplicant problema

Hálózati eszközök

Van egy FreeRADIUS szerver, amiben gyoker-, koztes- es szervertanusitvanyok vannak.
EAP-TLS-sel csatlakoznek hozza Linux alol (Arch+KDE+NetworkManager), de nam adja magat.
A tanusitvanyok jok, FreeRADIUS jo. (Win7, WinMobile, Android gond nelkul csatlakoznak)

Mikor Linuxrol probalok csatlakozni egy ilyet dob a log:

EAP-TLS packet will contain more data than we can process

A tanusitvanyok: SHA256 2048b.

Gyanitom, hogy a supplicant noveli meg a TLS csatornaba kuldendo adat mennyiseget, csak nem ertem, hogy miert es hogy.

Talalkozott valaki esetleg ezzel a jelenseggel es megoldasa is lenne ra?

Megoldas:
NetworkManager feluleten ketfele keppen adhato meg a tanusitvany-kulcs/tanusitvany-tanusitvany-kulcs duo-/triumviratus.
1. User tanusitvany URES
2. CA, a CA tanusitvany
3. Kulcs, a p12 fajl

valamint
1. User, a felhasznaloi tanusitvany (PEM/DER)
2. CA, a CA tanusitvany
3. Kulcs, a felhasznaloi kulcs (PEM/DER)

Es a masodik esettel mukodik...

  • 4481 megtekintés

( uid_7086 | 2013. 12. 08., v – 15:29 )

Első menetben - ha megoldható - próbáld radiusd -XX formában indítani, akkor talán mond valami bővebbet is, hogy valójában mi baja!

Egyébként egy olyan tippem van még, hogy az eap.conf-ban a fragment_size értéke nem felel meg a felette lévő kommentben található leírásnak. (bár ez könnyen lehet, hogy hülyeség)

Illetve amit még kipróbálnék, hogy EAP-TLS helyett mondjuk EAP-TTLS + MSCHAPv2-vel működik-e?

Update: http://lists.freeradius.org/pipermail/freeradius-users/2007-May/019161… - ebben is lehet valami... Linuxos wpa_supplicant anno nekem is okozott gondokat. :(
(érdekes, hogy a freebsd-s elsőre indult, gond nélkül)

A hibat a
freeradius -XX
kimenetebol masoltam ide.

a fragment size ertekenek jonak kell lennie, hiszen a Win7, WinMobile, Android csatlakozik hozza. (raadasul szerver tanusitvany validacioval)
ebbol kifolyolag az EAP-TLS is jo.

Megneztem a linket, amit irtal; ott is csak a problemarol irnak es semmi javaslat a megoldasra/megkerulesre.

Hm. Ennyire szűkszavú üzeneteket a radius.log-ban szoktam látni, a -XX kimenete időnként mond is valamit.

A TTLS-t csak azért javasoltam, jelszavas authentikációval megfejelve, mert azzal legalább azt kizárhatod, hogy a kliens tanúsítványával van esetleg gond. (nekem pár éve, még 1.x vagy annál is korábbi radius esetében úgy emlékszem, kellett valamit variálni a tanúsítványokkal, hogy használni tudjam őket a radius-szal)

Kert kiement:

Sun Dec 8 16:05:41 2013 : Info: [eap] Request found, released from the list
Sun Dec 8 16:05:41 2013 : Info: [eap] EAP/tls
Sun Dec 8 16:05:41 2013 : Info: [eap] processing type tls
Sun Dec 8 16:05:41 2013 : Info: [tls] Authenticate
Sun Dec 8 16:05:41 2013 : Info: [tls] processing EAP-TLS
Sun Dec 8 16:05:41 2013 : Debug: TLS Length 37075
Sun Dec 8 16:05:41 2013 : Info: [tls] Received EAP-TLS First Fragment of the message
Sun Dec 8 16:05:41 2013 : Info: [tls] eaptls_verify returned 9
Sun Dec 8 16:05:41 2013 : Info: [tls] The EAP-TLS packet will contain more data than we can process.
Sun Dec 8 16:05:41 2013 : Info: [tls] eaptls_process returned 4
Sun Dec 8 16:05:41 2013 : Info: [eap] Handler failed in EAP/tls
Sun Dec 8 16:05:41 2013 : Info: [eap] Failed in EAP select
Sun Dec 8 16:05:41 2013 : Info: ++[eap] returns invalid
Sun Dec 8 16:05:41 2013 : Info: Failed to authenticate the user.
Sun Dec 8 16:05:41 2013 : Auth: Login incorrect: [balu/] (from client eaptls port 0 cli 6C-71-D9-78-B4-9B)
Sun Dec 8 16:05:41 2013 : Info: Delaying reject of request 71 for 1 seconds
Sun Dec 8 16:05:41 2013 : Debug: Going to the next request

A klienstanusitvanyokkal sem lehet sok gond, ha minden massal mukodik csak wpa_supplicanttel nem

Ez nagyon jo otletnek tunik; mar csak azt kene valahogy kideritenem, hogy hogyan adjam be a NetworkManagernek, hogy hasznalja ezt az opciot.
A NetworkManager indit egy wpa_supplicantet, de igy: wpa_supplicant -u
vagyis DBUS controllal.
Ebben tudnal esetleg segiteni?

Kiprobaltam NetworkManager nelkul csak wpa_supplicanttel. Termeszetesen mukodik.
Ugy latszik kell az a phase1="include_tls_length=1" opcio.
Lenyeg a lenyeg, hogy megy

wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
eapol_version=1
ap_scan=1
network={
ssid="SSID-1"
key_mgmt=WPA-EAP
proto=RSN
group=CCMP
eap=TLS
identity="balu"
ca_cert="/home/balu/CA.crt"
client_cert="/home/balu/client.crt"
private_key="/home/balu/client.key.pem"
private_key_passwd="titok"
phase1="include_tls_length=1"
eapol_flags=3
mode=0
priority=3
disabled=0
}

De a NetworkManagert nem tudom ravenni, hogy menjen...

Az ilyesmi mindig visszaadja a hitem, hogy nem vagyok full hülye ezekhez a dolgokhoz. :)

Bár ha jobban meggondolom, azért lenne mit tanulni, bőven... :D

Egyébként ha berakod azt az opciót a NetworkManager konfigjába, akkor mi történik? Visít a NM, hogy nem jó? Lenyeli? Esetleg átadja az egyébként működő supplicant-nak/-nek, csak nincs dokumentálva?

Kerlek szepen, ugye nyilvan fut a NetworkManager szolgaltatas.
Ha kezzel beleirom a megfelelo konfigba, nemes egyszeruseggel kitorli a NM.

Mar azon a szinten vagyok, hogy marad a wpa_supplicant, hiszen az tokeletesen mukodik.
Szerettem volna megoldani NM berkein belul, de most mar ugy vagyok vele, mint parasztbacsi a sassal...

Egyebkent megvan a megoldas!!!

NM-ben megadtam a CA tanusitvanyt meg a kulcsfajl, mint p12 fajl; ekkor nem tudtam megadni a felhasznaloi tanusitvanyt. (Ennek elmeletileg ez a helyes mukodese)

openssllel kiszedtem a pkcs12 fajlbol a kliens es a CA tanusutvanyt, valamint a felhasznaloi kulcsot.
Ezeket megadva Csatlakozik ez a nyamvadt NM is.

Hm. Ha jól emlékszem, van valami 4096bájtos limitje a RADIUS-nak. Csak azt nem tudom, hogy ebbe bele kell-e férnie a teljes tanúsítványnak...

---

Off: írtad, hogy megy androidról is. Nem szokott az android leszakadozni? Én már másfél hete szenvedek vele, mert gyenge a térerő, kicsit sok lehet az interferencia, emiatt gyakran leszakad a mobilom, viszont az újrakonnektálás általában azzal végződik, hogy bontja a kapcsolatot. Neten keresgélve azt láttam, hogy ez valami androidos bug lehet, de csak feltételes módban...

Megmondom oszinten, hogy kb 2 oran at pingeltem folyamatosan, de mindig volt valasz...
SGS3 fozott ROMmal

Probaltam SHA512 4096b-es tanusitvannyal is, aminel a klienstanusitvany 3207B es az meg siman megy, ugyhogy lehet, hogy tenyleg 4096B lehet a limit, ezert a tanusitvanyoknal celszeru mindig kibontani a p12 fajlt.
Ebben az a vicces, hogy en csinalom a tanusitvanyokat (csinaltam egy scriptet, ami opensslt hasznal), lertehozom a certeket, keyeket majd csinalok belole egy p12-t. (gondoltam ezt konnyu cipelni, importalni mindenhova)
Erre csak ki kell bontanom mindenhol :-)

Ja, hogy "főzött" ROM. Az nálam nem játszik. Nekem a "nagy testvér" (:D) van (note2), de gyári ROM-mal és nem is akarom lecserélni.
Érdekes, hogy amíg a RADIUS nem volt jelen, addig semmi baja sem volt, mióta tesztelem a RADIUS-t, azóta rendszeresen leszakadok. És elég határozottan úgy tűnik, a térerő ingadozásával van összefüggésben a szakadozás.