Radius Server werkt niet meer

[jepebe]

Tnx Robert! Dat gaat werken! Ik vreesde al een uitgebreide userdatabase met systeembeheerdersnarigheden.

[jepebe]

en die foutmelding gaat over ms chap, chap staat voor challenge handshake protocol, horend bij radius dacht ik. MS vrees ik voor....

[Briolet]

Volgens mij moet je met 1 account op meerdere toestellen kunnen inloggen. Het enige wat de Wifi router doet, is aan de nas vragen of persoon x mag inloggen. Er wordt niet bijgehouden of je ook weer uitlogt. Ook als de nas down gaat,  blijft de wifi verbinding staan.

Ik heb wel gemerkt dat de IP adressen soms onlogisch zijn. Door de huidige problemen waren mij settings gewist en moest ik ze opnieuw instellen. Ik heb 2 routers in mijn netwerk. Ubee --> airport --> nas. Voor de airport moet ik het WAN IP gebruiken en niet het IP van het interne netwerk, waar ook mijn andere Wifi accessoints in zitten.

Qua rechten kun je ook een speciale wifi-only groep aanmaken de verder geen rechten op de nas heeft en daar de gasten aan koppelen.

[Robert Koopman]

en die foutmelding gaat over ms chap, chap staat voor challenge handshake protocol, horend bij radius dacht ik. MS vrees ik voor....

Maar ik krijg dit pas sinds de update naar 5.1
En of MS voor Microsoft staat betwijfel ik, louter Apple draadloze apparatuur de er dagelijks gebruik van maken.
Elke verbinding die gemaakt wordt geeft deze melding.

[Briolet]

MS staat wel degelijk voor MicroSoft. Ik gok dat MS dit protocol ontwikkeld heeft om op hun server te kunnen inloggen. Als je via een onbeveiligde verbinding inlogt, gaat het wachtwoord als platte tekst door de lucht. Bij een MS-Chapv2 inlog krijg je een complexe inlog challenge waarbij alleen een gehashte versie van het wachtwoord overgedragen wordt. Die hash kan nog steeds onderschept worden en met brute-force gekraakt worden. Volgens mij is wel al aangetoond dat dit mogelijk is, maar vereist toch nog erg krachtige computers.

Bij de nas kun je deze gehele inlog ook nog via het standaard servercertificaat beveiligen en dan is er zeker geen vuiltje aan de lucht. Echter gaan niet alle OS-en vriendelijk om met zulke certificaten. Bij de apple producten krijg je bij de eerste inlog de melding dat het certificaat onbekend is met de optie om het certificaat in toekomst te vertrouwen. Makkelijk dus.

Bij android en windows, moet je het certificaat handmatig installeren. Of kiezen om zonder certificaat te verbinden. Dan gaat je gehashte wachtwoord wel leesbaar door de lucht en zou ik voor de zekerheid nooit inloggen met een administrator account.

[Robert Koopman]

In de Radius Server kan je een basiscertificaat downloaden.
Maar hoe krijg ik dat certificaat op mijn iPhone?
Ik zal de bestaande verbinding eens verwijderen en opnieuw toevoegen.

[Briolet]

In de apple producten zoals de iPhone is dat geen probleem. Bij de eerste inlog krijg je altijd de vraag of je het certificaat wilt accepteren. (Dat certificaat meesturen is een standaard onderdeel van het opbouwen van een SSL/TLS verbinding) En omdat dit radius certificaat hetzelfde certificaat is als voor een https inlog, is de kans groot dat hij er al instaat vanwege een eerdere toestemming bij een https inlog.
Toen ik met de radius server begon vond ik het heel onbevredigend om niet te zien hoe de inlog precies verliep en ik heb uiteindelijk Wireshark gepakt om zeker te zijn dat er werkelijk een certificaat gebruikt werd om de authenticatie te beveiligen.

Het proces is gelijk aan die van de Ziggo/UPC WifiSpots. Daar was het voor de meeste Windows/Android mensen te lastig om een certificaat te installeren, vanuit een lopende verbinding. Sinds een paar maand heeft Ziggo daar nu speciale apps die de installaties voor je doen. 

