OPNsense Forum
International Forums => German - Deutsch => Topic started by: senser8912 on November 19, 2022, 12:38:22 pm
-
Hallo zusammen,
habe heute morgen auf 22.7.8 geupdated.
In dem Zuge wurde freeradius auf 3.2.1 gebracht.
Nun verbinden sich aber leider meine WLAN-Clients nicht mehr, Fehlermeldung siehe unten.
Ich habe die config von freeradius gecheckt, dieses auch mal neu installiert.
Außerdem wurde der komplette Weg vom WLAN-Client bis zur opnSense überprüft, ich finde soweit keinen Fehler.
Fehlermeldung googlen hilft leider auch nicht.
Habt ihr eine Idee, oder gar das selbe Problem?
Auth: (25) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [USERNAME/<via Auth-Type = eap>] (from client ACCESSPOINT port 0 cli XX-XX-XX-XX-XX-XX)
Auth: (25) Login incorrect: [USERNAME/<via Auth-Type = Reject>] (from client ACCESSPOINT port 0 cli XX-XX-XX-XX-XX-XX via TLS tunnel)
-
Libressl oder Openssl
-
Moin!
Habe openssl im Einsatz.
-
Welche Version war vorher drauf?
-
Kann ich leider nicht mehr sagen.
Da ich aber regelmäßig update sage ich jetzt mal ganz flach: Die, die vorher der Standard war.
-
Update: Ich konnte das Problem zwar lösen, aber nur sehr unzufriedenstellend:
Der config-Parameter "Check TLS-Common-Name" machte Probleme.
Nehme ich diesen heraus, können sich die Geräte wie gewohnt einloggen.
Nun habe ich aber natürlich ein neues Problem: Solange man ein gültiges Zertifikat hat, kann man sich quasi als ein beliebiger User anmelden.
Das Zertifikat mit dem common-Name "mueller" kann nun plötzlich von "schneider" verwendet werden.
Liegt hier ggfs. ein Bug vor?
Denn die common-names stimmen mit den Usernames überein und vorher hat alles funktioniert...
-
Frag doch mal im FreeRADIUS Forum/Mailingliste/Discord/...
Was auch immer die haben. Scheint ja eine Änderung in der neueren Version zu sein.
-
Wenn du den Parameter raus nimmst deaktivierst du den Zertifikatscheck oder nicht? Würde ja dann das Verhalten erklären
-
Kann den Fehler / das Feature bestätigen nach Update der OPNsense
os-freeradius 1.9.20
freeradius3 3.0.25
Auth: (153) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [XYZPhone/<via Auth-Type = eap>] (from client WiFi-AP port 0 cli xx-xx-xx-xx-xx-xx)
Google Pixel 7 mit letztem Patch Stand.
Ein Xiaomi Mi 10 hat allerdings keine Probleme sich im WiFi anzumelden. Da geht es weiterhin.
Was ist das nun?
-
Das letzte Update installiert nicht Freeradius 3.0
25?
-
@mimugmail: Soweit ich das verstehe wird schon noch grundsätzlich ein gültiges Zertifikat benötigt.
Allerdings kann man sich seinen Useraccount eben quasi frei aussuchen.
-
https://github.com/FreeRADIUS/freeradius-server/issues/4753
Da gibt es diesen Fehler bereits.
Das Xiaomi kann sich jetzt ebenfalls nicht mehr anmelden. Vermutlich die Sitzung abgelaufen und Neuanmeldung jetzt auch nicht mehr möglich.
Was mein Laptop macht kann ich gerade nicht sagen, da dieser noch nicht eingeschaltet war. Ich vermute das selbige.
Demnach ein größeres Problem was behoben werden müsste.
mein Updateverlauf (auf opnsense gefiltert, kurioserweise wird das freeradius Paket/Plugin nirgends im Log angezeigt...)
und das Update von heut morgen hat eben das FreeRadius Problem/Feature eingebaut.
2022-11-22T07:56:31 Notice pkg-static opnsense-update upgraded: 22.7.3 -> 22.7.7
2022-09-01T21:09:10 Notice pkg-static opnsense upgraded: 22.7.3_1 -> 22.7.3_2
2022-09-01T21:01:41 Notice pkg-static opnsense upgraded: 22.7.2 -> 22.7.3_1
2022-09-01T21:01:20 Notice pkg-static opnsense-lang upgraded: 22.7.1 -> 22.7.3
2022-09-01T21:01:19 Notice pkg-static opnsense-update upgraded: 22.7.2 -> 22.7.3
2022-08-27T07:07:47 Notice pkg-static opnsense upgraded: 22.7.1 -> 22.7.2
2022-08-27T07:07:07 Notice pkg-static opnsense-update upgraded: 22.7 -> 22.7.2
-
https://github.com/FreeRADIUS/freeradius-server/issues/4753
Da gibt es diesen Fehler bereits.
Das Xiaomi kann sich jetzt ebenfalls nicht mehr anmelden. Vermutlich die Sitzung abgelaufen und Neuanmeldung jetzt auch nicht mehr möglich.
Was mein Laptop macht kann ich gerade nicht sagen, da dieser noch nicht eingeschaltet war. Ich vermute das selbige.
Demnach ein größeres Problem was behoben werden müsste.
mein Updateverlauf (auf opnsense gefiltert, kurioserweise wird das freeradius Paket/Plugin nirgends im Log angezeigt...)
und das Update von heut morgen hat eben das FreeRadius Problem/Feature eingebaut.
2022-11-22T07:56:31 Notice pkg-static opnsense-update upgraded: 22.7.3 -> 22.7.7
2022-09-01T21:09:10 Notice pkg-static opnsense upgraded: 22.7.3_1 -> 22.7.3_2
2022-09-01T21:01:41 Notice pkg-static opnsense upgraded: 22.7.2 -> 22.7.3_1
2022-09-01T21:01:20 Notice pkg-static opnsense-lang upgraded: 22.7.1 -> 22.7.3
2022-09-01T21:01:19 Notice pkg-static opnsense-update upgraded: 22.7.2 -> 22.7.3
2022-08-27T07:07:47 Notice pkg-static opnsense upgraded: 22.7.1 -> 22.7.2
2022-08-27T07:07:07 Notice pkg-static opnsense-update upgraded: 22.7 -> 22.7.2
Also mit 22.7.3_2 ging alles noch?
Dann Test1:
opnsense-revert -r 22.7.3_2 os-freeradius
Dann reboot .. wenn es dann nicht geht
Test2:
opnsense-revert -r 22.7.3_2 freeradius3
Wieder reboot und dann sollte es funktinieren und bitte Ergebnis hier posten.
-
Reboot ist gemacht. Allerdings musste ich die Version anpassen.
Ich beobachte jetzt
root@:~ # opnsense-revert -r 22.7.3_2 os-freeradius
Fetching os-freeradius.pkg: ..[fetch: https://mirror.dns-root.de/op
nsense/FreeBSD:13:amd64/22.7/MINT/22.7.3_2/OpenSSL/Latest/os-freera
dius.pkg.sig: Not Found] failed
root@:~ # opnsense-revert -r 22.7.3 os-freeradius ��
Fetching os-freeradius.pkg: ... done
Verifying signature with trusted certificate pkg.opnsense.org.20220
701... done
os-freeradius-1.9.20: already unlocked
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
os-freeradius: 1.9.20
Number of packages to be installed: 1
[1/1] Installing os-freeradius-1.9.20...
Extracting os-freeradius-1.9.20: 100%
Stopping configd...done
Starting configd.
Reloading plugin configuration
Configuring system logging...done.
Reloading template OPNsense/Freeradius: OK
-
Und geht's jetzt? Hast recht mit dem _ ... der gehört raus .. copy+paste Fehler :)
-
Ich muss erstmal beobachten.
Beim Xiaomi ist das auch nicht sofort aufgetreten während das Pixel7 direkt nicht mehr ging nach Update
-
Trat jetzt wieder auf.
habe jetzt noch
opnsense-revert -r 22.7.3 freeradius3
hinterher geschoben.
Ohne reboot ist hier ein Login wieder möglich. Beobachte erst einmal weiter (ohne reboot)
-
Scheint wieder zu funktionieren mit der jetzigen Version.
Bisher kein Fehler
-
Mit jetzige Version meinst du den revert von 22.7.3 oder? Ich red grad mit Franco wie wir da weiter machen ...
-
Genau, der Revert.
Nutzen diese Authentifizierung einfach zu wenige dass sich das nicht so in die Masse zurück meldet?
Hat FreeBSD einen anderen Code-Stand als das github?
Ein jetziges radiusd -v gibt mir die 3.0.25 (Built on Aug 31 2022 at 01:49:57) zurück, was ja bereits die Problemversion gemäß der Github Meldung seien soll??? Diese jedoch bereitet hier keine Probleme in der Authentifizierung. Bis jetzt keine Probleme.
Die aus dem Update von 22.7.7 hier hat 3.0.25 (Built on Nov 2 2022 at 16:14:09) mit dem Authentifizierungsfehler.
Passt dann auch irgendwie nicht ganz zusammen mit dem issue Ticket
https://github.com/FreeRADIUS/freeradius-server/issues/4753
Würden hier debug logs weiter helfen? 2.November vs 31. August? Würde aber erst am Abend bei mir möglich werden.
-
Moin.
Ich verfolge diesen Fred ja auch. :P
Und ja ich nutze diese Authentifizierung auch (aber nur für WLAN, und nicht für LAN Clients).
Aber ich habe keine Probleme.
Bei mir funktioniert alles wie gehabt.
Ich setzte aber nur folgende Client-OS's ein: "iOS, Linux, Windows"
Bei dieser Konstellation merke ich nichts von den genannten Fehler.
-
Moin.
Ich verfolge diesen Fred ja auch. :P
Und ja ich nutze diese Authentifizierung auch (aber nur für WLAN, und nicht für LAN Clients).
Aber ich habe keine Probleme.
Bei mir funktioniert alles wie gehabt.
Ich setzte aber nur folgende Client-OS's ein: "iOS, Linux, Windows"
Bei dieser Konstellation merke ich nichts von den genannten Fehler.
Und du hast 22.7.8?
-
Ich ergänze hiermit meine Konfiguration vom freeradius
Zertifikate mit gleich lautenden CommonName sollten doch nicht die user Datenbank gegen prüfen vom Radius? Nutze den Radius auth zusätzlich zur VLAN Zuweisung Switch und WiFi ap (anhand Mac Adresse)
Wobei jetzt nur das Pixel 7 den gleichlautenden Namen hat, das Xiaomi aber nicht.
Dieser config Export ist gekürzt.
<freeradius>
<ldap version="1.0.1">
<innertunnel>0</innertunnel>
<protocol>LDAPS</protocol>
<server/>
<identity/>
<password/>
<base_dn>dc=example,dc=domain,dc=com</base_dn>
<user_filter>(uid=%{%{Stripped-User-Name}:-%{User-Name}})</user_filter>
<group_filter>(objectClass=posixGroup)</group_filter>
</ldap>
<dhcp version="1.0.0">
<dhcps/>
</dhcp>
<lease version="1.0.0">
<leases/>
</lease>
<avpair version="1.0.0">
<avpairs/>
</avpair>
<general version="1.0.2">
<enabled>1</enabled>
<vlanassign>1</vlanassign>
<fallbackvlan_enabled>0</fallbackvlan_enabled>
<fallbackvlan_id/>
<ldap_enabled>0</ldap_enabled>
<exos>0</exos>
<wispr>0</wispr>
<chillispot>0</chillispot>
<mikrotik>0</mikrotik>
<sqlite>0</sqlite>
<sessionlimit>0</sessionlimit>
<log_destination>files</log_destination>
<log_authentication_request>1</log_authentication_request>
<log_authbadpass>1</log_authbadpass>
<log_authgoodpass>1</log_authgoodpass>
<dhcpenabled>0</dhcpenabled>
<dhcplistenip/>
<mysql>0</mysql>
<mysqlserver>127.0.0.1</mysqlserver>
<mysqlport>3306</mysqlport>
<mysqluser>radius</mysqluser>
<mysqlpassword>radpass</mysqlpassword>
<mysqldb>radius</mysqldb>
</general>
<eap version="1.9.17">
<default_eap_type>tls</default_eap_type>
<elliptic_curve>prime256v1</elliptic_curve>
<enable_client_cert>1</enable_client_cert>
<ca>59275ffc0a386</ca>
<certificate>592768c233978</certificate>
<crl/>
<check_tls_names>1</check_tls_names>
<tls_min_version>1.0</tls_min_version>
</eap>
<user version="1.0.3">
<users>
<user uuid="50c5fbf5-1fe1-4edf-a720-74ca9a032f26">
<enabled>1</enabled>
<username></username>
<password></password>
<description>GooglePixel7</description>
<ip/>
<subnet/>
<route/>
<ip6/>
<vlan>1111</vlan>
<logintime/>
<simuse/>
<exos_vlan_untagged/>
<exos_vlan_tagged/>
<exos_policy/>
<wispr_bw_min_up/>
<wispr_bw_max_up/>
<wispr_bw_min_down/>
<wispr_bw_max_down/>
<chillispot_bw_max_up/>
<chillispot_bw_max_down/>
<mikrotik_vlan_id_number/>
<mikrotik_vlan_id_type/>
<sessionlimit_max_session_limit/>
<servicetype/>
<linkedAVPair/>
</user>
</users>
</user>
<client version="1.0.2">
<clients>
<client uuid="b168f682-8966-4561-ba58-3c157fe27906">
<enabled>1</enabled>
<name>T1600G-28TS</name>
<secret></secret>
<ip>192.168.xxx.xxx</ip>
</client>
<client uuid="5bf069d6-7755-4f44-bf5a-8aa3cdab405d">
<enabled>1</enabled>
<name>WiFi-AP</name>
<secret></secret>
<ip>192.168.xxx.xxx</ip>
</client>
</clients>
</client>
</freeradius>
-
Vielen Dank für eure Hilfe!
Auch bei mir hat der revert geklappt.
Stelle mir aber die Frage des Vorposters:
Fällt es niemandem sonst auf? Hier liegt doch offenbar ein Bug vor.
-
Vielen Dank für eure Hilfe!
Auch bei mir hat der revert geklappt.
Stelle mir aber die Frage des Vorposters:
Fällt es niemandem sonst auf? Hier liegt doch offenbar ein Bug vor.
Was hast du von welcher Version auf welche revertet. Wir haben hier ja mehrere Themen. Einer meldet Probleme mit 22.7.7, das hat die gleiche FreeRadius Version wie 22.7.3, aber 22.7.8 ist 3.2.1 statt 3.0.25.
Ich hab hier bisher nix konkretes
-
Ich hatte das OS ja von 22.7.7 auf 22.7.8 gebracht, in dem Zuge wurde freeradius auf 3.2.1 angehoben.
Nun bin ich von dort wieder herunter auf 3.0.25.
-
Ok, Fazit für
User senser8912: Mit Update von 22.7.7 auf 22.7.8 und dementsprechend FR 30 auf 32 Probleme mit WPA2 Enterprise, Revert hat geholfen.
User rantwolf: Installierte Version 22.X.X (???), alles funktioniert
User iamhermes: Update von 22.7.3 auf 22.7.7 (FR Version unverändert) und Geräte kommen nicht rein, revert auf 22.7.3, alles geht wieder.
Können das die anderen beiden noch bestätigen?
-
Keine Ahnung ob es hilft: ich hatte nach dem Übergang von 22.7.6 auf 22.7.7 Anmeldeprobleme im WLAN mit WPA-EAP und freeradius-server auf der OPNsense. Aufgetreten ist das bei mir nur mit iOS und iPadOS (jeweils aktuelle Version). MacOS devices hatten keine Probleme. Geholfen hat bei mir "Netzwerk ignorieren" und dann neu anmelden. Seeehr merkwürdig....
Mit Update auf 22.7.8 warte ich noch...
-
Keine Ahnung ob es hilft: ich hatte nach dem Übergang von 22.7.6 auf 22.7.7 Anmeldeprobleme im WLAN mit WPA-EAP und freeradius-server auf der OPNsense. Aufgetreten ist das bei mir nur mit iOS und iPadOS (jeweils aktuelle Version). MacOS devices hatten keine Probleme. Geholfen hat bei mir "Netzwerk ignorieren" und dann neu anmelden. Seeehr merkwürdig....
Mit Update auf 22.7.8 warte ich noch...
Ein Test wäre aber schön, revert zurück geht ja immer :)
-
Ich habe jetzt die 22.7.8 reingeprügelt nachdem gestern mein Test mit dem freeradius von 22.7.7 mit zwei Stunden degugging keine Fehler hoch brachte.
Da auch das Update von 22.7.7 auf 22.7.8 ohne Workaround nicht funktioniert (missing freeradius 3.0.25 files) hatte ich das bisher aufgeschoben und das fehlgeschlagene debugging gleich als Anlass für die neuere Version genommen.
Wird sich zeigen was jetzt geschieht. Ich beobachte.
radiusd: FreeRADIUS Version 3.2.1, for host amd64-portbld-freebsd13.1, built on Nov 16 2022 at 05:04:28
-
Danke dir, bin gespannt :)
-
Keine Ahnung ob es hilft: ich hatte nach dem Übergang von 22.7.6 auf 22.7.7 Anmeldeprobleme im WLAN mit WPA-EAP und freeradius-server auf der OPNsense. Aufgetreten ist das bei mir nur mit iOS und iPadOS (jeweils aktuelle Version). MacOS devices hatten keine Probleme. Geholfen hat bei mir "Netzwerk ignorieren" und dann neu anmelden. Seeehr merkwürdig....
Mit Update auf 22.7.8 warte ich noch...
Ein Test wäre aber schön, revert zurück geht ja immer :)
OK. Habe gerade auf 22.7.8 geupdated. Reboot wurde nicht durchgeführt (nicht automatisch und auch nicht von mir). Verbindung geht bislang. Auch keine weiteren Auffälligkeiten bisher...
-
Heute die nächste Kuriosität.
Wie gesagt das Update auf die 22.7.8 ohne reboot durchgeführt.
Die WPA2-Enterprise Authentifizierung lief bisher ohne Probleme.
Heute einen komplett Reboot durchgeführt da sich irgendwie die Qualität des Routings abnahm (DSL-Modem + APU2)
Nach dem Reboot der APU konnte sich mein Win11 Rechner nicht mehr anmelden und wollte prompt neue Zugangsdaten zum WiFi
Hier half jetzt nur Check TLS Common-Name zu deaktivieren, da ich beim Win11 keine Möglichkeit der Eingabe der Identität habe nebst Angabe des Userzertifikates
Zu den Hintergründen beim Win11 Rechner:
Dieser bietet sobald man sich am WLAN Anmelden will nur noch die Möglichkeit Benutzername+Passwort ODER Zertifikat. Weitere Auswahlmöglichkeiten werden mir hier nicht angeboten. Auch das manuelle hinzufügen meines WPA2-Enterprise WiFi half nicht weiter. Ich habe noch in erinnerung dass man eine Identität angeben konnte zum Zertifikat.
Gegenprobe auf dem Pixel7 Gerät. WiFi gelöscht und neu angelegt. CA Zertifikat bei erster Verbindung vertrauen, Nutzerzertifikat ausgewählt. KEINE Identität angegeben --> kein Connect möglich. Irgendetwas da reingeschrieben --> connect möglich.
Irgendetwas hat sich beim Reboot vom Freeradius aufgeräumt. Aber alles in sich doch irgendwie sehr kurios. Ein Debug Log habe ich gemacht von der fehlgeschlagenen Win11 Anmeldung und liegt vor. Nur ob das so viel bringt weiß ich nicht
Vielleicht kann ja jemand etwas zu diesem DEBUG Mitschnitt sagen
radiusd: FreeRADIUS Version 3.2.1, for host amd64-portbld-freebsd13.1, built on Nov 16 2022 at 05:04:28
(7) Received Access-Request Id 149 from 192.168.200.253:48409 to 192.168.200.1:1812 length 243
(7) User-Name = "MeinLaptop"
(7) NAS-IP-Address = 192.168.200.253
(7) NAS-Identifier = "22e829aabbcc"
(7) Called-Station-Id = "22-E8-29-AA-BB-CC:MeinHochSensiblesWLAN"
(7) NAS-Port-Type = Wireless-802.11
(7) Service-Type = Framed-User
(7) Calling-Station-Id = "B4-B5-B6-AA-BB-CC"
(7) Connect-Info = "CONNECT 0Mbps 802.11b"
(7) Acct-Session-Id = "9FD343CD4B259C46"
(7) Acct-Multi-Session-Id = "1C44C5FF48582DF8"
(7) WLAN-Pairwise-Cipher = 1027076
(7) WLAN-Group-Cipher = 1027076
(7) WLAN-AKM-Suite = 1027073
(7) Framed-MTU = 1400
(7) EAP-Message = 0x02d000060d00
(7) State = 0x39366d1f3ce6604cbeba10a4ec638971
(7) Message-Authenticator = 0x3a2ad747a8c49b57d6d5e632f80024d1
(7) Restoring &session-state
(7) &session-state:Framed-MTU = 994
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.3 Handshake, ClientHello"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerHello"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, Certificate"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerKeyExchange"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, CertificateRequest"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerHelloDone"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, Certificate"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, ClientKeyExchange"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, CertificateVerify"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, Finished"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 ChangeCipherSpec"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, Finished"
(7) &session-state:TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384"
(7) &session-state:TLS-Session-Version = "TLS 1.2"
(7) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(7) authorize {
(7) policy filter_username {
(7) if (&User-Name) {
(7) if (&User-Name) -> TRUE
(7) if (&User-Name) {
(7) if (&User-Name =~ / /) {
(7) if (&User-Name =~ / /) -> FALSE
(7) if (&User-Name =~ /@[^@]*@/ ) {
(7) if (&User-Name =~ /@[^@]*@/ ) -> FALSE
(7) if (&User-Name =~ /\.\./ ) {
(7) if (&User-Name =~ /\.\./ ) -> FALSE
(7) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) {
(7) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE
(7) if (&User-Name =~ /\.$/) {
(7) if (&User-Name =~ /\.$/) -> FALSE
(7) if (&User-Name =~ /@\./) {
(7) if (&User-Name =~ /@\./) -> FALSE
(7) } # if (&User-Name) = notfound
(7) } # policy filter_username = notfound
(7) [preprocess] = ok
(7) [chap] = noop
(7) [mschap] = noop
(7) [digest] = noop
(7) suffix: Checking for suffix after "@"
(7) suffix: No '@' in User-Name = "MeinLaptop", looking up realm NULL
(7) suffix: No such realm "NULL"
(7) [suffix] = noop
(7) eap: Peer sent EAP Response (code 2) ID 208 length 6
(7) eap: No EAP Start, assuming it's an on-going EAP conversation
(7) [eap] = updated
(7) [files] = noop
(7) [expiration] = noop
(7) [logintime] = noop
(7) [pap] = noop
(7) } # authorize = updated
(7) Found Auth-Type = eap
(7) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(7) authenticate {
(7) eap: Expiring EAP session with state 0x39366d1f3ce6604c
(7) eap: Finished EAP session with state 0x39366d1f3ce6604c
(7) eap: Previous EAP request found for state 0x39366d1f3ce6604c, released from the list
(7) eap: Peer sent packet with method EAP TLS (13)
(7) eap: Calling submodule eap_tls to process data
(7) eap_tls: (TLS) Peer ACKed our handshake fragment. handshake is finished
(7) eap_tls: Validating certificate
(7) Virtual server check-eap-tls received request
(7) User-Name = "MeinLaptop"
(7) NAS-IP-Address = 192.168.200.253
(7) NAS-Identifier = "22e829aabbcc"
(7) Called-Station-Id = "22-E8-29-AA-BB-CC:MeinHochSensiblesWLAN"
(7) NAS-Port-Type = Wireless-802.11
(7) Service-Type = Framed-User
(7) Calling-Station-Id = "B4-B5-B6-AA-BB-CC"
(7) Connect-Info = "CONNECT 0Mbps 802.11b"
(7) Acct-Session-Id = "9FD343CD4B259C46"
(7) Acct-Multi-Session-Id = "1C44C5FF48582DF8"
(7) WLAN-Pairwise-Cipher = 1027076
(7) WLAN-Group-Cipher = 1027076
(7) WLAN-AKM-Suite = 1027073
(7) Framed-MTU = 1400
(7) EAP-Message = 0x02d000060d00
(7) State = 0x39366d1f3ce6604cbeba10a4ec638971
(7) Message-Authenticator = 0x3a2ad747a8c49b57d6d5e632f80024d1
(7) Event-Timestamp = "Nov 27 2022 19:46:24 CET"
(7) EAP-Type = TLS
(7) TLS-Client-Cert-Serial := "00"
(7) TLS-Client-Cert-Expiration := "270523225140Z"
(7) TLS-Client-Cert-Valid-Since := "170525225140Z"
(7) TLS-Client-Cert-Subject := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof"
(7) TLS-Client-Cert-Issuer := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof"
(7) TLS-Client-Cert-Common-Name := "bahnhof"
(7) TLS-Client-Cert-X509v3-Subject-Key-Identifier += "B0:6D:DF:7C:FC:F2:37:78:5E:34:95:04:5F:69:97:3A:02:05:F8:07"
(7) TLS-Client-Cert-X509v3-Authority-Key-Identifier += "keyid:B0:6D:DF:7C:FC:F2:37:78:5E:34:95:04:5F:69:97:3A:02:05:F8:07\n"
(7) TLS-Client-Cert-X509v3-Basic-Constraints += "CA:TRUE"
(7) TLS-Client-Cert-Serial := "0e"
(7) TLS-Client-Cert-Expiration := "250409121646Z"
(7) TLS-Client-Cert-Valid-Since := "220410121646Z"
(7) TLS-Client-Cert-Subject := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=MeinLaptop"
(7) TLS-Client-Cert-Issuer := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof"
(7) TLS-Client-Cert-Common-Name := "MeinLaptop"
(7) TLS-Client-Cert-Subject-Alt-Name-Dns := "publicDNS.spdns.de"
(7) TLS-Client-Cert-X509v3-Basic-Constraints += "CA:FALSE"
(7) TLS-Client-Cert-X509v3-Subject-Key-Identifier += "24:3A:6B:31:46:9A:6A:9B:48:D2:D3:75:9F:88:74:65:C3:ED:4A:D1"
(7) TLS-Client-Cert-X509v3-Authority-Key-Identifier += "keyid:B0:6D:DF:7C:FC:F2:37:78:5E:34:95:04:5F:69:97:3A:02:05:F8:07\nDirName:/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof\nserial:00\n"
(7) TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication"
(7) TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2"
(7) WARNING: Outer and inner identities are the same. User privacy is compromised.
(7) server check-eap-tls {
(7) session-state: No cached attributes
(7) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/check-eap-tls
(7) authorize {
(7) update config {
(7) &Auth-Type := Accept
(7) } # update config = noop
(7) if (&User-Name == &TLS-Client-Cert-Common-Name || &User-Name == "host/%{TLS-Client-Cert-Common-Name}") {
(7) EXPAND host/%{TLS-Client-Cert-Common-Name}
(7) --> host/bahnhof
(7) if (&User-Name == &TLS-Client-Cert-Common-Name || &User-Name == "host/%{TLS-Client-Cert-Common-Name}") -> FALSE
(7) else {
(7) update config {
(7) &Auth-Type := Reject
(7) } # update config = noop
(7) } # else = noop
(7) [files] = noop
(7) [expiration] = noop
(7) [logintime] = noop
(7) } # authorize = noop
(7) Found Auth-Type = Reject
(7) Auth-Type = Reject, rejecting user
(7) Failed to authenticate the user
(7) Using Post-Auth-Type Reject
(7) Post-Auth-Type sub-section not found. Ignoring.
(7) Login incorrect: [MeinLaptop/<via Auth-Type = Reject>] (from client WiFi-AP port 0 cli B4-B5-B6-AA-BB-CC via TLS tunnel)
(7) } # server check-eap-tls
(7) Virtual server sending reply
(7) eap_tls: Certificate rejected by the virtual server
(7) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed
(7) eap: Sending EAP Failure (code 4) ID 208 length 4
(7) eap: Failed in EAP select
(7) [eap] = invalid
(7) } # authenticate = invalid
(7) Failed to authenticate the user
(7) Using Post-Auth-Type Reject
(7) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(7) Post-Auth-Type REJECT {
(7) attr_filter.access_reject: EXPAND %{User-Name}
(7) attr_filter.access_reject: --> MeinLaptop
(7) attr_filter.access_reject: Matched entry DEFAULT at line 11
(7) [attr_filter.access_reject] = updated
(7) [eap] = noop
(7) policy remove_reply_message_if_eap {
(7) if (&reply:EAP-Message && &reply:Reply-Message) {
(7) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(7) else {
(7) [noop] = noop
(7) } # else = noop
(7) } # policy remove_reply_message_if_eap = noop
(7) } # Post-Auth-Type REJECT = updated
(7) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [MeinLaptop/<via Auth-Type = eap>] (from client WiFi-AP port 0 cli B4-B5-B6-AA-BB-CC)
(7) Delaying response for 1.000000 seconds
(7) Sending delayed response
(7) Sent Access-Reject Id 149 from 192.168.200.1:1812 to 192.168.200.253:48409 length 44
(7) EAP-Message = 0x04d00004
(7) Message-Authenticator = 0x00000000000000000000000000000000
(7) Cleaning up request packet ID 149 with timestamp +23 due to cleanup_delay was reached
-
Kannst du einen revert machen und reboot?
-
Heute die nächste Kuriosität.
Wie gesagt das Update auf die 22.7.8 ohne reboot durchgeführt.
Die WPA2-Enterprise Authentifizierung lief bisher ohne Probleme.
Heute einen komplett Reboot durchgeführt da sich irgendwie die Qualität des Routings abnahm (DSL-Modem + APU2)
Nach dem Reboot der APU konnte sich mein Win11 Rechner nicht mehr anmelden und wollte prompt neue Zugangsdaten zum WiFi
Hier half jetzt nur Check TLS Common-Name zu deaktivieren, da ich beim Win11 keine Möglichkeit der Eingabe der Identität habe nebst Angabe des Userzertifikates
Zu den Hintergründen beim Win11 Rechner:
Dieser bietet sobald man sich am WLAN Anmelden will nur noch die Möglichkeit Benutzername+Passwort ODER Zertifikat. Weitere Auswahlmöglichkeiten werden mir hier nicht angeboten. Auch das manuelle hinzufügen meines WPA2-Enterprise WiFi half nicht weiter. Ich habe noch in erinnerung dass man eine Identität angeben konnte zum Zertifikat.
Gegenprobe auf dem Pixel7 Gerät. WiFi gelöscht und neu angelegt. CA Zertifikat bei erster Verbindung vertrauen, Nutzerzertifikat ausgewählt. KEINE Identität angegeben --> kein Connect möglich. Irgendetwas da reingeschrieben --> connect möglich.
Irgendetwas hat sich beim Reboot vom Freeradius aufgeräumt. Aber alles in sich doch irgendwie sehr kurios. Ein Debug Log habe ich gemacht von der fehlgeschlagenen Win11 Anmeldung und liegt vor. Nur ob das so viel bringt weiß ich nicht
Vielleicht kann ja jemand etwas zu diesem DEBUG Mitschnitt sagen
radiusd: FreeRADIUS Version 3.2.1, for host amd64-portbld-freebsd13.1, built on Nov 16 2022 at 05:04:28
(7) Received Access-Request Id 149 from 192.168.200.253:48409 to 192.168.200.1:1812 length 243
(7) User-Name = "MeinLaptop"
(7) NAS-IP-Address = 192.168.200.253
(7) NAS-Identifier = "22e829aabbcc"
(7) Called-Station-Id = "22-E8-29-AA-BB-CC:MeinHochSensiblesWLAN"
(7) NAS-Port-Type = Wireless-802.11
(7) Service-Type = Framed-User
(7) Calling-Station-Id = "B4-B5-B6-AA-BB-CC"
(7) Connect-Info = "CONNECT 0Mbps 802.11b"
(7) Acct-Session-Id = "9FD343CD4B259C46"
(7) Acct-Multi-Session-Id = "1C44C5FF48582DF8"
(7) WLAN-Pairwise-Cipher = 1027076
(7) WLAN-Group-Cipher = 1027076
(7) WLAN-AKM-Suite = 1027073
(7) Framed-MTU = 1400
(7) EAP-Message = 0x02d000060d00
(7) State = 0x39366d1f3ce6604cbeba10a4ec638971
(7) Message-Authenticator = 0x3a2ad747a8c49b57d6d5e632f80024d1
(7) Restoring &session-state
(7) &session-state:Framed-MTU = 994
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.3 Handshake, ClientHello"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerHello"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, Certificate"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerKeyExchange"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, CertificateRequest"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, ServerHelloDone"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, Certificate"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, ClientKeyExchange"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, CertificateVerify"
(7) &session-state:TLS-Session-Information = "(TLS) recv TLS 1.2 Handshake, Finished"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 ChangeCipherSpec"
(7) &session-state:TLS-Session-Information = "(TLS) send TLS 1.2 Handshake, Finished"
(7) &session-state:TLS-Session-Cipher-Suite = "ECDHE-RSA-AES256-GCM-SHA384"
(7) &session-state:TLS-Session-Version = "TLS 1.2"
(7) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(7) authorize {
(7) policy filter_username {
(7) if (&User-Name) {
(7) if (&User-Name) -> TRUE
(7) if (&User-Name) {
(7) if (&User-Name =~ / /) {
(7) if (&User-Name =~ / /) -> FALSE
(7) if (&User-Name =~ /@[^@]*@/ ) {
(7) if (&User-Name =~ /@[^@]*@/ ) -> FALSE
(7) if (&User-Name =~ /\.\./ ) {
(7) if (&User-Name =~ /\.\./ ) -> FALSE
(7) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) {
(7) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE
(7) if (&User-Name =~ /\.$/) {
(7) if (&User-Name =~ /\.$/) -> FALSE
(7) if (&User-Name =~ /@\./) {
(7) if (&User-Name =~ /@\./) -> FALSE
(7) } # if (&User-Name) = notfound
(7) } # policy filter_username = notfound
(7) [preprocess] = ok
(7) [chap] = noop
(7) [mschap] = noop
(7) [digest] = noop
(7) suffix: Checking for suffix after "@"
(7) suffix: No '@' in User-Name = "MeinLaptop", looking up realm NULL
(7) suffix: No such realm "NULL"
(7) [suffix] = noop
(7) eap: Peer sent EAP Response (code 2) ID 208 length 6
(7) eap: No EAP Start, assuming it's an on-going EAP conversation
(7) [eap] = updated
(7) [files] = noop
(7) [expiration] = noop
(7) [logintime] = noop
(7) [pap] = noop
(7) } # authorize = updated
(7) Found Auth-Type = eap
(7) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(7) authenticate {
(7) eap: Expiring EAP session with state 0x39366d1f3ce6604c
(7) eap: Finished EAP session with state 0x39366d1f3ce6604c
(7) eap: Previous EAP request found for state 0x39366d1f3ce6604c, released from the list
(7) eap: Peer sent packet with method EAP TLS (13)
(7) eap: Calling submodule eap_tls to process data
(7) eap_tls: (TLS) Peer ACKed our handshake fragment. handshake is finished
(7) eap_tls: Validating certificate
(7) Virtual server check-eap-tls received request
(7) User-Name = "MeinLaptop"
(7) NAS-IP-Address = 192.168.200.253
(7) NAS-Identifier = "22e829aabbcc"
(7) Called-Station-Id = "22-E8-29-AA-BB-CC:MeinHochSensiblesWLAN"
(7) NAS-Port-Type = Wireless-802.11
(7) Service-Type = Framed-User
(7) Calling-Station-Id = "B4-B5-B6-AA-BB-CC"
(7) Connect-Info = "CONNECT 0Mbps 802.11b"
(7) Acct-Session-Id = "9FD343CD4B259C46"
(7) Acct-Multi-Session-Id = "1C44C5FF48582DF8"
(7) WLAN-Pairwise-Cipher = 1027076
(7) WLAN-Group-Cipher = 1027076
(7) WLAN-AKM-Suite = 1027073
(7) Framed-MTU = 1400
(7) EAP-Message = 0x02d000060d00
(7) State = 0x39366d1f3ce6604cbeba10a4ec638971
(7) Message-Authenticator = 0x3a2ad747a8c49b57d6d5e632f80024d1
(7) Event-Timestamp = "Nov 27 2022 19:46:24 CET"
(7) EAP-Type = TLS
(7) TLS-Client-Cert-Serial := "00"
(7) TLS-Client-Cert-Expiration := "270523225140Z"
(7) TLS-Client-Cert-Valid-Since := "170525225140Z"
(7) TLS-Client-Cert-Subject := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof"
(7) TLS-Client-Cert-Issuer := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof"
(7) TLS-Client-Cert-Common-Name := "bahnhof"
(7) TLS-Client-Cert-X509v3-Subject-Key-Identifier += "B0:6D:DF:7C:FC:F2:37:78:5E:34:95:04:5F:69:97:3A:02:05:F8:07"
(7) TLS-Client-Cert-X509v3-Authority-Key-Identifier += "keyid:B0:6D:DF:7C:FC:F2:37:78:5E:34:95:04:5F:69:97:3A:02:05:F8:07\n"
(7) TLS-Client-Cert-X509v3-Basic-Constraints += "CA:TRUE"
(7) TLS-Client-Cert-Serial := "0e"
(7) TLS-Client-Cert-Expiration := "250409121646Z"
(7) TLS-Client-Cert-Valid-Since := "220410121646Z"
(7) TLS-Client-Cert-Subject := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=MeinLaptop"
(7) TLS-Client-Cert-Issuer := "/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof"
(7) TLS-Client-Cert-Common-Name := "MeinLaptop"
(7) TLS-Client-Cert-Subject-Alt-Name-Dns := "publicDNS.spdns.de"
(7) TLS-Client-Cert-X509v3-Basic-Constraints += "CA:FALSE"
(7) TLS-Client-Cert-X509v3-Subject-Key-Identifier += "24:3A:6B:31:46:9A:6A:9B:48:D2:D3:75:9F:88:74:65:C3:ED:4A:D1"
(7) TLS-Client-Cert-X509v3-Authority-Key-Identifier += "keyid:B0:6D:DF:7C:FC:F2:37:78:5E:34:95:04:5F:69:97:3A:02:05:F8:07\nDirName:/C=DE/ST=Germany/L=City in Germany/O=HomeNetwork/emailAddress=nobody@not.me/CN=bahnhof\nserial:00\n"
(7) TLS-Client-Cert-X509v3-Extended-Key-Usage += "TLS Web Client Authentication"
(7) TLS-Client-Cert-X509v3-Extended-Key-Usage-OID += "1.3.6.1.5.5.7.3.2"
(7) WARNING: Outer and inner identities are the same. User privacy is compromised.
(7) server check-eap-tls {
(7) session-state: No cached attributes
(7) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/check-eap-tls
(7) authorize {
(7) update config {
(7) &Auth-Type := Accept
(7) } # update config = noop
(7) if (&User-Name == &TLS-Client-Cert-Common-Name || &User-Name == "host/%{TLS-Client-Cert-Common-Name}") {
(7) EXPAND host/%{TLS-Client-Cert-Common-Name}
(7) --> host/bahnhof
(7) if (&User-Name == &TLS-Client-Cert-Common-Name || &User-Name == "host/%{TLS-Client-Cert-Common-Name}") -> FALSE
(7) else {
(7) update config {
(7) &Auth-Type := Reject
(7) } # update config = noop
(7) } # else = noop
(7) [files] = noop
(7) [expiration] = noop
(7) [logintime] = noop
(7) } # authorize = noop
(7) Found Auth-Type = Reject
(7) Auth-Type = Reject, rejecting user
(7) Failed to authenticate the user
(7) Using Post-Auth-Type Reject
(7) Post-Auth-Type sub-section not found. Ignoring.
(7) Login incorrect: [MeinLaptop/<via Auth-Type = Reject>] (from client WiFi-AP port 0 cli B4-B5-B6-AA-BB-CC via TLS tunnel)
(7) } # server check-eap-tls
(7) Virtual server sending reply
(7) eap_tls: Certificate rejected by the virtual server
(7) eap: ERROR: Failed continuing EAP TLS (13) session. EAP sub-module failed
(7) eap: Sending EAP Failure (code 4) ID 208 length 4
(7) eap: Failed in EAP select
(7) [eap] = invalid
(7) } # authenticate = invalid
(7) Failed to authenticate the user
(7) Using Post-Auth-Type Reject
(7) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(7) Post-Auth-Type REJECT {
(7) attr_filter.access_reject: EXPAND %{User-Name}
(7) attr_filter.access_reject: --> MeinLaptop
(7) attr_filter.access_reject: Matched entry DEFAULT at line 11
(7) [attr_filter.access_reject] = updated
(7) [eap] = noop
(7) policy remove_reply_message_if_eap {
(7) if (&reply:EAP-Message && &reply:Reply-Message) {
(7) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(7) else {
(7) [noop] = noop
(7) } # else = noop
(7) } # policy remove_reply_message_if_eap = noop
(7) } # Post-Auth-Type REJECT = updated
(7) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [MeinLaptop/<via Auth-Type = eap>] (from client WiFi-AP port 0 cli B4-B5-B6-AA-BB-CC)
(7) Delaying response for 1.000000 seconds
(7) Sending delayed response
(7) Sent Access-Reject Id 149 from 192.168.200.1:1812 to 192.168.200.253:48409 length 44
(7) EAP-Message = 0x04d00004
(7) Message-Authenticator = 0x00000000000000000000000000000000
(7) Cleaning up request packet ID 149 with timestamp +23 due to cleanup_delay was reached
Bist du motiviert was mit mir zu testen um das zu fixen?
-
Sorry, everything is German here. But it seems related: https://github.com/opnsense/core/issues/6167#issuecomment-1341331883
Am i correct that this is a freeradius upstream bug? Maybe opnsense can better revert the version until upsteam is fixed?
-
(Looks like it. And a revert is out of the question if not carried out by FreeBSD ports, which is highly unlikely.)