Blacky_24

Nachtrag: Bei der PIX muss man immer im Hinterkopf haben: - Eine PIX ist kein Router (auch wenn sie mit ein paar Routingprotokollen umgehen kann) - Traffic kann nicht durch das Interface raus durch das er reingekommen ist - "Traffic may not exit the PIX Firewall on the same network interface it entered." - Jedes Interface hat einen Security-Level (inside 100, outside 0), je höher der Level desto "vertrauenswürdiger" ist das Interface aus sicht der PIX - Traffic von einem If mit höherem Security-Level kann nur dann durch ein If mit niedrigerem Security-Level wenn es dafür ein NAT oder ein STATIC gibt - Du kannst das aber auch so hinbauen dass eine IP-Adresse auf sich selbst genattet wird (sollte man aber erst machen wenn man weiss was man tut) - Umgekehrt (niedriger Security-Level an höheren Secerity-Level) geht nur wenn Du mit einer ACL (ab PIX-OS 5.irgendwas) entsprechende Löcher in die PIX schiesst (es gibt historisch auch noch den Befehl "CONDUIT" i.V.m. "OUTBOUND" der im Prinzip ähnlich tickt wie ein ACL-Statement, CONDUIT/OUTBOUND sollte aber nicht mehr verwendet werden und eine bunte Mischung von CONDUIT und ACL ist ein abolutes Nono). - Wenn Du wissen willst was Deine ACLs tun - setz Dich in die Mitte von der PIX - VPNs werden in der Mitte von der PIX terminiert, deswegen kannst Du VPN-Traffic nicht mit ACLs auf dem Outside-If kontrollieren Auch wenn es verpönt ist - Handbuch lesen hilft :) - zumindest das zweite Kapitel sollte man gelesen und verstanden haben bevor man sich an die PIX ran macht, da stehen die ganzen wichtigen Prinzipien drin: http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_configuration_guide_book09186a0080172852.html Gruss Markus

Die 501er tickt nicht anders wie alle anderen PIXen auch - gleiche PIX-OS-Versionen vorausgesetzt (für 501/506 gibt es kein 7.x). Wenn Du ganz einfach verhindern willst dass die PIX auf einen Ping antwortet ist das ganz einfach, schau Dir mal die an: icmp permit any outside icmp permit any inside Die kann man negieren und dann wir die PIX selbst zum schwarzen Loch für ICMP. Abgesehen davon macht die PIX von sich aus garnix - man muss ihr alles sagen. Wenn Du von drinnen nach draussen pingen (und die Antworten von draussen empfangen) willst brauchst Du keine riesen Löcher in die PIX zu schiessen, da hilft eine saubere ACL - die den (meiner Meinung nach wünschenswerten ) Nebeneffekt hat dass nicht die ganze Welt auf Deiner PIX oder gar durch die PIX durch in Deinem Netz rumpingt: object-group icmp-type icmp-outbound description DEFINITION ICMP OUTBOUND (ALLOW REPLIES) icmp-object echo-reply icmp-object source-quench icmp-object unreachable icmp-object time-exceeded access-list OUTSIDE-IN permit icmp any any object-group ICMP-OUTBOUND Gruss Markus

Grummel. Nicht mal ins MSDN und ins Partner Network kommt man rein. Die Loadbalancer bei Akamai werden glühen. Gruss Markus

Das kann durchaus sein :) Beim Konfigurieren der PIX musst Du Dir immer vorstellen dass Du mitten in der PIX sitzt. Abgesehen von speziellen Konfigs mit Split-ACLs muss der Traffic durch ein Interface rein und durch ein anderes Interface raus. Mit einer ACL mit dem Ziel OutsideIf könntest Du nur Traffic blocken der auf genau dieses If adressiert ist, nichts anderes. Du kannst das If auch nicht synonym für die grosse weite Welt dahinter nehmen. Wenn Du Clients nach draussen blocken willst ist es am einfachsten, für diese Clients kein "NAT (inside) 1 ..." eintragen. Wenn es über ACLs gehen soll kannst Du das natürlich in allen Varianten durchspielen access-list INSIDE-OUT deny ip 10.0.0.0 255.255.255.0 any Wenn Du mehrere interne Hosts blocken willst kannst Du die ACL mit einer entsprechenden object-group einigermassen übersichtlich halten: object-group network DENY-INSIDEOUT description Blafasel network-object 10.0.0.1 255.255.255.255 network-object 10.0.0.17 255.255.255.255 network-object 10.0.0.199 255.255.255.255 access-list INSIDE-OUT deny ip any object-group DENY-INSIDEOUT Gruss Markus

