Whistleblower

Hm, aber sollten dann nicht die Probleme schon an anderer Stelle auftreten? Ich habe gestern noch mal ein paar Sachen getestet, und mir noch mal die IPSec SA's angeschaut. Demnach legt der Cisco ganz korrekt für jede Host-zu-Host Verbindung einen Eintrag an. Ich sehe auch, dass da Pakete durchgingen, allerdings nur Encaps und Encrypted: local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (192.168.123.1/255.255.255.255/0/0) current_peer x.x.x.x port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 261, #pkts encrypt: 261, #pkts digest: 261 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 3 local crypto endpt.: y.y.y.y, remote crypto endpt.: x.x.x.x path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4 current outbound spi: 0x0(0) Habe dann noch einmal von einer anderen IP getestet und dann folgende Fehler gesehen: 008188: Oct 25 16:37:21.248 PCTime: IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity: {esp-aes 256 esp-md5-hmac comp-lzs } 008189: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256 008190: Oct 25 16:37:21.248 PCTime: IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity: {esp-aes 256 esp-sha-hmac comp-lzs } 008191: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256 008192: Oct 25 16:37:21.248 PCTime: IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity: {esp-aes esp-md5-hmac comp-lzs } 008193: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256 008194: Oct 25 16:37:21.248 PCTime: IPSEC(crypto_ipsec_process_proposal): transform proposal not supported for identity: {esp-aes esp-sha-hmac comp-lzs } 008195: Oct 25 16:37:21.248 PCTime: ISAKMP:(2009): IPSec policy invalidated proposal with error 256 ... usw ... Demnach haperts da irgendwo ganz deutlich noch an den Proposals, aber warum nur von der einen IP?

Hi, Gegenseite steht eine Checkpoint - hab aber leider keinerlei Zugriff darauf, und kann daher auch nicht überprüfen, ob da die Proposals stimmen... Gabs bei Cisco nicht auch nen Befehl, um zu erkennen, mit welchen proposals die Gegenseite reinkommt? Hab auch schon VPNs zu non-Ciscos gebaut, aber es waren immer Lan-2-Lan VPNs... Hier ist das Schema ja ungefähr so: permit host 192.168.123.1 host 172.16.1.1 permit host 192.168.123.1 host 172.16.1.2 permit host 192.168.123.1 host 172.16.1.3 permit host 192.168.123.2 host 172.16.1.1 permit host 192.168.123.2 host 172.16.1.2 permit host 192.168.123.2 host 172.16.1.3 permit host 192.168.123.2 host 172.16.1.1 permit host 192.168.123.2 host 172.16.1.2 permit host 192.168.123.2 host 172.16.1.3 nur mit jeweils 5 Hosts pro Seite...

Hallo zusammen, versuche gerade ein VPN zwischen einem Cisco 876 und einem anderen Hersteller einzurichten. Problem (meines Erachtens) dabei: Es wird keine Lan-2-Lan Verbindung aufgebaut, sondern nur Host-2-Host (bzw. quasi eine Matrix mit 5 Hosts auf der einen Seite und 5 auf der anderen). Beim Debug bekomme ich folgende Fehler: 004110: Oct 24 16:01:33.212 PCTime: IPSEC(epa_des_crypt): decrypted packet failed SA identity check 004111: Oct 24 16:02:12.300 PCTime: IPSEC(epa_des_crypt): decrypted packet failed SA identity check 004112: Oct 24 16:02:29.128 PCTime: crypto_engine: Create DH shared secret 004113: Oct 24 16:02:29.128 PCTime: crypto_engine: Modular Exponentiation 004114: Oct 24 16:02:29.136 PCTime: crypto_engine: Create IKE SA 004115: Oct 24 16:02:29.136 PCTime: crypto engine: deleting DH phase 2 SW:53 004116: Oct 24 16:02:29.136 PCTime: crypto_engine: Delete DH shared secret 004117: Oct 24 16:02:29.236 PCTime: crypto_engine: Decrypt IKE packet 004118: Oct 24 16:02:29.236 PCTime: ISAKMP:(2107):Unable to copy name into saved_grpname Laut Cisco sollte der Fehler in den ACLs zu suchen sein (nicht auf beiden Seiten identisch). Meine Frage ist jetzt erstmal, ob Cisco diese Konfiguration überhaupt unterstützt? Weiss da jemand genaueres zu?

