mr._oiso

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 ausschließlich diesem Eintrag: host 192.168.2.10 host 192.168.1.25 anschließend auch nur noch 2.10 mit 1.25 reden ! Na und "permit ip any any" (recht hast Du) Sicher ist das sicherlich nicht ! Mein Vorschlag im nächsten Post Greez Mr. Oiso – Hi Pete, da ich nicht weiss, was der Server 192.168.2.10 in der DMZ macht. hier ein allg. Vorschlag: no access-list CRYPTOACL extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 static (intern,dmz) 192.168.2.x 192.168.1.x netmask 255.255.255.255 Lass die beiden Server über einen statischen NAT Eintrag miteinander kommunizieren. Damit umgehst Du die NAT 0 (Ausnahme). Für x wähle jeweils eine frei Adresse aus dem internen und dem dmz Netz. Wenn Du z.B. einen SMTP Proxy hier in der DMZ betreibst ginge auch: static (intern,dmz) tcp 192.168.2.x smtp 192.168.1.x smtp netmask 255.255.255.255 Statt dem hier: access-list DMZ extended permit ip host 192.168.2.10 host 192.168.1.25 access-list DMZ extended permit ip any any Solltest Du die ACL schon genauer definieren: z.B.: access-list DMZ extended tcp host 192.168.2.10 any eq smtp access-list DMZ extended tcp host 192.168.2.10 any eq www access-list DMZ extended udp host 192.168.2.10 any eq domain access-list DMZ extended udp host 192.168.2.10 any eq ntp access-list DMZ extended tcp host 192.168.2.? (andere Server) access-list DMZ extended udp host 192.168.2.? (andere Server) oder wenn z.B. 192.168.2.10 ein Terminal Server inkl. Webzugriff für die Remote Side ist access-list DMZ extended tcp host 192.168.2.10 eq 3389 192.168.110.0 255.0.0.0 access-list DMZ extended tcp host 192.168.2.10 eq www 192.168.110.0 255.0.0.0 access-list DMZ extended icmp host 192.168.2.10 host 192.168.1.25 ICMP in jedem fall erst einmal um zu sehen ob es funktioniert Nice Weekend Greez from Mr. Oiso – Hi again, Tips: Du kannst den static auch weglassen und nur die ACL DMZ einrichten, musst dann aber access-list CRYPTOACL extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 stehen lassen. Der Übersicht wegen mache ich es auf jeden Fall so, damit ich mir nicht bei einer Config ähnliche Gedanken mache. Und, ich würde die nat 0 an DMZ und intern über getrennte ACL's definieren ! Ciao Mr. Oiso

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: none Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: 1,10,20,186,1002-1005 Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Protected: false Unknown unicast blocked: disabled Unknown multicast blocked: disabled Appliance trust: none VS0129504802#sh spanning-tree VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 8192 Address 0005.7497.3900 Cost 3 Port 65 (Port-channel2) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 0009.7c4a.10c0 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Po2 Root FWD 3 128.65 P2p Daran können wir sehen ob der Channel überhaupt arbeitet ! Greez from Mr. Oiso

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 gebundenen map am Interface (outside) auch. Ohne dem, ist es damals auch nicht gegangen. Die einzelnen Fhler jedoch habe ich nicht mehr auf dem Schirm, welche mir dabei über den Weg gelaufen sind ! Notfalls teste ruhig mal "crypto isakmp identity auto" ! Und mach mal nen "debug crypto ipsec 7" oder gleich die "debug crypto ipsec 100" Greez Mr. Oiso

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 Frage ! access-list Extern_nat0_outbound extended permit ip any A.B.0.0 255.255.0.0 nat (Extern) 0 access-list Extern_nat0_outbound Alles, was von extern nach intern soll, dafür gilt mit disen zei Einträgen plötzlich kein Nat mehr ? Wozu ? Damit sind diese beiden Nat Entries static (Extern,Intern) A.B.80.51 A.B.80.41 netmask 255.255.255.255 static (Extern,Intern) A.B.80.52 A.B.80.42 netmask 255.255.255.255 gleich mal "unwirksam" , wobei ich eher glaube, dass du hier mit der externen IP 51 die interne 41 erreichen willst, und dann sollte der command so aussehen static (Intern,Extern) A.B.80.51 A.B.80.41 netmask 255.255.255.255 Letztendlich zu diesen commands static (Extern,Extern) A.B.80.50 A.B.80.40 netmask 255.255.255.255 static (Extern,Extern) A.B.C.53 access-list Extern_nat_static welchen Sinn verfolgst du damit ? Soweit ich das weiss, macht es nur Sinn, in zum Beispiel so einem Fall: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968d1.shtml Aber auch danach sieht es nicht aus ! Und... static (Extern,Extern) A.B.C.53 access-list Extern_nat_static sollte sicherlich nen https forwarding von der interface extern IP auf die 80.15 intern werden ! oder ? von dem hier ganz zu schweigen, static (Extern,Extern) A.B.80.50 A.B.80.40 netmask 255.255.255.255 sind 80.50 und 80.40 nicht Adressen......ah, 40-42 waren die aus dem vpn pool....:confused: wieso wieder zu 80.50-52 :confused: Ich glaube eine Netzwerkskizze wäre angebracht. Und ändere mal A.B.C.53 in reale Zahlen wie 1.2.3.53 und für A.B.80.50 dann 1.2.80.53 Irgendwie komme ich mit der Konfiguration noch nicht ganz klar ! :( Muss da mal ne Nacht mit schlafen ! :o Bimo Greez Mr. Oiso

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 description Extern nameif Extern security-level 0 ip address A.B.C.50 255.255.255.240 ospf cost 10 --------------------------------------------------- Alle Adresse, welche durch ACL "access-list Intern_nat0_outbound" erkannt werden, sind davon ausgenommen. Bedeutet, wenn ein Host aus dem Netzwerk A.B.0.0/16 nach host A.B.80.40-42 möchte, soll kein NAT gemacht werden ! bewirkt durch -> nat (Intern) 0 access-list Intern_nat0_outbound und access-list Intern_nat0_outbound extended permit ip A.B.0.0 255.255.0.0 host A.B.80.40 access-list Intern_nat0_outbound extended permit ip A.B.0.0 255.255.0.0 host A.B.80.41 access-list Intern_nat0_outbound extended permit ip A.B.0.0 255.255.0.0 host A.B.80.42 Im Zusammenhang mit : ip local pool VPN_Intern A.B.80.40-A.B.80.49 mask 255.255.0.0 sieht es so aus, als wenn die ersten drei Mobilen User (dynamic VPN) ins Interne Netzwerk dürfen (zumindest könnten) und dies restlichen 43-49 (7) nicht. Ist das so gewollt ? Interpretiere ich richtig ? Und Du bist dir bewusst, dass Du für den mobilen User Adressen aus dem Internen Netzwerk verwendest, welche du dort auch frei haben solltest ? Soviel erst einmal zu Teil 1 Greez Mr. Oiso

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 Mit dem Befehl 100.100.100.1-100.100.100.3 beschränkst Du nur den Adr.-Raum für die Adressen die sie dazu verwenden soll. Bei der ASDM müsste ich also erst nachschauen wo Du das einstellen kannst ! :confused: Deshalb wage doch mal den Schritt: telnet 200.200.200.1 und zeige uns hier den Output von "show run" Tip: Nimm bitte sämtliche Passwörter raus, und vergiss dabei DNS-namen nicht, wenn es sich um eine Finale Konfiguration handelt. Somit können wir auch gelich die ACL's mal einsehen ! Die sind nämlich immer gerne "Big-Problems" Greez Mr. Oiso

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. (sicherlich irgendwo abgeschrieben) :D Unter normalen Umständen ist das auch nicht störend ! So laufen zumindest mehrere Tunnel bei mir im Feld. Gemacht habe ich dieses wahscheinlich irgendwo im Zusammenhang mit einer Watchguard. Bei der z.B. wird manchmal eine Policy so eingetragen. A.B.C.D <-> E.F.G.H (bidirectional) Normal wäre jedoch bei Cisco immer: permit Prot. local remote Und das auf beiden Seiten ! Da ich aber hier permit Prot. local remote permit Prot. remote local verwendet habe, haben sich die Pakete des Mobile Client zwischen den ASA's im Kreis bewegt. Mit anderen Worten: Die ASA in der Mitte des Szenarios hat die Pakete nicht mehr an den Client zurück gegeben, sondern an die ASA von der sie das Paket bekommen hat zurück geleitet. :D Mit noch anderen Worten: Immer schön dass machen, was im Guide steht, wenn es einen gibt ! ;) Greez @ all Nice Weekend Mr. Oiso

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

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 netmask 255.255.255.255 static (inside,dmz) 10.0.0.102 172.16.1.4 netmask 255.255.255.255 static (inside,dmz) 10.0.0.103 172.16.1.29 netmask 255.255.255.255 Allerdings hast Du mich jetzt wahrscheinlich auf dem falschen Fuss erwischt :D Ich fahre hier eine ASA5510 mit Version 7.2.2 und ohne Vlan Lizenz. Jedoch bin ich der Meinung, das die Vlan's hier keine Rolle spielen, da sie letztlich auch nameif outside konfiguriert sind. Natürlich solltest Du darauf achten, dass Du die allg. NAT Rule im Griff hast und eine "outside_access_in in interface outside" hast, welche den syn https durchlässt. Ohne den HTTPS von aussen frei zu machen, kann die static PAT (NAT) rule nicht funktionieren. Ich werde es auf jeden Fall zum Wochenende mal selber im Release 8.0.3 testen, da ich dort auch nen https Citrix WebAccess benötige. Ansonsten ist aus diesem Dokument viel rauszuholen ! Cisco Security Appliance Command Line Configuration Guide, Version 8.0 - Configuring NAT [Cisco ASA 5500 Series Adaptive Security Appliances] - Cisco Systems Greez Mr. Oiso

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 #send errors: 0, #recv errors: 0 Das tut's schon mal ! Das Dumme ist jedoch, dass man den Traffic schlecht capture'n oder filtern kann, da er eben encrypted sein sollte. Am Endpunkt, also der zweiten ASA kann man ihn dann capture'n am inside interface. Danach jedoch passiert schon folgendes in der SA. #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 19, #pkts decrypt: 19, #pkts verify: 19 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #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 #send errors: 0, #recv errors: 0 Die ASA entschlüsselt noch den request (z.B. ICMP), den man dan capture'n kann, man sieht auch noch den reply wieder reinkommen am inside, aber dann wird nicht verschlüsselt. #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 :confused: Vor allem :confused: , weil neben diesem Tunnel ein normaler L2L liegt, welcher einwandfrei läuft. Jetzt hab ich schon 37 mal die Nat Rule geprüft und ACL's rein und raus genommen ............... :( Bleibt jetzt nur noch die Frage nach den Releases und ihren Bug's. Oder z.B. auch die Frage: Im Guide gelten für alle Tunnel die gleichen encryption parameter z.B. 3des/sha sowohl für die dynamischen Clients als wie auch für den static. Ich jedoch nutze Release 8.0.3 und 7.1.2 Ausserdem eine ASA mit 3des und die andere mit des Lizenz. Ergo muss der IPSec einmal von 3des auf des zurück und umgekehrt. Ob das Probleme bereitet. Mal sehen was Cisco sagt. Ich mach mal nen Test mit einem dynamischen User und einer des Verschlüsselung - Eben "Guided" Update folgt. Nice evening Greez Mr. Oiso

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 P0 192.168.20.3 > 10.10.11.222: icmp: echo reply Danach jedoch ist Schluss ! :confused: capture, debug, study ................... :cry: Greez Mr. Oiso

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

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

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

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-Connect welcher funktioniert zum local/trusted network welches 192.168.1.0/24 ist. Wenn ich hier eine policy definiere mit: split-tunnel-policy tunnelall (default) split-tunnel-policy value "list" und die "list" (standard) permit 192.168.1.0 255.255.255.0 funktioniert soweit alles ganz gut. Nur bis dahin alles "Easy" Jetzt besitzt die ASA aber noch einen static Tunnel 192.168.1.0/24 - 192.168.20.0/24 Dieser ist ebenfalls funktionstüchtig und läuft. Jetzt habe ich die Routing-Policy IPSEC (SA) um die Einträge permit 192.168.20.0 255.255.255.0 10.10.11.0/24 erweitert. Das sorgt dafür, dass ich zwischen den static peer's nun eine policy habe, welches den mobile Usern ermöglichen sollte über ihre VPN Verbindung auch das Netzwerk 192.168.20.0/24 zu erreichen. sh crypto ipsec sa - auf den static peer's zeigt mir auch eindeutig den Tunnel. Nur sehe ich keine encrypt/decrypt packets, solange das "slpit-tunneling" der mobilen User nicht richtig arbeitet. Habe also die "list" (standard) permit 192.168.1.0 255.255.255.0 um permit 192.168.20.0 255.255.255.0 erweitert und bekomme die beim VPN-Client unter "Status/Statistics/Route Details" auch angezeigt. ACL's habe ich bereits alle geprüft und zwischenzeitlich auch auf "ip any any" inkl. "icmp any any" gehabt. Ohne Ergebnis ! Irgenwas stimmt mit dem Routing oder dem Split-Tunneling nicht ! Aber was ?

Hi @ all, da habe ich doch glatt auch einmal ein Problem. Wahrscheinlich bin ich aber auch nur blind ! Ich versuche schon seit Freitag Split-Tunneling auf einer ASA einzurichten, aber irgendwie will es nicht funktionieren. Anbei meine Konfiguration (Ausschnitte) agoga.com Die Client's aus 10.10.11.0/24 sollen durch den Tunnel nach 192.168.20.0/24 Was hält sie auf ? Danke für jedes wachsame Auge ! Greez Mr. Oiso

Mahlzeit Leute, kleiner Tip, "copy flash:vlan.dat tftp" und auf den neuen Switch wieder hochladen, reload und fertig ! :D So hat man auch gleich ne Sicherung, falls einem das Pech mit einer neuen und zu hohen Config Revision Number ereilen sollte. ;) Greez Mr. Oiso