Abgesehen von den Sicherheitsimplikationen geht so eine Konfig wenn man pro Verschlüsselungsmethode ein eigenes VLAN mit einer eigenen SSID verwendet. Gruss Markus

Die PIX kann kein DynDNS bzw. unterstützt in den ACLS keine Hostnamen. Gruss Markus

Configs? Debugs? Gruss Markus

Öhm. Verstehe ich nicht :) Willst Du verhindern dass bestimmte Syteme von Inside auf bestimmte oder alle Systeme Outside zugreifen können? Gruss Markus

Wieder jemand der an was rumfummelt was er nicht verstanden hat? Zum lesen des Handbuches hats nicht gereicht? "You cannot Telnet to the outside interface of PIX." SSH auf der PIX: PIX-OS grössergleich v5.2. hostname IRGENDWAS domain-name DOMÄNE.DE aaa-server LOCAL protocol local username BENUTZERNAME password GEHEIM privilege 15 aaa authentication ssh console LOCAL aaa authentication telnet console LOCAL aaa authorization command LOCAL ssh NETZDASSHVONAUSSENDARF NETZMASKE outside ssh timeout 60 ca gen rsa key 1024 ca save all exit wr me Wenn Du nachträglich den Host- oder Domänennamen änderst musst Du die Zertifikate neu generieren "ca gen rsa key 1024". PDM von aussen geht nur durch einen VPN-Tunnel. Gruss Markus

Immer ausschreiben! Gruss Markus

Afaik produziert Cisco seit einigen Jahren keine Hubs mehr, die Dinger wurden abgekündigt. Besonders gut bestückt war Cisco da nie, es gab ein Tischmodell (Gehäuse wie die 1750er Router) und ein 19"-Modell, letzteres wurde AFAIK von HP zugekauft. Wie mir ein Cisco-Mensch mal erklärt hat wurden diese Geräte nur Produziert um bei Ausschreibungen als "Komplettanbieter" auftreten zu können. Dass die Teile irgendwie besonders "intelligent" gewesen wären ist mir nicht erinnerlich. Waren wohl auch nicht wirklich die Verkaufsschlager, in Natura habe ich die Teile nie im Produktiveinsatz gesehen, so einen Tischhub habe ich noch im Lab. Die Preise waren auch so angesetzt dass man sich eher einen 1900er Catalyst fürs gleiche Geld gekauft hat, nach der Devise "Hubs haben wir auch, aber nehmen sie gleich den Switch, der ist billiger". Irgendwo habe ich noch die Specs, wenns jemanden interessiert ... Gruss Markus

Gib mal im global config "pots ?" ein. Mit den pots-Befehlen musst Du erst eine Telefonie-Basiskonfiguration durchführen damit der Router die Interfaces aufschaltet. Gruss Markus

Du solltest unbedingt vorher prüfen ob alle Tunnelenden kompatibel sind. Mit den Watchguards war es bis vor einiger Zeit nicht möglich, ein sauberes VPN an Cisco hinzukriegen - mittlerweile gehts, Du brauchst aber auf beiden Seiten relativ aktuelle Software. NAT sollte kein Problem sein - wenn Du vor dem Tunnel nattest. Je nach Anzahl der gleichzeitig aufgebauten Tunnel brauchst Du am Hub relativ leistungsstarke Hardware - ggf. ein VPN-AIM - um den ganzen Traffic in erträglicher Zeit aus- und einzupacken. Gruss Markus

Ausrechnen: 10101100.00010010.10000001.00000000 172.18.129.0 10101100.00010010.10000010.00000000 172.18.130.0 10101100.00010010.10000100.00000000 172.18.132.0 10101100.00010010.10000101.00000000 172.18.133.0 11111111.11111111.11111000.00000000 255.255.248.0 =/21 10101100.00010010.10000000.00000000 172.18.128.0 Die einzelnen Netze binär untereinander schreiben. Von links her nachsehen bis wo die Bitfolge aller Netze gleich ist. Vor dem ersten abweichenden Bit einen senkrechten Strich durch alle Netze machen - im gegebenen Fall ist das 22. Bit das erste mit Abweichung (die beiden oberen sind im 22. Bit 0, die unteren 1) - also ist der Strich hinter dem 21. Bit - und das gibt Dir die Netzmaske vom "Supernet". Für das eigentliche Netz musst Du jetzt nur noch die ersten 21 Bit von einem der Ursprungsnetze in Dezimal umrechnen und bekommt im gegebenen Fall eben die 172.18.128.0. Irgendwann kannst Du das dann im Kopf rechnen :) Gruss Markus

