FreeRadius Server unter Linux für User-Authentication & dot.1X

Wer viel mit Netzwerkgeräten arbeitet stößt früher oder später zwangsläufig auf das problem User authentifizieren zu wollen. In einem Netzwerk mit 50 Switchen ist es nicht zielführend lokale User auf jedem Switch einzutragen.
Passwortänderung? Na klar auf 50 Switchen ist man dann beschäftigt.
Oder man will Netzwerkauthentifizierung nach 802.1X – Der User darf erst nach Eingabe seines Usernamen/Passworts ans Netzwerk. Grade in größeren Firmen ist das Problem der unbewachten LAN Dose öfter Thema.
Ein anderer Anwendungsbereich sind WLANs. PreShared Keys kennt und nutzt mittlerweile fast jeder – nur was machen wenn man dieses ändern will? Jedem User das neue Passwort nennen? Ein Alptraum, geheim zu halten ist so ein PSK auch eher schwer. Hier gibt es die Lösung in Form von WPA2-Enterprise, wo ein Radius Server die User Authentifizierung übernimmt, es also keine gemeinsamen Shared Secrets mehr gibt.

Für all sowas benötigt man einen Radiusserver, den man unter Linux auch als freie Version bekommt.
Ich will hier die notwendigen Konfigurationen für Freeradius unter Ubuntu 10.04 beschreiben.
installieren:
aptitude install freeradius

Man sagt welcher Client sich anmelden darf (z.B. Switch, APs etc) und hat dafür ein Shared Secret definiert, mit dem die Radius Connection verschlüsselt ist. Es handelt sich hier um Netzwerkgeräte, nicht um ein Shared Secret, was der Endwanwender je zu Gesicht bekommt.

Den Client definiert man in
/etc/freeradius/clients.conf
client 172.16.10.100/32 {
secret = MeinPasswort
shortname = Cisco ASA
}

alternativ kann man auch ganze Netze (z.B. mit AP Adressen oder Switchen mit dem gleichen Passwort freigeben:
client 172.16.11.0/24 {
secret = MeineSwitche
shortname = Meine Switche sind in dem Netz
}

User und Passwörter brauchen wir auch, die legt man in der
/etc/freeradius/users an
"jan" Cleartext-Password := "jankanns"
"test" Cleartext-Password := "test123"

Dann der Radius Server neu starten und das reicht zumindest schonmal um User an eine ASA zu anzumelden.

Die Einstellungen an der ASA:

Configuration > Device Management > Users/AAA > AAA Server Groups

Dort eine Radius Servergruppe Anlegen und im unteren Fenster die IP hinzufügen.
Richtiges Interface wähen, die Ports sind 1812 und 1813 das Shared Secret für diesen Client (in diesem Fall „asapass“) gehört in „Server Secret Key“.
Das „Common Password“ Feld bleibt frei.
Mit dem „Test“ Button kann man die Authentication testen

Auf der CLI testet man mit
root@server:~# radtest test test123 127.0.0.1 1812 testing123
Sending Access-Request of id 158 to 127.0.0.1 port 1812
User-Name = "test"
User-Password = "test123"
NAS-IP-Address = 127.0.1.1
NAS-Port = 1812
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=158, length=20

Wenn man Debug Ausgaben haben will startet man Radius mit dem Parameter X:

/etc/init.d/freeradius stop
freeradius -X

Und schon ergiessen sich viele Meter Debugausgaben.

Ich teste jetzt mit verschiedenen Switchen und versuche es auch mal mit WLAN und EAP-TLS und schreibe dann ein Update-Artikel.

Alcatel OAW – RAPs eine neue Firmware geben

RAPs wie die Remote Access Points von Alcatel/Aruba heißen sind ne feine Sache.
Leider kommt nicht jeder RAP mit einer aktuellen Firmware, was bedeutet, dass solche features wie PPPoE oder UMTS Unterstützung uU nicht in der Firmware zum Zero Conf zur Verfügung stehen.

Auf einen aktuellen Firmwarestand kommen sie nach dem provisionieren – Sind sie mit dem Controller verbunden, bekommen sie das AOS vom Controller.L
eider wird nach einem reset wieder ein altes AOS geladen.

Um auch nach einem Reset das aktuelle AOS benutzen zu können muss man die backup-partition der RAPs flashen, das geht mittels des Befehls
(OAW-4504) #apflash ip-addr 192.168.234.20 backup-partition

Mit show ap image version sieht man die vorhandene Version und auch ob das upgrade noch andauert:

(OAW-4504) #show ap image version
AP Image Versions On Controller
-------------------------------
AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010
Access Points Image Version
---------------------------
[snip]
192.168.234.20 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 3.3.2.11-rn-3.0.1(p4build@trinidad.arubanetworks.com)#21263 Wed May 6 22:30:18 PDT 2009 Yes 1 0 0 0 In Progress (3 secs)

Nach dem Upgrade steht statt In Progress dann Completed und der RAP bootet die neue Version.

192.168.234.20 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 3.3.2.11-rn-3.0.1(p4build@trinidad.arubanetworks.com)#21263 Wed May 6 22:30:18 PDT 2009 Yes 1 0 0 0 Completed (65 secs)

Diese wird auch in der backup-partition angezeigt:
192.168.234.10 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 Yes 3 0 0 0 Done

Ein Fragezeichen auf der Cisco CLI eingeben

Manchmal muss man auf der Cisco CLI ein Fragezeichen eingeben, z.B. wenn man DHCP Options angeben will wo auf eine Webseite verwiesen wird und dort Parameter übergeben werden:
x.y.z/website.php?option=username

Auf der CLI bringt Cisco gleich die Kontext Hilfe. Will man das verhindern weil man halt wirklich ein „?“ braucht muss man vor dem Fragezeichen ein mal STRG+V benutzen.

Fortigate: Zwei WAN Schnittstellen/ISPs nutzen, einen default Weg haben

Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next

In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.

Nicht cisco GBICs/SFPs

Cisco will das man nur seine eigenen GBICs benutzt. Bei manchen 3rd Party SFPs gibt es dann Fehler:
%PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi1/0/1
%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port gi 1/0/1 has bad crc

Mittels der undokumentierten Befehle
service unsupported-transciever
no errdisable detect cause gbic-invalid

kann man sein Glück trotzdem versuchen.
Das klappt nicht auf allen Plattformen und leider nicht mit allen GBICs/SFPs, aber ein Versuch sollte es wert sein.