So, Tunnel steht jetzt soweit! :-) Einstellungen für DPD und PFS waren noch nicht ganz sauber... Allerdings gehen noch keine Pakete über den Tunnel - vermute mal, dass die ACLs der Gegenseite noch nicht mitspielen. Oder gibt es sonst noch Möglichkeiten, wo die Pakete hängen bleiben könnten? Mache gerade von einem Client ein Dauerping zu einem Rechner im entfernten LAN. Sehe auch, das die Pakete durch meine "noNAT"-ACL gehen und ebenso die ACL für den IPSec-Traffic durchlaufen. Allerdings kommen keine Pakete zurück, müsste ich sonst in meiner incoming ACL sehen...

Hi Wordo, Kille ich mit einem "clear crypto sa" nicht auch die bestehenden Tunnel zu anderen Lokationen? DPD hat die Gegenseite übrigens aktiviert, ich allerdings noch nicht, weil mir noch die Daten dazu fehlen (oder kann ich die irgendwo aus dem debug erahnen?) Was mich ja auch wundert ist folgendes: Am Anfang akzeptiert er die atts (die zweite Policy matcht): 409790: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): processing SA payload. message ID = 0 409791: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): processing vendor id payload 409792: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): vendor ID seems Unity/DPD but major 194 mismatch 409793: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):found peer pre-shared key matching x.x.x.x 409794: Oct 10 11:20:28.185 PCTime: ISAKMP:(0): local preshared key found 409795: Oct 10 11:20:28.185 PCTime: ISAKMP : Scanning profiles for xauth ... 409796: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):Checking ISAKMP transform 2 against priority 1 policy 409797: Oct 10 11:20:28.185 PCTime: ISAKMP: encryption 3DES-CBC 409798: Oct 10 11:20:28.185 PCTime: ISAKMP: hash MD5 409799: Oct 10 11:20:28.185 PCTime: ISAKMP: default group 2 409800: Oct 10 11:20:28.185 PCTime: ISAKMP: auth pre-share 409801: Oct 10 11:20:28.185 PCTime: ISAKMP: life type in seconds 409802: Oct 10 11:20:28.185 PCTime: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 409803: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):Hash algorithm offered does not match policy! 409804: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):atts are not acceptable. Next payload is 0 409805: Oct 10 11:20:28.185 PCTime: ISAKMP:(0):Checking ISAKMP transform 2 against priority 2 policy 409806: Oct 10 11:20:28.189 PCTime: ISAKMP: encryption 3DES-CBC 409807: Oct 10 11:20:28.189 PCTime: ISAKMP: hash MD5 409808: Oct 10 11:20:28.189 PCTime: ISAKMP: default group 2 409809: Oct 10 11:20:28.189 PCTime: ISAKMP: auth pre-share 409810: Oct 10 11:20:28.189 PCTime: ISAKMP: life type in seconds 409811: Oct 10 11:20:28.189 PCTime: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 409812: Oct 10 11:20:28.189 PCTime: ISAKMP:(0):atts are acceptable. Next payload is 0 409813: Oct 10 11:20:28.189 PCTime: ISAKMP:(0): processing vendor id payload 409814: Oct 10 11:20:28.189 PCTime: ISAKMP:(0): vendor ID seems Unity/DPD but major 194 mismatch aber später dann diese Meldung: 409844: Oct 10 11:20:28.401 PCTime: ISAKMP (0:2068): received packet from x.x.x.x dport 500 sport 500 Global (I) MM_KEY_EXCH 409845: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): processing ID payload. message ID = 0 409846: Oct 10 11:20:28.404 PCTime: ISAKMP (0:2068): ID payload next-payload : 8 type : 1 address : x.x.x.x protocol : 17 port : 500 length : 12 409847: Oct 10 11:20:28.404 PCTime: ISAKMP:(0):: [b]peer matches *none* of the profiles[/b] 409848: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): processing HASH payload. message ID = 0 409849: Oct 10 11:20:28.404 PCTime: ISAKMP:received payload type 17 409850: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): processing vendor id payload 409851: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068): vendor ID is DPD 409852: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):SA authentication status: authenticated 409853: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):SA has been authenticated with x.x.x.x 409854: Oct 10 11:20:28.404 PCTime: ISAKMP: Trying to insert a peer y.y.y.y/x.x.x.x/500/, and inserted successfully 8348C1FC. 409855: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH 409856: Oct 10 11:20:28.404 PCTime: ISAKMP:(2068):Old State = IKE_I_MM5 New State = IKE_I_MM6 Aber die Authentication lief demnach ja trotzdem erfolgreich durch...

