09.10.2021

6172

802.1x an Cisco CBS350 und Windows Server

Moin Zusammen,

ich hab seit kurzem Cisco CBS350 Switche im Einsatz.

Ziel ist eine 802.1x Authentifizierung mit dynamischer VLAN-Zuweisung.

Ich bin nach dieser Anleitung vorgegangen: https://www.cisco.com/c/de_de/support/docs/smb/switches/cisco-250-series ...
Optisch unterscheidet sie sich natürlich vom CBS350, aber die Settings sind gleich.

Unter Radius Client am Switch ist der Radiusserver (Windows Server 2016) hinterlegt.

Unter 802.1XAuthentication -> Properties ist die Portbasierte Authentication aktiv, Methode steht auf Radius.

An meinem Testclient ist der Dienst aktiv und der Radius zeigt auch eine zugelassene Authentifizierung an.

Wireshark zeigt mir am Server, dass ein Radius Access-Accept in dem die VLAN ID übertragen wird an den Switch.
DHCP ist auf dem Server für alle VLANs konfiguriert.

Am Client kommt vom Radius nichts an laut Wireshark und er bekommt immer wieder eine IP aus dem Default-VLAN.

Hab das beim letzten mal mit Ruckus-Switchen gemacht und das ging nach anfänglichen Problemen ohne Probleme.

Hat noch jemand eine Idee?

Grüße und ein schönes WE

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1370398092

Url: https://administrator.de/forum/802-1x-an-cisco-cbs350-und-windows-server-1370398092.html

Ausgedruckt am: 21.12.2024 um 16:12 Uhr

43 Kommentare

Neuester Kommentar

Hallo,

was hast Du auf dem NPS eingestellt?

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...

Grüße

lcer

Der Teufel ist ein Eichhörnchen bei den Cisco SoHo Modellen....

Deine Konfig sieht vermutlich so aus:

Radius Setup

Port Setup

Per se ist damit dann erstmal alles richtig eingestellt. Aber dennoch landet man immer nur im Default VLAN oder wenn der Port auf "Reject" steht und damit eine VLAN ID erzwingt, geht zwar die Radius Authentication durch, der Port bleibt aber geblockt. Genau dein Fehlerbild also

Das lässt immer darauf schliessen das der .1x Authenticator (Switch) etwas nicht richtig versteht.
Und genauso ist es dann auch....
Der FreeRadius im Debugging Mode sagt das der Switch einen Tunneled Request schickt also die ganzen Daten im Radius Request getunnelt. (Output gekürzt)

 } # server inner-tunnel
(8) Virtual server sending reply
(8)   Tunnel-Type = VLAN
(8)   Tunnel-Medium-Type = IEEE-802
(8)   Tunnel-Private-Group-Id = "10"
(8)   MS-MPPE-Encryption-Policy = Encryption-Allowed
(8)   User-Name = "vlan10"
(8) eap_peap: Got tunneled reply code 2
(8) eap_peap:   Tunnel-Type = VLAN
(8) eap_peap:   Tunnel-Medium-Type = IEEE-802
(8) eap_peap:   Tunnel-Private-Group-Id = "10"
...
(8) eap_peap: Tunneled authentication was successful
(8) eap_peap: SUCCESS
(9) Sent Access-Accept Id 70 from 172.20.1.101:1812 to 172.20.1.102:49205 length 0 

User Konfig dazu

"vlan10"          Cleartext-Password := "vlan10"

                Tunnel-Type = 13,
                Tunnel-Medium-Type = 6,
                Tunnel-Private-Group-Id = 10  

Man achte auf das inner tunnel im Debug Output !

Dummerweise erwartet der Switch dann auch einen Tunneled Reply, was man dem Radius Server im Setup sagen muss, sonst ignoriert der Cisco die VLAN ID.
Dazu gibt es auch einen entsprechenden Post in der Cisco Knowledge Base:
https://community.cisco.com/t5/small-business-switches/sg300-cant-assign ...
Bringt man zumindestens dem FreeRadius in seiner eap.conf Datei das Tunneln bei,
copy_request_to_tunnel = yes
use_tunneled_reply = yes
klappt die dynamische VLAN Zuweisung danach auf Anhieb sofort:

(172.20.10.1 ist der Router im VLAN-10)
Getestet auf einem SG300, 350X und vermutlich ist es auf dem CBS identisch.

Moin,
so in etwa sieht es bei mir auch aus.

Hier ist natürlich unten noch der Radius-Server eingetragen mit dem entsprechenden Key. Ich sehe ja auch die Anfragen im Eventlog auf dem Server und er lässt zu bei dem berechtigten Benutzer bzw. lehnt es ab.