hi jon, um die ein oder andere dialer map/pool oder profile Konfiguration wirst Du hier wohl nicht herum kommen. Und solange du die 30 Kanäle nicht aufbrauchst, kannst du die Verbindungen ja auch an Sub-Interfaces binden P.S.: Example TechNotes bei cisco gibt es sogar ohne CCO Login ! check this out: ISDN, CAS Configuration Examples and TechNotes - Cisco Systems Greez Mr. Oiso

Hi maegl, hi hegl, @hegl, sorry für die ...... (Du weisst schon), ich nehme es halt gern genau ! ;) Aber nur so erklärt sich oft vieles von alleine ! Im Debug Output gab es bis auf: Feb 15 09:38:28 [iKEv1 DEBUG]: Group = x.x.x.x, IP = x.x.x.x, IPSec SA Proposal # 1, Transform # 1 acceptable Matches global IPSec SA entry # 10 keine Fehler, nur in diesem Eintrag ist genau zu sehen, dass die Phase 2 auf die falsche IKE Policy aufsetzt. "Matches global IPSec SA entry # 10" Eigendlich hätte hier die # 20 stehen müssen, damit der Tunnel nach Vorgabe in beiden Richtungen hätte funktionieren können. Auch die Entnahme der "set reverse-route" kann die Aktion begünstigt haben, welche mir gestern Abend dann im Bett auch sinnlos erschien, weil die Policy doch anhand einer L2L hätte direkt matchen dürfen. Habe da anfänglich leicht dran vorbei geschaut, obwohl Du eine pppoe mit dynamic IP am outside laufen hast. Ich dachte mir aber schon, dass Du sicherlich eine endlose "lease" bekommst, und daher war ansonsten auch alles richtig. Eine weitere mögliche Lösung wäre gewesen: Verwende solange es die Resourcen der Hardware zulassen unterschiedliche IKE Proposal's, um solche Fehler zu umgehen (oder bename sie einfach anders). Richtig lustig wird es erst noch wenn man nun auch noch L2TPoverIPSec oder gar SSLVPN Policies mit einarbeitet ! Schön, dass ich helfen konnte ! Und sollten noch Fragen offen sein, nur zu ! Nice evening ! Greez Mr. Oiso

