s21it21

hallo, er meint den wizard von der pix. auch die beitet eine grafische oberfläche an (=PDM). den musst du aber erst aktivieren. erst dann kannst du via https auf das ding zugreifen. dann solltest du recht einfach via pdm-wizard so ein vpn aufbauen können. die website von cisco bietet dazu einige, gute dokumente (einfach googlen). lg martin

hallo, es gibt bei der pix ein paar ids-funktionen. die sind aber nicht so toll. aber vielleicht kannst du grundsätzliches da einstellen (glaube aber eher nicht). sonst bietet die pix grundsätzlich keine möglichkeit aktiv auf port-scans zu reagieren (ist ja keine checkpoint :) ). lg martin

hallo, am eines ist mir mal sofort aufgefallen: Du hast die access-liste: access-list icmp_acl permit tcp any any access-list icmp_acl permit udp any any access-list icmp_acl permit icmp any any echo access-list icmp_acl permit icmp any any echo-reply access-list icmp_acl permit icmp any any source-quench access-list icmp_acl permit icmp any any unreachable access-list icmp_acl permit icmp any any time-exceeded access-list icmp_acl permit icmp any any traceroute access-list icmp_acl permit tcp interface outside range 4242 4243 host 84.191.251.239 range 4242 4243 Diese ist am OUTSIDE Interface gebunden. Dir ist schon klar, dass Du tcp und udp komplett OFFEN hast!! So wo liegt denn nun das Problem? Deine statics sind so konfiguriert, dass die IP 84.191.212.192 verwendet bzw. die externe-IP vom Interface verwendet wird. So weit so gut. Ist die 84.191.212.192 eine Deiner pupIPs, oder ist das eine von denen die immer wechselt. Wenn diese nicht mehr aktuell ist, weil eben die IPs wechseln, dann ist klar, dass das nicht funktioniert. Die Access-Lists sind zwar vorhanden, die statics greifen aber nicht mehr, da ja die pupIP sich von Dir geändert hat. Du müsstes also ALLE statics immer mit dem interface verwenden. Dann passen sich diese an die NEUE pupIP von Dir an. Wichtig ist auch noch, dass Du dann bei den statics auch noch die Ports angibts, aber das machst Du ja e schon. LG Martin

hallo, es würde extrem helfen, wenn du die pix-version angibst und vielleicht auch noch sagst, wie du deine internet-verbindung aufbaust (ppoe, dhcp)? Meinst Du, dass die access-liste am outside-interface nicht mehr greift? wenn Du Regeln definiert hast, die auf die externe IP der PIX zugeschnitten sind, ist klar, dass diese nicht mehr funktionieren, da ja die PIX nun eine neue IP bekommen hat. Wenn Du das meinst, ist das ja klar. Aber trotzdem sollten die Regeln bei "wr t" (in der cli) sichtbar sein. Welche Regeln hast Du denn am outside-interface definiert? Ausser einer any-any-drop-rule + logging (die pix droppt von haus aus alle inbound verbindungen), würden die regeln bei einer dynamischen ip sowieso nichts bringen. lg Martin

Hello, Ja sorry, Protokoll 50 und 51. LG Martin

Hallo, Damit IPSEC durch eine Firewall geht, muss das offen sein: * TCP port 50 for IPSec Encapsulating Security Protocol (ESP) traffic * TCP port 51 for IPSec Authentication Header (AH) traffic * UDP port 500 for Internet Key Exchange (IKE) negotiation traffic Und die hintere PIX muss mit einer IP-Adresse (also auf der das VPN terminiert) im Internet erreichbar sein. lg Martin

hello, mm, ok. du willst also ein site2site von zwischen deiner 501er-pix und deren firewall haben, damit du dann im tunnel zwischen deinem win2003-server und denen dort eine verbindung herstellen kannst. richtig? wenn dem so ist, dann hast du von dieser firma viel zu wenig infos bekommen. für eine site2site-verbindung brauchst du infos wie firewall-ip der anderen seite ( + welches produkt wird verwendet), welche verschlüsselung, arbeitet man mit zertifikaten oder mit pre-shared-keys, welche lifetimes werden eingestellt und vor allem welche verbindungen werden über den tunnel dann geschalten (also welche traffic darf durch bzw. wer darf die verbindungen aufbauen) weiters ist immer interessant welches interne netz die dort verwenden. haben die nämlich das gleiche intern lan wie du, dann musst du naten. etc. also so einfach ist das dann auch nicht. den vpn-client kannst du auf der pix gar nicht installieren, wenn du das gemeint hast. du kannst eben "nur" die pix als vpn-endpunkt hernehmen (und das wird sehr oft so gemacht). aber nochmal, der cisco vpn-client funktioniert unter win2003-server. ACHTUNG: Solltest Du doch den VPN-Client auf Deinem Server zum Laufen bringen, dann musst Du achten, dass Deine PIX den VPN-Traffic komplett durchlässt und dass die VPN-Pakete auch wieder zurückfinden. Dafür wirst Du unter Umständen eine eigene pupIP für Deinen Server brauchen. Dieser Server muss dann über diese pupIP für den VPN-Traffic (unteranderem udp-500) aus dem Internet erreichbar sein!!!! lg martin