Hier stehts aktuell auf Force Authrized. Sonst auf Auto. Aber dann komme ich von Extern nicht mehr auf den Client drauf. Erst wenn ich mich angemeldet habe. Dann gehts.

So, ich habe es jetzt nochmal in einer Testumgebung nachgestellt und habe das gleiche Problem.

Der NPS sagt: Zugriff gewährt, der Client und der Switch sagen: Nicht authentifiziert.

Hinzu kommt, dass ich mich mit einem neuen Benutzer nicht anmelden kann, weil kein Netzwerkzugriff vorhanden ist.

Hätte ich mal bloß gewartet und Ruckus gekauft

config-file-header
switch7fab1a
v2.5.7.85 / RCBS3.1_930_871_059
CLI v1.0
file SSD indicator encrypted
@
ssd-control-start
ssd config
ssd file passphrase control unrestricted
no ssd file integrity control
ssd-control-end cb0a3fdb1f3a1af4e4430033719968c0
!
!
unit-type-control-start
unit-type unit 1 network gi uplink none
unit-type-control-end
!
spanning-tree mode pvst
vlan database
vlan 20,1000
exit
voice vlan oui-table add 0001e3 Siemens_AG_phone
voice vlan oui-table add 00036b Cisco_phone
voice vlan oui-table add 00096e Avaya
voice vlan oui-table add 000fe2 H3C_Aolynk
voice vlan oui-table add 0060b9 Philips_and_NEC_AG_phone
voice vlan oui-table add 00d01e Pingtel_phone
voice vlan oui-table add 00e075 Polycom/Veritel_phone
voice vlan oui-table add 00e0bb 3Com_phone
dot1x system-auth-control
dot1x traps authentication failure 802.1x
dot1x traps authentication success 802.1x
dot1x supplicant traps authentication failure
dot1x supplicant traps authentication success
ip dhcp relay address 172.16.10.4
ip dhcp relay enable
bonjour interface range vlan 1
hostname switch7fab1a
encrypted radius-server key yAujxSo0R33cHsdfn92+Ujz6dxWNGygwLWh4wGKJ+ouNG0=
encrypted radius-server host 172.16.10.4 key yAujxSsdfo0R33cHn92+Ujz6dxWNGygwLWh4wGKJ+ouNG0=
aaa accounting dot1x start-stop group radius
username root password encrypted $15$EuazdiOMqri3GbZf$WnWmmcP/FnL1pumhq3BBqsdafTELTd+xbVfVZVUdDmTi5HcnK+OpxGlzfpnyNva1PrlD27LBPKwp1DbGypk8jUgH7A== privilege 15
ip ssh server
ip ssh password-auth
clock timezone J 0 minutes 0
no clock source sntp
!
interface vlan 1
 ip address 172.16.10.250 255.255.255.0
 no ip address dhcp
!
interface vlan 20
 name Test
 ip address 172.16.20.250 255.255.255.0
 ip dhcp relay enable
!
interface vlan 1000
 name Guest
 ip address 192.168.100.250 255.255.255.0
 ip dhcp relay enable
 dot1x guest-vlan
!
interface GigabitEthernet2
 dot1x guest-vlan enable
 dot1x timeout reauth-period 300
 dot1x radius-attributes vlan
 dot1x port-control auto
!
exit
ip helper-address all 172.16.10.4 7
ip route 172.16.10.0 /24 172.16.10.4

Also so weit so gut. Aufm Switch sehe ich im Log die Authentication.

Username\Test with mac .... is authorized on port gi2
port gi2 is authorized
link-w-down: vlan 1000
link-i-up: vlan 20

Auf dem Client wird mir bei der Anmeldung angezeigt, dass ich angemeldet werde und dann bekomme ich die Meldung, dass die Domain nicht verfügbar sei.

Offenbar klappt das mit dem DHCP-Relay nicht. Ich sehe die Anfragen auf dem Server, also einen DHCP Discover, aber keine weiteren DHCP Anfragen.

Will mir irgendwie auch nicht in den Kopf, weil ich da sonst nicht im Ansatz so viel Kram eingestellt habe um in anderen VLANs eine IP zu bekommen.

Jemand noch eine Idee?

Ich hab dem Client jetzt mal eine statische IP gegeben und dabei gemerkt, dass ich den Server gar nicht erreichen kann.
Ich kann die VM kann nicht erreichen.
Edit: Hyper-V Host erreiche ich.

Damit erklärt sich natürlich auch das Anmeldeproblem.

