mturba

Ein ausgeschalteter Rechner, der solche Probleme verursacht? Kannst du das Szenario mal genauer beschreiben? Was hatte dieser Rechner für eine Aufgabe, dass er eine solche Störung verursachen konnte? Generell denke ich auch, dass Squire's Vorschlag, mal einen Wireshark-Trace zu machen, eine gute Idee ist, um genauere Informationen darüber zu bekommen, was (oder wer) diese Broadcasts verursacht.

Ja, z.B. so: access-list acl_outside extended permit icmp any any time-exceeded access-list acl_outside extended permit icmp any any unreachable Den Namen "acl_outside" musst du natürlich entsprechend ersetzen... Gruß, Martin

Hi, damit Traceroute durch eine PIX funktioniert, müssen in der Outside-ACL ICMP time-exceeded und unreachables erlaubt werden. (Warum das immer noch nicht per inspect funktioniert, weiß ich auch nicht... mit der IOS-Firewall geht's...) Gruß, Martin

DAS wär allerdings ne Möglichkeit...

Hi, Keine Sorge, den Eindruck hatte ich auch nicht. :) Ausserdem ist es auch häufig hilfreich, Sachen in Frage zu stellen. Das ist das, was vorwärts bringt. Unabhängig davon, wieviel Erfahrung man schon in irgendwelchen Bereichen gesammelt hat, kann man immer noch was dazu lernen - und das nicht nur von Leuten, die das schon länger machen... Sowas in der Art hätte ich allerdings auch eher erwartet. Wäre wirklich interessant zu wissen, wie die zugrunde liegende physikalische Infrastruktur aussieht.

Hi, Es scheint, als würden Otaku19 und substyle unter "trunking" etwas anderes verstehen... Otaku19 meinte damit einen Port, auf dem VLAN-Tagging durchgeführt wird (bei Cisco: trunking), während substyle damit die Zusammenschaltung mehrerer Ports meint (bei Cisco: channeling). Meines Erachtens ja. Ein "Uplink" ist auch nur ein Link ;-) Das Kaskadieren dieser Switche (auch mit 802.1q-Trunking) ist problemlos möglich. Allerdings solltest du dir darüber im Klaren sein, dass bei einer solchen Konstruktion der letzte Switch in dieser Kette von der Verfügbarkeit aller anderen Switche abhängt. Wenn also ein Switch ausfällt, sind alle, die sich weiter hinten in der Kette befinden (und natürlich die dort angeschlossenen Rechner) nicht mehr verfügbar. Hier liegt unter anderem einer der Unterschiede zu einem Stack... Laut Cisco sind alle Ports non-blocking, es dürfte also keinen Unterschied machen, ob die Kupfer- oder die MiniGBIC-Ports verwendet werden. Viele Grüße, Martin

Hi, es wäre interessant zu erfahren, wo genau du das gemessen hast - ich vermute mal, dass es sich entweder um einen nicht-managebaren Switch oder einen Hub handelt, an dem mindestens noch ein Cisco- und ein 3Com-Switch angeschlossen sind? Wenn man's ganz genau nimmt, ist es nur ein Aussenden ganz normaler Configuration-BPDUs, die zum einen von einem Cisco-Switch, der die Cisco-proprietäre IEEE 802.1d-Protokollerweiterung PVST+ verwendet und den Switch mit der Adresse 00:12:d9:04:8c:00 als Root betrachtet, der eine Priorität von 32773 hat von einem 3com-Switch, der das IEEE 802.1d-Protokoll verwendet und den Switch mit der Adresse 00:04:0b:37:8e:78 als Root betrachtet, der eine Priorität von 32768 hat ausgesendet werden. Das ist normaler Spanning Tree-Verkehr. Nein, nicht zwangsweise. Das ist eine normale Quote, wenn man davon ausgeht, dass jeder Switch alle 2 Sekunden ein Configuration-BPDU aussendet. Das sieht keineswegs nach einer Schleife aus. Wäre in der Topologie tatsächlich eine Schleife vorhanden, hätte das wesentlich dramatischere Auswirkungen. Nein, diese Configuration-BPDUs werden (wie schon oben angedeutet) alle zwei Sekunden versendet, um mitzuteilen, dass sie noch da sind. Viele Grüße, Martin

Ah, okay... da hab ich keinen Account, deswegen.

Keine Ahnung, wo schaust du denn nach? Ich besuche immer die öffentlichen Cisco-Webseiten unter "Career Certifications and Paths" (Introduction-Career Certifications & Paths - Cisco Systems). Dort sind eigentlich immer die aktuellen Inhalte aufgeführt...