Guten Morgen! Was willst Du?? Du willst vom Windows-2003 Server einen VPN-Tunnel aufbauen, der auf der 501er PIX terminiert? Verstehe ich Dich richtig? Mm, ich bilde mir schon ein, dass der VPN-Client von Cisco schon auf einem Win2003-Server läuft! Du kannst aber auch statt ipsec, pptp verwenden. Dann brauchst Du keinen eigenen Client dafür. Verwendest Du den PDM oder bist Du mit der CLI vertraut? lg Martin

hello, wenn du mehrere access-listen hast zb.: access-list outside_Interface permit tcp host x host y eq 80 access-list outside_Interface permit tcp host v host z eq 443 usw. du kannst die einzelnen access-listen nur so bearbeiten, indem du die zu erst löschst und dann eben neu anlegst (mit den neuen parametern). zu deinem zugriff auf den ftp-server. generell sollte es so sein, dass die pup-ip der firewall nur für die firewall ist (zumindest in grösseren umgebungen). wenn services, wie in deinem fall, von aussen verfügbar sein sollten, dann sollte eine weitere pupip genommen werden. wenn du das nicht kannst, weil du einfach nur eine einzige pupip zur verfügung hast, dann geht das trotzdem. ABER: dabei musst du aufpassen, dass du beim static-befehl den port genau mit angibst. nur dann funktioniert das. gibst du den port nicht an, so geht nichts mehr (diesen fall hatte ich schon öfters bei kunden). meine bevorzugten versionen sind also: 1) pupip der firewall wird für nichts anders benutzt 2) wenn es nicht anders geht, dann eben static-einträge mit den entsprechenden port-parametern mitangeben. lg martin

hallo, das lässt sich so nicht gleich sagen. wie gehen die clients ins internet raus bzw. wie machst du das auf der pix (static, nat, pat)? hast du schon mal am outside-interface der pix mitgesnifft? geht der traffic raus, oder nicht? kommt der traffic wieder zurück, wie schaut es am inside interface dann aus? du musst schon genauere infos hier posten, dann kann man dir helfen. :) so wie du es angibts, könnte es sein, dass du für die clients irgend eine einschränkung (ip-adressen-pool) eingestellt hast. nach einer gewissen zeit ist das aufgebraucht und du musst eben clear xlate hernehmen, damit alles wieder "frisch" ist. mit wie vielen clients probierst du denn das? und der vollständigkeit halber wäre die pix-version nicht schlecht. arbeitest du mit dem pdm oder mit dem cli? lg martin

hallo, warum ist denn die externe-ip des servers nicht erreichbar? ist das absichtlich so gelöst worden? die clients würden dann aus dem internen lan ins internet raus gehen und dann eben wieder rein zum server. das sollte schon funktionieren (bei der cisco-pix könnte das probleme bereiten). kann man bei den pdas die interne-ip des server vielleicht zusätzlich eintragen? dann synct der client eben mit dieser ip und im externen lan dann eben über die pupip. lg martin

hello, beachte aber, dass du bei der verschiebung (wenn zb. weiter oben eine access-liste dazukommt, oder was gelöscht wird) der access-liste auch den kommentar mit "bewegen" musst. lg martin

Hallo! So wie Wordo schon geschrieben hat, das geht (habe ich schon x mal gemacht). Man muss eine Art Transfernetz erzeugen. Dieses muss auf beiden Seiten geroutet werden (damit der Traffic ins VPN rein geht). Nachteil ist natürlich, dass man jeden Host/Server der durch das VPN erreichbar sein muss, natten muss und, dass genau diese IP-Adresse dafür im anderen Netz bekannt sein muss (neue DNS-Einträge etc.). Wie schon gesagt, es funktioniert. Auf der Checkpoint ist das vom natten her nicht so der Aufwand, bei der PIX muss man eben etwas mehr konfigurieren (kann verwirrend sein). Aber funktionieren tut das auf jeden Fall. lg Martin

hello, wir hatten das so gelöst: alle ports im schulungslan bekommen eine dhcp-adresse, können aber ausschließlich nur ins internet raus und sonst nirgends hin. will man ins verwaltungslan (trainer, etc.), dann braucht man einen vpn-client am laptop + token von uns. mit dem baut man dann ein vpn auf (so als ob man eben von irgendwo aus dem i-net kommt). und selbst der zugriff innerhalb im vpn ist auf userebene stark eingeschränkt. lg martin