Hast Du am Client-PC die Authentifizierung richtig eingestellt? https://docs.microsoft.com/de-de/windows/win32/nativewifi/onexschema-aut ...

Böse Falle: Computer- oder Benutzerauthentifizierung ist mit XOR. Wenn der Computer authentifiziert ist, und sich ein Benutzer anmeldet, muss es auf dem NPS eine Regel geben, die den Benutzer auch authentifiziert - sonst wird die Verbindung gekappt.

Grüße

lcer

Zitat von @lcer00:

Hast Du am Client-PC die Authentifizierung richtig eingestellt? https://docs.microsoft.com/de-de/windows/win32/nativewifi/onexschema-aut ...

Böse Falle: Computer- oder Benutzerauthentifizierung ist mit XOR. Wenn der Computer authentifiziert ist, und sich ein Benutzer anmeldet, muss es auf dem NPS eine Regel geben, die den Benutzer auch authentifiziert - sonst wird die Verbindung gekappt.

Grüße

lcer

Ja, das ist so weit alles richtig eingestellt und es gibt nur eine Benutzerauthentifizierung.

Aktuell scheint es eher ein Routingproblem zu sein, weil ich die VM nicht erreichen kann. Oder es ist ein Problem mit dem Hyper V.

Beim ESX kann ich beim virtuellen Switch die VLAN ID 4095 eingeben, aber die Möglichkeit habe ich beim Hyper-V nicht.

Wenn es nur eine Benutzerauthentifizierung gibt, kann der PC den DC nicht kontaktieren um den Benutzer zu authentifizieren.

Grüße

lcer

dh. es muss beides aktiv sein? Muss dazu der Client auch in einer entsprechenden Gruppe sein oder reicht es Mitglied der Domäne zu sein?

Bei den Ruckus war das nicht notwendig.

Ich habe jetzt das Gerät eingefügt in die Authentifizierungsgruppe im AD und auf Benutzer oder Computer-Auth gestellt. Nur bringt mir das absolut nichts, weil die Authentifizierung nun über den Computernamen läuft.

Da kann ich gleich portbasiertes VLAN einrichten. Ich brauche Benutzerabhängige VLAN Zuweisung, weil die MA zum Teil an unterschiedlichen Arbeitsplätzen sitzen.

Wenn Du Computerauthentifizierung einstellst, ist der PC und alle seine Benutzer authentifiziert. Wenn Du Benutzerauthentifizierung einstellst, ist der PC ohne angemeldeten Benutzer nicht authentifiziert. Bei „Computer- oder Benutzerauthentifizierung“ ist der PC authentifiziert solange kein Benutzer angemeldet ist. Bei der Benutzeranmeldung wird dann die Computerauthentifizierung beendet und der Benutzer muss neu authentifiziert werden.

Stell am PC testweise auf Computerauthentifizierung und erstelle auf dem NPS eine Regel für die Computergruppe.

Grüße

lcer

Zitat von @lcer00:

Wenn Du Computerauthentifizierung einstellst, ist der PC und alle seine Benutzer authentifiziert. Wenn Du Benutzerauthentifizierung einstellst, ist der PC ohne angemeldeten Benutzer nicht authentifiziert. Bei „Computer- oder Benutzerauthentifizierung“ ist der PC authentifiziert solange kein Benutzer angemeldet ist. Bei der Benutzeranmeldung wird dann die Computerauthentifizierung beendet und der Benutzer muss neu authentifiziert werden.

Stell am PC testweise auf Computerauthentifizierung und erstelle auf dem NPS eine Regel für die Computergruppe.

Grüße

lcer

So, ich habe jetzt eine neue Gruppe und eine neue Richtlinie erstellt.
Hab ein weiteres VLAN erstellt in das ich die Computer packe, wenn noch kein Benutzer sich authentifiziert hat.
Das scheint in der Tat jetzt zu klappen.

Laut Switch bin ich jetzt im User-VLAN, hab aber im Log gesehen, dass der Port für das Computer VLAN wieder down ist und für den User dann Up ist.

Ich werde das mal in dem eigentlichen System einrichten und testen.

Ich danke dir für die Hinweise!!!

Nabend,
also ich habe es nun mal in der eigentlich Umgebung eingerichtet, aber ich scheine noch irgendwo einen Haken zu haben.