Nunja. Cisco muss auch nicht immer sein :) Cisco kann sicher ein paar tolle Sachen - allerdings fast nichts was andere nicht auch können - und wirklich "Spitzenklasse" ist Cisco - wenn überhaupt - nicht in vielen Bereichen (wobei Marketing eindeutig zu den Spitzenbereichen gehört). Wenns um Switching geht und man wirklich das Letzte aus der Infrastruktur rauskitzeln will ist man mit Foundry und Extreme oft besser bedient, beim Routing im Carrier-Umfeld landet man sehr schnell bei Juniper und von der Access-Infrastruktur von Redback kann sich Cisco auch noch ein paar Sachen abschauen. Im Enterprise-Umfeld sieht das etwas anders aus, da kommt es auf zentrales und einheitliches Management an und dadrüber kann man auch einen Teil der höheren Anschaffungskosten kompensieren - plus den Vorteil dass man eine einheitliche, integrierte Infrastruktur hat die ein paar Sachen ermöglicht die sonst nicht realisiert werden könnten - wofür man dann halt proprietäre Mechanismen in Kauf nimmt. Abgesehen davon war Cisco meiner Meinung nach nie der grosse Innovator - vielleicht mit der Ausnahme dass die irgendwann mal quasi den Router erfunden haben - seitdem wird zugekauft was ein einigermassen innovatives Produkt hat und nicht bei drei aufm' Baum war - die Catalysten, die PIXen, WLAN, VoIP, VPN-Konzentratoren ... Gruss Markus

Och, da fallen mir schon ein paar Sachen ein die man damit machen kann, vor allem mit dem Letzteren. Allerdings brauchst Du dafür anderes Equipment als einen 8xx, die Unterstützung für MPLS und BGP ist auf denen nicht gerade üppig. Wenn Du irgendwo einen 6500er mit SE720 oder einen 7600er rumliegen hast könnte man da schon was machen :) Gruss Markus

Dann installier mal FW/3DES und nutz auch die Features die da drin sind und check dann was noch an Bandbreite über bleibt :) Ich habe das Gefühl dass die 87x für solche Geschichten die deutlich bessere Plattform ist - abgesehen davon dass die auch problemlos mit 6000er DSL klar kommen. Gruss Markus

Naja, das mit dem Ping ist nur beschränkt aussagekräftig. Je nach Tunneldefinition auf den PIXen geht ICMP halt nicht durch. Ich würde mir auf den Shareservern mal die Default Gateways ansehen - entweder die zeigen auf die PIX oder auf einen Router der weiss dass er das Aussenstellennetz über die PIX erreichen kann. Ausserdem sollte man mal auf die PIXen schauen wie die Tunneldefinition aussieht (und ob die auf beiden Seiten gleich ist). Wenn das einer ordentlich gemacht hat und da nur der TS-Traffic durchgeht kannst Du lange versuchen, Shares aufzumachen. Gruss Markus

Eventuell unterschiedliche Netze? Kannst Du von den Clients in der Aussenstelle die Server mit den Shares anpingen? Stehen die Server mit den Shares im gleichen IP-Netz wie die TS? Gruss Markus

Damit wird der 836 dann endgültig zur lahmen Möhre. Gruss Markus

Dann hast Du wohl ein IOS welches diese Funktionalität nicht unterstützt - entweder zu alt oder das falsche Featureset. Gruss Markus

Ja. Ist das CCO oder wieder kaputt heute oder hast Du die Suche auf cisco.com nicht gefunden? http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a00804550bc.html#wp1193429 Was Du so alles hörst ... Gruss Markus

Hast Du eine andere Tabelle als ich oder musst Du nur die Fettfinger von der Brille putzen - in der Zeile 506/506E steht bei mir im letzten Feld unter "Logical Interfaces" eindeutig eine "2"? Ansonsten hilt ggf. die Eingabe von "sh ver" weiter. Dann kauf Dir eine 515er, die ist von Haus aus für solche Sachen gebaut, das mit einer 506er und LIs bzw. VLAN abzubilden ist eine Krücke - und gerade eine solche sollte man wenn es um Security geht nicht bauen. Gruss Markus

Es gibt im CCO Config-Guides in denen das Schritt für Schritt und mit Screenshots ausführlich beschrieben wird. Gruss Markus

Wie kommst Du denn auf dieses schmale Brett? Die unterste IP adressiert das Netz und die oberste den Broadcast für das Netz. Das ist bei allen Netzen so, dementsprechend geht der Host-Bereich im nachfolgenden Netz von 17-30. Gruss Markus