IPv6, VoIP und WLAN stehen aber zumindest im Curriculum: 640-802 CCNA-Career Certifications & Paths - Cisco Systems Da du schreibst, dass es schon ein Jährchen her ist - verwechselst du das evtl. mit der 640-801? Gruß, Martin

Ich denke, dir fehlt, der PIX zu sagen, dass sie kein NAT zwischen dem inside- und dem VPN-Netz machen soll, beispielsweise so: access-list 101 extended permit ip any 192.168.192.0 255.255.255.0 nat (inside) 0 access-list 101

Es wird ein XOR zwischen Source- und/oder Destination-MAC/-IP oder TCP/UDP-Ports vorgenommen, um zu entscheiden, über welche physikalische Verbindung der entsprechende Verkehr gesendet wird. Siehe auch: Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches - Cisco Systems

Hi Wordo, danke für das Angebot... ich werd dich nächste Woche deswegen nochmal anschreiben. Gruß, Martin

Ups, wenn ich mir die CISCO-Doku [...] anschaue, ist das genau andersherum - mit nat-control erzwingst Du dies! Argh... hast recht, hab ich verwechselt ;) - danke für die Richtigstellung.

Ja, an ein Relikt dachte ich auch schon. Muss bei Gelegenheit mal testen, ob sich der Tunnel auch ohne diesen Befehl in der Crypto Map aufbaut. Hast du da Erfahrungen?

Das ist die Anzahl der PAUSE-Frames, die über dieses Interface geschickt wurden (vgl. IEEE 802.3x FlowControl). Die Interface-Resets sind vermutlich eine Folge der (offensichtlich bestehenden) Überlastung dieses Interfaces.