Auf dem Cisco sehe ich, dass der Client im Loginscreen im VLAN 250 ist. Das ist quasi das VLAN in das ich die Computer packe ohne Authentifizierung durch den Nutzer. Ich sehe aber auch im DHCP, dass hier keine IP vergeben wird.
Wenn sich dann ein Nutzer anmeldet sehe ich einen Wechsel auf dem Cisco in das VLAN20, aber es wird ebenfalls keine IP vergeben und die Anmeldung schlägt dementsprechend fehl.
Anmeldungen ins Default-VLAN gehen problemlos durch über die Authentifizierung.
Da habe ich eine Richtlinie für die Domänen-admins, die dann im Default-VLAN landen.

Wenn ich angemeldet bin kann ich auch jede Schnittstelle auf der Sophos pingen. Dort habe ich für jedes VLAN eine Schnittstelle eingerichtet als VLAN-Interface und dieses im DHCP als Gateway hinterlegt.

Auf dem DHCP sehe ich in Wireshark ein Discover vom Client und ein Offer mit der IP Adresse die der Server vergeben will, aber das wars. Die scheint am Client nicht anzukommen.

Stehe gerade noch etwas auf dem Schlauch was mir fehlt.

Grüße

Arbeitet dein Switch im Layer 3 Mode oder nur im Layer 2 Mode ?
Was passiert wenn du Client in VLAN 20 und VLAN 250 Ports steckst die ausgenommen sind von der .1x Authentisierung. Bekommen diese Clients dort DHCP IP Adressen aus diesen VLANs ? Das solltest du zuerst wasserdicht checken um sicherzustellen das die DHCP Vergabe sauber und gesichert in den VLANs funktioniert.
Normalerweise kommt DHCP nach .1x so das der Fehler vermutlich im DHCP dieser VLAN Segmente liegt ?!

Im Layer3 Modus.

Du meinst portbasiert in das jeweilige VLAN stecken?

Hallo Xaero1982,

Soweit ich das verstanden habe, hast du den Cisco im Layer-3-Modus und als Gateway deine Sophos in den jeweiligen Netzen, korrekt?

Zitat von @Xaero1982:
Auf dem DHCP sehe ich in Wireshark ein Discover vom Client und ein Offer mit der IP Adresse die der Server vergeben will, aber das wars. Die scheint am Client nicht anzukommen.

Haben beide Geräte (Cisco Switch und Sophos) eine IP im Netz des DHCP-Servers?
Falls ja, schau dir im Wireshark mal die MAC-Adressen von DHCP-Request und Offer an. Vielleicht gibt es in diesem Kontext ein Routingproblem?

Viele Grüße

mxrecord

Soweit ich das verstanden habe

Nein das hast du dann vermutlich falsch verstanden, denn das wäre im L3 Mode ja unsinning und auch kontraproduktiv, denn so hätte man 2 Router parallel und hebelt die Firewall aus. Ein fataler Fehler.
Die Sophos ist (hoffentlich) mit einem separaten Koppel VLAN angebunden. wie es HIER beschrieben ist !
Ein klassisches L3 Setup also.

Haben beide Geräte (Cisco Switch und Sophos) eine IP im Netz des DHCP-Servers?

Wäre Unsinn, denn der Switch macht mit dem o.a. Konzept immer DHCP Relay (DHCP Helper). Mac Adressen haben per se auch niemals was mit Routing zu tun (L2 only !) Also bitte nichts wild durcheinanderbringen...

Im Layer3 Modus.

OK, dann ist DHCP Relay für dich zwingend ! Hast du das entsprechend konfiguriert ??
Auf allen VLAN IP Interfaces in denen kein DHCP Server ist muss dann DHCP Relay aktiviert sein auf Interface Basis und die Relay Forwarding IP ist die IP des zentralen DHCP Servers.
Das VLAN IP Interface mit dem zentralen DHCP Server hat kein Relay aktiviert. Logisch, denn hier werkelt ja der DHCP Server selber.

Du meinst portbasiert in das jeweilige VLAN stecken?

Ja, genau ! In jedem VLAN mal einen Port von der .1x Authnetisierung ausnehmen und dort einen Client einstecken und die DHCP IP Adressvergabe wasserdicht checken.

Zitat von @aqui:

Soweit ich das verstanden habe

Wieso zwei Router parallel?
In der Tat gibt es eigentlich nur eine VLAN Schnittstelle - in VLAN 1 - auf dem Switch. Auf der Sophos habe ich für jedes VLAN ein VLAN-Interface erstellt, welches ich via DHCP als Gateway für das jeweilige VLAN verteile.
Warum? Weil ich eigentlich so wenig wie möglich auf dem Switch konfigurieren möchte.

Die Sophos ist (hoffentlich) mit einem separaten Koppel VLAN angebunden. wie es HIER beschrieben ist !
Ein klassisches L3 Setup also.

