s21it21

hello, kommt drauf an, wie viel geld du ausgeben will/darfst: proxy: squid auf basis linux proxy-deluxe-edition: stell dir eine kleine bluecoat hin, super geniale proxy-appliance (http://bluecoat.com --> kann genaue policies festlegen, wer, wann, auf was surfen darf, cached inhalte firewall: zb.: für die aussenstellen geht eine safe@office-appliance von checkpoint. (http://www.checkpoint.com/products/safe@office/index.html . Das Ding ist mit einem normalen Netgear-Router ein wenig zu vergleichen, ABER 1) Stateful Checkpoint-Firewall eingebaut 2) WLAN-Option 3) Virenscanner dabei (hardwarebasierend) 4) Full Site-to-Site VPNs 5) SecureClient gratis dabei --> Das heist User können sich remote via vpn in die aussenstelle verbinden und von zu hause aus arbeite 6) Web GUI 7) 2 x USB Anschlüsse für Drucker Das wäre ein optimales Ding für Aussenstellen. Bei Bedarf kann man das Ding via https auch von Aussen warten. Mit dem Ding kannst ein Site-to-Site VPN auf so ziemlich alle Fws aufbauen. lg Martin

achso, das wusste ich nicht, dass man da dem client auch den zugriff ins local-lan unterbinden kann. wieder was gelernt (ich kenne das nur vom secure-client von checkpoint). :) lg martin ps: sorry, dann muss ich passen....

Hello! Ok, kenne mich aus. Das heisst alle Client gehen via VPN in die Zentrale und sollen dann ins Internet geroutet werden. Ich würde, wie schon erwähnt, einen eigenen Proxy hinstellen, damit Du nachvollziehen kannst was da genau passiert. Du musst nur vom Routing eben sicherstellen, dass die Retourpakete die vom Internet kommen wieder in den "richtigen" Tunnel zurück zum Client gehen. Was Du dann auf der Firewall für die Clients freischaltest (http, https, pop3, etc.) bleibt Dir überlassen. Zum Thema VPN: Der beste Weg, meiner Meinung nach ist, wenn Du das VPN mit Zertifikaten aufbaust. Das können aber nicht alle Firewalls. Wenn Du mit Pre-shared-Keys arbeitest (phase 1 des vpns), dann nimm ein ausreichend komplexes Passwort (min. 16 Zeichen, Sonderzeichen, Gross/Klein-Schreibung, etc.). Und nimm für jeden Tunnel ein anderes. Weiters würde ich min. 3DES-Verschlüsselung anstreben. Wie gesagt, kommt drauf an, was die Dosen anbieten. lg Martin P.

hello, was sagt das log-file vom vpn-client? funktioniert die lokale lan verbindung nicht, wenn die vpn-verbindung aufgebaut wurde oder reicht es, wenn der client nur gestartet wurde. wenn die vpn-leitung aufrecht ist, schätze ich mal, dass der client aus irgendeinen grund den gesamten traffic verschlüsselt und somit das für euer lokales lan sinnlos ist. lg martin

Hallo Leute! Kurze Frage: Kennt jemand diese CDROMs bzw. sind diese sinnvoll: LINK ist weg :) (habe den LINK weggetan, weil ich gesehen habe, dass das hier nicht so wirklich gewünscht ist. verstehe ich aber voll und ganz, danke für die antwort). lg martin

Hello, Meinst Du diesen Cisco-VPN-Concentrator? So weit ich weiss gibts von Cisco einen eigenen VPN-Client (so wie den SecureClient von Checkpoint) der sicher mit der PIX funktioniert. Ich gehe mal davon aus, dass dieser auch mit dem Concentrator funktionieren wird. Mit der CiscoPIX habe ich mal so etwas gemacht. Das funktioniert eigentlich recht gut. Checke mal: http://www.secwiz.com/Default.aspx?tabid=37 lg Martin P.

Hallo! Um eine genaue Aussage zu treffen: Ihr habt ein paar Kunden (externe Firmen) die irgendwie in Euer Netzwerk wollen und von dort aus ins Internet geroutet werden sollen? Verstehe ich das richtig? Oder ist es so, dass diese Firmen eine eigene Internetleitung haben, diese komplett via VPN in Euer Netzwerk geroutet werden und von dort dann ins Internet weiter geleitet werden sollen? Meinst Du also Site-to-Site-VPNs oder eher Clients die via Client-Software ein VPN auf Eure Firewall aufbauen und dann ins Internet sollen? lg Martin

