jussi 11 Geschrieben 15. Februar 2010 Melden Teilen Geschrieben 15. Februar 2010 der tunnel bestand und traffic ging hindurch. dann habe ich ein zusätzliches if hochgenommen, und die folgenden 3 schritte gemacht: 1) hostroute zum tunnel partner setzen 2) crypto map OUTSIDE_MAP geschwenkt 3) crypto isakmp enable ebenfalls aufs neue interface geschwenkt. der tunnel ist vollständig oben, d.h. ike und ipsec sa sind established. jetzt möchte ich die FW regeln anpassen. ---------------------------------------------------------- ich hatte zuvor im wesentlichen 2 acls gehabt für 2 interfaces: access-group outside_access_in in interface outside access-group inside_access_in in interface inside nun habe ich eine weitere gemacht und an das neue vpn interface gebunden access-list vpn_access_in extended permit ip object-group vpn_netze <lokalesnetz> <maske> dieses loch ist ziemlich gross aber es sollte doch erst mal alles durch. aber es geht leider nicht alles durch. partner seite ist alles gut, nun meine fragen als asa noob: 1) wie kann ich mit logging monitor nur acl verletzungen angezeigt bekommen. 2) die existierenden acl sind aufgrund diverser konfigurations artefakte sehr unübersichtlich, bestehen aber nur aux "IN" listen wo wird entschieden was raus darf, oder ist das aufgrund von stateful inspektion eh klar? fakt ist ich kann einige hosts im lokalen lan per ping durch den tunnel erreichen andere nicht und in den listen findet sich dahingehend KEINE unterscheidung Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 15. Februar 2010 Melden Teilen Geschrieben 15. Februar 2010 bei so etwas gilt es abzuklären: passen auf beiden Seiten die Crypto ACL zusammen ? Sprich gibts für alles was du machen willst auch eine Möglichkeit einer SA ? für ASA: ist sysopt connection permit-vpn/ipsec aktiv oder nicht ? falsl nicht, wurde in den ACLs alles richtig freigegeben ? Die inspection dient in diesem Fall dazu um Antwortpakete auf eien bereits initiierte Verbindung zu erlauben, für den Aufbau muss die Verbindung eben in der jeweiligen ACL freigegeben sein oder falls keine da ist, eben das Security-level des eingangsinterface höher sein als das des ausgangsinterfaces. Mit so allgemeinen Angaben kann dir keiner helfen, bei einer Tunnelconfig muss eben alles sitzen, einmal vertippt und das wars schon. Zitieren Link zu diesem Kommentar
jussi 11 Geschrieben 15. Februar 2010 Autor Melden Teilen Geschrieben 15. Februar 2010 hallo, danke für die antwort, grundsätzlich hast dui recht, aber der tunnel steht wie gesagt, für jedes netzt existieren separate sas. es ist 100% ein FW / acl problem, auf der gegenseite ist alles erlaubt. habe jetzt mal den von dir genannten schalter sysopt connection permit-vpn gesetzt aber trotzdem geht nicht alles durch Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 15. Februar 2010 Melden Teilen Geschrieben 15. Februar 2010 der betrifft auch nur die interfaces an welchen der Tunnel terminiert, nicht an den jeweiligen "inside" interfaces. Auch immer weider eien Blick wert sind die aktuellen NAT geschichten evtl verbockt man sich da was Zitieren Link zu diesem Kommentar
jussi 11 Geschrieben 15. Februar 2010 Autor Melden Teilen Geschrieben 15. Februar 2010 ich möchte nicht natten dazu habe ich folgendes gemacht: nat (inside) 0 access-list remote_site und remote_site ist ne access-list welche die remote lans beinhaltet. aber was mich viel mehr wundert. da ich ja nicht natte brauche ich doch eigentlich routen, doch ich kann die routen zu den remote lans nrgends finden, was bedeutet die asa wird das über die df route abfackeln, welche sich auf dem falschen interface befindet. ich kenne einige andere vpn konzentratoren, da kommt die remote lan route automatisch mit dem tunnel hoch, falls das nicht so ist bei der asa, wie sieht die remote lan route dann aus? zielnetz / maske > auf tunnel gegenstelle oder auf interface oder wie? Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 15. Februar 2010 Melden Teilen Geschrieben 15. Februar 2010 route auf peer IP..zu dem muss es natürlich auch ne passende Route geben falls nicht direct connected Zitieren Link zu diesem Kommentar
jussi 11 Geschrieben 15. Februar 2010 Autor Melden Teilen Geschrieben 15. Februar 2010 hmm die route(n) haben es gebracht, aber das ist für mich total unverständlich. 1. habe ich doch eine access-liste die benennt was in den tunnel soll und ich habe ein tunnel peer, für alle anderen vpn konzentratoren diese welt ist doch damit die route klar... 2. konnte ich einige hosts im lan auch ohne diese route erreiche, aber das war offensichtlich wegen einer randbedingung die mir nicht bekannt war (host war geliefert vom tunnelpartner und der hatte hostrouten... insgesamt eine mischung aus "ich habs nicht drauf" und "never trust the customer, no exceptions" Zitieren Link zu diesem Kommentar
jussi 11 Geschrieben 16. Februar 2010 Autor Melden Teilen Geschrieben 16. Februar 2010 Otaku, das habe ich gestern in der eile ganz vergessen: DANKE für deine Geduld! Zitieren Link zu diesem Kommentar
Otaku19 33 Geschrieben 16. Februar 2010 Melden Teilen Geschrieben 16. Februar 2010 das mit den routen hat etwas mit dem ablauf der paketverarbeitung zu tun iirc, rein das einrichten der "Encryption domain" bringt da nichts :) na hauptsache es funkt Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.