Jump to content

leviathan84

Abgemeldet
  • Gesamte Inhalte

    13
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

10 Neutral
  1. das terminal kann verbindungen von der fortigate zur asa aufbauen. in die umgekehrte richtung funktionierts allerdings noch nicht :/ traffic logging auf der fortigate nicht möglich da kein fortianalyzer vorhanden
  2. laut packet-tracer sollte das packet durchgehn. die SA für die beiden netze local/remote steht. sie bettifft sämtlichen IP traffic zwischen den ausgewählten netzte. der PING funktioniert ja auch. habe mittlerweile mittels "sh conn" festgestellt dass tatsächlich eine UDP Verbindung vom Server ausgehend auf die remote IP aufgebaut wird. Was allerdings noch nicht unbedingt bedeutet dass die Pakete auch im Tunnel landen. Werde mir demnächst die andere Seite vornehmen.
  3. hi, eine Serverapplikation versucht auf einem bestimmten UDP highport (>30000) ein Terminal zu erreichen. Zwischen den beiden liegt ein VPN tunnel (ASA <->Fortigate). Im VPN Tunnel ist IP ohne Einschränkungen erlaubt. PING ist erfolgreich und wird mir auch im Log Viewer auf meiner Seite (ASA) angezeigt. Wenn ich jedoch über die Serverapplikation einen Verbindungsaufbau per UDP initiiere, also versuche das Terminal in das System einzubinden, seh ich keine logs im Log viewer. Problem: Das Terminal kann nicht eingebunden werden. Ich möchte mich vergewissern, dass die UDP Daten in den Tunnel geschickt werden. Auf die Gegenstelle hab ich leider keinen Zugriff. Testweise hab ich eine TFTP Verbindung zwischen den beiden Standorten eingerichtet. Funktionierte erfolgreich und schien auch in den Logs auf! WIe kann ich den UDP Traffic über den Highport mitloggen?
  4. habs jetzt hinbekommen. hab die priorität des dfsnamespace servers, der ne downtime hatte, höher gesetzt. somit kommen alle dfs anfragen direkt an ihn. so gaaanz klar isses mir nach wie vor nicht - aba es funzt :)
  5. kein WINS Server auf den Clients eingetragen nbtstat -c (NetBIOS-Remotecache-Namentabelle) server01 10.1.x.x Richtiger Server mit richtiger IP. Auch ein Ping auf Server01 antwortete mit der richtigen IP nslookup genauso Bin gerade mit demselben User auf einem zusätzlichen Notebook an der Domäne angemeldet und der Zugriff per Kurzname funktioniert! Auf meiner Workstation hingegen nicht!
  6. FQDN und per IP funktioniert: \\server1.local\share1\ordner1 \\10.1.x.x\share1\ordner1 nur mit kurznamen klappts nicht. bei mir is keine GPO gesetzt bei anderen usern eventuell schon. werd ich noch cheggn
  7. dcdiag: Starting test: frsevent There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause Group Policy problems. .........................Server1 failed test frsevent per IP funktionierts von meiner Workstation! also \\10.1.X.X\Share1\Ordner geht wenn ich auf meiner WS nslookup Server1 mach, wird er auch richtig aufgelöst. DNS Servereinstellunge sind eingetragen. Namensauflösung funktioniert
  8. Hi, ich kann seit einigen Tagen auf verschiedensten Workstations einen Ordner in einem Share auf Server1 (2008R2) per \\Server1\Share1\Ordner1 nicht erreichen. Eines unserer Programme sieht sich dort beim Start nach nem .INI file um. Bei einigen funktionierts bei einigen nicht. Fehlermeldung1 bei Zugriff per UNC über Explorer: Netzwerkfehler: Auf \\Server1\Share1\Ordner1 konnte nicht zugegriffen werden; Fehlercode: 0x80004005 Fehlermeldung2 bei Zugriff per durchklicken \\Domäne -> DFSShare1 -> DFSLink (verweist auf Ordner1): "Ordner öffnen": \\Domäne\DFSShare1\DFSLink bezieht sich auf einen Pfad, der nicht verfügbar ist ... Wenn ich den Pfad allerdings auf einen Laufwerksbuchstaben mappe, kann ich den Inhalt des Shares erreichen. Server1, einer von mehreren Domänencontrollern, wurde am Tag bevor die Probleme auftraten neugestartet. Das ist der einzige Anhaltspunkt. Ansonsten wurden keine Konfigurationsänderungen gemacht. Als workaround müssen alle User (>50) welches das Programm benutzen sich ab/anmelden. Machmal funktionierts erst nach mehrmaligem ab/anmelden. Das es mit dem Logonserver zusammen hängt kann ich mittlerweile auch schon ausschließen. Es passiert auch, dass es auf manchen Workstations funkioniert, während es auf anderen zur gleichen Zeit nicht funktioniert. steh nach tagelanger rescherche vor einem scheinbar unlösbaren Problem :( irgendwelche ideen?
  9. die angabe des if führte auch nicht zum erfolg. ich glaube das problem gefunden zu haben. nachdem ich die route eingetragen hatte änderte sich die gateway ip des eintrags in der routing tablle. aber nur in der liste der aktiven routen. interessanter weise auf den zweiten hop (=vpngateway) dahinter. also externer mailserver - vpngateway - lokaler_router - exchange ich hab bisher immer den lokalen router angegeben. allerdings ist das vpngateway auch direkt über layer2 vom exchange erreichbar. jetz hab ich bei der persistenten route gleich das vpngateway angegeben und der eintrag bleibt erhalten! zumindest schon eine halbe stunde lang ;)
  10. hi, habe hier eine win2k3 exchange maschine mit 2 nics (2 vershiedene vlans) und 2 default gateways. das derzeit verwendete gateway 10.0.0.101 ist ein ISA2k6 (hat ein zweites interface in ner DMZ für mailempfang und OWA). das zweite gateway 10.0.0.102 ist der core switch (VLAN router) und wird für anfragen aus dem internen netz verwendet (interne clients auf exchange). die gateways haben unterschiedliche metriken. If1 hat kein gateway eingetragen. If2 hat nur 10.0.0.102 eingetragen. 10.0.0.101 wurde dann scheinbar manuell als persistant default route eingetragen. 10.0.0.101 == metrik 5 10.0.0.102 == metrik 10 ich benötige eine statische host route (192.168.1.100/32) auf 10.0.0.102 um den retour traffic dieses hosts über 10.0.0.102 zu schicken. ohne die route wird der traffic derzeit über 10.0.0.101 zurück geschickt. route add <ip_zielhost> mask 255.255.255.255 10.0.0.102 -p Nach dem hinzufügen der route scheint diese in den "active routes" und "persitant routes" listing des "route print" outputs auf. die route wird anschließend auch verwendet. interessanterweise scheint sie allerdings unter den aktiven routen mit einem anderen zielgateway auf. sieht fast wie ein bug aus. funktioniert aber trotzdem erstmal. Nach wenigen minuten verschwindet sie allerdings ohne weiteres zutun aus den "active routes" und somit zieht wieder 10.0.0.101. "route print" output: Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 10.0.0.102 if2 10 0.0.0.0 0.0.0.0 10.0.0.101 if2 5 .... Default Gateway: 10.0.0.101 =========================================================================== Persistent Routes: Network Address Netmask Gateway Address Metric 0.0.0.0 0.0.0.0 10.0.0.101 5 192.168.1.100 255.255.255.255 10.0.0.102 1 ... kann mir jemand das verhalten erklären bzw. sagen wieso die route aus der routing tabelle verschwindet??
  11. die funktion welche das timestamp erzeugt lieferte nicht das aktuelle Datum zurück. funktion auf GETDATE() geändert => solved
  12. danke, auf die Daten kann jetzt zugreifen. Allerdings werden Sie erst nach ca 2 Stunden aktualisierst
  13. hi, ich verwende einen MS SQL Server um VPN Anmeldungen zu protokollieren. Die VPN Verbindungen werden an einem IAS (Win2k3) über das Active Directory authentifiziert. Zur zeit wird sowohl in ein lokales File am IAS wie auch auf den SQL Server gelogt. Allerdings wird das Log am SQL Server Ca. 2 Stunden verzögert aktualisiert. Das lokale File ist immer aktuell. Wo kann man diese Verzögerung konfigurieren? Des weiteren Suche ich eine Möglichkeit einen SQL View remote über meine Workstation über eine Client Applikation abzurufen, damit ich mich nicht immer extra mit dem SQL Server verbinden muss. mfg
×
×
  • Neu erstellen...