Jump to content

RalphT

Members
  • Content Count

    594
  • Joined

  • Last visited

Community Reputation

14 Neutral

About RalphT

  • Rank
    Board Veteran

Recent Profile Visitors

449 profile views
  1. Ich wollte noch mal kurz eine Rückmeldung geben: In diesem Fall war es einfach: Ein Neustart half.
  2. Moin Norbert, Nein, den habe ich nicht. Ja, der Panda. Dazu muss ich sagen, dass ich den auch schon im Verdacht hatte. Mein nächster Weg wäre jetzt erst mal einen Neustart durchzuführen. Nur geht das gerade jetzt nicht. Dazu müsste ich bis heute abend warten. Evtl. könnte ich mal testweise den AV deinstallieren. Äh, nein leider nicht. Wäre wohl der nächste Schritt, wenn ein Neustart nichts bringt. Ja, ich weiß, man sollte immer up to date sein. Aber die Kiste läuft schon so lange ohne Probleme, dann denkt man an ein Update nicht so oft. Die Clients sollten auf dem aktuellen Patchstand sein.
  3. Moin, ich habe hier ein Problem mit einem Exchange 2010 SP3. Wenn ich im Outlook eine Mail versende, bleibt manchmal unten im Outlook der grüne Balken mit "Nachricht 1 von 1 wird versendet" für ca. 2 Min. stehen. Beim Emfänger ist die Mail jedoch schon angekommen. Das geschieht auch immer sehr zeitnah. Parallel zum E-Mail-Konto habe ich den OWA dazu aufgerufen. Im OWA habe ich mehrmals eine Nachricht an einen selbst versendet. Vom OWA aus scheint das alles sehr schnell zu funktionieren. Auch im Outlook des Empfängers erscheinen zügig die neuen Mails. In der Ereignisanzeige vom Exchange ist keine Fehlermeldung zu sehen. Testweise habe ich mal den lokalen Cache vom Outlook gelöscht und Outlook wieder gestartet. Die anschließende Replikation schien soweit zu funktionieren, brachte aber keine Besserung. Der Fehler scheint wohl nur beim Versenden im Outlook aufzutreten. Was könnte das denn sein? PS: Manchmal ist es auch so, dass bei Outlook steht "Übermittlung wird vorbereitet". Die Mail ist aber schon sofort raus und auch beim Empfänger angekommen. Das habe ich eben auch mal an einen anderen Arbeitsplatz ausprobiert.
  4. Nein, wichtig ist das nicht. Ich bin da heute durch Zufall drauf gestoßen. Hätte ja sein können, dass das auch schon mal jemand hier hatte. Ich weiß auch garnicht, ob die Mehrheit einen Client über diesen Weg in die AD bringt oder mit dem Button darunter "Ändern". Dann gibt es diesen Fehler nicht und hier ist auch weniger Tipparbeit erforderlich.
  5. Moin, ich bin heute über eine Sache gestolpert, die ich derzeit nicht verstehe. Die Umgebung: 2 DCs 2008 R2 und ein Client Win10. Domäne = SUB.FIRMA.DE Netzwerk: Die beiden DCs sind im LAN 192.168.10.0/24. Auf dem einzigen Switch ist noch zusätzlich ein VLAN konfiguriert: 192.168.21.0/24. Der Switch macht zwischen den beiden LANs das Routing. Firewalls auf DCs sind testweise mal deaktiviert. Der Client ist derzeit im VLAN 192.168.21.0/24. Ich nehme den Client aus der Domäne. Das Konto auf dem DC lösche ich nicht. Ich nehme den Client wieder in die Domäne. Dazu gehe ich den Weg mit dem Button "Netzwerk-ID..." Dort trage ich im ersten Fenster die Daten ein. Klicke ich auf Weiter, sagt mir das System, dass schon ein Konto existiert und fragt, ob ich das Konto verwenden möchte. Ich klicke auf JA. Jetzt kommt folgender Fehler: Fehler: "Der DNS-Name ist nicht vorhanden." (gekürzt) Lösche ich das Computer-Konto in der AD, dann kann ich den Client der Domäne hinzufügen. Wenn ich den Client im gleichen LAN in dem auch die beiden DCs sind, dann habe ich das o.g. Problem nicht. Der Client bekommt sein IP-Konfiguration vom DHCP. Die beiden DNS-Einträge auf dem Client zeigen auf die beiden DCs. Fehlt hier im DNS ein Eintrag oder ist das Verhalten normal?
  6. Alles klar, danke Dir! Ich hatte das zwar nur testweise gelöscht, aber vielleicht sollte ich dafür zusätzlich ein GPO verwenden. Das ist dann wohl doch sicherer. Gerade eben hatte ich noch folgendes ausprobiert: Client aus Domäne raus und rein. Danach waren die Einträge wieder da.
  7. Ich wollte eigentlich nur wissen, wie diese Einträge in dem lokalen Zertifikatsspeicher unter "Zwischenzertifizierungsstellen" erscheinen. Irgenwie scheint das automatisch nicht zu funktionieren. Bislang ist mir das nie aufgefallen, da diese Einträge eigentlich bei jedem Client auch immer vorhanden sind. (Wenn man sie nicht händisch löscht)
  8. Daran hatte ich schon gedacht, mir dann aber überlegt, dass das ja vorher auch immer so funktionierte. Ich hatte mir über diesen Speicherort bislang keine Gedanken gemacht. Wie lange muss man da denn warten? Ein gpupdate half hier auch nicht. Eigentlich nicht weiter wild, denn die Zertifkate an den wichtigen Orten sind ja vorhanden.
  9. Moin, ich habe eine 2-stufige PKI. Auf jedem Server/Client in der Domäne sind Einträge im lokalen Zertifikatsspeicher unter "Zwischenzertifizierungsstellen". Dort ist das ROOT und SUB-Zertifikat zu finden. Bei einem Client habe ich das mal gelöscht. Nach dem Neustart des Clients waren die beiden Zertifkate nicht mehr da. Wie kommen diese Einträge dort hin? Wozu dienen diese beiden Zertifkate an diesem Speicherort? Der Eintrag vom ROOT-Zertifikat ist unter "Stammzertifizierungsstellen" weiterhin zu finden. Dort sorgt ja eine GPO für die Verteilung.
  10. Ich sehe gerade, dass auf der Seite Verbindungsliste die Regelerzeugung auf automatisch steht.
  11. Ich bin gerade am suchen, wo der Eintrag geblieben ist. Seit diesem Update finde ich den gerade nicht. Bei den anderen Lancoms steht der Wert immer auf "Jede einzeln nach Bedarf". Ich bin mir sehr sicher, dass ich hier nichts verändert habe, daher behaupte ich mal, dass das auch für diese Lancom zurifft.
  12. Nun habe ich heute die Version 10.20 RU2 aufgespielt. Nachdem der Router seinen Neustart beendet hatte, hatte ich gleich gesehen, dass das nicht Erfolg führte. Ich musste also beim Tunnelaufbeu bei 2 Netzen wieder nachhelfen. Jetzt bin ich mir nicht sicher, ob ich dich richtig verstanden habe: Besteht das Problem im VPN immer noch bei der aktuellen Version oder redest hier von VRRP?
  13. Danke dir. Ich habe einen Lancom, der ist derzeit nicht so wichtig. Da werde ich die 10.20 RU aufspielen. Dann mal sehen. Auf der Lancomschulung hat man mir zig mal eingetrichtert, dass ich immer die neueste Firmware nehmen soll. Ok, ich gucke da nicht immer regelmäßig drauf. Vielleicht auch deshalb, weil alles funktioniert. Bei der Sonicwall hatte ich auch mal ohne vorher nachzufragen, die neueste Firmware aufgespielt. Naja, danach hatte ich große Augen: Es waren im Firewallregelwerk nicht mehr alle Regeln zu sehen. Aber sie wirkten noch - zum Glück. Eine Nachfrage beim Händler ergab, dass es dort einen BUG gab. Regeln, die in der Beschreibung Umlaute hatten, wurden nicht mehr angezeigt. Da gab es auch von der Sonicwall einen Beitrag dazu, wie man das wieder in Ordnung bringt.
  14. Hmmm, also auf dem Problemlancom ist die 10.12.038RU9. Auf einem anderen Lancom, der auch mal Probleme macht ist sogar noch die 9.24.0070 drauf. Ich habe gerade nachgesehen: Derzeit ist 10.20 RU2 aktuell. Dazu muss ich sagen, dass ich bei keinen der Lancoms VRRP nutze. Dann könnte ich die doch nehmen - oder??
  15. Moin, ich habe hier schon länger ein Problem. Der VPN-Tunnel zwischen einer Sonicwall NSA 2600 und einem Lancom 1783 VAW ist nach einer gewissen Zeit immer gestört. Wenn das der Fall ist, dann ist zwischen den verbundenen LANs keine Datenübertragung mehr möglich. Zwischen der Sonicwall bestehen auch noch andere VPN-Verbindungen zu anderen Lancoms. Auch zwischen diesen Verbindungen tritt ab und zu mal dieses Problem auf. Auf der Sonicwall und auf dem Lancom ist der Tunnel immer noch verbunden. Hier etwas zur Konfiguration: Zwischen der Sonicwall und dem Lancom bestehen mehrere Netzbeziehungen. Auf der Sonicwallseite sind es derzeit 5 verschiedene LANs und auf der Lancomseite sind es 2 verschiedene LANs. Der Fehler äußert sie wie folgt: Es wird oder wird nur meist nur eine LAN-Verbindung unterbrochen. Also die anderen bestehenden Netzbeziehung zwischen den beiden Firewalls funktionieren einwandfrei. Jetzt ist natürlich die Frage, was ist an dieser gestörten LAN-Verbindung anderes? Da habe ich länger geforscht und bin jetzt der Meinung, dass das am Traffik liegt. Denn zwischen diesen LANs wird fließt der meiste Datenverkehr. Abhilfe schafft entweder ein erneuter, kompletter Tunnelaufbau auf der Seite vom Lancom oder ein erneuter Aufbau nur von diesem Netz auf der Sonicwall. (Button Renegotiate) Anschließend wird nur diese Netzbeziehung wieder erneut aufgebaut und das Problem ist für mehrere Stunden ok. Auf der Lancomseite und Sonicwall habe ich folgende Werte für den Tunnel konfiguriert: --------------- Sonicwall -------------- Phase 1: Main-Mode DH-Group 2 AES-128 SHA-1 Lifetime 108.000s Phase 2: ESP AES-128 SHA-1 Lifetime: 28.800s --------------- Lancom -------------- Phase 1: AES-128 SHA-1 Liftetime: 108.000s Phase 2: AES 128 SHA-1 Liftime: 28.800 0 kBytes Hier die Netzbeziehungen (die habe ich zig mal auf beiden Seiten auf Richtigkeit kontrolliert): Seite Sonicwall: 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 192.168.4.0/24 192.168.5.0/24 Seite Lancom: 192.168.10.0/24 192.168.12.0/24 Hier wird auf beiden Seiten mit fester IP-Adresse und Presharedkey gearbeitet. Der meiste Traffik läuft auf der Sonicwallseite im Netz: 192.168.5.0/24. Und genau nur diese Verbindung zu den Remotenetzen im Lancom ist gestört. Alle anderen Netzbeziehungen laufen ständig. Ode sagen mir vorsichtig so: Hier wurde bislang keine Fehler festgestellt. Wenn der Tunnel händisch neu aufgebaut wird, dann hält das für ca. 6-7 Std. Diese Zeit entspricht aber nicht dem Erneuerungsintervall von 28.800s. Anschließend darf man wieder "Hand anlegen". Was mich dabei stutzig macht ist folgendes: In der Sonicwall kann ich für den gesamten Tunnel die Option "Disable IPsec Anti-Replay" aktivieren. Wenn man das dann abspeichert, funktioniert der VPN manchmal wochenlang tadellos. Bis der Fehler dann wieder auftritt. Ab dann tritt das Phänomen wieder regelmäßig auf. Dann nehme ich in der Sonicwall wieder diese o.g. Option raus. Danach läuft das wieder wochenlang. Ich denke mal, dass diese Option mit diesem Fehler nichts zu tun hat. Ich tippe eher darauf, dass dieser Fehler durch eine Konfigurationsänderung erstmal weg ist. Das wird wohl Zufall sein. Meine letzte Idee war, dass die Sonicwall mit der Firmware dieses Problem hat. Ich hatte aber, mit Rücksprache von Sonicwall, eine aktuelle, gut lauffähige Firmwareversion aufgespielt. Aber daran lag es nicht. Ja, jetzt die spannende Frage: Hat da jemand eine Idee?
×
×
  • Create New...