Nop

Dann wohl nicht

Haben beide Geräte (Cisco Switch und Sophos) eine IP im Netz des DHCP-Servers?

Nun, da sowohl der Switch und die Sophos, als auch die Server aktuell im gleichen Netz sind, ja.
Sophos: 172.16.10.1
Server: 172.16.10.4 (dhcp, dns, nps, ad)
Switch: 172.16.10.250

Im Layer3 Modus.

Ja, ich habe DHCP Relay auf dem Switch aktiviert. Habe den DHCP Server eingetragen und das entsprechende Interface eingerichtet.

Das VLAN IP Interface mit dem zentralen DHCP Server hat kein Relay aktiviert. Logisch, denn hier werkelt ja der DHCP Server selber.

Du meinst portbasiert in das jeweilige VLAN stecken?

Ja, genau ! In jedem VLAN mal einen Port von der .1x Authnetisierung ausnehmen und dort einen Client einstecken und die DHCP IP Adressvergabe wasserdicht checken.

Okay. Muss ich testen, wenn ich vor Ort bin. Der Test-Rechner scheint mal wieder verreckt zu sein :D

Hallo Xaero1982,

hat der Switch im VLAN 250, wo das DHCP-Relay arbeiten soll, eine IP-Adresse?

DHCP-Relayanfragen werden klassischerweise mit der IP des DHCP-Relays im entsprechenden Subnetz als Source-IP abgesendet (bspw. 172.16.250.250, sofern der Switch diese IP im VLAN 250 hätte).

Da der Switch im L3-Modus arbeitet, wird er die Anfrage über sein Interface im VLAN 20 direkt an den DHCP-Server senden. Dieser wird die Antwort (gemäß seiner Routingtabelle - er ist ja im anderen Netz) an sein Default-Gateway (Sophos?) senden, da er sonst keinen Pfad in das andere VLAN kennt. Du hättest hier also ein asymmetrisches Routing, was generell ein unschönes Design ist und vermutlich die Ursache des Problems.

Eine saubere und schnelle Lösung könnte es sein, das DHCP Relay auf die Sophos zu verlagern, wie es eigentlich üblich wäre (DHCP-Relay wird klassischerweise auf dem Gateway im Netz platziert).

Viele Grüße

mxrecord

Wieso zwei Router parallel?

Ist doch logisch... Du hast wenn es so (falsch) konfiguriert sein sollte wie Kollege @mxrecord beschrieben hat, also einmal die Firewall tagged mit L3 Interfaces in allen VLANs wie auch parallel den Switch mit seinen L3 Interfaces in den VLANs. Damit hast du dann 2 parallele Router in allen VLANs. Ein fatales Fehldesign wenn dem so wäre...
Es sei denn du hast uns das alles hier falsch beschrieben...?!
Wenn du die VLANs auf dem Switch im_L3_Design betreibst, dann routest du ausschliesslich mit dem Switch und über ein Transfer/Koppel VLAN ist deine Firewall angeschlossen.
DHCP Relay auf den VLAN IP Interfaces und fertig ist der Lack.

Das andere wäre dann ein reines L2 Switch Design ohne VLAN IP Interfaces auf dem Switch und dann entsprechende VLAN Interfaces auf der Firewall wie hier beschrieben.
Laut deinen Aussagen machst du ja aber L3, oder ?

Eine saubere und schnelle Lösung könnte es sein, das DHCP Relay auf die Sophos zu verlagern

Nein...jedenfalls nicht in Bezug auf schnell. Mit einer Trunk Anbindung der Firewall über einen Tagged Link (L2 Design oben) muss jeder lokale VLAN Verkehr doppelt über diesen Trunk. Hin zur FW und zurück ins Ziel VLAN. Deshalb sind solche sog. "one armed" oder "Router/FW on the stick" Lösung in Bezug auf Performance und Schnelligkeit keine gute Lösung sofern man überwiegend VLAN lokalen Routing Traffic hat.
In puncto lokaler Performance ist dann ein L3 Design über den Switch immer die erheblich bessere Lösung da das IP Forwarding in Silizium auf dem Switch direkt in die VLAN Segmente passiert.
Frage also wie nun das Design vom Kollegen @Xaero1982 nun wirklich aussieht ?!?

Ihr verwirrt mich.

Nochmal: Es gibt aktuell auf dem Switch nur das Interface im Default-VLAN: 172.16.10.250.
Dort ist auch die Sophos drin mit 172.16.10.1

