Jump to content

hegl

Abgemeldet
  • Gesamte Inhalte

    704
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von hegl

  1. Active bedeutet, dass der zweite Node sozusagen mit läuft und beim Ausfall des ersten Nodes einspringt.

    Standby Failover wird meistens für Datenbanken verwendet. Hier wird ein identisches System installiert, welches sich mit dem aktiven repliziert und dann bei einem Fehlerfall des aktiven Systems, hochgefahren wird.

     

    Das sehe ich allerdings ein wenig anders:

     

    wie der Kollege blackbox schon erwähnte laufen bei Active/Active beide Systeme aktiv und machen load balancing. In diesem Modus ist kein VPN-Failover möglich!!!

     

    im Active/Standby laufen zwar auch beide Systeme, hierbei ist aber nur eine - und zwar das primary - aktiv. Im Fehlerfall muss also das zweite System nicht hochgefahren werden, sondern übernimmt die Funktion des Ersten mit den entsprechenden IP-Adressen. Die Umschaltzeit ist hierbei länger (bei Active/Standby dagegen fast nicht merkbar).

  2. Hallo Hegl,

     

    die Frage ist nur, wieso andere Clients keine Probleme damit haben. Wenn ich mich von hier (ausm Büro) bei unserem Kunden einwähle, fluppt es ja tadellos.

     

    Diese Frage kann ich Dir leider auch nicht beantworten - aber diese Erfahrungen habe ich auch gemacht.

    Ich hatte seinerzeit verschiedene VPN-Konstellationen nachgebaut und alle funktionierten. Nur der eine Kunde konnte die RDP-Verbindung nicht aufbauen, wobei ich natürlich dann auch den Fehler bei ihm (in seiner Fireall bzw.bei seinem VPN-Gateway) vermutet habe. Dieser Kunde hatte aber angeblich keine Probleme zu anderen Systemen per RDP und sah keinen Grund, den Fehler bei sich selber zu suchen - das ist halt immer das Problem wenn zwei Seiten mitmischen :mad:

    Bei den PIXen hatte ich auch keine Möglichkeit in Richtung Pre-Fragmentation etwas zu ändern, bei der ASA zum Glück schon. So bin ich aus der Sache rausgekommen.

  3. Hi,

     

    meinst Du mit NAT-T den klassichen DSL-Zugang mit einem "NAT-Router", der also ein privates Netz mit einer öffentlichen IP im Internet darstellt?

     

    Ja!

     

     

    Ist das bei UMTS theretisch nicht gleich?Die Karte erhäkt eine private IP vom Provider und wird dann wieder in eine öffentiche IP gewandelt. Ich nehme an, die machen das auch per PAT, ist also keine 1:1 staische Umsetzung.

     

    Unsere Firma hat Vodafone als UMTS-Anbieter und die arbeiten mittlerweile wegen altbekannter Problematik beim NAT mit globalen IP´s, d.h. es erfolgt keine Adressumsetzung mehr.

     

     

    Ich habe das Feature "Headend will never initiate keepalive monitoring" über ASDM auf der ASA nicht gefunden

     

    Configuration\Remote Access VPN\ Network (Client) Access\IPsec Connection Profiles\<dein profile>\Advanced\IPSec\IKE Keepalive

  4. Schau mal, ob auf dem Server der Patch zu MS05-041 installiert ist. Der müsste dafür verantwortlich sein. Wir hatten das gleiche Problem über IPSec bei einer CISCO PIX und anschließend auch bei der CISCO ASA. Zum Glück hat die ASA jetzt ein feature um dieses Pre-Fregmentation zu beeinflussen und sind so aus der Sache rausgekommen.

     

    Nach meinen Recherchen müsste die Ursache aber am o.g. Patch liegen!

  5. moin moin,

     

    Gibt es vielleicht eine Begrenzung der Anzahl gleichzeitiger VPN Verbindungen, die mit dem selben Account sind?

    der Account ist local auf der Firewall angelegt.

     

    wie kann ich sonst die Anzahl der gleichzeitiger Verbindungen festlegen?

     

     

    Danke & Gruss

     

    Auf der ASA kannst Du dies über den ASDM ganz einfach begrenzen!

  6. Bei SSL VPN´s habe ich keine Erfahrungen, bei IPSec kann ich Dir etwas zu den keepalive´s mitteilen.

     

    Nachdem wir nun ca. 6 Wochen unsere ASA´s im Einsatz haben laufen die IPSec-Clients stabil. Anfangs hatte ich massive Probleme, dass die Verbindungen in unregelmäßigen Abständen (3 min. - 8 min. - 15 min - 45 min. usw) abbrachen. Dabei hatte ich die Vorgabe eines CCIE beherzigt und ein keepalive von 30/2 gewählt. Hiebei habe ich weiter festgestellt, dass Clients, die hinter einem NAT-Device lagen und damit NAT-T nutzten länger die Verbindung gehalten haben, als die, die nicht NAT-T nicht nutzten. Dies waren speziell unsere UMTS-User, da diese eine globale IP vom Provider zugewiesen bekommen. Nach langen Hin-und-Her habe ich mich nun entschlossen das Fetaure "Headend will never initiate keepalive monitoring" (über ASDM) zu aktivieren. Dies hat zum Nachteil, dass ungewollte Verbindungsabbrüche erst nach einem IDLE-Timeout von 30 min. auf dem VPN-Server bemerkt werden. Weitere Nachteile habe ich noch nicht festgestellt und sind mir auch nicht bekannt.

  7. Es läuft natürlich alles parallel und ausschließlich mit PSK - und ohne Probleme :)

    Das selbige lief auch schon mit PIXen unter 6.3.5, bei den ASA mit 8.0

     

    Bei den ASA´s habe ich es - im Gegensatz zu den PIXen - nicht übers CLI gemacht, sondern den ASDM verwendet. Dieser funktioniert wenigstens im Vergleich zum PDM.

  8. Hast du im Log ein throttling aktiv oder passiert das wirklich nur 1 mal pro Sekunde?

     

    throttling? :confused: :confused: :confused:

    ja, jede sec ein ereignis!

     

     

    Ich wuerd mal capturen und schauen von welchem IF das herkommt.

     

    Dank Deiner Hilfe weiß ich ja jetzt, wie ge-captured wird ;)

    ..aber leider werde ich dort nicht fündig - noch mehr --> :confused: :confused: :confused:

  9. Seit heute sehe ich auf meinen ASA´s DoS-Attacken, die als Land Attack beschrieben werden. Muss oder kann ich hier was tun???

     

    2|Dec 20 2007|12:47:07|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:08|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:09|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:10|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:11|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:12|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:13|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:14|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:15|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:16|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:17|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:18|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:19|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:20|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:21|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    2|Dec 20 2007|12:47:22|106017|0.0.0.0|0.0.0.0|Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0
    

  10. In unserem Infranet ist seit kurzem ein Sript eingebaut, das auf google-analytics zeigt. Da dies natürlich außerhalb liegt, wird der User an der Firewall nach UserId & PW gefragt.

     

    Zuerst habe ich mir gedacht, dass ich die IP dafür einfach freischalte, mittlerweile sehe ich aber schon 8 IP´s für diesen Host - also ein Fass ohne Boden. Außerdem bekomme ich aber auch nicht mit, sollten sich die IP´s für diesen Host einmal ändern. Auffallen würde es nur an der Statistik, die dann nicht mehr aktualisiert würde.

     

    Wie komme ich da am elegantesten raus?

  11. Soweit ich das glaube verstanden zu haben, ist das command fixup durch inspect ersetzt worden. Konnte ich früher beim fixup weitere Ports hinter dem Protokoll angeben, (fixup ftp 21, 3333) so geht das mit dem inspect nicht direkt so. Und hier hakt es bei mir mir...

     

    Folgendes Szenario: wir benötigen eine ftp-Verbindung von A nach B über Port 3333 im passive mode. Dazu habe ich eine ACL, die den traffic von A nach B über tcp/3333 erlaubt. Gibt B mir aber jetzt den Antwort Port für den passive-mode (>1023) mit, wird der natürlich durch die ACL geblockt. Da ich nicht alles über 1023 aufmachen möchte, muss ich doch definieren können, dass die ASA für diese Verbindung den Antwort Port dynamisch aufmacht. Versucht habe ich dies über eine class-map. Leider hat dies nicht geklappt.

    Bin ich da auf dem Holzweg oder habe ich ggf. die class map nicht richtig definiert? Wenn ja, hat jemand ein sample?

  12. So einfach scheint es doch nicht zu sein...

     

    ...habe wie in der command reference beschrieben

     

    capture <name> interface inside

     

    angegeben.

    Dann habe ich versucht mir dies über den Browser anzeigen zu lassen

     

    https://<IP-Adresse>/capture/<name>/pcap

     

    Dabei erhalte ich die Fehlermeldung, dass er diesen file nicht findet.

    Auch bei

     

    copy capture tftp

     

    erhalte ich die Meldung, dass ein derartiger file nicht auf disk0 liegt.

     

    Ich habe es auch mit

     

    capture <name> access-list <ACL-Name> interface <ifname>

     

    getestet. Leider mit dem gleichen Ergebnis. Was mache ich falsch?

  13. bei der PIX konnte ich bis zur Version 6 mit

     

    debug packet <ifname> src <src-ip> netmask <netmask>...

     

    eine Kommunikation überblicken.

    Bei der ASA (hier aktuell Version 8.0) gibts diesen Befehl nicht mehr.

    Wie kann ich dies jetzt realisieren?

    Übers logging würde es zwar gehen, da ich aber einige oder sehr viele Syslog ID´s unterbinde sehe ich auch nicht alles. Natürlich kann ich dies wieder freigeben, jedoch müsste ich anschließend wieder alles entsprechend ändern. Das kann´s doch nicht sein?

×
×
  • Neu erstellen...