hegl

Kannst Du überhaupt das inside interface anpingen? Was sagt debug icmp trace ? Was sagt das logging?

Nimm mal das inspect icmp aus der policy-map!

Mir fällt leider so auch nichts auf :mad: , denn die ACL vpn_nat hast Du schon richtig gesetzt. Logge mal auf der PIX mit, vielleicht ist da was zu sehen. Schau auch mal, welche IP Du zugewiesen bekommst (siehst Du z.B. im Client). Dort siehst Du auch unter den statistics\route details die secured routes, also das, auf das du per VPN zugreifen darfst.

voilá Cisco PIX 500 Series Security Appliances Configuration Examples and TechNotes - Cisco Systems

stell mal deine config ein und es wird leichter sein, zu antworten.

Da Du ja Deinen DC auch als DNS-Server betreibst, leitest Du von diesem für ihn unbekannte Domains an einen (oder mehrere) externe DNS-Server weiter. In der Regel sind dies natürlich die DNS-Server Deines Providers. Entsprechend musst Du Anfragen von Deinen DC auf die ext. DNS-Server per ACL erlauben.

Jepp und wenn Du nun auch noch die Zieladressen einschränkst...statt any also <DNSServer-IP> konfigurierst biste sauber. Und noch was: wir kommen allerdings mit udp/53 aus und benötigen tcp/53 nicht!

Was muss ich auf einer PIX (Version 6.3.5) konfigurieren, damit ich mit einem VPN Client IPSec over UDP nach draußen machen kann (sprich über UDP/4500) ? Zum Testen habe ich bereits nach draußen alles offen und nach innen isakmp erlaubt. Die Verbindung kommt zwar zustande, jedoch ist dann Transport Tunneling inactive. Daraus resultiert wieder das Problem, dass die Verbindung alle Nase lang abbricht. Siehe auch http://www.mcseboard.de/cisco-forum-allgemein-38/cisco-vpn-client-103354.html Hänge ich mich hinter einen Standard-DSL-Router ist Transport Tunnel active und die Verbindung stabil. :confused:

Heisst das, Du hast einen internen DNS-Server und nutzt nicht die PIX als DHCP-Server? Dann hast Du schlechte Karten und musst die DNS-Server eintragen und eine ACL definieren. Nutzt Du aber die PIX als DHCP-Server, so gibts Du in der config die DHCP-Server an und bei den Clients lässt Du diese dynamisch durch die PIX zuweisen.

sehe ich anders: wenn du dich mit Netzwerken beschäftigen willst, dann lerne routing, switching, firewalling etc.. Also beschäftige dich mit CISCO oder ähnlichen Anbietern. <edited by marka: Quote-Tags korrigiert>

Hmm, auf den ersten Blick sehe ich auch nichts. Was sagt denn das logging?

Schon mal an den echo-reply gedacht, der zurückgeschickt wird? Du läst zwar durch ..ip any... icmp-Pakete raus, aber für den ech-reply hast du weder eine ACL noch die dazugehörende access-group. Während bei z.B. http die PIX die Rückantwort automatisch zulässt, musst Du beim ping dies explizit freischalten!

Ich habe auf einem ASA-Kurs ein Buch ein von CiscoPress erhalten: Cisco ASA and PIX Firewall Handbook, Autor: David Hucaby, ISBN 1--8705-158-3. Das Gute vdaran ist, dass dort die Befehle für den FWSM 2.x und die PIX 6.x und 7.x (also ASA) gegenüber stehen. Leider ist dieses Buch auch schon (fast) wieder überholt, da Cisco nicht nur in der 7-er Version Änderungen in der Syntax vorgenommen hat, sondern auch - so habe ich gehört - in der 8-er Version. Allerdings hilft Dir das OS bei Eingabe der alten Syntax weiter, indem sie Dir teilweise mitteilt, welchen Befehl Du stattdessen nutzen solltest. Auf der sicheren Seite bist Du natürlich, wenn Du der command reference mächtig bist.