Deinen Einwand @aqui mit der Perfomance verstehe ich. D.h. sinnvollerweise sollte ich auf dem Switch in jedem VLAN ein Interface mit entsprechender IP erstellen und dieses dann den Clients als Gateway mitgeben?

Ziel war es eigentlich die ganzen Firewallregeln über die Sophos abzufackeln und nicht über ACLs auf dem Switch. Finde ich persönlich wesentlich charmanter auf der Sophos.

Ich bin jetzt vor Ort und werde erstmal nochmal die harte Zuweisung testen wegen der DHCP Vergabe.

Hallo,

Zitat von @Xaero1982:

Ihr verwirrt mich.

Nochmal: Es gibt aktuell auf dem Switch nur das Interface im Default-VLAN: 172.16.10.250.
Dort ist auch die Sophos drin mit 172.16.10.1

Das DHCP-Relay gehört auf das Gateway. Wenn der Switch nicht Gateway ist:

schalte das Relay auf dem Switch ab
aktiviere das Relay auf der Sophos.

oder:

oder lass den Switch (IPs in den VLANS)
und aktiviere das Relay auf dem Switch

Grüße

lcer

Nochmal: Es gibt aktuell auf dem Switch nur das Interface im Default-VLAN: 172.16.10.250.

Dort ist auch die Sophos drin mit 172.16.10.1
Und dann ??
Auf der Sophos sind dann auch die VLAN Subinterfaces auf diesem Interface und sie ist mit einem 802.1q Trunk an den Switch angebunden ??
Das kommt alles tropfenweise...

Man hat keinerlei Ahnung WIE du denn nun die VLANs routest ? L2 oder L3 ?

Gut, oben klingt es ja dann nach L2 also der Switch routet NICHT und die Sophos macht alles. Dann ist DHCP Relay (eine L3 Funktion !) natürlich völliger Quatsch auf dem Switch wenn der gar kein L3 macht.
Dann muss das alles logischerweise auf der Sophos aktiviert werden.
Verwirrung komplett...

Kollege @lcer00 hat die einfache Logik dahinter oben ja nochmal zu Recht betont !

Sophos routet = Switch nur L2 = keine Switch VLAN IPs = kein DHCP Relay a.d. Switch
Switch routet = Switch L3 mit VLAN IPs = DHCP Relay a.d. Switch = Sophos keine VLAN

Subinterfaces

Entweder oder ! Du kannst nur ein Konzept anwenden.

Eigentlich doch ganz einfach und hast du als Profi doch schon zigmal umgesetzt.

Zitat von @lcer00:

Hallo,

Zitat von @Xaero1982:

Ihr verwirrt mich.

Nochmal: Es gibt aktuell auf dem Switch nur das Interface im Default-VLAN: 172.16.10.250.
Dort ist auch die Sophos drin mit 172.16.10.1

Das DHCP-Relay gehört auf das Gateway. Wenn der Switch nicht Gateway ist:

schalte das Relay auf dem Switch ab
aktiviere das Relay auf der Sophos.

Grüße

lcer

Hab ich so getan.
Kein Relay aufm Switch.
Relay auf der Sophos aktiv und dort alle VLAN-Schnittstellen drin. Außer Default-VLAN

Ich vermute Ich weiß woran es liegt. Ich bastel das ja gerade parallel zum Produktivsysten und ich sollte das erstmal in die finale Verkabelung bringen mit dem Server etc.

Muss ich am WE machen.

Zitat von @Xaero1982:

Ich vermute Ich weiß woran es liegt. Ich bastel das ja gerade parallel zum Produktivsysten und ich sollte das erstmal in die finale Verkabelung bringen mit dem Server etc.

Muss ich am WE machen.

Wir sind jedenfalls gespannt!

Grüße

lcer

Zitat von @lcer00:

Wir sind jedenfalls gespannt!

Grüße

lcer

Ich auch

ich berichte. Vielleicht geb ich mir das auch schon morgen früh vor Dienstbeginn.
Will das ja auch fertig bekommen.

Grüße

und dort alle VLAN-Schnittstellen drin. Außer Default-VLAN

Und im Default VLAN ist auch den zentraler DHCP Server ??
Bedenke das du auf dem Interface bzw. IP Netz wo sich der zentrale DHCP Server befindet KEIN Relay aktivieren darfst !!
Wir sind dann mal auf das Feeback gespannt ! 😉

Zitat von @aqui:

und dort alle VLAN-Schnittstellen drin. Außer Default-VLAN

Und im Default VLAN ist auch den zentraler DHCP Server ??

Jaha

S.o.

