durch einen Stromausfall hat es meinen Server etwas zerlegt und ich musste auf ein altes BackUp der VM zurückgreifen.
Jetzt (vielleicht war es aber schon vorher ein Problem) ergibt sich das Problem, dass die Rechner sich wohl korrekt beim Server und der Firewall authentifizieren, sie aber keinen Internetzugriff erhalten.
Soll heißen: ich bekomme beim Starten des Browsers nicht die Nachfrage nach Proxy-Zugangsdaten (die sind also wohl korrekt), es kann aber auch keine Webseite geladen werden (Intranet - ssh 10.0.0.1 z.B. - geht).
Hat jemand eine Idee, wo ich das Problem debuggen könnte?
Danke,
Guntram
PS: Ich hatte zwischenzeitlich auch mal ein Upgrade der Firewall gemacht, das ist aber irgendwie gescheitert, weshalb ich die VM wieder zurückgesetzt habe. Vielleicht hat die sich dabei auch verschluckt?
Update: wenn ich jetzt am Client versuche, ins Netz zu gehen fragt er nach den Proxy-Zugangsdaten (hatte zwischendurch Update vom Server und von der Firewall gemacht).
In den Systemeinstellungen sind die Proxy-Einstellungen aber vorhanden - d.h., das logon-Skript wird offensichtlich ausgeführt…
Ich hänge mich hier mit an. LMN7 auf dem neuesten Stand. Clients Windows 10.
Nach diversen Versuchen, die Firewall upzudaten und schließlich zurücksetzen auf den alten Stand bekomme ich keine Verbindung mehr über den Proxy ins Internet. Die Konfiguration des Web-Proxy hat vorher funktioniert und ich habe sie nicht verändert. Die Systemzeiten sind alle i.O. Die User sind korrekt in der Gruppe „internet“ und sowohl der Prüfer als auch der Check „Kerberos-Anmeldung“ funktionieren.
Welches Log müsste ich einschalten/lesen, um dem Problem auf den Grund zu kommen?
Wer kann helfen, aktuell kommt hier niemand ins Internet!
ja, wie gesagt lief die Konfiguration ja bis zu den Update-Versuchen und
ich bin deine Anleitung auch nochmal durchgegangen, das passt soweit alles.
wenn du die Firewall auf einen älteren ZUstand zurücksetzt, dann kann es
sein, dass inzwischen Firewall und samba neue Passwörter ausgehandelt
haben. Das erinnert der Server: der Firewall wurden aber Teile des
Gedächtnisses entfernt. Also paßt das nicht mehr.
Dann mußt du dir ein neues Cerberos Ticket für die Firewall ziehen oder
wenigstens prüfen, ob es noch tut.
Das ist beschrieben in der Anleitung (vorsicht: hat mehrere Seiten).
Das hast du gemacht?
Und alles ist grün und keine Fehler? Und es geht trotzdem nicht?
Ich hoffe, ich verstehe dich richtig: Du meinst, ich soll eine neue Keytab anlegen? Ja, das habe ich mittels des global-admin gemacht, vorab noch die alte gelöscht. Der Log sieht gut aus:
Keytab name: FILE:/usr/local/etc/squid/squid.keytab
KVNO Principal
Bei mir hat „Schlüsseltabelle erzeugen“ auch keine Besserung gebracht. Ist die Fehlermeldung zwischendurch (ldap_add_principal) relevant?
Password for global-admin@LINUXMUSTER.LAN:
– init_password: Wiping the computer password structure
– generate_new_password: Generating a new, random password for the computer account
– generate_new_password: Characters read from /dev/urandom: 72
– get_dc_host: Attempting to find domain controller to use via DNS SRV record in domain LINUXMUSTER.LAN for procotol tcp
– DnsSrvQuery: Running DNS SRV query for _kerberos._tcp.dc._msdcs.LINUXMUSTER.LAN
– validate: Found DC: server.linuxmuster.lan. Checking availability…
– get_dc_host: Found preferred domain controller: server.linuxmuster.lan
– create_fake_krb5_conf: Created fake krb5.conf file: /tmp/.msktkrb5.conf-5Fy3Lm
– destroy_g_context: Destroying Kerberos context
– initialize_g_context: Creating Kerberos context
– finalize_exec: sAMAccountName: FIREWALL-K$
– get_short_hostname: Determined short hostname: firewall
– get_short_hostname: Determined short hostname: firewall
– try_machine_keytab_princ: Trying to authenticate FIREWALL-K$ from local keytab
– switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-kQULvC
– finalize_exec: Authenticated using method 1
– LDAPConnection: Connecting to LDAP server: server.linuxmuster.lan
SASL/GSSAPI authentication started
SASL username: FIREWALL-K$@LINUXMUSTER.LAN
SASL SSF: 256
SASL data security layer installed.
– ldap_get_base_dn: Determined default LDAP base: dc=LINUXMUSTER,dc=LAN
– get_default_ou: Using OU: CN=Computers,dc=LINUXMUSTER,dc=LAN
– ldap_check_account: Checking that a computer account for FIREWALL-K$ exists
– ldap_check_account: Found computer account
– ldap_check_account: Found userAccountControl: 0x1000
– ldap_check_account: Found supportedEncryptionTypes: 28
– ldap_check_account: Found dNSHostName: firewall
– ldap_check_account: Found servicePrincipalName: HTTP/firewall.linuxmuster.lan
– ldap_check_account: User principal specified on command line
– ldap_check_account_strings: Inspecting (and updating) computer account attributes
– ldap_check_account_strings: Found userPrincipalName: HTTP/firewall.linuxmuster.lan@LINUXMUSTER.LAN
– ldap_check_account_strings: userPrincipalName should be HTTP/firewall.linuxmuster.lan@LINUXMUSTER.LAN
– ldap_check_account_strings: Nothing to do
– ldap_set_supportedEncryptionTypes: No need to change msDs-supportedEncryptionTypes they are 28
– ldap_set_userAccountControl_flag: Setting userAccountControl bit at 0x200000 to 0x0
– ldap_set_userAccountControl_flag: userAccountControl not changed 0x1000
– ldap_get_kvno: Found KVNO: 1
– set_password: Attempting to reset computer’s password
– set_password: Trying to use keytab for FIREWALL-K$ to change password
– set_password: Successfully set password
– ldap_add_principal: Checking that adding principal host/firewall to FIREWALL-K$ won’t cause a conflict
Error: another computer account (CN=FIREWALL,OU=server,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan) has the principal host/firewall
Error: ldap_add_principal failed
– remove_keytab_entries: Trying to remove entries for FIREWALL-K$ from keytab
– execute: Updating all entries for computer account FIREWALL-K$ in keytab WRFILE:/usr/local/etc/squid/squid.keytab
– update_keytab: Updating all entries for FIREWALL-K$
– add_principal_keytab: Adding principal to keytab: FIREWALL-K$@LINUXMUSTER.LAN
– add_principal_keytab: Using supportedEncryptionTypes: 28
– get_salt: Using salt: LINUXMUSTER.LANhostfirewall-k.linuxmuster.lan
– add_principal_keytab: Adding entry of enctype 0x17
– add_principal_keytab: Adding entry of enctype 0x11
– add_principal_keytab: Adding entry of enctype 0x12
– add_principal_keytab: Adding principal to keytab: FIREWALL-K$@LINUXMUSTER.LAN
– add_principal_keytab: Using supportedEncryptionTypes: 28
– get_salt: Using salt: LINUXMUSTER.LANhostfirewall-k.linuxmuster.lan
– add_principal_keytab: Adding entry of enctype 0x17
– add_principal_keytab: Adding entry of enctype 0x11
– add_principal_keytab: Adding entry of enctype 0x12
– add_principal_keytab: Adding principal to keytab: HTTP/firewall.linuxmuster.lan@LINUXMUSTER.LAN
– add_principal_keytab: Using supportedEncryptionTypes: 28
– get_salt: Using salt: LINUXMUSTER.LANhostfirewall-k.linuxmuster.lan
– add_principal_keytab: Adding entry of enctype 0x17
– add_principal_keytab: Adding entry of enctype 0x11
– add_principal_keytab: Adding entry of enctype 0x12
– update_keytab: Entries for SPN HTTP/firewall.linuxmuster.lan have already been added. Skipping …
– add_keytab_entries: Trying to add missing entries for FIREWALL-K$ to keytab
– add_keytab_entries: Checking if HTTP/firewall.linuxmuster.lan needs to be added to keytab
Im Vergleich zu Lars habe ich aber in der Kerberos-Übersicht noch ein Problem mehr: " Hostname DNS Reverse-Lookup" ist bei mir rot. Wo könnte das Problem liegen? Oder ist das nicht unbedingt relevant?
Ich habe es jetzt noch mal mit Tabelle löschen und dann erstellen probiert. Jetzt kommt folgender Fehler:
Password for global-admin@LINUXMUSTER.LAN:
-- init_password: Wiping the computer password structure
-- generate_new_password: Generating a new, random password for the computer account
-- generate_new_password: Characters read from /dev/urandom: 85
-- get_dc_host: Attempting to find domain controller to use via DNS SRV record in domain LINUXMUSTER.LAN for procotol tcp
-- DnsSrvQuery: Running DNS SRV query for _kerberos._tcp.dc._msdcs.LINUXMUSTER.LAN
-- get_dc_host: Attempting to find domain controller to use via DNS SRV record in domain LINUXMUSTER.LAN for procotol udp
-- DnsSrvQuery: Running DNS SRV query for _kerberos._udp.dc._msdcs.LINUXMUSTER.LAN
-- get_dc_host: Attempting to find a domain controller to use (DNS domain)
-- validate: Error: gethostbyname failed for LINUXMUSTER.LAN: Name does not resolve
-- get_dc_host: Found preferred domain controller:
Error: get_dc_host failed
D.h., ich habe wohl noch ein Problem mit der „lokalen DNS-Konfiguration“? Wo muss ich das einstellen?
Wenn ich auf dem Server (ssh 10.0.0.1) bin, funktioniert ping linuxmuster.lan.
Von der Firewall aus (ssh 10.0.0.254), kann ich ping 10.0.0.1, aber ping linuxmuster.lan geht nicht.
Vorschläge?
PS: Hostname DNS Reverse-Lookup ist jetzt wieder grün…
kontrollier mal deine Einstellungen zum DNS in der Firewall.
Dazu gibt es Treads hier im Forum wo steht, wie das eingestellt sein muss.
Läuft der unbound Dienst?
Ist er richtig konfiguriert?
Wichtig ist vor allem, was in der OPNsense unter
System->Einstellungen->Allgemein ganz unten steht.
Bei mir steht da die IP des Servers.
irgendwas läuft da richtig schief.
Wenn ich die kerberos-Authentifizierungscheckliste aufrufe und immer mal aktualisiere, kommen immer wieder andere Dienste, die rot sind. Machmal ist fast alles grün, manchmal fast alles rot :-(…
Zu Deinen anderen Hinweisen:
unbound läuft
„richtig konfiguriert“ ist schwer zu beantworten ;-). Ich habe jedenfalls nichts geändert…
bei System->Einstellungen->Allgemein sind und DNS-Server zwei Einträge:
10.0.0.1
192.168.10.11
jeweils aber ohne ausgewähltes Gateway.
Soll das so? Bei Gateway stehen zur Auswahl:
Wenn ich die kerberos-Authentifizierungscheckliste aufrufe und immer mal
aktualisiere, kommen immer wieder andere Dienste, die rot sind. Machmal
ist fast alles grün, manchmal fast alles rot :-(…
auch bei mir wechseln die Farben ab und zu : per se ist das also nicht
fatal.
Zu Deinen anderen Hinweisen:
unbound läuft
„richtig konfiguriert“ ist schwer zu beantworten ;-). Ich habe
jedenfalls nichts geändert…
… außer dass du die Firewall auf einen früheren Zustand zurückgesetzt hast.
Klingt für mich schon nach einer Änderung …
Und zu dem schwer zu beantworten: hast du das Forum durchsucht nach
Hinweisen, wie das ein zu stellen ist?
bei System->Einstellungen->Allgemein sind und DNS-Server zwei Einträge:
10.0.0.1
192.168.10.11
jeweils aber ohne ausgewähltes Gateway.
Soll das so? Bei Gateway stehen zur Auswahl:
WAN_DCHP6 - wan -
WAN_DHCP - wan - 192.168.11.1
GW_LAN - lan - 10.0.0.254
deine Firewall ist für IPv6 konfiguriert?
Das ist bei mir immer abgeschaltet.
Wo steht den, wie man die OPNsense für die lmn7 mit ipv6 konfiguriert?
ich habe da nichts von Hand eingestellt. Wenn da etwas „konfiguriert“ ist, dann weil das nach Abarbeiten der Anleitung so entstanden ist.
Ich habe mal das „IPv4 bevorzugen“ ausgewählt. Bringt soweit keine Änderung.
Ich bin beim Durcharbeiten des Forums - da ich ja aber (außer das Zurücksetzen der VM der Firewall nach einem gescheiterten Update auf den Zustand direkt vor dem Update) nichts an der Firewall gespielt habe, ging ich davon aus, dass dort alles auf Standard - als korrekt eingestellt - laufen müsste.
Einen Verdacht habe ich noch: durch Raumwechsel unseres proxmox-Hosts (Hardware) hat sich dessen Netzwerk bzw. IP-Adresse geändert. In der opnSense fliegen ja auch 192.168.11.xxx-Adressen rum. Welche Bedeutung haben diese?
Muss da an jeder Stelle die IP von red-Anschluss des proxmox (192.168.11.89) rein oder kriegt die Firewall eine eigene Adresse im red-Netz?
Oder gar nichts von beiden?
):
