Jump to content

hegl

Abgemeldet
  • Gesamte Inhalte

    704
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von hegl

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

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

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

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

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

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

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

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

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

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

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

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

×
×
  • Neu erstellen...