Switch, Server, Sophos, alles im gleichen Netz.

Bedenke das du auf dem Interface bzw. IP Netz wo sich der zentrale DHCP Server befindet KEIN Relay aktivieren darfst !!

Is nicht

Wir sind dann mal auf das Feeback gespannt ! 😉

Ich auch ;)

Jaha

S.o.

Switch, Server, Sophos, alles im gleichen Netz.

Na ja zumindest für die Sophos und den Switch gilt das ja nicht, die sind zusätzlich ja noch in allen VLANs (hoffentlich ?!)

Zitat von @aqui:

Jaha

S.o.

Switch, Server, Sophos, alles im gleichen Netz.

Na ja zumindest für die Sophos und den Switch gilt das ja nicht, die sind zusätzlich ja noch in allen VLANs (hoffentlich ?!)

Ich hab dich auch ganz doll gerne @aqui

Sophos ja, und der Switch hat aktuell nur seine VLANs und keine Interfaces in den VLANS, außer das Default-VLAN

Moin,

Also ich hab jetzt das Relevante umgebaut. Server und Sophos sind auf dem neuen Switch.

Laut Wireshark auf dem Testclient sehe ich wie zuvor:
Dhcp Discover

Die kommen laut Wireshark auch am Server an, welcher eine IP aus dem richtigen VLAN (20) verteilt. Das geht an die Schnittstelle der Sophos mit 172.16.20.252
Offenbar kann die Sophos damit nichts anfangen, weil es kommt nicht beim Client an oder es kommt nicht beim Client an.

Die Authentifizierung läuft. Der Port wird korrekt in VLAN 20 gesteckt.

Sophos hängt am Switch an einem Trunk-Port in dem alle VLANs auf tagged stehen, außer dem default. Das ist auf untagged.

Der Server ist an einem trunk LAG, aber ich vermute hier liegt das Problem.

Beim esx setze ich das Interface auf VLAN 4095 und das geht beim HyperV nicht. Ich weiß halt nicht, ob das dhcp offer überhaupt an der Sophos ankommt.

https://www.kaiherzig.eu/hyperv-switch-vlan-trunking/

muss ich das zufällig auch so einrichten? Will mir irgendwie nicht in den Kopf.

Authentifizierung außen vor.

Client schickt sein DHCP Discover ins Netz
Sophos schickt das weiter an den DHCP
DHCP bekommt das Discover und sendet seinerseits ein DHCP Offer.
Offer sollte zurück zur Sophos und diese widerum zum Client.
Am Client kommt aber kein Offer an.

Nur wenn der Client im Default-VLAN ist bekomme ich eine IP. D.h. doch aber im Grunde, dass der Server keine separate VLAN Config benötigt? Das macht doch alles die Sophos?

Oder steh ich aufm Schlauch?

Ich glaub es läuft

Guten Morgen,

ist das noch eine Sophos UTM oder schon eine XG?
Bei der UTM gab es im DHCP Relay die Eigenheit, dass bei der Interfaceliste auch das Interface des DHCP-Servers enthalten sein muss, siehe auch https://support.sophos.com/support/s/article/KB-000035988?language=en_US.
Widerspricht etwas dem gesunden Netzwerkerverstand, aber ist bei Sophos wohl so. Hab ich anfangs auch etwas gebraucht, bis ich das rausgefunden hatte.

Beim esx setze ich das Interface auf VLAN 4095 und das geht beim HyperV nicht. Ich weiß halt nicht, ob das dhcp offer überhaupt an der Sophos ankommt.

Du kannst beim Hyper-V doch einfach ein VLAN-Tag in den vNIC-Eigenschaften der VM angeben? Finde das sogar einfacher als bei VMware.

Viele Grüße
mxrecord

Moin,

zu früh gefreut. Funktionierte an dem PC an dem das Profil schon mal geladen war.

Das mit dem Interface bei der Sophos hab ich auch gefunden. Danach ging es dann auch erstmal irgendwie. Dazu gleich. Ist eine Sophos UTM.

Es bringt mir doch aber nichts nur ein VLAN Tag mitzugeben. Ich hab hier fast 20 VLANs. Beim ESX habe ich mit TAG 4095 einfach alles mitgegeben.

So aktuell sieht es so aus:

Ich melde mich an und irgendwann kommt dann die Meldung, dass die Domäne nicht verfügbar sei. Wenn ich mich mit einem vorhandenen Profil anmelde geht das und ich habe auch eine IP aus dem VLAN 20. Irgendwas fehlt noch beim Anmeldevorgang.

Danke euch!

Zitat von @Xaero1982:

