hegl

Hi Pretender, ich stand mal vor der gleichen Überlegung undn habe auch nicht wirklich eine Antwort gefunden. Ein CISCO-Spezi meinte auch mal, das sei ziemlich egal.

wie sehen deine acl´s aus?

Jepp, genau das meinte ich!

Eigentlich wird in dem o.g. zweiten Link alles dargestellt! In deiner ACL "Mail" musst du nicht die lokale IP angeben, sondern die globale, sprich 217.146.x.x oder wie soll die interne IP auf dem outside-intreface ziehen? Heisst also im Detail: 1. Erstelle eine ACLfür smtp und definiere dort, wer (welche IP, in deinem Fall also any) auf Deinen Mailserver zugreifen darf. Dabei musst du beachten, dass die Freigabe auf die NAT-Adresse des Mailservers verweist, also auf die 217.146.x.x access-list Mail permit tcp any host 217.146.x.x eq smtp 2. Ordne diese ACL dem entsprechenden interface zu access-group MAIL in interface outside 3. Definiere ein static nat: static (inside,outside) 217.146.x.x <IP Mailserver> netmask <mask> Fertig! Deine DNS-Konfiguration sollte dann so aussehen, dass der MX-Record auf die 217-er IP zeigt.

Ich glaube, das sollte reichen: Configuration Examples Configuring the PIX Firewall with Mail Server Access on Inside Network [Cisco PIX 500 Series Security Appliances] - Cisco Systems

CISCO sagt dazu: Because all inbound sessions must be explicitly permitted by an access list or a conduit, the sysopt connection permit-IPSec command is used to permit all inbound IPSec authenticated cipher sessions. Ich bin eigentlich auch davon ausgegangen, dass Du diesen Befehl implementiert hast, da dies ein Basic-Befehl bei IP-Sec ist!

Das hatte ich Dir doch schon bei Deinem anderen Posting versucht zu erklären.... Eine ACL bindest Du immer auf das Interface, wo die Regel angewendet werden soll! Also bindest Du diese auf das outside-interface. Wenn Du schon eine access-group darauf gebunden hast, musst Du natürlich auch die passende ACL-Id nehmen, da, wie Du richtig bemerkt hast, man nur eine ACL-Id pro interface binden kann!

Ist das nicht genau anders herum??? Ich habe meine ACL-Id mit spli-tunnel verknüpft und kann nun auf das lokale Netzwerk, sowie aufs Internet zugreifen. Vorher hatte ich nur Zugriff auf die im Tunnel definierte Adressen.

Hatte ich beides bereits scharf - et kütt äver nix!

jenau siehe dein früheres posting jenau

Du must halt die ACL so wählen, dass sie zu der access-group passt!

Ich erhalte keine Fehlermeldung. Es scheint, als würde die PIX, auf der ich isakmp keepalive konfiguriert habe, gar kein keepalive schicken. Aber danke für die Klarstellung!

So, ich habe mir gerade mal ein paar Minuten Zeit genommen und es getestet: 1. Du benötigst einen ACL für den Taffic im Tunnel 2. Für diese IP´s machst Du idealerweise auch ein NAT 0 mit entsprechender ACL 3. Willst Du nun Zugriffsregeln implementieren, machst Du eine weitere ACL, die Du mit der access-group auf das interface bindest. 4. Mit vpn-group <group-name> split-tunnel <access-list> sagst Du dann, dass nur für die unter 1. bzw. 2. beschriebene Traffic ein Tunnel erzeugt wird. Alles andere geht an Deinem Gateway unverschlüsselt seine Wege. Du siehst in den Route Details der Statistic des VPN-Clients dann, für welche IP´s der Tunnel gilt.

