hegl

Nein, weder auf 6129 noch auf 445. Die FW beim VPN-Client ist nicht gesetzt! Habe mal mit nmap gescannt: PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http 443/tcp open https 8080/tcp open http-proxy Obwohl der Dienst für Dameware gestartet ist, wird er nicht als offen deklariert.

Nach der Umstellung auf den CISCO VPN Client können wir per Dameware nicht mehr auf die Clients zugreifen. Der ping zum Client funktioniert und der Client kann auf alle konfigurierten Ressourcen im LAN zugreifen. IP ist nicht beschränkt, dass heisst tcp und udp sind für alle Ports offen. Wenn ich die Verbindung auf die per local-pool zugewiesene Adresse aufbaue, erhalten ich einen "Winsock Connect Error": Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die Verbindung verweigert. Hat jemand eine Ahnung, wodran das liegen könnte?

Nein, es geht hier um eine statische IP. Mittlerweile muss man aber von enem Defekt auf der Netzwerkkarte ausgehen, da auch bei unterschiedlichen Switchports und ohne port-security das angeschlossene Gerät manchmal nicht zu ereichen ist.

Wir haben ein ähnliches Problem auf einem 3548-er. Dort ist auch die Port-Security aktiviert und von Zeit zu Zeit geht der Port auch in error-disable-Status. Das Merkwürdige an der Sache ist dies, dass erstens kein anderes Gerät an dem Switchport angeschlossen ist und die verursachende MAC-Adresse der an dem Switch angeschlossen MAC-Adresse ähnelt. Hat der Switch z.B. im sticky die MAC 010A.BD12.781F so ist die verursachende MAC die 0001.0ABD.1278 ! Heisst also eine 00 davor gesetzt und die letzten beiden abgeschnitten. Sehr seltsam ... :confused:

Wenn Du mit resetten meinst, die conf zu löschen geht´s mit: write erase

Damit eine Änderung der ACL zieht, habe ich auf dem renote device den Befehl vpnclient disable abgesetzt. Der Tunnel wird getrennt und wieder neu aufgebaut. Merkwürdig finde ich aber, dass die SA´s auf dem EasyVPN-Server weiterhin bestehen bleiben. Aber der Zugriff funktioniert weiterhin. Zum Testen von weiteren ACL´s habe ich diese Prozedur wiederholt, sehe dass der Tunnel neu aufgebaut wird, aber keine SA für diesen Tunnel mehr auf dem EasyVPN-Server angezeigt wird (sh crypto ipsec sa), trotz dass am remote device die Tunnel-LED brennt. Auch der Zugriff in das remote-Netz sowie auf das device selber funktioniert nicht mehr. Ich habe dies in einem Lab nachgestellt und stelle das gleiche Problem fest. Auch ein Neustart des remote device führt zu keinem Erfolg. Kann ich auch dem EasyVPN-Server einen Befehl abesetzen machen, ohne alle anderen SA´s ebenfalls zu eleminieren, was ja mit clear crypto ipsec sa passieren würde? Ich vermute nämlich als Ursache eine Cache-Geschichte. Oder habt ihr sonst eine Idee, woran es liegen könnte?

Gibts zwischen der Aussenstelle und der Zentrale einen VPN-Tunnel? Dann siehst Du das über sh crypto ipsec sa. Dann kannst Du auch über den Tunnel die PIX administrieren und die Zugriffs-IP entsprechend einschränken.

Es funktioniert - und keiner weiß warum... :) :) :) ...oder besser gesagt, und keiner weiß, warum es gestern nicht funktionierte. Nachdem ich heute morgen das remote device angeschaltet habe, sah ich im debugging auf dem Easy VPN Server wilde Aktivitäten :D und danach mit sh crypto ipsec sa, dass der Tunnel steht. Dann noch schnell die ACL angepasst und ein ping funktioniert, sowie auch Internet über das remote device. @ Wordo VIELEN DANK FÜR DEINE HILFE

Ich habe eine sample configuration bei CISCO gefunden. PIX-to-PIX 6.x: Easy VPN (NEM) Configuration Example - Cisco Systems Im Prinzip so, wie Du´s erklärt hast :) Nur fällt mir hier auf, dass ich die ACL anders konfiguriert habe. In diesem Beispiel hat der local pool nichts mit der ACL zu tun. Ich habe dagegen - in Anlehnung an eine normale VPN-Client-Konfiguration - die IP-Adressen des local pool in der ACL konfiguriert. Also hier in dem Bespiel access-list 101 permit ip 10.1.1.0/24 10.3.3.0/24 Werd´ ich morgen mal direkt ändern, mal schau´n, was sich tut. Gut Nächtle :o