Hi Wordo! Habe ein "debug crypto isakmp" und ein "debug crypto ipsec" laufen... Hatte ja auch schon diverse Meldungen gegoogelt, und einiges im Zusammenhang mit DPD gefunden - aber an welchen Stellen kann ich da jetzt für DPD was ändern? Weiss leider auch nicht, ob die Gegenseite DPD fährt... Muss ich morgen mal klären.

Hallo zusammen, habe gerade mal ein kleines Problem mit einem L2L VPN von einem 876 zu einer ASA, jeweils beide mit fester öff. IP. Laut dem Debug scheint Phase 1 erst erfolgreich zu klappen, die SAs werden dann aber kurze Zeit später doch wieder gelöscht: 167880: Oct 9 14:03:20.386 PCTime: ISAKMP:(2111):SA has been authenticated with x.x.x.x 167881: Oct 9 14:03:20.386 PCTime: ISAKMP: Trying to insert a peer y.y.y.y/x.x.x.x/500/, and inserted successfully 833EC76C. 167882: Oct 9 14:03:20.386 PCTime: ISAKMP:(2111):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH 167883: Oct 9 14:03:20.386 PCTime: ISAKMP:(2111):Old State = IKE_I_MM5 New State = IKE_I_MM6 und dann... : 167895: Oct 9 14:03:20.442 PCTime: ISAKMP (0:2111): received packet from x.x.x.x dport 500 sport 500 Global (I) QM_IDLE 167896: Oct 9 14:03:20.442 PCTime: ISAKMP: set new node 1982641305 to QM_IDLE 167897: Oct 9 14:03:20.442 PCTime: ISAKMP:(2111): processing HASH payload. message ID = 1982641305 167898: Oct 9 14:03:20.442 PCTime: ISAKMP:(2111): processing NOTIFY PROPOSAL_NOT_CHOSEN protocol 3 spi 0, message ID = 1982641305, sa = 83548830 167899: Oct 9 14:03:20.442 PCTime: ISAKMP:(2111):deleting node 1982641305 error FALSE reason "Informational (in) state 1" 167900: Oct 9 14:03:20.442 PCTime: ISAKMP:(2111):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY 167901: Oct 9 14:03:20.442 PCTime: ISAKMP:(2111):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE 167902: Oct 9 14:03:20.446 PCTime: ISAKMP (0:2111): received packet from x.x.x.x dport 500 sport 500 Global (I) QM_IDLE 167903: Oct 9 14:03:20.446 PCTime: ISAKMP: set new node 1214460594 to QM_IDLE 167904: Oct 9 14:03:20.446 PCTime: ISAKMP:(2111): processing HASH payload. message ID = 1214460594 167905: Oct 9 14:03:20.446 PCTime: ISAKMP:(2111): processing DELETE payload. message ID = 1214460594 167906: Oct 9 14:03:20.446 PCTime: ISAKMP:(2111):peer does not do paranoid keepalives. 167907: Oct 9 14:03:20.446 PCTime: ISAKMP:(2111):deleting SA reason "No reason" state (I) QM_IDLE (peer x.x.x.x) 167908: Oct 9 14:03:20.446 PCTime: ISAKMP:(2111):deleting node 1214460594 error FALSE reason "Informational (in) state 1" 167909: Oct 9 14:03:20.446 PCTime: ISAKMP: set new node -1893712350 to QM_IDLE 167910: Oct 9 14:03:20.446 PCTime: ISAKMP:(2111): sending packet to x.x.x.x my_port 500 peer_port 500 (I) QM_IDLE 167911: Oct 9 14:03:20.450 PCTime: ISAKMP:(2111):purging node -1893712350 167912: Oct 9 14:03:20.450 PCTime: ISAKMP:(2111):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL 167913: Oct 9 14:03:20.450 PCTime: ISAKMP:(2111):Old State = IKE_P1_COMPLETE New State = IKE_DEST_SA Hab leider nur Config-Zugriff auf meine Seite (876, IP y.y.y.y) Kann jemand genauer entschlüsseln, wo das Problem liegt? Hab schon mehrere ISAKMP Policies angelegt, und er greift sich auch eine, die dann passt (3DES, DH2, SHA, Lifetime 3600). Der PSK wird auch akzeptiert...

