mturba

Wie sieht denn der relevante Ausschnitt aus der Konfiguration aus?

Normales ISDN-Kabel müsst schon passen. Wenn du allerdings mit deinem Telefon schon keine Verbindung bekommst, solltest du erstmal nach deiner Leitung schauen, bevor du dich an die Routerkonfiguration machst.

Nee, auf den Accessports habe ich spanning-tree portfast konfiguriert, in der Konfiguration in meinem vorherigen Post aber weggelassen, weils für die 802.1x-Geschichte nicht wichtig war. Es dauert ca. 3-5 Sekunden, bis der Port einem VLAN zugewiesen ist und der Rechner eine IP-Adresse bekommen hat, da ich die tx-period auf 1 gesetzt habe und defaultmässig 2 retries gemacht werden. Nach dem letzten retry verwendet der Switch die MAC-Adresse, die an diesem Port gesehen wurde zur Authentifizierung, das war diese mac-auth-bypass-Sache.

Ich finde die CCNP-Prüfungen deutlich anspruchsvoller als die CCNA-Prüfung. Wenn dir allerdings die CCNA-Prüfung so leicht gefallen ist, wie du sagst, würde ich ernsthaft in Erwägung ziehen, in Richtung CCNP zu gehen.

Allerdings glaube ich, dass es nur schwer möglich ist, diese Prüfungen alle zu bestehen, ohne entweder viel Erfahrung zu haben oder Zugriff auf ein Testlab, an dem man Verschiedenes ausprobieren kann.

Wuuunderbar, hat funktioniert!

Der relevante Ausschnitt aus der Switchkonfiguration sieht folgendermassen aus:

!
aaa new-model
!
aaa authentication dot1x default group radius
aaa authorization network default group radius
!
dot1x system-auth-control
!
interface FastEthernet1/0/1
switchport mode access
dot1x mac-auth-bypass
dot1x pae authenticator
dot1x port-control auto
dot1x timeout tx-period 1
dot1x guest-vlan 100
!
radius-server host 1.2.3.4 auth-port 1812 acct-port 1813 key 7 14112D040D0538302131
!

Der Eintrag in der FreeRADIUS-Konfiguration sieht folgendermassen aus:

001122AABBCC    Auth-Type := Local, User-Password == "001122AABBCC"
               Tunnel-Medium-Type = IEEE-802,
               Tunnel-Private-Group-Id = 123,
               Tunnel-Type = VLAN

Vielen Dank nochmal an alle :)

Das ATM läuft aber trozdem über Ethernet oder nicht?

Wie meinst du das, ob ATM über Ethernet läuft? Falls die Frage ist, ob PPPoA über Ethernet läuft: Nein, wie der Name schon sagt, PPP läuft über ATM. PPP wird eingepackt in ATM-Zellen und damit transportiert, OHNE den zusätzlichen Ethernet-Frame drumrum wie bei PPPoE.

Hast du's mal mit der Beispielkonfiguration aus dem Cisco 700 Configuration Guide probiert?

set system 764
cd lan
set ip address 172.16.17.9
set ip netmask 255.255.255.248
set ip routing on
set user isp
set number 5558011
set ppp password client
set ppp secret client
set ppp address negotiation local on
set ip routing on
set ip route destination 0.0.0.0/0 gateway 0.0.0.0 propagate on
set bridging off
set ip address 0.0.0.0
set ip netmask 0.0.0.0
set timeout 360
set ip pat on
set active
reboot

Quelle: Cisco 700 Series Router Software Configuration Guide - Basic Configurations [Cisco 700 Series ISDN Access Routers] - Cisco Systems

Was verstehst du unter Kanal?

Was hast du bisher unternommen, um den Switch ans Netz zu bringen?

Falls Kupfer: Hast du ein Crossoverkabel verwendet?

Falls LWL: Hast du die beiden Adern mal vertauscht?

Hier hier für einen 3560.

 

Configuring IEEE 802.1x Port-Based Authentication

Hola,

 

non supplicant authentication ist auch mit cisco möglich..

 

Catalyst 2960 Switch Software Configuration Guide, 12.2(25)SEE - Configuring IEEE 802.1x Port-Based Authentication* [Cisco Catalyst 2960 Series Switches] - Cisco Systems

Hmm... danke :-) Wie konnt ich das nur überlesen... werde das morgen sofort testen!

Ein Ansatz wäre bestimmt MAC-basierende 802.1x Authentifizierung damit solltest du über den RADIUS Server VLANs zuordnen können. Bei HP funktioniert das soweit ich weis indem man als Radius-User und als Radius-Passwort die MAC-Adresse des Clients nimmt.

Richtig, und das funktioniert auch für die meisten Hersteller. Mein Ziel ist, herauszufinden, ob das bei Cisco auf die gleiche Art möglich ist, oder ob Cisco diese Möglichkeit nicht vorsieht,

1. die Authentifizierung anhand der MAC-Adresse durchzuführen

2. die entsprechenden Radius-Attribute auszuwerten und anhand derer die VLAN-Zuordnung vorzunehmen, wie es andere Hersteller auch tun

VLAN Membership Policy Server (VMPS)—IEEE802.1x and VMPS are mutually exclusive

Danke für den Hinweis, evtl. habe ich mich nicht richtig ausgedrückt. Mein Ziel ist nicht, die VLAN-Zuordnung per VMPS zu machen und gleichzeitig 802.1x port based authentication zu fahren. Ziel ist es, eine Möglichkeit zu finden, in einer heterogenen Umgebung (Cisco, Procurve, Foundry, ...) eine dynamische VLAN-Zuordnung anhand der MAC-Adresse zu erreichen.