Ich habe das remote device im Moment zum Testen im gleichen Netz wie den VPN Server, d.h. ohne Router, Firewall etc. Ich weiß wirklich nicht, ob der Tunnel steht oder nicht. Mit sh crypto ipsec sa sehe ich nichts, mit vpnclient disconnect auf dem remote device scheint es so, als wenn der Tunnel down geht, da die VPN-Lampe erlischt und ich im debugging anschließend wieder einen Verbindungsaufbau verfolgen kann, der dann aber wiederum diesen "delete all sa" in sich hat. Daraufhin erfolgt wieder das kontinuierliche DPD, was ja eigentlich für einen konnektierten Tunnel spricht. Ausserdem kann ich zu diesem Zeitpunkt kein Internet machen, was - wenn ich den VPN-Client disable setze - funktioniert. Wie erkennt das remote device eigentlich was in den Tunnel geht und was nicht? M.E. kann ich dies doch mit split-tunnel steuern, oder? Was in den Tunnel soll, gebe ich doch mit dem vpngroup TEST split-tunnel 101 an? So klappt´s auf jeden Fall mit den Clients, die sich Tag für Tag verbinden. Seltsam, seltsam...

Irgendwie habe ich´s noch immer ned verstanden und funktionieren tut´s auch ned :confused: Folgendes habe ich nun konfiguriert: Remote Device: vpnclient vpngroup TEST password test1 vpnclient username hans password anfang vpnclient server 213.168.x.y vpnclient mode network-extension-mode vpnclient enable Easy VPN-Server (also PIX im RZ): access-list 101 permit ip X.X.X.X Maske 172.20.20.0 255.255.255.248 nat (inside) 0 access-list 101 ip local pool eazy-pool 172.20.20.1-172.20.20.7 crypto ipsec transform-set Berlin esp-3des esp-sha-hmac crypto dynamic-map Hamburg 10 set transform-set Berlin crypto map EAZY 65535 ipsec-isakmp dynamic Hamburg crypto map EAZY client configuration address respond crypto map EAZY client authentication AuthInbound (muss ich nehmen, da bereits für VPN Clients konfiguriert) crypto map EAZY interface outside isakmp enable outside isakmp policy 30 authentication pre-share isakmp policy 30 encryption 3des isakmp policy 30 hash sha isakmp policy 30 group 2 isakmp policy 30 lifetime 28800 vpngroup TEST address-pool eazy-pool vpngroup TEST password test1 vpngroup TEST dns-server x.x.x.x vpngroup TEST wins-server x.x.x.x vpngroup TEST split-tunnel 101 Was ich sehe ist, dass am remote device die vpn-tunnel-lampe brennt und beide PIXen sich DPD-Pakete schicken. Beim debugging auf dem EasyVPN Server sehe ich weiter: ISAKMP (0): atts are acceptable. Next payload is 3 ISAKMP (0): SA has been authenticated return status is IKMP_NO_ERROR ISAKMP (0): sending INITIAL_CONTACT notify ISAKMP (0): sending NOTIFY message 24578 protocol 1 ISAKMP (0): sending phase 1 RESPONDER_LIFETIME notify ISAKMP (0): sending NOTIFY message 24576 protocol 1 VPN Peer: ISAKMP: Added new peer: ip:213.168.X.X/500 Total VPN Peers:3 VPN Peer: ISAKMP: Peer ip:213.168.X.X/500 Ref cnt incremented to:1 Total VPN Peers:3 ISAKMP: peer is a remote access client ISAKMP/xauth: request attribute XAUTH_TYPE ISAKMP/xauth: request attribute XAUTH_USER_NAME ISAKMP/xauth: request attribute XAUTH_USER_PASSWORD ISAKMP (0:0): initiating peer config to 213.168.X.X. ID = 1121394458 (0x42d71f1a) crypto_isakmp_process_block:src:213.168.X.X, dest:213.168.X.Y spt:500 dpt:500 ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 213.168.X.X. message ID = 18738652 ISAKMP: Config payload CFG_REPLY return status is IKMP_ERR_NO_RETRANS Auf dem remote device dagegen: ISAKMP (0): atts are acceptable. Next payload is 0 ISAKMP (0): processing KE payload. message ID = 0 ISADB: reaper checking SA 0xab51dc, conn_id = 0 ISADB: reaper checking SA 0xa2e694, conn_id = 0 DELETE IT! VPN Peer: ISAKMP: Peer ip:213.168.X.Y/500 Ref cnt decremented to:0 Total VPN Peers:1 VPN Peer: ISAKMP: Deleted peer: ip:213.168.X.Y/500 Total VPN peers:0IPSEC(key_engine): got a queue event... IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP IPSEC(key_engine_delete_sas): delete all SAs shared with 213.168.X.Y und dann weiter ISADB: reaper checking SA 0xab51dc, conn_id = 0 return status is IKMP_NO_ERR_NO_TRANS crypto_isakmp_process_block:src:213.168.X.Y, dest:213.168.X.X spt:500 dpt:500 ISAKMP (0): processing NOTIFY payload 24576 protocol 1 spi 0, message ID = 2827159204 ISAKMP (0): processing responder lifetime ISAKMP (0): phase 1 responder lifetime of 3600s return status is IKMP_NO_ERR_NO_TRANS crypto_isakmp_process_block:src:213.168.X.Y, dest:213.168.X.X spt:500 dpt:500 ISAKMP_TRANSACTION exchange ISAKMP (0:0): processing transaction payload from 213.168.X.Y. message ID = 11207124 ISAKMP: Config payload CFG_REQUEST ISAKMP (0:0): checking request: ISAKMP: attribute XAUTH_TYPE (16520) ISAKMP: attribute XAUTH_USER_NAME (16521) ISAKMP: attribute XAUTH_USER_PASSWORD (16522) ISAKMP (0:0): responding to peer config from 213.168.X.Y. ID = 1121394458 return status is IKMP_NO_ERROR