hallo, das problem ist bei der pix bekannt. wenn man ein debug packet all macht (inside oder outside), dann kann das die pix verdammt in schwierigkeiten bringen!!! cisco ist das problem schon seit langem bekannt..... warum das mit dem dns nicht funktioniert hat ist eigenartig, am inside interface hättest du daten (udp 53) von der internen quelladresse sehen müssen, am outside interface müsste man eben falls upd-53 pakete sehen, aber eben mit der genatteten pubip. wenn die daten am inside-interface ankommen, aber am outside-interface nicht, dann passt was mit dem NAT nicht (static, pat, etc.). lg martin

hello, generell musst du in jedem tunnel die netze definieren die geroutet werden dürfen bzw. welcher datenverkehr im vpn-tunnel erlaubt sein soll. dass der tunnel aufgebaut werden kann ist unabhängig davon, was durch den tunnel gehen darf, checke das mal, vielleicht kommst du dann ja drauf. die ip + subnetzmaske die du bekommst schaut schon ein wenig komisch aus. lg martin

Hello! Kann man denn in einer Terminal-Session für den User keine eigenen Drucker definieren? Stell doch einfach einen Drucker in die Zweigstelle (der via VPN in der Domäne hängt bzw. ansprechbar ist) und beim Login via Terminal-Session bekommen die User diesen Drucker zugewiesen. Die Netze zwischen Zentrale und Zweigstelle müssen natürlich geroutet werden, aber davon gehe ich mal aus. lg Martin

hello, dann dürfte das portforwarding nicht funktionieren? aktivire mal das ganze so, dass du den rechner auch aus dem internet pingen kannst, bzw. schaue dir die logfiles vom router an. kann es vielleicht sein, dass du eine pers. fw auf dem internen rechner installiert hast? vielleicht blockierst du dich noch durch eine zusätzliche rule auf der firewall (wenn du auf deinem router so eine hast)? lg martin

Hello! Grundsätzlich (wenn du das auf der PIX nicht umgedreht hast), darf alles aus der höheren in die niedrigere Priorität hinaus. Höchste Priorität = lokales LAN niedrigste Pr. Internet Das heisst Du musst nur irgend ein NAT (static, etc.) einrichten. Dann darf alles aus dem lokalen LAN raus (ohne dass Du eine Access-List gemacht hast). Wenn du aber trotzdem Access-Listen gemacht hast, dann würde ich DNS für udp (e klar) ABER auch für tcp freischalten. Wenn nämlich ein DNS-Paket zugross wird/ist, dann kann der Client die DNS-Abfrage via tcp machen. Wenn Du das blockierst, kann die DNS-Auflösung nicht erfolgen. Um das Verhalten genau zu analysieren logge Dich auf der Pix direkt ein und mache eind debug packet inside auf der Firewall. Bzw. mache ein debug packet outside xxxx (schaue in der hilfe nach was du genau brauchst). Dann siehst DU was da genau hängen bleibt. Und ein Tipp pfeife auf den Grafischen Manager, der ist ein Müll. :D Outside = Interface Internet Inside = Interface LAN (wenn DU das nicht anders eingestellt hast) lg martin

Hello! Ich glaube auch, dass Du "nur" mit einem CCNA nicht so toll dastehst. Der CCNA (oder jede Zertifizierung) bringt nur was wenn Du auf diesem Gebiet auch Praxis nachweisen kannst. Ich habe zb.: mit Firewalls sehr viel zu tun und habe dann mal den CCSA gemacht (Checkpoint-Zertifizierung). Die Zertifizierung war nur die Draufgabe, viel wichtiger war/ist meine Erfahrung und die wirkliche Praxis mit dem Zeug. Übrigens ich bin auch so ein halber Quereinsteiger (habe zwar Informatik studiert, aber eben nie fertig). Mit einer Zertifizierung alleine wäre ich nicht weitergekommen. Ich glaube die Kombination aus Erfahrung/Praxis + Zertifizierung machts aus. lg Martin

hello, ike udp 500 (tcp bei bedarf auch wen encapsuliert wird), für ipsec müsen folgende protokolle freigeschalten sein: esp (protokoll 50), ah (protokoll 51), skip (protokoll 57) lg martin

Hallo Leute! Vielen Dank für Eure Antworten, so etwas in der Art habe ich mir gedacht. lg Martin

Hallo Leute! Da auch ich mich auf dem Weg zum MSCE befinden (stehe noch am Anfang), stellt sich für die die Frage, ob man die Prüfung auf deutsch oder doch lieber auf englisch machen sollte. Ich bin bereits CCSA (Checkpoint-Zertifizierung) und da war es eben so, dass es diese nur auf englisch gab. Mit der englischen Sprache habe ich kein Problem, aber auf deutsch kann das ja doch schon angehemer sein (vor allem wenn die Fragen komplizierter werden). Vielen Dank für Eure Infos. lg Martin