Einziger Ansatz bisher ist, eine Datenbankanbindung für OpenVMPS zu schreiben, der die VLAN-Zuordnung per VMPS für die Cisco-Geräte übernimmt und parallel dazu einen FreeRADIUS, der auf der gleichen Datenbasis die VLAN-Zuordnung per 802.1x vornimmt. Schön wäre allerdings gewesen, wenn man sich den VMPS-Daemon hätte sparen können.

Wie sieht denn deine Konfiguration aus? Hast du dir mal das Debugging mit

debug crypto isakmp
debug crypto ipsec

angeschaut?

Hi,

bei vielen Herstellern aktiver Netzwerkkomponenten wie z.B. Procurve, Extreme oder Foundry gibt es die Möglichkeit, eine MAC-basierte 802.1x-Authentifizierung durchzuführen mit dynamischer VLAN-Zuordnung. Bei Cisco scheint es diese Möglichkeit nicht zu geben, zumindest habe ich in der Dokumentation nichts dazu gefunden. Vermutlich verlässt sich Cisco dabei auf sein proprietäres VMPS-Protokoll, anstatt auf herstellerpezifische Radius-Attribute.

Weiß da jemand etwas drüber?

Danke und Gruß,

Martin

Hi,

die Verwendung eines MS-Zertifikatsservers für diesen Zweck hat sich bei uns gut bewährt, das Rollout funktioniert ohne Probleme.

Hier ist ein Link zu dem Add-On, welches für das Auto-Enrollment per SCEP gebraucht wird:

Download details: Simple Certificate Enrollment Protocol (SCEP) Add-on for Certificate Services

Viele Grüße,

Martin

Bist du dir sicher, dass es an der Firewall deines VPN-Clients liegt? Eventuell verbietet dir auch die Policy des angewählten VPN-Servers, dass während der VPN-Sitzung weitere Verbindungen bestehen, die nicht durch den Tunnel gehen, Stichwort Split-Tunneling und Local LAN Access.

Hi,

Release Notes for VPN Client, Release 4.8  [Cisco VPN Client] - Cisco Systems

Allerdings solltest du für die Beantwortung derartiger Fragen wohl lieber die Suchfunktion der Herstellerseite verwenden ;)

Das Solarwinds Toolset ist dafür sehr brauchbar:

Standard Toolset SolarWinds

Gruß,

Martin

Achso, und ich gratulier natürlich auch :) Super Leistung, hat meine auch noch knapp getoppt, hatte damals 961 Punkte geholt...

Ich habe damals (vor ca. 2 1/2 Jahren) den CCNA Cisco Certified Network Associate Study Guide (Exam 640-801) zum Lernen verwendet - das war damals auch das Einzige an Literatur, was ich verwendet habe --> sehr empfehlenswert!

Die Konfiguration, z.B. deines Dialer-Interfaces etc.

Geht sogar schon ab 12.3(4)T:

Cisco Systems - Real-Time Resolution for IPSec Tunnel Peer

@hkahmann: Was bedeutet dynamische IP-Dienste? Bezieht sich das auch auf die Möglichkeit, IPSec-Tunnel zu dynamischen Endpunktadressen aufzubauen?

@hivo: Gerne, kein Problem...

Soweit mir bekannt ist, nicht... in der clients.conf ist das ja kein Problem, da definiert man einfach nur, welche Radius-Clients akzeptiert werden und mit welchem Key. Im huntgroups-Configfile geht es darum, jedes einzelne NAS einer bestimmten Huntgroup zuzuordnen, um dann dafür die Zugriffsrechte einzuschränken. Deswegen ist das dort wohl nicht vorgesehen, das pauschal für ein ganzes Netz zu machen. Das ist allerdings nur meine Vermutung, beim Überfliegen der Doku hab ich auch keine Möglichkeit gefunden. Evtl. weiß da aber jemand anders mehr drüber...

Hab das grad mal getestet - meine Vermutung, das mit priv-lvl=0 regeln zu können, hat sich nicht bestätigt. Stattdessen muss der Radius-Server dafür sorgen, dass nur User bestimmter Gruppen Zugang bekommen.

Mit FreeRADIUS kann man das hinbekommen, indem man sog. Huntgroups definiert in /etc/freeradius/huntgroups, z.B.

switches     NAS-IP-Address == 10.0.0.1
            Group = admin

Alle anderen User werden dann automatisch verweigert für dieses NAS, d.h. die Cisco-AVPair-Geschichte ist dafür eigentlich garnicht nötig, nur, wenn man halt Unterscheidungen in den Privilege Levels machen will. Evtl. kann man Winradius auch dazu überreden, nur bestimmte User für die Authentifizierung an einem NAS zuzulassen.

Wobei ich grad überlesen habe, dass der Zweck war, der Gruppe Test überhaupt keinen Zugriff zu gewähren. Mein Beispiel bezieht sich auf die Vergabe eines niedrigen Privilege Levels. Hab da auch spontan keine Idee, evtl. mit priv-lvl=0 o.ä. - werd das bei Gelegenheit mal ausprobieren.

Wo definierst du denn, zu welcher Gruppe welche User gehören?

Das Setzen des Privilege-Levels muss m.E. auf der Radius-Seite passieren über Cisco-AVPairs.

Ein ganz einfaches Beispiel anhand eines einzelnen Users in FreeRADIUS:

Admin1         Auth-Type := Local, User-Password == "test123"
              Cisco-AVPair = "shell:priv-lvl=1"


Admin2         Auth-Type := Local, User-Password == "test345"
              Cisco-AVPair = "shell:priv-lvl=15"

Ein gutes Dokument von Cisco zum Thema:

How to Assign Privilege Levels with TACACS+ and RADIUS [Authentication Protocols] - Cisco Systems

Gruß,

Martin