Hi maegl, jo, jo, ich habe mir etwas viel Zeit gelassen, sorry. Aber ich denke mal ich kenne die Lösung. Pack doch mal bitte Deine crypto map VPNBO 10 ipsec-isakmp dynamic rtpdynmap an das Ende der map VPNBO Ich bin mir nicht sicher, ob der "reverse-route" für den Tunnel zu stande kommt, daher würde ich nach Cisco Beispiel vorgehen ! Demnach die dynmap immer ans absolute Ende der map, welche am Outside hängt. Die Reihenfolge der Crypto map würde ich immer nach der Genauigkeit des Machting's aufbauen. Je mehr Parameter für die Policy matchen, desto niedriger die ID crypto ipsec transform-set vpnboeching esp-3des esp-md5-hmac crypto dynamic-map rtpdynmap 10 set transform-set vpnboeching crypto map VPNBO 20 match address VPNRG crypto map VPNBO 20 set peer X.X.X.X crypto map VPNBO 20 set transform-set vpnboeching crypto map VPNBO 20 set reverse-route crypto map VPNBO 30 match address VPNBA crypto map VPNBO 30 set peer Y.Y.Y.Y crypto map VPNBO 30 set transform-set vpnboeching crypto map VPNBO 40 ipsec-isakmp dynamic rtpdynmap crypto map VPNBO interface outside crypto isakmp enable outside crypto isakmp policy 20 Hier das Beispiel von Cisco !--- Configuration of IPsec Phase 2 crypto ipsec transform-set myset esp-3des esp-sha-hmac !--- IPsec configuration for the dynamic LAN-to-LAN tunnel crypto dynamic-map ezvpn 30 set transform-set myset !--- IPsec configuration for the static LAN-to-LAN tunnel crypto map outside_map 20 match address outside_cryptomap_20 crypto map outside_map 20 set peer 172.16.1.1 crypto map outside_map 20 set transform-set myset !--- IPsec configuration that binds dynamic map to crypto map crypto map outside_map 65535 ipsec-isakmp dynamic ezvpn !--- Crypto map applied to the outside interface of the ASA crypto map outside_map interface outside isakmp enable outside Erstens: Doppelt wäre gewesen,.... access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0 access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0 und überhaupt, ICMP war noch nie "in IP drin" .............. !!! (wie sich das schon anhört) :suspect: Refer to: RFC 792 RFC 1122 Requirements for Internet Hosts -- Communication Layers Zitat RFC1122 ICMP is a control protocol that is considered to be an integral part of IP, although it is architecturally layered upon IP, i.e., it uses IP to carry its data end- to-end just as a transport protocol like TCP or UDP does. ICMP provides error reporting, congestion reporting, and first-hop gateway redirection. IGMP is an Internet layer protocol used for establishing dynamic host groups for IP multicasting. The Internet layer protocols IP, ICMP, and IGMP are discussed in Chapter 3. ICMP also arbeitet nach wie vor auf der selben OSI Schicht wie IP, und zwar in der Vermittlungsschicht (Layer3). Und "in IP drin" kann es daher per Definition nicht sein. Refer to: Open Systems Interconnection Reference Model Wenn wir nun also ein Vermittlungschicht Protokoll wie IP in eine IPSec Policy aufnehmen, um die Grundlage der Vermittlungsart innerhalb des IPSec Tunnel festzulegen, so sei es unter Umständen auch Ratsam, ICMP mit hinzuzunehmen, damit "Deiner Meinung nach" ICMP auch innerhalb des IPSec Tunnel, weiterhin "in IP drin" sein darf ! :D Greez Mr. Oiso