[Robert Koopman]

Verbinding vergeten, opnieuw aanmelden, certificaat accepteren en meteen in de logfile kijken.
Nog altijd dat foute wachtwoord...... Blijft vreemd.

[Briolet]

Ik log nu in via de Ziggo WifiSpot bij gebrek aan eigen WiFi toegang.…
Het log is als volgt:

Code: [Selecteer]

RADIUS Server

Type Date & Time Event
Error 2014-11-07 20:27:16 /usr/local/synoradius/rad_listen[7]: Error binding to port for 10.0.1.30 port 1812
Error 2014-11-07 20:27:16 Failed binding to authentication address 10.0.1.30 port 1812: Address already in use
Info 2014-11-07 20:27:16 Loaded virtual server inner-tunnel
Info 2014-11-07 20:27:16 Loaded virtual server <default>


Tja, alles herhaalt zich bij de installatie van DSM 5.1 update 2. Exact hetzelfde probleem en foutmelding. Dit keer heb ik geprobeerd of ik niet gewoon een andere poort kan gebruiken. Dus ik stel poort 1814 in, maar krijg dan gewoon dezelfde foutmelding, maar nu voor poort 1814.
Alle andere opties zoals nas resetten en Radius Server opnieuw installeren had ik vorige keer al geprobeerd en zal nu vast ook falen.
 
Tragisch omdat Synology al aangegeven had dat ze de fout gevonden hebben en dit in een volgende update zouden verbeteren. Nu heeft de update waarschijnlijk alle aanpassingen overschreven die de techneuten van Synology op mijn nas hadden gedaan om hem weer werkend te krijgen.

[Robert Koopman]

Hmmm...
Ik doe de update nog maar even niet denk ik.

[r00n]

Had net ook al onder ander bericht gezet dat de radius server bij mij nog steeds goed werkt na de laatste update.

[Robert Koopman]

Ga ik toch updaten dit weekeinde, kijken of het bij mij blijft werken.

[Briolet]

Eigenlijk heb ik nog nooit issues gehad met de radius oplossing.

Anderen ook niet, dus moet het iets specifieks op mijn nas zijn. Het enige wat waarschijnlijk niet standaard is, is dat ik recent de Wifi-optie geactiveerd heb op mijn 212j nas. Die activering heeft de gehele netwerkomgeving aangepast, incl firewall. Dus ik vermoed dat dit een afwijkende configuratie update vraagt, waar ze mee de mist in gaan.
Ik heb alleen Synology pakketten in gebruik dus een onbekende aanpassing kan ik uitsluiten zodat het hun aanpassingen zijn die de boel in de war gooien. 

[Briolet]

Ik kreeg net een mailtje van Synology:

Code: [Selecteer]

Dear customer ,

Thank you for contacting Synology support.

After discussed with our developers, we assumed it a side effect of a known issue at the moment

For workaround , please try to disable dhcp client with these command :
 stop dhcp-client IFACE=eth0
It can be process with login with SSH/TELNET, as root account (password is same as admin)

See if the problem still happens.

Hope this helps.

Zijn suggestie gaf een error:

Code: [Selecteer]

GedeeldeData> stop dhcp-client IFACE=eth0
stop: Unknown instance: eth0

Maar na inloggen bleek de radius server nu wel actief en volgens het log was hij al twee uur eerder actief geworden. Zij hebben dit dus al remote opgelost. Zijn idee was dus dat de bug samenhangt met de DHCP mode.

In elk geval doen alles het nu weer. En als het weer mis gaan, heb ik een idee in welke richting te zoeken.

[cyrus1977]

Ik ben hier zojuist ook tegen aan gelopen.
Situatie. Als ik de firewall aanpas, hangt de radius server.


Oplossing: herstart de radius app en dus niet de hele server (dat lost het niet op).


Waarschijnlijk lost synology dit in een volgende release op. Heb het nog maar even gemeld aan synology.