Jump to content

mr._oiso

Members
  • Content Count

    352
  • Joined

  • Last visited

Community Reputation

10 Neutral

1 Follower

About mr._oiso

  • Rank
    Senior Member
  • Birthday 08/25/1971
  1. Hi Pete, also, ........... Einmal funktioniert es mit Deiner ACL*1, weil Du Dich noch nicht entschieden hast, ob Du das Packet von 192.168.2.10 nun routen oder natten willst. Im Grunde kann die ASA das Packet routen, aber das tut sie eben nur, wenn Du es in die NAT (Ausnahme) : nat (dmz) 0 access-list CRYPTOACL über die ACL CRYPTOACL mit aufnimmst ! Deshalb funktioniert es so wie geschildert. Die Frage 2 und 3 lässt sich schnell erklären. Am Ende einer jeden ACL steht, auch wenn die ASA es nicht anzeigt: "access-list DMZ extended deny ip any any" Daher kann bei aussc
  2. Hi Chrissie, poste doch mal folgende Output's ! Ich denke Dein Channel steht noch nicht richtig ! VS0129504802#sh int gig 0/1 sw Name: Gi0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: trunk (member of bundle Po2) Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN:
  3. hi hegl, bist Du gezwungen worden das zu konfigurieren oder machst Du das freiwillig ? :D Egal: FQDN sollte eigendlich nicht abgefragt werden ! Daher scheint das Problem schon ernster. Hast Du denn die ganzen Registry Einstellungen für den Client (Windoofs) gemacht ? Die sind auf jeden Fall genau (peinlichst genau) zu machen, sonst geht nix. Ich habe eine Konfiguration im Feld mit L2TPoIPSec welche "Gott sei Dank" läuft. Unter Version 7.2.2 recht stabil ! Hast Du auf die "crypto map" geachtet ? Habe sowohl in der dynmap den L2TP ganz am Ende (highest ID) als wie in der gebu
  4. hi diavolo86, re ! :D Wie in Teil 1 beschrieben, trifft PAT natürlich nur zu, wenn hier folgendes zuvor passiert ist. Sofern ein "static" inside to outside konfiguriert ist, werden die externen Adressen "reserviert", ist das nicht der Fall, so werden die verfügbaren Adressen A.B.C.53-54 und 57-62 der Reihe nach aufgebraucht, 1:1 Nat, und dann erst geschieht PAT via Interface, also der 50 global (Extern) 1 A.B.C.57-A.B.C.62 netmask 255.255.255.240 global (Extern) 1 A.B.C.53-A.B.C.54 netmask 255.255.255.240 global (Extern) 1 interface Soweit noch alles o.k. Jetzt aber meine
  5. hi diavolo86, :suspect: die Konfiguration ist ja starker Tobak ! Aber eine Frage sei erlaubt, was soll die ASA letzt endlich machen. Ich gehen mal davon aus, dass diese Konfiguration die ist, welche nicht läuft. Daher fangen wir am besten klein an ! Diese NAT Rule ist klar, das Netzwerk A.B.0.0/16 am Internen Interface soll genattet werden ! Also normales PAT via Extern -> sämtliche Adressen aus A.B.0.0/16 werden über die ASA zu A.B.C.50. (Aussnahmen "access-list Intern_nat0_outbound") bewirkt durch -> nat (Intern) 1 A.B.0.0 255.255.0.0 interface Ethernet0/0 de
  6. hi diavolo86, hier die Antwort zu letzten Frage: ja ! Was meine ich mit global ! NAT: Local and Global Definitions [iP Addressing Services] - Cisco Systems Du legitimierst quasi die ASA damit auf Adress-Räume zu reagieren. Mit dem Befehl "global (outside) 1 interface" Bezieht sie sich also genau auf dass, was am Interface konfiguriert wurde. z.B. einen Adress-Raum 100.100.100.1/24 Diesen Eintrag verwendet sie für ihre Nat-Rules. Ist der Eintrag z.B. nur 100.100.100.1/32 am Interface, dann wäre "global (outside) 1 interface" das selbe wie global (outside) 1 100.100.100.1
  7. Hi hegl, die Lösung ist: access-list ipsecPolen extended permit ip host 10.10.11.222 192.168.20.0 255.255.255.0 no access-list ipsecPolen extended permit ip 192.168.20.0 255.255.255.0 host 10.10.11.222 access-list ipsecPolen extended permit icmp host 10.10.11.222 192.168.20.0 255.255.255.0 no access-list ipsecPolen extended permit icmp 192.168.20.0 255.255.255.0 host 10.10.11.222 Auf der ASA, welchen den IPSec Traffic umleitet/weiterreicht, darf diese Policy nicht so aussehen wie bei mir. Ich weiss auch nicht welche Pferde mich geritten haben eine solche Policy zu verwenden. (s
  8. hi again, check out : global (outside) 1 100.100.100.1-100.100.100.3 Und poste mal den Guide aus dem Du die Sache mit dem Subinterface hast ! Nice evening Greez Mr. Oiso
  9. hi diavolo86, genau, ja das meine ich. Ein Beispiel wie ich es im Feld laufen habe: interface Ethernet0/0 description External nameif outside security-level 0 ip address A.B.C.91 255.255.255.248 global (outside) 1 interface nat (inside) 0 access-list nonat nat (inside) 1 172.16.0.0 255.255.0.0 nat (dmz) 0 access-list nonat nat (dmz) 1 10.0.0.0 255.255.255.0 static (dmz,outside) tcp interface smtp 10.0.0.4 smtp netmask 255.255.255.255 static (dmz,outside) tcp A.B.C.92 www 10.0.0.6 www netmask 255.255.255.255 static (dmz,outside) tcp interface pop3 10.0.0.4 pop3 netma
  10. Hi@all, hi hegl Tja, Fehlermeldung Fehlanzeige. Mit dem "same-security-traffic" ist zumindest einmal schon das IPSec Relay, aktiv. IPSec Traffic am Umlenkpunkt rein und raus. #pkts encaps: 40, #pkts encrypt: 40, #pkts digest: 40 #pkts decaps: 45, #pkts decrypt: 45, #pkts verify: 45 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 40, #pkts comp failed: 0, #pkts decomp failed: 0 #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0 #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly:0
  11. Hi @ all so weit so gut. Den netten Link aus dem letzten Post hab ich wohl selbst nicht richtig gelesen, "same-security-traffic permit intra-interface" war der erste Schlüssel zum "fast" Erfolg. Leider läuft es immer noch nicht. Jedoch lässt sich nun auf der entfernten ASA im cature sehen, dass z.B. ein ICMP reply vom Mobile-User der ersten ASA reinkommt und auch der reply ist von der dst-ip die ASA in Richtung inbound trusted wieder betritt. 34: 02:03:48.290298 802.1Q vlan#1 P0 10.10.11.222 > 192.168.20.3: icmp: echo request 35: 02:03:48.290451 802.1Q vlan#1 P
  12. hi @ all, für alle, denen mein Roman :D nicht ganz eindeutig ist. Hier soll es hingehen ! PIX/ASA 7.x Enhanced Spoke-to-Client VPN with TACACS+ Authentication Configuration Example - Cisco Systems Greez Mr. Oiso
  13. Hi diavolo86, ein "forwarding" static sollte hier reichen. static (inside,outside) tcp 100.100.100.3 https 200.200.200.10 https netmask 255.255.255.255 Greez Mr. Oiso
  14. Hi hegl, nice tip to use object groups ! :D Wie ich sagte ein Alias für Services und Address-Spaces etc. ! :cool: Feature ! Ist das neu in Version 8 ? thx Greez
  15. Hi Wordo, hi hegl, @Wordo: sowas würde ich nie machen ! ;) @hegl: Gute Frage, da schau ich doch gleich mal nach was Du mit "network-objects" meinst. Zu meiner Schande habe ich mir dazu noch keine Gedanken gemacht. Sicherlich ist das nichts anderes als ein Alias für die Destination-Netzwerke welche ich erreichen will, oder liege ich da falsch. Generell, meine ich mit 10.10.11.0/24 - 192.168.20.0/24, einmal den dynamischen Pool der mobilen VPN Clients welcher 10.10.11.0/24 ist und ein destination network hinter einem static Tunnel ! Die mobilen User haben einen normalen VPN-Connec
×
×
  • Create New...