Hallo, Wie schon gefragt wurde, gehts dabei um echtes Loadbalancing (Also die Lastverteilung angebotenen Services), oder gehts eher um eine redundante Leitung? Wenn ich "Downstream" richtig interpretiere, gehts eher um eine stärkere "Download"-Leitung. Das hat aber eher nix mit Loadbalancing zu tun. lg Martin

hallo, wie wäre es einfach mit "wr t" oder "show running config". da wird einem do einfach alles gezeigt. oder du speicherst alles auf einen tftp-server. dieses file öffnest du dann in einem texteditor. lg martin

Hallo Herbert! Jetzt weisst Du warum der PDM ein Schrott ist. :) Normalerweiser kann man das mit dem access-listen sehr wohl realisieren. Wie gesagt der PIX ist es egal, was Du machst (bis zu einem gewissen Grad). lg Martin

Hallo, Bei der PIX ist das so: Mit dem "name"-Befehl kannst Du für eine IP-Adresse einen Namen vergeben. Dabei ist es unwichtig ob das ein Host oder ein Netz ist. Dies wird dann erst bei der wirklichen "access-list" vergeben (mit eben netmask). Somit ist der "name"-Eintrag einfach nur ein Mapping zwischen Namen und "irgendeinem Objekt". Also mir ist nicht bekannt, dass das bei der PIX ein Problem sein sollte. Dieser ist es komplett egal, ob Du einmal den Host oder das Netz meinst. Kann es sein, dass das Problem wo anders liegt? Poste mal diese zwei Access-Listen genau, dann kann man vielleicht mehr sagen. lg Martin

Hallo, Zu aller erst mal, besorge Dir bitte unbedingt ein Buch/Kurs/Unterlagen zur PIX. Das Device ist auf keinen Fall so nebenbei zu beherrschen. Man muss bei der PIX sehr genau wissen, was man tut und braucht. Deine Fragen kann man nicht so ganz einfach beantworten. Es kommt zu erst darauf an, was wie konfiguriert ist. Ich versuche es trotzdem mal: Wenn Du von Aussen auf einen internen Server via ssh zugreifen willst, dann musst Du diesen internen Server mit dem STATIC Befehl mal richtig natten. Weiters brauchst Du am Outside-Interface eine entsprechende ACCESS-LIST. Damit erlaubst Du den SSH-Zugriff dann auf diesen Server. Der PDM ist defaultmäßig nicht immer aktiviert. Es gibt PIXen, da kann man diesen mit einem FirstInstall-Script aktivieren. Die Zugangsdaten entsprechen den angelegten Usern direkt auf der PIX. Der PDM ist zwar nett, aber man kann damit nicht alles auf der PIX machen. Gewöhne Dich lieber an die Kommandozeile. Wie gesagt, bevor Du Dich an die PIX machst, lies lieber einiges nach (auf der Cisco-Webpage findet man auch einiges). Man muss die Philosophie der PIX einfach verstanden haben, das erleichtert einiges. lg Martin

hallo, willst du jetzt durch die pix durch pingen (also zb. einen anderen server), oder willst du die pix selbst pingen. Das ist nämlich ein Unterschied bei der Kiste. Wenn Du durch die PIX pingen willst, dann muss man das mit access-listen freischalten (und zwar den Weg hin und zurück --> icmp ist nicht stateful). Willst Du die PIX direkt pingen, dannn geht das nur, wenn du das mit dem icmp-befehl machst. ABER ACHTUNG: Bei der PIX ist es NICHT möglich, ein anderes Interface, als das direkte zu pingen. Beispiel: Hängst Du hinter dem Inside-Interface, kannst Du von dort aus NICHT das Outside-Interface pingen! Das kann zwar manchmal sehr dumm sein, ist aber leider so (ist halt auch nur eine PIX *g*). Probiere mal von der PIX aus den Host zu pingen, funktioniert das? lg Martin PS: Conduits werden bei der PIX nicht mehr untersützt und sollte man nicht mehr verwenden.

Hallo, Teste mal ob es wirklich am fixup liegt, dass du nicht mehr hinkommst. Lösche es mal und teste es dann. Bei meiner PIX (501, V6.3(4)) funktioniert tftp mit und auch ohne fixup. lg martin

