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.

Merk dir einfach, dass du bei der Berechnung der BC-Adresse ALLE Host-Bits auf 1 setzt, dann hast du es schon ;-)

Gruß,

AJ

Genau das hat er doch gemacht:

...

 

Wenn ich jetzt die Nullen des Geräteteils mit Einsen fülle komme ich auf folgende Binaärzahl: 00001010.11111010.00111111.11111111

...

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.

Mal abgesehen von den den ganzen alten Normen, ist es theoretisch und auch praktisch möglich 256 Netze zu bilden ;)

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

Es wird davon ausgegangen, dass ein Subnetz nicht aus nur Nullen (dieses Netz) oder nur Einsen (Broadcast) bestehen darf, also zieht man 2 ab, dann sind es 254 ...

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....

Also wenn man mal vom CIDR abgeht und die Frage ohne Subnetzmaske beantoworten muss, dann ist das 190er Netz ein Klasse B Netz

 

So sehe ich das auch

 

Also ich denke du hast Dich verschrieben und meinst C Klasse. :-)

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 ;)

Da es sich bei den Angaben um eine 24 Bit Netzmaske handelt, also 24 der 32 Bit für den Netzwerkbereich, wäre das erste logische Netzwerk die 190.5.0.x /24, das zweite 190.5.1.x /24 und so weiter. Was allerdings die Antworten der zweiten Frage, als falsch beweisen würde, denn dann könntest du 256 Netzwerke erstellen! Was meiner Meinung nach auch richtig ist. Hab vorhin nicht genau hingesehen.

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.

Das falsche Gateway kennt die Route zum Netz ueber das richtige Gateway? Proxy ARP?

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?

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.

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.

Ich meinte die Java Version :)

Ä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?

Nutzt du das freiwillig? :D

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.

Ich benutz 6.1.3 und 8.0.4 fuer mehrere 5505 und 5510.

 

Fang jetzt wegen Java Update 11 mit 6.1.5.51 an ...

Na dann viel Glück :)

Nie ein Problem gehabt. Fuer intensive Nutzung von WebVPN taugt 8.0.3 leider nicht wirklich.

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?

Hallo,

 

ich kenne mich zwar nicht mit der PIX aus.

Aber beim IOS gibt es seit einiger Zeit den Befehl:

 

configure replace

 

Dadurch werden die Konfigurationen nicht gemerged.

Die eingespielte Konfiguration ersetzt so die running-config

 

Mfg

A.

das gibts bei der ASA ned.

...Ich nehme aber an dass ich ein Backup dass per TFTP durchgeführt worden ist eins zu eins mit copy tftp startup hochladen kann...

jepp

...und die neue config leuft anschließend sofort als running config?

Nö --> siehe unten

...Ganz sicher bin ich mir nicht den auf einer cisco Page habe ich etwas vom vorhergehenden Editieren gelsen. Trift das auch hier zu? Auch habe ich es von cisco.com so verstanden: Wenn eine runnig config auf der PIX exestiert und eine ander per copy tftp startup hochgelden wird werden die zwei zusamengeführt. Ist das wirklich so???...

Jenau so iss et.

Basiert auf SSH, nur halt fuer Filetransfer, also auch nur Port 22! :)

Jepp, danke.

Wir haben uns gerade zu SFTP entschieden und funktioniert.

Welchen Sinn wuerde Verschluesselung machen wenn ein Geraet dazwischen den Traffic wieder entschluesseln koennte? :) Wie waere es mit SCP?

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:

One possible workaround in this situation is to use an FTP client that supports the use of a "clear comannd channel" while still using TLS/SSL to encrypt the data channel. With this option enabled, the PIX should be able to determine what port needs to be opened

Wir wollte gerade auf FileZilla umsteigen, eben wegen FTPS, aber hier finde ich die entsprechende Einstellmöglichkeit nicht. Welchen Client würdet ihr empfehlen?