Hi maegl, hast Du nach dem Aufbau des Tunnels nur nen Ping geschickt, um den Tunnel zu testen ? Erweitere mal die IPSec Policy um ICMP access-list VPN extended permit ip 192.168.2.0 255.255.255.0 192.168.10.0 255.255.255.0 + access-list VPN extended permit icmp 192.168.2.0 255.255.255.0 192.168.10.0/24 Auf beiden Seiten ! Poste mal nen: debug crypto isakmp & debug crypto ipsec (vom Tunnelaufbau bis über Phase 2 hinweg) und nen show crypto ipsec sa ! Greez Mr. Oiso

Hi jholzer Das ist ein ****er Fehler, und ist mir bekannt. Die Lösung jedoch scheint nicht so Einfach. In zwei Situationen hatte ich den Felher auch schon einmal. Einmal mit einem HA active/standby Watchguard Firewall System. Diese fragen sich gegenseitig via ARP-Request ab. Hier wechselten die Boxen ständig den active/standby, weil der Cisco Catalyst nur einen Incomplete ARP entry zurückgegeben hat. Lösung war: Fix Speed/Duplex 100/full z.B. In einer anderen Situation war es ein medizintechnisches Gerät, spez. Anfertigung. Ähnlich wie Deine Elektronik. Hier jedoch hat das Fixen der Prot's nix gebracht. Leider liess sich auf der elektronischen Seite die Link Layer nicht beeinflussen, daher musste ich einen Switch/Release- Wechsel vornehmen um das Problem zu beheben. Als erstes würde ich einmal die Verkabelung checken und die Port's fixen. Also Autonegotiation abschalten. Dann wäre es Interessant, ob du den Cat3550 als Router oder als reinen Switch betreibst. Abschalten von IP CEF könnte helfen. In jedem Fall auch mal ein "debug arp" Auch helfen könnte der wechsel von Pagp zu LACP, oder gänzlich abschalten. Auf den folgenden Seiten findest Du .... "leider" eine Menge von möglichen Ursachen, aber auch möglichen Lösungen. TAC Case Collection http://www.cisco.com/en/US/partner/tech/tk827/tk831/technologies_tech_note09186a0080094303.shtml Da Deine Elektronik wahrscheinlich sehr individuell ist, wird auch die Lösung sehr individuell sein. Bedenke aber immer den Nutzen gegenüber dem Aufwand. Greez from Mr. Oiso

