hegl

Jepp, ASDM Webseite kommt und der Aufruf scheint erstmal auch zu funktionieren - aber er lädt halt die config nicht. Werde wahrscheinlich erst heute Nachmittag da weiter machen können...

Das war leider nur ´ne kurze Freude: nachdem es endlich funktionierte habe ich noch ein paar lesende Zugriffe gestatte, wie privilege show level 5 mode exec command nat und plötzlich zickt der ASDM Version 6.4 wieder herum. Also ASA neu gebootet (funktionierende config war noch in startup-config) und...Pech gehabt, ASDM tut´s schon wieder nicht, SSH ja. Heisst also, dass ich den ASDM aufrufen kann und beim abrufen der config kommt o.g. Fehler. Bis jetzt läuft die ASA ohne VPN-Konfiguration, d.h. nur mit ein paar ACL´s. Jetzt habe ich auf disk0: noch gesehen, dass hier mehrere Datein FSCK00xx.REC vorhanden sind. Im CISCO-Forum spricht ein CISCO-Mensch von einem "defekten" Dateisystem. Komisch ist allerdings, dass beide neuen ASAs 5505, Version 8.2.5 diese Dateien haben und auch über Google sehe ich, dass ich nicht der Einzige bin. What the hell is going on???

Oh man. Die Frage nach SSH war des Rätsels Lösung: aaa auth ssh fehlte. Aber wieso läuft der ASDM genau bis zu dem Zeitpunkt, wo die erste ACL gesetzt wird? Denn ab hier fängt das Problem dann an; das kann ich so nachstellen. Und, war früher in den V8.2x nicht dieser Befehl schon standardmäßig konfiguriert? Ich weiß es nicht genau, da die letzte Grundkonfiguration schon was her ist und ich die Dinger dann erst immer von V8.x auf die neuste Version gebracht habe (bisher max. V8.2.3)

Bin gerade beim Einrichten einer ASA5505 per ASDM und soweit eigentlich auch fertig (gewesen). Dann habe ich noch SSH-Zugriffe für bestimmte Hosts erlaubt und erhalte plötzlich die Meldung: Habe dann via CLI die letzten Befehle wieder rausgenommen - leider ohne Erfolg. Auch ein Reboot der ASA bringt mich nicht weiter. Habe mal auf http den debugger laufen lassen; der letzte Eintrag ist "file not found: disk0/dap.xml" Kennt jemand das Problem?

Keinerlei Fehlermeldungen Keine erwähnenswerte Netzlast vorhanden

Thx :)

Stelle mir gerade die Frage, wann ziehen die Gruppenrichtlinien in einer Domäne. Direkt bei der Anmeldung, wie läuft das dann ab? Gibt´s da irgendwo ein Funktionschemata zu? Was kann dazuführen, dass einzelne Rechner die GPL nicht zugewiesen bekommen, obwohl die Rechner einwandfrei im Netztwerk kommunizieren können, d.h. auch an der Domäne angemeldet sind?

ups, vielleicht schlägt es ja manchmal doch durch, dass ich vom Land komme :cool: By the way, erfahre gerade, dass ein UAG-System aufgesetzt werden soll und hier zwingend zwei NICs benötigt werden. Warum allerdings UAG und nicht "nur" TMG weiß ich jetzt nicht, wer weiß, was da wieder alles geplant wird...:confused::confused::confused:

Ääääähhhh, was ist denn KISS?

Jepp, soll für Exchange, aber ggf. auch zukünftig für Sharepoint eingesetzt werden. Um sich die volle Funktionalität nicht zu verbauen, soll halt über 2 NICs gearbeitet werden. Wer weiß, was noch alles kommt.... Im Cisco-Forum habe ich eben gesehen, dass bei einer Lösung der TMG hinter der FW installiert wird. Hieße also, dass ich mein jetziges inside der FW an das outside des TMG hänge und die interne NIC des TMG dann ins LAN. Macht das unter den gegebenen Umständenden denn Sinn? Dazu müsste ich natürlich einige Änderungen vornehmen und käme ohne einen Ausfall nicht herum. Oder wäre der Ansatz einen zweiten Weg ins LAN zu konfigurieren die sinnvollere Lösung? Was wäre denn bei einem totalen Neuaufbau die sinnvollste/sicherste/bevorzugte Lösung?

Wir wollen/müssen in eine bestehende Firewallstruktur mit mehreren unterschiedlichen DMZ´s einen TMG integrieren. Da weiterhin nur die zentrale Firewall den Zugriff ins interne LAN bereitstellen soll, gibt es wohl ein dickes Problem: Laut den Beschreibungen unter Planning Forefront TMG network topology muss ein interface zwingend ins internen LAN zeigen; das hat mir auch ein Microsoft-Spezi so bestätigt. Ist dem wirklich so? Wir hatten eigentlich geplant, das externe interface in eine von außen zugängliche bestehende DMZ zu integrieren und für das interne interface eine neue DMZ der bestehenden Firewall zu schaffen, worüber dann der Verkehr ins interne LAN geroutet würde. Daraus scheint aber wohl nichts zu werden, oder?

