hegl

Geht ein Telnet auf Port 6129 und 445? Vll. ist die FW vom VPN Client aktiviert (Haekchen beim Client gesetzt?)

 

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:

 

By the way - wie kann man die ASA über das CLI komplett resetten ?

 

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.

Fuer PIX 6.X oder 7.X? Dann tipp ichs aus "The Complete Cisco VPN Configuration Guide" ab.

Hab bei PIXen keine Routine ... :)

 

Version 6.3

Klar, EasyVPN Remote kann bereits eine 501 mit Version 6.2.

 

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?

einfach das "sysopt connection permit-ipsec" rausgeben und den Verkehr per ACL am Interface steuern.

/#9370

 

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.

wieso lehnt eigentlich die ASA die Verbindungen ab??

ne Idee vielleicht??

 

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?

 

Der PIX ist es ****egal in welcher Reihenfolge die ACLs konfiguriert sind. Es kommt nur auf die Reihenfolge der ACEs an.

 

/#9370

 

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.

Soviel ich verstanden habe, will er die ASA anpingbar haben ....

 

Nein, er schreibt doch oben, dass er vom Notebook aus pingt!

 

CISCO sagt zu dem Fehler:

 

313004

Error Message: %PIX|ASA-4-313004: Denied ICMP type=icmp_type, from source_address oninterface interface_name to dest_address:no matching session Explanation

ICMP packets were dropped by the security appliance because of security checks added by the stateful ICMP feature that are usually either ICMP echo replies without a valid echo request already passed across the security appliance or ICMP error messages not related to any TCP, UDP, or ICMP session already established in the security appliance.

 

Recommended Action: None required.

 

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?