hegl

Ich habe mal ne alte config rausgekramt und meine mich auch erinnern zu können, dass das gewählte transform-set nicht geht. Versuch es mal mit 128-Bit AES. In meiner alten config finde ich auch keine Eintrag analog zu tunnel-group-map default-group Birmann Also könnte der überflüssig sein oder sogar ggf. stören. Teste es einfach mal aus.

Genau das hat er doch gemacht: Nur hat er sich dabei im Netzteil verschrieben....

Wir würden gerne im VPN-Client dem User es nicht gestatten, die Stateful Firewall zu aktivieren. Dazu wäre es sinnvoll, die Option auszublenden. Bei CISCO habe ich dazu auch etwas gefunden, VPN Client Rel 4.7 Release Notes [Cisco VPN Client] - Cisco Systems um bei der Installation dies schon so zu konfigurieren. Leider werde ich da überhaupt nicht schlau draus. Hat dies schon mal jemand gemacht oder hat einen anderen Tipp? Hintergrund ist der, dass wir remote nicht mehr auf ein Anwender-Notebook zugreifen konnten, weil eben der Haken bei Stateful Firewall (Allways On) gesetzt war. Eine Möglichkeit wäre vielleicht die vsdata.dll zu eleminieren. Aber mache ich da nicht was anderes ggf. zu nichte? Eine Personal Firewall haben wir nicht im Einsatz.

Ups, jetzt wo du es sagst. Im 134-er Netz haben wir ja auch das Eigene mitgezählt :):):)

Jepp, das war´s. Aber damit ist die Aufgabe schon wieder hinfällig, weil es dann das Netz 192.5.0.x gar nicht geben darf....

Nö! 190-er Netz ist laut Einteilung ein Class-B-Netz. Durch das Subnetting erhält es "nur" einen Class-C-Character. Ich glaube, wir meinen jedenfalls das Gleiche ;) Deiner Erklärung stimme ich auch zu, nur dem Ergebnis nicht. Das erste Netz wäre das eigene, also 192.5.0.x. Zu adressieren wären nun noch die Netze 192.5.1.x, 192.5.2.x ...192.5.255.x --> also 255 Netze. Da aber die Lösung nicht angeboten wird, nehme ich an, dass sich hier auf eine alte RFC bezogen wird (weiß aber leider nicht mehr welche). Ich habs aber auch nie richtig verstanden. Jedenfalls sind danach bei einem 8-Bit-Subnetting nur 254 Subnetze möglich. Soviel ich weiß, ist diese RFC aber nachher angepasst worden. Also müssten die richtige Antwort m.E. 255 sein.

Jepp, das ist es. no ip proxy-arp Thx

Gute Frage. Habe gerade mal versucht mir dazu ein paar Gedanken zu machen. Bin mir aber bei dem 190-er Netz nicht sicher - vor allem wegen den möglichen Antworten. Aber vielleicht ensteht ja hierdurch eine Diskussion und wir erarbeiten dies gemeinsam? Im ersten Fall meine ich, dass nur ein Netzwerk logisch adressierbar ist. Es handelt sich um ein Class-B-Netz mit der dazugehörigen Standardmaske. Also geht der Bereich von 134.5.0.1 - 134.5.255.255 und nur dieses ist logisch adressierbar. Im zweiten Fall handelt es sich wiederum um ein Class-B-Netz, allerdings mit einem 8-Bit Subnetting. Vorausgesetzt in dem 190.5.x.x würden nur 8-Bit-Subnetze existieren, wären 254 mögliche Netze logisch adressierbar. Da diese Annahme aber nicht vorausgesetzt werden kann, bin ich mit meinem Latain am Ende und würde sagen, meine Aussage ist falsch. Ich bin gespannt, wer weiterhelfen kann.

Ein Azubi hat mir gerade eine Frage gestellt, worauf ich nicht eindeutig antworten konnte. :mad: Folgende Situation: Cat6500 mit RSM und konfigurierten VLAN´s. Nun ist es möglich, dass trotz Eingabe eines falschen Gateway auf dem WINXP-Client, ein ping auf einen anderen Client in einem anderen VLAN funktioniert. Was hat das für Gründe? Ist das ok?

Tun sie auch, nur sind in der 8.0.4 wieder Fehler, die in der 8.0.3 nicht auftraten. Also schön auf der 8.0.3 bleiben, oder auf ne 8.0.4 InterimsRelease setzen.

sorry, war falsch.

Habe gerade eine neue 5505 bekommen mit Version 8.0.4 und dem ASDM 6.1.3 Die sollten sich dann wohl auf jeden Fall verstehen.

Ähhh, komme gerade nicht ganz mit. Wie soll ich den ASDM ohne Java nutzen, oder was meinst Du? Die eingesetzte Java-Version benötige ich wegen LMS.