hello, jetzt verwirrt m43stro nicht komplett. :) fakt ist, dass jeder personal-firewall-hersteller das irgendwie anders löst bzw. versucht grafisch darzustellen. wenn man sich zb.: mal die symantec-pers-fw ansieht, dann kennt man sich ja noch weniger aus. Ich glaube die "Lösung" Deines Problemes liegt einfach an der Art und Weise wie man die Freischaltungen bei dieser Software machen muss. Merke Dir einfach als Fausregel, dass man bei Statefull-Inspection nur den ausgehenden Verkehr freischalten muss, die Rückantworten werden implizit freigeschalten. Bei einem Paketfilter/Persfirewall/L3/4-FW muss man eben, je nach Implementierung den kompletten Weg in beide Richtungen freischalten. Wenn es Dir darum geht, was für Dich das beste ist, dann verwende irgendeinen (nicht negativ gemeint) Router (SMC,Netgear, etc.). Diese Dinger sind nicht so übel (für den privaten Bereich). Weiterer Vorteil ist, dass Dein PC dann nicht direkt im Internet hängt und nur durch so eine persFW geschützt wird. Der Router ist dann noch dazwischen der Deinen PC "versteckt" (NAT). lg Martin lg Martin

Hallo, Wie schon gesagt, es kommt vor, dass man DNS sehr wohl in beide Richtungen freischalten muss. Das liegt aber natürlich nicht an DNS sonder dann an der Firewall. Bei diesen Firewalls muss man dan so ziemlich jeden "Rückverkehr" freischalten. Das geht dann so weit, dass man Outbound (vom Client ins Internet) alle high-ports freischaltet. Und das ist absolut unsicher. FTP ist auf gar keinen Fall ein "normales" Protokoll (wobei "normal" relativ ist und davon abgesehen, dass es ein vollkommen unsicheres Protokoll ist). Es gibt sehr viele Firewalls die damit Probleme haben (gute natürlich nicht). FTP-Datenverker muss eine Firewall wirklich beherrschen und "verstehen". Es kommt ja darauf an, ob man passiv- oder active-ftp verwendet. Und wenn das die Firewall nicht beherrscht, dann wird es sehr unangenehm (es gibt viele Firewalls die nur eine Art unterstützen). Das beste Programm, dass Dir anzeigt, welche Verbindungen Dein PC macht ist noch immer: "netstat -an". Da siehst Du sämtliche Verbindungen die hergestellt sind bzw. auf die der PC lauscht. lg Martin

Hallo, Die AT-Gaurd-FW ist so wie die meisten Software-Firewalls Schrott bzw. ist nur ein Paketfilter und nicht mehr. Dass TCP verbindungsorientiert ist und UPD nicht stimmt schon, hat aber primär nichts mit dem Verhalten der FW zu tun (mit dieser FW). Kurz die Info: Viele Paketfilter-FWs (so wie AT-Guard) filtern den Traffic auf Grund von Quell/Ziel-IP und Port. Dass dabei die Daten auch wieder zurück müssen ist diesen Dingern mal egal. Und das ist das Problem. Bei bekannten Protokollen oder bei gänigen checken die Dinger das noch, aber dann eben nicht mehr. Eine StateFull-Firewall schreibt sich die Verbindungen in eine eigene Tabelle und schaltet impliziet den Rückverkehr wieder frei (aber eben nur für diese eine Verbindung und nicht global und auch nicht dauerhaft). Das is eben der grosse Unterschied. Solche Paketfilterfirewalls sind dann natürlich extrem mühselig und unübersichtlich bzw. sind auch nicht mehr State-of-the-art. Im Heimbereich sind diese Dinger aber noch sehr verbreitet. Ich pers. rate von solchen FWs ab. lg Martin

Hallo! Ich habe bis jetzt die Erfahrunge gemacht, dass ein CCNA zwar nett ist, aber nicht wirklich grossartig anerkannt wird. Diese Zertifizierung ist aus Sicht der Firmen (die ich kenne bzw. Kontakte habe) das Mindestmaß an Netzwerkverständnis. Ich habe die Erfahrung gemacht, das man sich min. auf ein/zwei Firewalls sehr gut auskennen sollte (PIX, Checkpoint, etc.). Dieses Wissen wird von sehr vielen Firmen zu den allgemeinen Netzwerkkenntnissen dazugerechnet (ob es sinnvoll ist, ist eine andere Frage). Ich würde sagen, der CCNA ist eine gute Basis für weiteres. Nur mit einem CCNA zu glauben, dass man sich aus der Masse hervorhebt bzw. mehr Gehalt aushandeln kann, ist falsch und unrealistisch. Man muss einfach bedenken, dass man den CCNA schon fast überall machen kann bzw. mitangeboten wird. Da gibt es schon zu viele Leute damit und das drückt natürlich diese Zertifizierung (ähnlich wie beim MCSE). Ich kenne leider zu viele Leute die gesagt haben, ich werde Netzwerkadmin, ich mache den CCNA und bekomme dann auch einen Job. Diese Zeiten sind einfach vorbei. Ideal ist natülich ein Studium + CCNA + mehr (+ 10 Jahre Erfahung und ein niedriges Wunschgehalt :) :) ). lg Martin