laut command reference: Use the vpngroup split-tunnel command to enable split tunneling on the PIX Firewall. Split tunneling allows a remote VPN client or Easy VPN Remote device simultaneous encrypted access to the corporate network and clear access to the Internet. Using the vpngroup split-tunnel command, specify the access list name to which to associate the split tunnelling of traffic. With split tunnelling enabled, the PIX Firewall downloads its local network IP address and netmask specified within the associated access list to the VPN client or Easy VPN Remote device as part of the policy push to the client. In turn, the VPN client or Easy VPN Remote device sends the traffic destined to the specified local PIX Firewall network via an IPSec tunnel and all other traffic in the clear. The PIX Firewall receives the IPSec-protected packet on its outside interface, decrypts it, and then sends it to its specified local network. If you do not enable split tunneling, all traffic between the VPN client or Easy VPN Remote device and the PIX Firewall is sent through an IPSec tunnel. All traffic originating from the VPN client or Easy VPN Remote device is sent to the PIX Firewall’s outside interface through a tunnel, and the client’s access to the Internet from its remote site is denied. Regardless of whether split tunneling is enabled, VPN clients and Easy VPN Remote devices negotiate an IPSec tunnel to the PIX Firewall unit’s IP address with a netmask of 255.255.255.255.

und, war es der Befehl isakmp keepalive ??? Nach Deinem Posting habe ich gestern das gleiche Problem bei mir festgestellt. Es reicht aber anscheindend nicht, wenn ich den Befehl auf dem zentralen VPN-Gateway (hier PIX 520) einschalte. Der Tunnel kommt erst mit dem ersten Paket zum Remote-Peer hoch:confused:

Hi, vor diesem Problem stehe ich eigentlich auch, habe es nur noch nicht geschafft, etwas zu testen. M.E. musst Du eine NAT-ACL und eine Policy-ACL konfigurieren. In der NAT-ACL sagst du, welche IP durch den Tunnel darf und mit der Policy-ACL sagtst Du dann, was die IP darf!

reicht das? Configuring PIX to PIX to PIX IPSec Fully Meshed - Cisco Systems

Generell kann ich Dir nur sagen, dass die PIX keine Probleme mit PPPoE hat; auf jeden Fall nicht in der Version 6.3.5. Ich habe seit 2 Wochen eine 501er an einem 2MBit-Anschluss eines regionalen Providers. Die Verbindung läuft und läuft und läuft... Was macht denn ein "Standard-DSL-Router" an diesem Anschluss? Welchen Provider nutzt Du, musst Du evtl. die MTU anpassen? Bei Cisco ist die MTU standardmäßig auf 1500 eingestellt! Mit Deinem output kann ich leider nichts anfangen...

Hi, mir fällt hier kein Fehler auf. Wie ist denn im Moment Stand der Dinge? Kannst Du denn auf die internen Hosts zugreifen oder nicht? Meines Erachtens sollte das geh´n. Als Einschränkung nimmst Du nur die access-list 80 ersetzt das IP durch TCP und hängst am Ende ein eq ftp bzw. eq telnet dran. Das sollte es sein! Also: access-list 80 permit tcp 192.168.1.0 255.255.255.0 192.168.4.0 255.255.255.0 eq 21 access-list 80 permit tcp 192.168.1.0 255.255.255.0 192.168.4.0 255.255.255.0 eq 23 Was soll denn die access-list 100 und isakmp key ******** address 0.0.0.0 netmask 0.0.0.0? Den isakmp-Befehl mit der Adresse 0 benutzt man idR für site-to-site, wo die eine site keine feste IP-Adresse hat, z.B. ein normaler DSL-Anschluss.

Es wäre hilfreich, wenn Du mal die Struktur posten würdest. Ich denke, Du hast ein Problem bei dem Traffic, den Du für den Tunnel erlaubst. Mit crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20 ziehst Du die ACL access-list outside_cryptomap_dyn_20 permit ip any 192.168.2.0 255.255.255.252 an. Für mich steht hier: erlaube ip von überall nach Netz 192.168.2.0! Wenn ich Dich richtig verstanden habe, willst Du aber ins Netz 192.168.1.0. Also pass Deine ACL entsprechend an und es sollte funktionieren. Konfiguriere als Test doch einfach any any und Du siehst sofort, ob es daran liegt.

Thx .

Wäre wirklich nett von Dir, wenn Du mir helfen könntest

Meines Wissens nach unterstützt die PIX kein DynDNS.

und wie stelle ich es an, wenn die remote pix an einem dsl-anschluss mit dynamischer ip hängt? :confused:

Der PDM war ein Test, sonst habe ich noch nie mit diesem Ding gearbeitet. Ich verstehe das Ding nämlich ned und hat auch zu viele Fehler. Im CLI weiss man wenisgtens was man tut. Wäre supi, wenn Du mir eine Beispiel-conf posten würdest :) :) :)