schon mal ein großes DANKE werde berichten, ob´s passt.

Version 6.3

Dann liegts ja nur noch an mir :) Habe gerade mal das manual studiert. Was ich hoffe verstanden zu haben ist, dass ich auf dem remote device in der vpngroup den address-pool dns-server wins-server und den default domain-name konfigurieren muss. Aber wie sieht meine config auf dem Easy VPN Server aus? Hast Du dazu ein sample?

Ich muss eine Aussenstelle per VPN anbinden, die in einem fremden "Kundennetz" liegt. Die Struktur vor Ort sieht da so aus, wie´s jeder von zu Hause kennt: DSL-Router mit WAN zum Provider und LAN (192.168.x.x), wo aber nicht nur unsere Jungs z.Zt. arbeiten. Ich würde also gerne in dieses 192-er Netz eine kleine PIX integrieren und diese eine Verbindung in unser RZ aufbauen lassen. Wie stelle ich das an? WAN-seitig hat die PIX ja dann eine 192-er Adresse, die ich ja nicht als remote peer angeben kann. Kann ich die PIX nicht als "VPN-Client" arbeiten lassen, wie´s im Moment auch die einzelnen MA mit Ihren PC´s tun?

Was meinst du mit rausgeben? Rausnehmen oder einfügen? Habe mir nie Gedanken über den Befehl gemacht, was macht der genau?

Sry, jetzt bin ich überfragt. Ich arbeite grundsätzlich mit virtuellen Adressen für´s NAT - ich habe auch aber einen gewissen pool zur Verfügung. Wie sich die ASA mit der Interface-Adresse verhält kann ich leider nicht beurteilen, obwohl dies ja das Prinzip eines jeden einfachen DSL-Routers ist.

Eine Idee habe ich auch nicht. Der Fehler tritt laut CISCO dann auf, wenn für das Paket keine Beziehung auf der ASA besteht. Wie sieht denn mittlerweile deine conf aus? Oben hast du eine access-group outside-access, die für deine einkommenden Verbindungen zuständig ist. In deinem letzten Beispiel hast du eine access-group outside. Wie ist die gebunden?

Jetzt haste mich aber ein wenig verwirrt... Was ich hoffe verstanden zu haben ist, dass in einer ACL namens Hallo (Policy NAT) darauf zu achten ist, an welcher Position der ACE steht, da das first match zieht. Richtig? Und ob eine "NAT-ACL" davor oder hinter dieser "Hallo-ACL" steht ist vollkommen wurscht. Auch richtig?

Was um Himmels Willen sind denn ACEs? Bei CISCO kenne ich die Abkürzung nur für Application Control Engine. :confused:

Wenn ich bei der PIX/ASA die ACL´s für NAT und die Policy trenne, ist es dann egal, in welcher Reihenfolge diese auftreten? Ich meine mal irgendwo gelesen zu haben, dass zuerst das Statement für NAT konfiguriert sein muss und dann erst die ACL mit der Policy. Kann das jemand bestätigen?

Was hälst Du als Erstes davon, Deine VLAN´s auf no shut zu setzen?

Ich möchte mich hier einmal mit einem ähnlichen Problem anschließen: Folgendes Szenario: Standort A, Netz 10.10.1.0 (dmz per VLAN) an diesem Netz und über die gleiche PIX per VLAN ein weiteres Netz mit 100.100.1.0 (inside) Standort B, Netz 10.10.2.0 Beide Standorte über VPN verbunden und Zugriffe von und in das 10-er Netz funktionieren. Nun möchte ich vom Standort B auf einem Drucker 100.100.1.1 drucken. Da Standort B aber keine globalen Adressen in ihrem RZ routet, mache ich am Standort A ein Static NAT static(inside,dmz) 10.10.1.1 100.100.1.1 netmask 255.255.255.255 0 0 Am Standort B gehen die Pakete in den Tunnel, aber bei mir kommt nichts an? Jetzt habe ich gelesen, man müsste für die encrypted doamin auch die 100.100.1.1 zulassen, weil bei der ankommenden PIX erst der Prozess für NAT und dann erst der für IPSec verarbeitet wird. Kann das jemand bestätigen? Ich kann´s leider nicht so einfach testen, da ich keinerlei Zugriff auf/in Standort B habe.

Nein, er schreibt doch oben, dass er vom Notebook aus pingt! CISCO sagt zu dem Fehler: Also würde ich in Deinem Fall auch auf das ICMP-Inspection setzen!

Hallo, wo ist eigentlich der Unterschied beim Anlegen einer access-group, ob ich access-group 123 in interface inside oder access-group 123 out interface outside angebe? Wenn ich also von inside nach outside will, ist es dann nicht egal, an welches interface ich die access-group binde?