Hallo, ich habe ein recht seltsames Problem: Ich habe einen SBS2003 mit 10 Cals. Darauf gibt es 8 Exchange-Postfächer und eine Hand voll Freigaben. Nun kommt es in unregelmaessigen Abständen dazu das jemand nicht mehr via Outlook auf sein Exchange-Postfach zugreifen kann. OWA oder der Zugriff auf freigegebene Ordner funktioniert weiterhin nur eben der Zugriff auf das Postfach via Outlook nicht. (Outlook 2003 SP3!). Wenn man den Server neu startet so funktioniert der Zugriff wieder eine Zeit lang. In den Eventlogs gibt es leider keine Hinweise oder Fehler - auch auf dem Client gibt es keinen Hinweis im Eventlog dazu. Es muss ja irgendein dynamischer Vorgang sein, der durch einen Serverneustart zurück gesetzt wird weil es danach wieder funktioniert. Kann mir jemand sagen oder vermuten welcher Mechanismus dies sein kann? Gruß

hi erazer2005 hier die wars***einlich schwierigere Version ! Hybrid Mode Cat6509 running CatOS 8.3(3) set trunk 4/1 desirable dot1q 1-4094 set trunk 4/2 desirable dot1q 1-4094 set trunk 4/3 nonegotiate dot1q 1-4094 set trunk 4/5 desirable dot1q 1-4094 set trunk 4/6 desirable dot1q 1-4094 set trunk 4/7 desirable dot1q 1-4094 set trunk 4/8 desirable dot1q 1-4094 set trunk 4/9 desirable dot1q 1-8,10-12,15-4094 set trunk 4/10 desirable dot1q 1-4094 set trunk 4/11 desirable dot1q 1-4094 set trunk 4/12 desirable dot1q 1-4094 set trunk 4/13 nonegotiate dot1q 1-4094 set trunk 4/14 nonegotiate dot1q 1-4094 set trunk 4/15 nonegotiate dot1q 1-4094 set trunk 4/16 nonegotiate dot1q 1-4094 set spantree portfast 4/1-3,4/5-16 disable set spantree portfast 4/4 enable set spantree guard none 4/1-16 set port channel 4/1-4,4/7-8,4/13-16 mode off set port channel 4/5-6,4/9-12 mode desirable silent ! #module 5 : 2-port 1000BaseX Supervisor set port name 5/1 VS33650901DSW1 (112) set port name 5/2 VS33650901DSW1 (112) set udld disable 5/1-2 set spantree portfast 5/1-2 disable set spantree guard none 5/1-2 set port channel 5/1-2 mode desirable silent Nice Weekend Greez Mr. Oiso

Hallo, ich habe ein kleines Problem mit einer Anwendung unter Windows 2000 Server. Diese Anwendung benötigt eine INI-Datei mit bestimmten Werten die normal auch vorhanden ist. Nun kommt irgendwann manchmal einmal am Tag, manchmal auch erst nach 3 Tagen es vor das der Inhalt der INI-Datei zwar noch da ist, aber alle Werte in ihr (nur Zahlen) plötzlich auf 0 stehen. Die Applikation selbst scheint es nicht zu sein die dies verursacht. Da bei der Installation d.h. vor der Konfiguration der Applikation diese INI-Datei auch mit diesen 0-Werten existiert scheint es mir so als ob irgendjemand den Ursprünglichen Zustand der Datei wieder herstellt. Ich sehe dann zwar das die Werte 0 sind, aber der Zeitstempel der Erstellung dieser Datei ist noch immer der des Installationszeitpunktes der Applikation. Gibt es eine Möglichkeit, Schreibzugriffe auf diese INI-Datei so zu protokolieren das ich herausfinden kann, wer, welcher Prozess, welches Windows-Konto wann diese Datei verändert hat? Es muss doch irgendein Tool geben was dies leistet oder? Gruß