Ist es denn jedesmal um die gleiche Uhrzeit? Dann schau doch mal, was um diese Uhrzeit am interface drüber geht. Wo sind die Mail- und Webserver konnektiert, auch am inside?

Du meinst den Hit-Counter? Was heisst hier nutzen? Er ist ganz hilfreich, um die config gering zu halten. Ich erhalte aus meiner Sicht soviel Müll (denn sie wissen nicht was sie tun...), und so kann ich wenigstens kontrollieren, was wirklich benötigt wird und dann ggf. entsprechend reagieren.

Na dann viel Glück :) WebVPN iss bei uns kein Thema, deshalb 8.0.3. Würde gerne auf eine höhere Version vom ASDM gehen, da dort das Problem mit dem Hit-Counter nicht mehr besteht. Aber dann werden Änderungen über den ASDM nicht richtig umgesetzt/übertragen. Das äußert sich so, dass man "apply" zeimal drücken muss, bevor der ASDM reagiert. Im ASDM ist dann der Befehl enthalten, aber in Wirklichkeit nicht übertragen worden. Selbst ein wr m hilft nicht. Nach schließen und starten des ASDM ist der entsprechende Befehl auch dort nicht mehr sichtbar. Oder kann das ein Java-Problem sein? Nutze 1.5.0_13

ASDM 6.1.5 und ASA5505 - dass passt nicht. Es läuft zwar, ist aber fehlerbehaftet. Auch wenn CISCO in seinen RN angibt, dass ASDM 6.1.3 und 6.1.5 für die 8-er Images der ASA laufen, so ist die Empfehlung von Consultans eine andere. Ich bin aufgrund diverser Probleme bei Verwendung von ASDM 6.1.3 bzw 6.1.5 auf die 6.0.3 zurück und bin glücklich damit (ich fahre auf der ASA die 8.0.3) ;) Unter 8.0.2 mit ASDM 6.0.2 hatte ich auch keine Probleme, mit 6.0.3 schon. Man sieht hier, dass da irgendwie ne Logik drin ist: ASDM 6.0.2 --> ASA 8.0.2 ASDM 6.0.3 --> ASA 8.0.3 usw. Das sind meine Erfahrungen für mehere 5520 und einer 5505.

Habe den Fehler gefunden - ein falsches static Dankeee.

Ich habe noch eine PIX515E, Version 6.3(3) im Einsatz. Plötzlich stellen wir fest, dass es an einem interface zu Problemen kommt. An diesem interface existiert ein CLASS-C-Netz. Mit wireshark habe ich nun festgestellt, dass die PIX sich für alles aus dem Netz verantwortlich fühlt; heisst speziell: der Rechner 10.10.10.1 fragt nach, wer hat 10.10.10.2. Ehe der host antwortet, sagt die PIX "Hey, das bin ich" nimmt darauffolgende Pakete kann, die aber durch die ACL´s denied werden. Alles was in dem Netz intern kommunizieren soll, läuft über die PIX. OK, sie ist das Gateway, aber in einer Broadcast-Domain spielt das doch keine Rolle. Alles was aus einem anderen Netz bzw. von einem anderen interface kommt und die Zieladresse im besagten Netz hat, wird entsprechend der ACL´s behandelt und funktioniert auch. Kennt jemand das Problem? Defefkte NIC?

Ich verzweifele gerade bei dem Versuch eine ASA5505 via Modem und Console-Port anzusprechen. Meine alten Elsa-Modems nehmen keinen Ruf an und alte, aber noch nagelneue Acer-Modems nehmen den Ruf zwar an, verständigen sich aber nicht mit der Console. Die Verbindung zwischen Console und und RS232 des Modems habe ich mittels Original Serial-Modem-Kabel, Null-Modem-Kabel und dem Cisco Console-Kabel versucht herzustellen. Was mache ich falsch bzw. wer weiß wie man dies bewerkstelligen kann?

das gibts bei der ASA ned.

jepp Nö --> siehe unten Jenau so iss et.

Jepp, danke. Wir haben uns gerade zu SFTP entschieden und funktioniert.

Muss mich erst mal schlau machen, was SCP ist ;) Anforderung ist halt den alten FTP-Server gegen eine neue, sichere Client-Server-Verbindung auszutauschen.

Ist es richtig, dass die ASA kein FTPS unterstützt? Ich habe dies "nur" im Zusammenhang mit der Version 7.x gelesen, aber nicht für die 8-er. Als workaround schreibt CISCO bei der 7-er: Wir wollte gerade auf FileZilla umsteigen, eben wegen FTPS, aber hier finde ich die entsprechende Einstellmöglichkeit nicht. Welchen Client würdet ihr empfehlen?