Messages

Is there a way to solve or ignore?

OPNsense 25.7.7_4-amd64
Using dnsmasq DNS and DHCP

Code Select Expand

2025-11-17T16:02:44 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:43 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:42 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:42 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:06 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:02 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:02 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:01 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:02:01 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:01:07 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:01:07 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:01:06 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T16:01:06 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:59:31 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:59:29 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:59:29 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:59:18 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:57:53 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:57:53 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:57:52 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:57:52 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:57:23 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:56:17 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:56:17 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:56:16 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:56:16 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:55:10 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:54:42 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:54:42 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:54:41 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:54:41 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:53:01 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:53:00 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:53:00 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:53:00 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:51:39 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:51:39 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:51:39 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:51:38 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com
2025-11-17T15:51:38 Warning dnsmasq possible DNS-rebind attack detected: dns.msftncsi.com

Wieso nicht einmal einen Dump dieser Pakete machen?
Das sagt aktuell gar nichts über den Inhalt aus. Auch ist es eine Broadcast Adresse an welche das geht (255.255.255.255) und nicht direkt an dein Netz adressiert.

Ich habe einen VMG1312 im Bridge Mode. Aber ich kann deinen besagten Traffic nicht feststellen.

Glasfaser Anschluss? Eventuell gibt es hier anderes Routing als an einem MSAN.
Auch dein Modem im Bridged Mode kann gewisse Sachen weiter reichen die für Telekom eigene Geräte bestimmte Statusmeldungen seien könnten.

[Check TLS Common-Name]

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

Code Select Expand


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

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

same here.
no upgrade to 22.7.8 possible (same missing messages)

did not use the workaround.

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.

Code Select Expand

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

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.

Scheint wieder zu funktionieren mit der jetzigen Version.
Bisher kein Fehler

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)

Ich muss erstmal beobachten.
Beim Xiaomi ist das auch nicht sofort aufgetreten während das Pixel7 direkt nicht mehr ging nach Update

Reboot ist gemacht. Allerdings musste ich die Version anpassen.
Ich beobachte jetzt

Code Select Expand

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

[2022-11-22T07:56:31 Notice pkg-static opnsense-update upgraded: 22.7.3 -> 22.7.7]

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

[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)]

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?

Is it possible to rename certificates instead to create new ones?

Mit direkter Benutzerauthentifizierung im FreeRadius selbst geht dies ohne weiteres mit entsprechendem VLAN zum WiFi AP hin.

Wenn ich allerdings nur ein Zertifikat nutzen will (angelegter User in der OPNsense nebst erstellten Zertifikat zum User) habe ich allerdings keine weiteren Login Parameter für den FreeRadius zwecks VLAN, da ja die Authentifizierung anhand Zertifikat ohne eine VLAN Zugehörigkeit erfolgt und nicht per User/Passwort nebst VLAN vom FreeRadius.

Ich könnte im AP die MAC-Basierte Authentifizierung zusätzlich aktiv schalten, allerdings sehe ich dies nicht wirklich als sinnreich/sicher an, da keine Zugehörigkeit vom Zertifikat zum VLAN existiert und sich das nur auf die MAC-Adresse vom Client bezieht. Jeder mit einem gültigen Zertifikat könnte sich mit passender MAC in ein anderes VLAN verschieben.


Nach etwas längerer Suche bin ich zumindest zum Ergebnis gelangt, dass es anhand der Zertifikatsparameter möglich sei, weitere Infos im FreeRadius zum Auth hinzuzufügen.

In der post_auth Sektion von sites-enabled/default nach

Code Select Expand

update {
    &reply: += &session-state:
}

müsste für jedes Zertifikat folgendes Ergänzt werden:

Code Select Expand

if (TLS-Client-Cert-Serial== "...."){   // oder andere Eigenschaften vom Zertifikat, Expiration...Issuer...Subject
update reply {
    &Tunnel-Type = 13,
    &Tunnel-Medium-Type = 6,
    &Tunnel-Private-Group-Id = "...definiertes VLAN für Zertifikat..."
}
}


Interessant wäre jetzt die Erweiterung vom freeradius Plugin um diese Funktion.
Hier schwebt mir auch die automatische Erkennung aller Client-Zertifikate im opnsense vor, worauf direkt die VLAN Zuweisung definiert werden könnte.


Oder gibt es einen Punkt irgendwo, wo dieses jetzt bereits gemacht werden kann?

Danke