Hallo, kann eigentlich irgendjemand erklären, was der Unterschied ist zwischen crypto map VPN 10 set trustpoint MYTRUSTPOINT und tunnel-group a.b.c.d ipsec-attributes trust-point MYTRUSTPOINT Braucht man beides, um eine zertifikatsbasierte L2L-Verbindung aufzubauen? Ist das historisch bedingt (aus Zeiten, wo's noch keine Tunnel-Groups auf der PIX/ASA gab)? Definiert das eine das Zertifikat, welches man selbst zur Authentifizierung sendet und das andere den Trustpoint, gegen den empfangene Zertifikate geprüft werden?

Ja, das macht der Client immer, zumindest sobald die Windows-Komponente "Aktualisierung von Stammzertifikaten" installiert ist. Der IE7 prüft vor jedem ersten Verbindungsaufbau den Hashwert, der unter http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt zu finden ist und führt vermutlich, falls sich dieser geändert hat, entsprechende Updates der Stammzertifikate durch. Allerdings zeigt der IE7 keine Seite an, solange es nicht möglich war, diese Adresse zu erreichen.

Genau - solange der IE7 das allerdings nicht erfolgreich tun konnte, zeigt er dem Benutzer auch nicht die Proxy-Authentifizierungsseite.

Hallo, ich habe ein Problem mit Proxy Authentication in Zusammenhang mit Internet Explorer 7. Vielleicht hat hier noch jemand eine Idee für eine Lösung dieses Problems, mir sind die Ideen ausgegangen. Das Szenario ist folgendes: wir setzen zur Zeit eine ASA (mit Version 7.2) ein, um HTTP Proxy Authentication in unserem Gästenetz durchzuführen. Sobald also ein Gast versucht, eine Webseite zu öffnen, bekommt er die Anmeldeseite gezeigt. Nach erfolgreicher Authentfizierung wird vom RADIUS-Server die entsprechende Benutzer-Accessliste an die ASA übermittelt, die dann die normale Accessliste (für diesen Benutzer) ersetzt. Während das mit dem Firefox oder IE 6 wunderbar funktioniert, gibt es seit IE 7 Probleme. Dieser möchte nämlich vor der Verbindung auf Stammzertifikats-Updates prüfen: GET /msdownload/update/v3/static/trustedr/en/authrootseq.txt HTTP/1.1 Accept: */* User-Agent: Microsoft-CryptoAPI/5.131.2600.2180 Host: www.download.windowsupdate.com Connection: Keep-Alive Cache-Control: no-cache Pragma: no-cache Dieser Verbindungsversuch wird von der ASA natürlich auch abgefangen und - wie bei einem ganz normalen HTTP-Verbindungsversuch auch, mit einem "moved temporarily" kommentiert: HTTP/1.1 302 Moved Temporarily Server: Adaptive Security Appliance HTTP/1.1 Location: [url]https://10.0.0.1:1443/netaccess/redirect.html?sid=2148668464[/url] Connection: close Daraufhin öffnet der IE 7 eine neue Verbindung, um auf Zertifikatsupdates zu prüfen, und zwar so lange, bis die ASA alle Connections resettet (in Abhängigkeit der Konfigurationsoption "aaa proxy-limit", standardmässig 16). Die einzigen Workarounds, die mir bisher eingefallen sind, sind alle nicht so richtig zufrieden stellend: 1. Einen anderen Browser zur Authentifizierung verwenden (z.B. Firefox), der dieses Verhalten nicht zeigt. Dies ist problematisch, da Gäste nicht immer alternative Browser installiert haben und nicht über administrative Rechte auf ihrem Rechner verfügen, um einen Browser installieren zu können. 2. "Aktualisierung von Stammzertifikaten" deinstallieren: * Start --> Systemsteuerung * Software --> Windowskomponenten hinzufügen/entfernen * Haken vor "Aktualisierung von Stammzertifikaten" entfernen * Weiter --> Fertig stellen Dies ist natürlich auch nur dann möglich, wenn Administratorrechte vorhanden sind. Zudem wird schnell vergessen, anschliessend die Aktualisierung von Stammzertifikaten wieder zu installieren. 3. Freigeben der IP-Adressen in der Accessliste des Gästenetzes Leider scheint die Namensauflösung von http://www.download.windowsupdate.com eine schier unendliche (und sich ständig ändernde) Liste von IP-Adressen zu ergeben, so dass dies auch nicht praktikabel ist. 4. Die einzige Lösung kann also m.E. sein, eine Freigabe abhängig von der URL zu machen, zu der die HTTP-Verbindung aufgebaut werden soll. Dies lässt sich mit einer entsprechenden Policy-Map ja erreichen. Allerdings soll diese dann sinnvollerweise nicht mehr in Kraft treten, sobald die Authentifizierung durchgeführt wurde. Soweit ich weiß, kann man aber so etwas wie "per-user-override", was bei einer Accessliste ja möglich ist, bei service-policys nicht angeben. Hat irgend jemand einen Hinweis, wie man da rangehen könnte? Danke schonmal und viele Grüße, Martin

Deine Konfig ist zwar noch nicht freigeschaltet, zwei Tips hab ich aber trotzdem schonmal: 1. Probleme mit der maximalen Segmentgröße (siehe PIX/ASA 7.X Issue: MSS Exceeded - HTTP Clients Cannot Browse to Some Web Sites - Cisco Systems) 2. Testweise mal http-inspection ausschalten (falls eingeschaltet).

Hmm, erinnert mich an diesen Thread: http://www.mcseboard.de/cisco-forum-allgemein-38/syslog-meldung-105034.html Leider ist in diesem Fall nicht eindeutig aus der Cisco-Dokumentation zu erkennen, ob der Verbindungsabbau von innen oder außen initiiert wurde. Als Grund für die Trennung ist nur angegeben: TCP FINs: Normal close down sequence. (Cisco Security Appliance System Log Messages, Version 7.2 - System Log Messages [Cisco ASA 5500 Series Adaptive Security Appliances] - Cisco Systems) Da die Verbindung ja sehr schnell wieder abgebaut wird, kannst du aber sicherlich mit Wireshark feststellen, wer von beiden Seiten zuerst das FIN-Flag setzt.

Ohne Serial und entsprechenden Activation Key hast du eine Restricted-license. Mit "show version" kannst du dir anzeigen lassen, was das betrifft: Licensed features for this platform: Maximum Physical Interfaces : 6 Maximum VLANs : 25 Inside Hosts : Unlimited Failover : Disabled VPN-DES : Disabled VPN-3DES-AES : Disabled Cut-through Proxy : Enabled Guards : Enabled URL Filtering : Enabled Security Contexts : 0 GTP/GPRS : Disabled VPN Peers : Unlimited

Leider nein, ASA-Image kann man keins booten - bzw. jein, in der Version 7.x sind PIX- und ASA-Image noch binärgleich. Ab der Version 8.x unterscheiden sie sich dann, das ASA-Image basiert auf einem Linux-Kernel, das PIX-Image ist noch Finesse-basiert. D.h., man kann sowohl 7.x als auch 8.x darin booten, emuliert wird allerdings immer nur eine PIX. Leider ist deshalb auch das WebVPN-Feature nicht verfügbar.

Jepp, das klappt super! Lässt sich sogar über physikalische Interfaces mit nem echten Netzwerk verbinden. In Verbindung mit dynamips/dynagen macht das richtig Spaß :)