Genau dieses Problem haben wir jetzt auch: Manche WIN7-Clients registrieren sich ausschließlich mit der IPv6-Adresse im DNS, alle anderen zusätzlich mit der IPv4. Die Clients werden zudem über ein Image absolut gleich installiert. Wir fahren eine 2008-er-AD im 2003-er Modus (wegen altem Exchange 2003). DC sind auch DHCP- und DNS-Server. Die Clients beziehen nur eine IPv4 Adresse vom DHCP-Server, bzw. nur DHCP für IPv4 ist dort konfuguriert. Der Unterschied zum o.g. Beispiel ist, dass wir für die DC ausschließlich Windows 2008 R2 einsetzen. Selbst das Deaktivieren von IPv6 oder nur "IPv4 vor IPv6" mittels Registry-Eintrag MSXFAQ.DE - IPV6 brachte keinen Erfolg. Wer kann helfen?

Vielen Dank für Deine Mühen - da suche ich schon äußerst lange dran. :):):)

Wir haben nun LMS 4.0.1 im Einsatz. Hier stellen wir fest, dass beim Webzugriff eines Clients (WinXP) die Speicherauslastung auf diesem den Tag über so ansteigt, dass der Rechner "steht"; d.h. die Auslagerungsdatei geht in die Begrenzung. Selbst wenn wir den Grenzwert hochsetzen ist bei ca. 1,5 GB an ein Arbeiten nicht mehr zu denken. Durch manuelles Aktualisieren des dashboards geht die Auslastung zwar merklich zurück, aber anschließend fängt das Spiel wieder von vorne an. Ist einem hierüber etwas bekannt?

Hmm, wenn das komplette 172.16.55.0 in den Tunnel geschoben wird, wieso sollte dann ausgerechnet die eine IP der ASA 172.16.55.1 nicht in den Tunnel gehen? Ich denke eher, dass die Kommunikation gar nicht über die 172.16.55.1 geht, da sich ja das 192.168.202.0 hinter dem outside-interface verbirgt und nur über den Tunnel erreichbar ist. Das scheint wieder was CISCO-spezifisches zu sein. An einem anderen Standort mit einer äquivalenten Konfiguration, aber mit einer Astaro, klappt das wunderbar.

Folgendes Szenario: Wir betreiben an einer Aussenstelle (LAN = 172.16.55.0) eine ASA5505 (InsideIP: 172.16.55.1), die per L2L-VPN mit unserer Zentrale (LAN = 192.168.202.0) kommuniziert. In der Aussenstelle steht ein Server, von dem aus ich mich per ASDM auf die ASA verbinde. Dies klappt auch soweit ganz gut, wenn ich den lokalen User auf der ASA nehme. In der Zentrale steht aber ein Radius-Server (192.168.202.77), über den ich die Authentifizierung laufen lassen möchte. Von jedem Rechner in der Aussenstelle funktioniert der Zugriff zum Radius-Server, nur von der ASA nicht: Wo liegt der Fehler?

Falsch, ich bekomme nur von unserem Security-Beauftragten das OK für die Einrichtung des RA. Und dann richte ICH es denen so ein, dass halt kein gleichzeitiger Internet-Access möglich ist ;) Nachfragen gingen noch nie weiter als bis zu mir :p und die Antwort heisst dann, dass die Unternehmens-Policy dies nicht vorsieht.

.....

Bei uns ist es genauso: Eigene MA nutzen dann über VPN den internen Proxy, die externen MA (Supporter) müssen sich halt damit zufrieden geben, dass sie dann kein Internet machen können. So sieht es unsere Policy vor.

Jepp, dns-doctoring wäre die Lösung. Ich denke jetzt doch, dass ich es so realisieren werde.

Grundsätzlich ja, aber der Kunde hat keine eigene Domain... Lässt es sich nicht anders lösen?

Wenn ich bei einem Standard-DSL-Router ein Portforwarding von der outside-IP auf eine interne Adresse mache, kann ich von intern die externe Adresse ansprechen, um auf den internen Server zu kommen. So hatte dies bis dato ein Kunde realisiert, um sowohl vom HomeOffice, als auch vom LAN auf diesen Server zuzugreifen. Das heisst, er gibt beim Programmaufruf die externe IP mit und kann so von extern und intern auf den Server zugreifen. Jetzt wollte ich diesen Kunden über eine Kunden-ASA anbinden, falle aber auf die Nase, weil die ASA dies nicht zulässt. (Nach meiner Logik auch vollkommen richtig, denn warum sollte ich eine interne Adresse über eine externe mit NAT ansprechen?) Der Kunde meckert nun natürlich, dass er nun immer die IP ändern muss, jenachdem wo er sich gerade befindet. Wie komme ich hier raus? DNS ist keine Alternative.

Sorry, aber das ist ja wohl absoluter Schwachsinn. Bevor Du Dir die config verbiegst, würde ich an anderer Stelle etwas Druck machen.

Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues - Cisco Systems

Ich kenne die Problematik mit defekten GBics. Was sagt denn die Portstatistic, hast du da irgendwelche Fehler (FCS-Error, CRC-Error)?