hegl

Bist Du sicher, dass Du zum Zeitpunkt des Startens des VPN-Clients schon eine Netzwerkverbindung (LAN, WLAN, etc.) hast?

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

...nicht dass ich wüsste...

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.

Ja! 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. Configuration\Remote Access VPN\ Network (Client) Access\IPsec Connection Profiles\<dein profile>\Advanced\IPSec\IKE Keepalive

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!

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

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.

Wo liegt denn der Unterschied zwischen TightVNC und RealVNC? Habe ich nicht ganz verstanden - sry!

und das sogar ganz easy :D :D :D

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.

throttling? :confused: :confused: :confused: ja, jede sec ein ereignis! Dank Deiner Hilfe weiß ich ja jetzt, wie ge-captured wird ;) ..aber leider werde ich dort nicht fündig - noch mehr --> :confused: :confused: :confused:

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

Ich habe auf meinen ASA5520 mehrere site-to-site VPN, eine Easy-VPN und zig RA-VPN laufen - ohne Probleme!

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?

Das ich nicht NAT-ten kann hat historische (firmenspezifische) Gründe...

Wie kommst Du denn darauf?

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?

das ist ja richtig fein....

Der ASDM kennt den capture nicht...:confused: finde jedenfalls nichts in der Hilfe...und auch sonst nirgendwo

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?

Mit dem capture-command habe ich bis dato noch nie mit gearbeitet; wird wohl Zeit. Dankeeeeeeee! :)

Bei einer site-to-site hat man die Möglichkeit die Richtung zu wählen - bidirektional, answer only, originate only. Bei RA nicht.

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?

Nein, die Routes sind ok, habe ich nur oben nicht mit angegeben.