ogghi88
Sep 16, 2020
view2301
view25
0
Goto Top

Radius auth. funktioniert nicht durch einen statischen VPN Tunnel?

GermansolvedQuestionLAN, WAN, WirelessNetworks
Hallo,

ich hoffe das hier jemand etwas input hat zu meinem Problem. face-smile

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
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 605029

Url: https://administrator.de/contentid/605029

Printed on: April 26, 2024 at 07:04 o'clock

25 Comments
Latest comment
Goto Top
Member: Looser27
Looser27 Sep 16, 2020 at 11:20:40 (UTC)
Goto Top
Bitte keine externen Links.....Du kannst die Bilder auch hier hochladen. Danke.
Member: ogghi88
ogghi88 Sep 16, 2020 at 11:30:12 (UTC)
Goto Top
Hallo, sind keine Bilder sondern logs. Sollte ich die direkt einfügen?
Member: Looser27
Looser27 Sep 16, 2020 at 11:32:39 (UTC)
Goto Top
Jep....

mit

Codeblock einfügen bleibt das gut lesbar.
Member: ogghi88
ogghi88 Sep 16, 2020 at 11:43:26 (UTC)
Goto Top
Kann es nicht editieren da es zu viele Änderungen sind...
Member: Looser27
Looser27 Sep 16, 2020 at 11:46:30 (UTC)
Goto Top
dann poste es neu drunter.....
Member: ogghi88
ogghi88 Sep 16, 2020 at 12:49:02 (UTC)
Goto Top
Klar doch!

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.
Member: aqui
aqui Sep 17, 2020 at 07:05:08 (UTC)
Goto Top
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.
heart1
Member: Looser27
Looser27 Sep 17, 2020 at 07:18:18 (UTC)
Goto Top
Hat die Site2 keinen eigenen DC? Sind die User an Site2 Domain-User?

User:
	Security ID:			NULL SID
	Account Name:			user.name
	Account Domain:			-
	Fully Qualified Account Name:	-

...läßt ein wenig daran zweifeln.
Member: ogghi88
ogghi88 Sep 17, 2020 at 07:22:55 (UTC)
Goto Top
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...
Member: ogghi88
ogghi88 Sep 18, 2020 at 12:10:21 (UTC)
Goto Top
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?
Member: Looser27
Looser27 Sep 18, 2020 updated at 12:17:13 (UTC)
Goto Top
Der Unifi Controller kennt auch das Netzwerk an Site2?
Welche Controller-Version hast Du laufen?
Member: aqui
aqui Sep 18, 2020 at 12:51:07 (UTC)
Goto Top
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... face-wink
Member: ogghi88
ogghi88 Sep 18, 2020 at 14:38:18 (UTC)
Goto Top
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.
Member: aqui
aqui Sep 18, 2020 updated at 16:04:01 (UTC)
Goto Top
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.
heart1
Member: ogghi88
ogghi88 Sep 21, 2020 at 11:48:06 (UTC)
Goto Top
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:

tcpdump

Sieht das nach was brauchbaren aus? Welchen Inhalt sollte ich genauer anschauen?
Bin da definitiv etwas n00b, danke darum für Geduld und Hilfe!
Member: aqui
aqui Sep 21, 2020 updated at 14:05:31 (UTC)
Goto Top
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:
  • 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
Eins oder alle 3 dieser Punkte ist es.
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. face-sad
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.
Member: ogghi88
ogghi88 Sep 23, 2020 at 08:39:20 (UTC)
Goto Top
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:

radius.again


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?
Member: aqui
aqui Sep 24, 2020 updated at 09:40:43 (UTC)
Goto Top
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/
Member: ogghi88
ogghi88 Sep 24, 2020 at 09:53:21 (UTC)
Goto Top
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
Member: aqui
aqui Sep 24, 2020 updated at 10:04:02 (UTC)
Goto Top
Die DHCP Server auf beiden Seiten vergeben andere Ranges innerhalb des /21 Netzes.
Wieder wirr und unverständlich !! face-sad
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 ?!
Member: ogghi88
ogghi88 Sep 24, 2020 at 10:12:56 (UTC)
Goto Top
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:

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 2024ms

ping -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 ms



Liegt hier eventuell der Hund begraben?
Member: aqui
aqui Sep 24, 2020 updated at 10:37:57 (UTC)
Goto Top
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
Geht 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. face-wink
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)
Mal ganz davon abgesehen das es auf Netzwerk technischer Unsinn ist mehr als 100 bus 150 Hosts in einer Layer 2 Collision Domain zu haben. Jeder Netzwerker weiss das und kennt diese "goldene Regel".
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 !)
Member: ogghi88
ogghi88 Sep 24, 2020 at 10:43:56 (UTC)
Goto Top
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
Member: aqui
aqui Sep 24, 2020 at 12:25:56 (UTC)
Goto Top
Ich war nie auf einer IP Grundschule.
Oha ! Aber dafür gibts ja das Forum hier. Wir haben genug Zaunpfähle und Kristallkugeln. face-wink

Wenn's das denn nun war bitte dann auch
How can I mark a post as solved?
nicht vergessen.
Member: ogghi88
ogghi88 Oct 09, 2020 at 11:36:12 (UTC)
Goto Top
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!
GermansolvedQuestionLAN, WAN, WirelessNetworks