Ups, wenn ich mir die CISCO-Doku PIX 7.0 introduces the nat-control command. You can use the nat-control command in configuration mode in order to specify if NAT is required for outside communications. With NAT control enabled, configuration of NAT rules is required in order to allow outbound traffic, as is the case with previous versions of PIX software. If NAT control is disabled (no nat-control), inside hosts can communicate with outside networks without the configuration of a NAT rule. However, if you have inside hosts that do not have public addresses, you still need to configure NAT for those hosts. anschaue, ist das genau andersherum - mit nat-control erzwingst Du dies!

Ähhh, irgendwie kriege ich gerade die Krise, weil ich mir nicht sicher bin, wie die PIX die Zurordnung der ACL zur access-group behandelt. Wenn ich von DMZ1 zur DMZ2 was erlauben möchte, ist es dann egal, ob ich access-group ACL in interface DMZ1 oder access-group ACL out interface DMZ2 konfiguriere? :confused:

Du musst der immer PIX sagen, ob sie NAT machen soll oder nicht. Ich versuch´s immer so zu erklären: mit nat/nonat bzw. static baust du die Straße und mit der policy erlaubst Du, wer darüber fahren darf ;) Ich denke, dass Du in Deiner Grundkonfiguration ja schon ein NAT für 133.99.16.9 angegeben hast; machst Du also kein nonat versucht die PIX zu NATten und Du läufst gegen die Pumpe... Jenau

Hi, Du must NAT (bzw. NONAT) und die Policy trennen. Wenn ich davon ausgehe, dass Du kein NAT machen möchtest, hast Du z.B. eine ACL nat (inside) 0 access-list nonat Für die ACL gilt dann: access-list nonat permit ip host 133.99.16.9 host 193.13.43.28 Hast Du in Deiner cryptomap eine ACL [ *EDIT* ] gebunden, machst Du nun für diese die policy: access-list [ *EDIT* ] permit tcp host 133.99.16.9 eq ftp host 193.13.43.28 Für den Rückweg halt analog dazu!

Was soll dass heissen? Wieso sollten Kontexte nicht in der 8-er Version laufen. Wie soll denn dann z.B. Active-Active-Redundanz konfiguriert werden???

Ich habe letztens auf einem ASA-Kurs mit Leuten gesprochen, die sich auch mit Web-VPN beschäftigt hatten. Einhellige Meinung (und unter vorgehaltenet Hand auch die des Kursleiters): vergesst Web-VPN bei CISCO...

Es reicht, wenn Du auf der einen Seite den Befehl absetzt: clear crypto ipsec sa Beim nächsten Zugriff auf das Netz geht der Tunnel dann wieder hoch.

Problem gelöst: wenn man mit einem Radius-Server arbeitet, sollte man auch für die VPN-Clients das zugewiesene Netz aus der Authentication herausnehmen...

Noch was zur Info: Über ein kürzlich in Betrieb genommes remote device, dass als HW-VPN-Client arbeitet, funktioniert alles einwandfrei. Die config ist sowohl für den HW- als auch für den SW-Client gleich.

Habe gerade mal mit Wireshark gesniffert: die Pakete, die an der Firewall rausgehen, kommen nicht an. tcp/6129 sehe ich gar nicht, stattdessen kommen zwei! Paket per tcp/137 an, die ich aber wiederum nicht an der Firewall rausgehen sehe :confused:

Sieht im Prinzip gleich aus: da ich beim VPN Client aber mit split-tunnel arbeite sieht der output zwar im Detail unterschiedlich aus, ist aber vom routing her als gleich anzusehen. Kann ja auch nicht anders sein, da erstens der ping von meiner management-station funktioniert, als auch der Zugriff des Clients in unser LAN. Managed denn niemand seine remote-user, die per VPN Client verbunden sind? Auch ein RDP funktioniert nämlich nicht!

Habe dies gerade mal mit pptp probiert - funktioniert prächtig! Also kann´s nur am VPN Client liegen.