Jaaaaa, es funzt endlich! Habe den static NAT Eintrag mit einer neuen Route-Map verknüpft, die NAT für internen Traffic unterbindet! Supi! Danke an Euch alle!

Ich nehme alles zurück - der Test ging nur, weil kein NAT für den Testrechner aktiv war - Liegt also definitiv an meinen NAT-Regeln...

Moin zusammen, hab mich mal wieder näher mit dem Thema http über den IPSec-Tunnel befasst und festgestellt, dass es kein generelles Problem zu sein scheint. Mit hfs (http file server) funktioniert der Zugriff einwandfrei. Anschließend habe ich einfach mal auf einem Testrechner XAMPP installiert und die ganze Website drauf kopiert. Auf diesen Rechner funzt der Zugriff einwandfrei... Das Problem scheint also woanders zu liegen - werde aber trotzdem nochmal die NAT-Regeln checken.

Hallo zusammen, gibt es beim Windows 2003 Server eine Möglichkeit, bei Vorhandensein eines großen DHCP-Scopes (z.B. 172.16.1.10 - 172.16.5.10 /16) Clients anhand der OUI in eine bestimmte Range zu packen? Das ganze hat keinen technischen Vorteil, so nur rein der logischen Struktur dienen.

Ja, danke erstmal an Euch beide! Dann weiss ich auf jeden Fall, dass es im Falle von zusätzlicher Verschlüsselung selbst mit Hardware-Modulen eine nicht ganz optimale Lösung für 100 Mbit Anbindungen wäre.

