hegl
-
Gesamte Inhalte
704 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von hegl
-
-
wie sehen deine acl´s aus?
-
Von aussen ist der MX Eintrag ja eh von unserem ISP DNS auf die 217.146.... gesetzt, oder meintest Du den ?
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.
-
-
HI
Bzw. was hat dieser Befehl überhaupt für Auswirkungen, so wie es scheint erlaubt er jeglichen Traffic der verschüsselt ist und deswegen greifen keine ACLs.
onedread
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!
-
wo sag ich dann der pix das sie nur den tcp port 23 durch den tunnel auf eine bestimmte ip durschlassen soll und sonst nichts? auch im split-tunnel oder in einer eigenen ACL. Und auf welches Interface muss ich die ACl dann binden weil ich kann ja nur pro interface eine ACL binden?
onedread
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!
-
split tunnel definiert, welche Adressen für Client VPN nicht über den IPSec Tunnel erreicht werden
/#9370
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!
-
kann ich die acl für die vpns nicht einfach zu der acl hinzufügen die schon am interface gebunden ist.
jenau
achja und welche interface muss ich das aufm inside oder aufm outside machen und muss ich dann zuerst die ip's der vpn clients oder die ip von den lan clients angeben?siehe dein früheres posting
Bzw. kann ich einfach der ACl die schon ans dementsprechnde Inside gebunden ist einfach mit der Regel adaptieren.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.
-
vielen herzlichen Dank... ich hab DPD aktiviert und somit ist das Problem weg :) MYOEY
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!
-
-
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.
-
-
Sorry, den Post hab ich wohl uebersehn, Config liefere ich heut nach muss grad noch was raussuchen/testen :)
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 :) :) :)
Pix 506e Dmz
in Cisco Forum — Allgemein
Geschrieben
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.