Moin,

zu früh gefreut. Funktionierte an dem PC an dem das Profil schon mal geladen war.

Zwischengespeicherte Anmeldeinformationen?

Das mit dem Interface bei der Sophos hab ich auch gefunden. Danach ging es dann auch erstmal irgendwie. Dazu gleich. Ist eine Sophos UTM.

Soll das Heißen, DHCP funktioniert jetzt?

Es bringt mir doch aber nichts nur ein VLAN Tag mitzugeben. Ich hab hier fast 20 VLANs. Beim ESX habe ich mit TAG 4095 einfach alles mitgegeben.

Was meinst Du damit?

So aktuell sieht es so aus:

Ich melde mich an und irgendwann kommt dann die Meldung, dass die Domäne nicht verfügbar sei. Wenn ich mich mit einem vorhandenen Profil anmelde geht das und ich habe auch eine IP aus dem VLAN 20. Irgendwas fehlt noch beim Anmeldevorgang.

Siehe oben!!!!!!!!
Der Anmeldevorgang benötigt zwingend eine erfolgreiche Computerauthentifizierung. Hast Du Das in den Adapteroptionen am PC eingestellt UND eine Computerauthentifizierung-Netzwerkrichtlinie auf dem NPS erstellt?

Damit eine Domänenanmeldung klappt muss entweder "Computerauthentifizierung" eingestellt sein oder "Computer - oder Benutzerauthentifizierung" keinesfalls nur "Benutzerauthentifizierung". Überprüfe das am PC direkt! Wenn Du nur die GPO änderst, kann der nicht authentifizierte PC das GPO-Update natürlich nicht durchführen!

Grüße

lcer

Zitat von @lcer00:

Zitat von @Xaero1982:

Moin,

zu früh gefreut. Funktionierte an dem PC an dem das Profil schon mal geladen war.

Zwischengespeicherte Anmeldeinformationen?

Ja, das Profil war ja auf der Kiste schon mal angemeldet. Damit ging es. Inzwischen habe ich rausbekommen, dass es ohne Firewallrichtlinie aus den VLANs auf den Server nicht klappt. Nachdem ich die eingefügt habe konnte ich mich anmelden. ABER ich kann mich nicht korrekt abmelden. Hier sind roaming profiles im Einsatz und die werden nach der Abmeldung nicht synchronisiert.

Das mit dem Interface bei der Sophos hab ich auch gefunden. Danach ging es dann auch erstmal irgendwie. Dazu gleich. Ist eine Sophos UTM.

Soll das Heißen, DHCP funktioniert jetzt?

DHCP funktioniert jetzt nachdem ich noch eine Firewallregel eingefügt habe.

Es bringt mir doch aber nichts nur ein VLAN Tag mitzugeben. Ich hab hier fast 20 VLANs. Beim ESX habe ich mit TAG 4095 einfach alles mitgegeben.

Was meinst Du damit?

Das ich beim ESX mit VLAN TAG 4095 alle VLANs übertragen kann. Geht so beim Hyper V nicht.

Das ist doch schon laaaange passiert nachdem du das geschrieben hattest

Es gibt eine NPS Richlinie für Computer. Da habe ich aktuell meine Testsysteme drin und das wird auch brav zugewiesen.
Danach gibt es entsprechende Richtlinien für die jeweiligen VLANs. Auch das klappt wunderbar.

Einzig die Abmeldung läuft jetzt nicht - da bekomme ich wie gesagt immer einen Synchronisationsfehler. Der Server ist nicht erreichbar.
Any ideas?

Grüße und danke

Geiler Schei**
https://mskb.pkisolutions.com/kb/2826201

Offenbar geht nicht beides. Roaming Profile + 802.1x - Yeah!

Zitat von @Xaero1982:

Geiler Schei**
https://mskb.pkisolutions.com/kb/2826201

Offenbar geht nicht beides. Roaming Profile + 802.1x - Yeah!

However, if the roaming profile exceeds a size of 10 megabytes (MB), you experience problems.

10MB! Wow! OK. Das kannte ich noch nicht. Danke.

Grüße

lcer

Die haben hier alle über 10mb ...

Naja also grds. funktioniert nun alles, wenn ich es richtig sehe.

Roaming Profiles muss ich sehen. Muss ich dann mal effektiv bei einem User mit großem Profil testen. Mit meinem und den Testprofilen scheint es zu gehen und meins ist 652mb groß. Das Testprofil 4,58mb.

Ich danke dir für deine Hilfe @icer00 und auch dir @aqui und natürlich @mxrecord und den anderen