Hallo, ich suche Unterlagen für den 2811er, speziell Angaben über die Routingkapazität. Früher war das dem CPQRG zu entnehmen, für die 2800er Serie fehlen mir die Daten leider vollkommen :-( Hintergrund ist der, dass ich wissen möchte, ob man eine SDH-Verbindung mit 100 MBit über zwei 2811 voll auslasten kann, oder ob vorher die Router dicke Backen machen. Cisco empfiehlt die Router-Serie ja "nur" für 4-6 T1/E1 Leitungen. Hat da jemand genauere Unterlagen oder Erfahrungen im Betrieb an 100MBit Strecken? Thx!

Hi #9370, Hm, wie definiere ich denn eine Ausnahme für den internen Traffic? Ich blick da grad net ganz durch.... D.h. ich kann die route-map rausschmeissen, und gebe dann direkt beim NAT die ACL an? EDIT: Habs grad gelesen!!!

Hi #9370, hm stimmt, an das Thema NAT habe ich bisher noch gar nicht gedacht - sonst geht ja auch alles (Remotedesktop, Freigaben, VoIP, SIP usw...). Muss ich mal checken! zu 2) sorry - die ACL ist gekürzt! Da fehlen Einträge von Lokation C, die nur auf bestimmte Server Zugriff hat. zu 3) MTU 1492 hatte ich testhalber irgendwann mal eingestellt, weils der Provider so vorgibt, hat aber keinen Einfluss, so wie ichs bisher testen konnte zu 4) Muss ich mir im Detail nochmal anschauen, hatte irgendwann ganz am Anfang mal Probleme mit NAT... Jedenfalls vielen Dank erstmal, jetzt hab ich wieder einige Ansatzpunkte!!!

Beim Testen habe ich vorgestern allerdings noch ein anderes Problem festgestellt. Sobald ich no ip inspect ethernet_0 konfiguriere, womit ich ja normalerweise ip inspect komplett deaktiviere, komme ich von den Lokationen gar nicht mehr ins Internet, selbst dann nicht, wenn ich mit dieser Konfig die Router neu boote. Meine ACL outside_rule blockt dann den eingehenden http-Verkehr... Also sinngemäß "ACL ouside_rule denied 123.4.5.6 (80) -> x.x.x.x (4023)" Erst, wenn ich ip inspect wieder einrichte und entsprechend auf die Interfaces binde, läuft http wieder...? Ist das ein Bug, oder mache ich da irgendeinen Denkfehler?

Lokation B:

Hi, nein, werden durchgelassen. Anbei mal Auszüge der Config, vielleicht findet sich ja irgendwo ein Fehler...: Lokation A: Lokation B folgt...

Hi Robby, gesniffert habe ich auch schon, MTU-Size auf dem Rechner ist auch schon auf 1300 heruntergesetzt. Allerdings will ich nicht auf sämtlichen Clients die MTU herunterdrehen, sondern das ganze lieber mit MSS bzw. PMTU lösen...

Hm, hat keiner eine Idee? Hab jetzt mal die Konfig glattgezogen, auf beiden Seiten ist für das VLAN-Interface MSS=1300 konfiguriert. Trotzdem leider keine Besserung, und das Problem tritt auf beiden Seiten auf. Sprich egal, auf welcher Seite ein Web-Server steht, man kommt von der jeweils anderen Seite nicht drauf... :-(

Hallo zusammen, Hab mal wieder eine Problemstellung, die irgendwie mit dem Thema ip inspect /CBAC oder MTU-Size zusammenhängt. Ähnlich wie bei meinem letzten Thread: http://www.mcseboard.de/cisco-forum-allgemein-38/probleme-http-grundlagen-ip-inspect-112531.html Diesmal ist das Problem folgendes: 2 Locations sind via IPSec-VPN verbunden In der Location A steht ein Webserver, der sowohl intern als auch von extern erreichbar sein soll. Zugriff vom eigenen LAN A ist in Ordnung, Zugriff vom Internet ebenso. Wenn ich vom anderen LAN B draufgehen will, bekomme ich ein Timeout. "show ip inspect sessions" zeigt dann Half-Open Sessions hierfür an. Woran kann's liegen? IP inspect ist z.Zt. nur auf den externen Schnittstellen aktiv, insofern dürfte der http-Traffic da nicht zerlegt werden. Allerdings stimmen die MTU/MSS-Angaben nicht überein, wie ich gerade noch mal festgestellt habe. LAN A = MSS=1350, LAN B = 1452 Muss ich bei Gelegenheit dann anpassen, hatte ich gestern auch schon versucht (beide auf 1350), allerdings mit dem Ergebnis, dass von LAN B auch kein Internetzugriff mehr möglich war. Vermutlich muss ich hier erstmal die Sessions clearen, bevor die neue MSS greift?? Die MTU habe ich jeweils nicht angegeben, da sie automatisch vom Provider zugewiesen werden sollte... Gibts eine optimale Vorgehensweise, wenn man mit diesen Werten "rumspielt", damit man auch wirklich dann mit den neuen Einstellungen testet? Erstmal ip inspect komplett aus, dann MSS anpassen, evtl. weitere Schritte (Sessions clearen?), dann ip inspect an, und dann testen?

Hi Otaku, so wie ich das bisher verstanden habe, überprüft ip inspect, ob der jeweilige Traffic protokoll-konform ist. Daher (bei mir) vermutlich auch die Probleme mit http, da er vermutlich fragmentierte Pakete nicht richtig zusammensetzen kann. Wenn Du ip inspect für ftp nutzen willst, und nicht den Standardport 21 verwendest, mußt Du die PAM table (Port Application Mapping) anpassen. z.B. in der Form: ip port-map application_name port port_# [list acl_#] Also für application_name ftp, für port_# Deinen ftp-Port und optional die ACL, die dafür genutzt werden soll (in der Du z.B. Deinen einzelnen ftp-Server angibst). Kontrollieren kannst Du die Einträge dann über show ip port-map Die Ports für eingehende Dienste (wie ftp, www ...) würde ich allerdings schon vorher über eine ACL einschränken.

Hi Thomas, hab das VLAN-Interface eigentlich schon MSS auf 1300 gestellt. Vielleicht muss ich tatsächlich mal ein wenig mit dem Wert varieren... Werds die Woche wohl mal austesten...

So grade nochmal getestet. "debug ppp neg" sagt 1492, also wie gewünscht... Habe sicherheitshalber auch noch mal auf dem Dialer definitiv 1492 angegeben. Macht allerdings keinen Unterschied. Sobald ich allerdings "ip inspect name ethernet_0 http" rausnehme, läuft die Seite (wie zu erwarten) auf Anhieb... Aber das ist eigentlich nicht die gewünschte Einstellung... :-( Noch Ideen, woran es scheitern könnte? Oder kann ich die Seite als Ausnahme definieren?

Danke, werde ich mal machen, wenn hier weniger Traffic ist... Eigentlich hatte ich das auch mal fest konfiguriert, aber ist wohl irgendwann wieder rausgewandert... Mal schauen, ob's dann daran liegt...