25
Radius auth. funktioniert nicht durch einen statischen VPN Tunnel?
Hallo,
ich hoffe das hier jemand etwas input hat zu meinem Problem.
Setup: 2x Win Server2008R2 mit NPS (1x backup), in site 1.
Unifi VM mit WLAN Setup (site 1), access points verteilt in site 1 und (per VPN) site 2.
Bei site 1 funktioniert die auth. per Radius, von site 2 nicht.
Site 1: https://hastebin.com/gagurowahu.css
Site 2: https://hastebin.com/kicacunugi.css
Firewall ist alles offen im Tunnel, auch alles andere geht ohne Problem durch den Tunnel.
Hat jemand eine Idee was das grob sein könnte?
Viele Grüsse
David
ich hoffe das hier jemand etwas input hat zu meinem Problem.
Setup: 2x Win Server2008R2 mit NPS (1x backup), in site 1.
Unifi VM mit WLAN Setup (site 1), access points verteilt in site 1 und (per VPN) site 2.
Bei site 1 funktioniert die auth. per Radius, von site 2 nicht.
Site 1: https://hastebin.com/gagurowahu.css
Site 2: https://hastebin.com/kicacunugi.css
Firewall ist alles offen im Tunnel, auch alles andere geht ohne Problem durch den Tunnel.
Hat jemand eine Idee was das grob sein könnte?
Viele Grüsse
David
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 605029
Url: https://administrator.de/forum/radius-auth-funktioniert-nicht-durch-einen-statischen-vpn-tunnel-605029.html
Ausgedruckt am: 22.04.2025 um 16:04 Uhr
25 Kommentare
Neuester Kommentar
Bitte keine externen Links.....Du kannst die Bilder auch hier hochladen. Danke.
Hallo, sind keine Bilder sondern logs. Sollte ich die direkt einfügen?
Jep....
mit
Codeblock einfügen bleibt das gut lesbar.
mit
Codeblock einfügen bleibt das gut lesbar.
Kann es nicht editieren da es zu viele Änderungen sind...
dann poste es neu drunter.....
Klar doch!
Site 1 wo es klappt:
Site 2 wo es nicht geht:
Site 1 wo es klappt:
Network Policy Server granted access to a user.
User:
Security ID: DOMAIN\user.name
Account Name: user.name
Account Domain: DOMAIN
Fully Qualified Account Name: DOMAIN\user.name
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: 8A-8A-20-C9-F7-D7:companyname AG Corporate
Calling Station Identifier: 20-6D-F3-40-26-58
NAS:
NAS IPv4 Address: -
NAS IPv6 Address: -
NAS Identifier: 8a8a20c9f7d7
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: -
RADIUS Client:
Client Friendly Name: AP-R12-04
Client IP Address: 172.16.0.34
Authentication Details:
Connection Request Policy Name: companyname AG Corp Wifi new
Network Policy Name: companyname AG Corp Wifi new
Authentication Provider: Windows
Authentication Server: server02.domain.local
Authentication Type: PEAP
EAP Type: Microsoft: Secured password (EAP-MSCHAP v2)
Account Session Identifier: 36393933373842323643453536453341
Logging Results: Accounting information was written to the local log file.Site 2 wo es nicht geht:
Network Policy Server discarded the request for a user.
Contact the Network Policy Server administrator for more information.
User:
Security ID: NULL SID
Account Name: user.name
Account Domain: -
Fully Qualified Account Name: -
Client Machine:
Security ID: NULL SID
Account Name: -
Fully Qualified Account Name: -
Called Station Identifier: 0E-EC-DA-FE-E5-07:companyname AG Corporate
Calling Station Identifier: 20-6D-F3-40-26-58
NAS:
NAS IPv4 Address: -
NAS IPv6 Address: -
NAS Identifier: 0eecdafee507
NAS Port-Type: Wireless - IEEE 802.11
NAS Port: -
RADIUS Client:
Client Friendly Name: AP-R28-06
Client IP Address: 172.16.0.56
Authentication Details:
Connection Request Policy Name: companyname AG Corp Wifi new
Network Policy Name: -
Authentication Provider: Windows
Authentication Server: server02.domain.local
Authentication Type: -
EAP Type: -
Account Session Identifier: 46373141314130354239364334454134
Reason Code: 3
Reason: The RADIUS Request message that Network Policy Server received from the network access server was malformed.
Zeigt ja das die Radius Requests ggf. nicht ankommen am Server bzw. nicht durch den VPN Tunnel geroutet werden ?!
Ein Traceroute an die Ziel IP wäre also hilfreich um zu sehen das der Request wirklich durch den Tunnel geht.
Hast du das zusätzlich auch einmal mit NTRadPing Check wasserdicht getestet von der Seite ?
https://support.secureauth.com/hc/en-us/articles/360019651812-How-To-Tes ...
Weitere Infos zu so einem Setup auch HIER.
Ein Traceroute an die Ziel IP wäre also hilfreich um zu sehen das der Request wirklich durch den Tunnel geht.
Hast du das zusätzlich auch einmal mit NTRadPing Check wasserdicht getestet von der Seite ?
https://support.secureauth.com/hc/en-us/articles/360019651812-How-To-Tes ...
Weitere Infos zu so einem Setup auch HIER.
1
Hat die Site2 keinen eigenen DC? Sind die User an Site2 Domain-User?
...läßt ein wenig daran zweifeln.
User:
Security ID: NULL SID
Account Name: user.name
Account Domain: -
Fully Qualified Account Name: -...läßt ein wenig daran zweifeln.
Ja, domain controller sind aber nur bei site1. Domain logon funktioniert von dortigen Win Maschinen auch ohne Probleme. Ist nur das WLAN das da nicht klappt...
Das lässt mich ja daran denken das da im Tunnel verloren geht, kann aber kaum sein. Ist ja alles offen für den Tunnel?
Der Unifi Controller kennt auch das Netzwerk an Site2?
Welche Controller-Version hast Du laufen?
Welche Controller-Version hast Du laufen?
kann aber kaum sein. Ist ja alles offen für den Tunnel?
Sein kann alles wenn das VPN falsch konfiguriert wurde !!!Ein Traceroute oder Pathping klärt das aber innerhalb von Sekunden...
Ist alles soweit ping-bar.
Alles AP's sind im 172.16.0/21 (stretched LAN über die beiden Sites).
RADIUS Server sind aber auf Site 1 in einem 192.168.1.1/24 subnet (legacy).
Pingbar ist alles von allen Seiten.
Alles AP's sind im 172.16.0/21 (stretched LAN über die beiden Sites).
RADIUS Server sind aber auf Site 1 in einem 192.168.1.1/24 subnet (legacy).
Pingbar ist alles von allen Seiten.
Dann einmal den Radius Server debuggen. Wenns ein FreeRadius ist mit freeradius -X. Oder in dessen Log sehen was passiert wenn Radius Requests vom remoten Standort dort eingehen.
Wenns ein Winblows Radius (NPS) ist, könnte die lokale Firewall remote Requests blocken wenn man die nicht customized hat !
Sehr hilfreich wäre auch ein Wireshark Trace am Radius Server Standort der mal den spezifischen Radius Request des remoten APs und auch den Reply des Servers mitschneidet. Damit kann man schon zu 98% sehen wo ein mögliches Problem liegt.
Wenns ein Winblows Radius (NPS) ist, könnte die lokale Firewall remote Requests blocken wenn man die nicht customized hat !
Sehr hilfreich wäre auch ein Wireshark Trace am Radius Server Standort der mal den spezifischen Radius Request des remoten APs und auch den Reply des Servers mitschneidet. Damit kann man schon zu 98% sehen wo ein mögliches Problem liegt.
1
Ist leider Winblows...
Firewall lässt alles zu den relevanten Ports zu.
Da fehlt mir etwas wissen denke ich, aber in Wireshark sieht ein dump auf dem ADC so aus:
Sieht das nach was brauchbaren aus? Welchen Inhalt sollte ich genauer anschauen?
Bin da definitiv etwas n00b, danke darum für Geduld und Hilfe!
Firewall lässt alles zu den relevanten Ports zu.
Da fehlt mir etwas wissen denke ich, aber in Wireshark sieht ein dump auf dem ADC so aus:
Sieht das nach was brauchbaren aus? Welchen Inhalt sollte ich genauer anschauen?
Bin da definitiv etwas n00b, danke darum für Geduld und Hilfe!
Hilfreich wäre gewesen wenn du zu den IP Adressen einmal angegeben hättest wer wer ist. Also raten wir mal im freien Fall... 192.168.141.10 = Radius Server und 172.16.0.56 = WLAN AP, richtig ?!
Das Problem ist aber schon sofort auch für einen Laien zu sehen !
Der Server antwortet ja nicht auf den Radius Request den der AP verzweifelt immer und immer wieder sendet. Bzw. nur ein einziges Mal.
Da gibt es mehrere Möglichkeiten einer Ursache:
Wenn du dir im Wireshark den Request Paket Inhalt ansiehst (mittleres Wireshark Fenster) dann siehst du auch genau was der AP an Daten an den Radius Server übermittelt. Auch die "Challenge" Antwort wäre mal interessant vom Inhalt. Leider fehlt das.
Auch das NPS Server Log wäre hilfreich. Sofern der Radius diesen Request überhaupt "sieht" und die lokale Firewall ihn nicht eh schon vorher weggefischt hat.
Aber der Fehler ist eindeutig. Request kommt fehlerfrei am Server an, Server antwortet nicht auf den Request.
Das Problem ist aber schon sofort auch für einen Laien zu sehen !
Der Server antwortet ja nicht auf den Radius Request den der AP verzweifelt immer und immer wieder sendet. Bzw. nur ein einziges Mal.
Da gibt es mehrere Möglichkeiten einer Ursache:
- Das 172.16.0.0 /24 er Netz ist im Radius vergessen worden einzutragen das dort Requests akzeptiert werden. (Entspricht der client.conf im FreeRadius Server)
- Das Radius Passwort ist falsch oder gar nicht eingetragen worden im AP (Case sensitive !)
- Die Winblows Firewall blockt Zugriffe aus dem 172.16.0.0er Netz
Wenn du dir im Wireshark den Request Paket Inhalt ansiehst (mittleres Wireshark Fenster) dann siehst du auch genau was der AP an Daten an den Radius Server übermittelt. Auch die "Challenge" Antwort wäre mal interessant vom Inhalt. Leider fehlt das.
Auch das NPS Server Log wäre hilfreich. Sofern der Radius diesen Request überhaupt "sieht" und die lokale Firewall ihn nicht eh schon vorher weggefischt hat.
Aber der Fehler ist eindeutig. Request kommt fehlerfrei am Server an, Server antwortet nicht auf den Request.
Hallo aqui,
danke für deine Hilfe!
Leider kann ich die 3 Punkte ausschliessen, bin mir sicher:
1. Das Netz ist das Gleiche, egal von welcher Site (spanned per VPN Tunnel)
2. Passwort stimmt, ist per Template und somit gleich auf beiden Sites.
3. Winblows firewall erlaubt NPS den Zugriff ohne Einschränkung.
Auch sieht es ja auf als kommt was an beim Radius NPS server:
Nun frage ich mich ob hier doch im Tunnel was verloren geht? Sollte nicht, da auch in den PFsense firewalls alles durch den Tunnel erlaubt ist.
Schwieriger Fall?
danke für deine Hilfe!
Leider kann ich die 3 Punkte ausschliessen, bin mir sicher:
1. Das Netz ist das Gleiche, egal von welcher Site (spanned per VPN Tunnel)
2. Passwort stimmt, ist per Template und somit gleich auf beiden Sites.
3. Winblows firewall erlaubt NPS den Zugriff ohne Einschränkung.
Auch sieht es ja auf als kommt was an beim Radius NPS server:
Nun frage ich mich ob hier doch im Tunnel was verloren geht? Sollte nicht, da auch in den PFsense firewalls alles durch den Tunnel erlaubt ist.
Schwieriger Fall?
1. Das Netz ist das Gleiche, egal von welcher Site (spanned per VPN Tunnel)
Ooops...wie ?? Das geht IP technisch gar nicht ! Guckst du hier:VPNs einrichten mit PPTP
Netze müssen einzigartig sein. Doppelte IPs gibts in keinem Netz. Das lernt der IT Azubi im ersten Lehrjahr !
Oder ist das jetzt falsch verstanden ??
Nun frage ich mich ob hier doch im Tunnel was verloren geht?
Wäre denkbar und kommt ab und zu mal vor.Das passiert wenn du einen MTU Mismatisch im Tunnel hast. Also Frames mit zu großer MTU die dann nicht fragmentiert werden können. Kommt mal vor im VPN Umfeld wenn deine VPN Systeme kein MTU Path Discovery supporten.
Kann man aber ganz gut mit Pings testen:
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/de/31507/Festlegen-der-optimalen-MTU-Grö ...
https://packetlife.net/blog/2008/aug/18/path-mtu-discovery/
Hi aqui,
OK, da hab ich mich sicher nicht richtig ausgedrückt, sorry!
Adressen sind nie doppelt vergeben, da weiss ich andere Arten um mich zu quälen :D
Die DHCP Server auf beiden Seiten vergeben andere Ranges innerhalb des /21 Netzes.
MTU Path Discovery. Klingt mal interessant, schaue ich mir an. Danke auch für die Links!
Viele Grüsse
David
OK, da hab ich mich sicher nicht richtig ausgedrückt, sorry!
Adressen sind nie doppelt vergeben, da weiss ich andere Arten um mich zu quälen :D
Die DHCP Server auf beiden Seiten vergeben andere Ranges innerhalb des /21 Netzes.
MTU Path Discovery. Klingt mal interessant, schaue ich mir an. Danke auch für die Links!
Viele Grüsse
David
Die DHCP Server auf beiden Seiten vergeben andere Ranges innerhalb des /21 Netzes.
Wieder wirr und unverständlich !! Bedeutet das denn nun das du zwei mal das gleiche /21er IP Netz auf beiden Seiten hast ??
Sprich z.B. 172.16.0.0 /21 also mit Hostadressen von 172.16.0.1 bis 172.16.7.254 ??
DHCP Endgeräte Adressen spielen da keinerlei Rolle. Sowie dort 2 identische IP Netz auftauchen bedeutet das den Todesstoß fürs VPN bzw. generell für ein IP Netz. Dann wären 2 gleiche IP Netze in einem Netzwerk was es niemals geben darf auch ohne VPN.
Solche IP Adress Banalitäten kennst du auch selber, denn mit mehreren gleichen IP Netzen wäre eine eindeutige Wegefindung (Routing) technisch ja vollkommen unmöglich !
Wäre sicher hilfreich und zielführend du skizzierst hier mal deine IP Adressierung um zu checken ob du ggf. schon gleich an einem simplen Kardinalsfehler im Adressdesign scheiterst ?!
Ich muss mal lernen das besser aus zu drücken...
Es gibt 1x Netz 172.16.0.0/21.
Bei Seite 1 gibt es einiges statisch gesetztes, DHCP nur 172.16.2.1 - 254
Bei Seite 2 gibt es einiges statisch gesetztes, DHCP nur 172.16.3.1 - 254
Das ist soweit auch alles gut, es gibt sicher keine doppelt vergebenen IPs!
Gerade gesehen das das virtuelle VPN interface auf der PFsense einen MTU von 1400 gesetzt hat (hat wohl mein Vorgänger so gemacht).
Von meiner Maschine den AP auf Seite 2 pinge:
Liegt hier eventuell der Hund begraben?
Es gibt 1x Netz 172.16.0.0/21.
Bei Seite 1 gibt es einiges statisch gesetztes, DHCP nur 172.16.2.1 - 254
Bei Seite 2 gibt es einiges statisch gesetztes, DHCP nur 172.16.3.1 - 254
Das ist soweit auch alles gut, es gibt sicher keine doppelt vergebenen IPs!
Gerade gesehen das das virtuelle VPN interface auf der PFsense einen MTU von 1400 gesetzt hat (hat wohl mein Vorgänger so gemacht).
Von meiner Maschine den AP auf Seite 2 pinge:
ping -s 1400 172.16.0.56
PING 172.16.0.56 (172.16.0.56) 1400(1428) bytes of data.
^C
--- 172.16.0.56 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2024msping -s 1300 172.16.0.56
PING 172.16.0.56 (172.16.0.56) 1300(1328) bytes of data.
1308 bytes from 172.16.0.56: icmp_seq=1 ttl=64 time=1.97 ms
1308 bytes from 172.16.0.56: icmp_seq=2 ttl=64 time=1.53 msLiegt hier eventuell der Hund begraben?
Es gibt 1x Netz 172.16.0.0/21. Bei Seite 1 gibt es einiges statisch gesetztes, DHCP nur 172.16.2.1 - 254
Bei Seite 2 gibt es einiges statisch gesetztes, DHCP nur 172.16.3.1 - 254Geht nicht ! Routingtechnischer Todesstoß
Sorry aber, solche IP Banalitäten lernt doch schon Fritzchen Müller in der IP Grundschule !
Siehst du auch selber: GLEICHES IP Netz auf beiden Seiten.
WIE stellst du dir denn vor wie man das routen soll...???
Liegt hier eventuell der Hund begraben?
Natürlich. Das du das nicht sofort gesehen hast spricht aber jetzt nicht gerade für deine IP Wissenskompetenz um das jetzt mal sehr vorsichtig und politisch korrekt auszudrücken. Das IP Netz geht doch von 172.16.0.1 bis 172.16.7.254 und rein nur der Netzwerk Part in der Adresse zählt für die Wegefindung ??
IP technisch richtig wäre:
- Seite 1: 172.16.0.0 /21 (DHCP z.B. 172.16.2.1 - .254)
- Seite 2: 172.16.8.0 /21 (DHCP z.B. 172.16.9.1 - .254)
Allein solche großen Subnetz Masken sind per se schon ein Fehler im Design. (Sofern man dort eben mehr als diese max. 150 Clients betreibt !)
Danke nochmals für den Wink mit dem Zaunpfahl!
Ich war nie auf einer IP Grundschule.
Auch habe ich das Setup nicht gemacht, sondern übernommen, heißt nicht das ich hier nicht etwas von Grund auf besser machen sollte.
Schönen kleinen Freitag, VG
David
Ich war nie auf einer IP Grundschule.
Auch habe ich das Setup nicht gemacht, sondern übernommen, heißt nicht das ich hier nicht etwas von Grund auf besser machen sollte.
Schönen kleinen Freitag, VG
David
Ich war nie auf einer IP Grundschule.
Oha ! Aber dafür gibts ja das Forum hier. Wir haben genug Zaunpfähle und Kristallkugeln. Wenn's das denn nun war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Hier noch ein Nachtrag.
Problem ist/war nicht das Routing hier im Netz, sondern Pakete die als Antwort vom NPS server kamen, die aufgrund ihrer Grösse silently dropped wurden.
MTU und so lustige Sachen...
Im NPS gibt es ein Framed-MTU setting, das richtig eingestellt das zum laufen gebracht hat.
Aufschluss hatte ein TCPDUMP gegeben, wo man schön sehen konnte das nichts retour kam vom NPS server.
Schönes WE allen!
Problem ist/war nicht das Routing hier im Netz, sondern Pakete die als Antwort vom NPS server kamen, die aufgrund ihrer Grösse silently dropped wurden.
MTU und so lustige Sachen...
Im NPS gibt es ein Framed-MTU setting, das richtig eingestellt das zum laufen gebracht hat.
Aufschluss hatte ein TCPDUMP gegeben, wo man schön sehen konnte das nichts retour kam vom NPS server.
Schönes WE allen!
