Site-to-Site VPN aus privatem Netz

[hegl 10]

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?

[Wordo 11]

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

[hegl 10]

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?

[Wordo 11]

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

Hab bei PIXen keine Routine ... :)

[hegl 10]

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

[Wordo 11]

alles abgekuerzt:

 

isa en out

isa pol 10 enc aes

isa pol 10 ha sha

isa pol 10 gr 5

isa pol 10 auth pre

acc nonat per ip 192. bla

nat (in) 0 acc nonat

cry ips trans mytrans esp-aes esp-sha-hmac

cry dynam dynmap 10

set transf mytrans

cry map statm 999 ips dyna dynmap

cryp map statm int out

sysopt conn permit-ipsec

cry map statmap client auth (local?)

cry map statmap clien conf

address respond

ip local pool remotepool

ip blabla

acc slittunnel permit ip

ip blabla

vpng smallgroup addre remotepool

vpng smallgroup password blalba

vpng smallgroup dns-server ipbla

vpng smallgroup split-tun splittunnel

vpng smallgroup idle-time 600

 

Authentfizierung war mit Radius, denk mal mit local und lokalen Usern gehts auch

[hegl 10]

schon mal ein großes

 

DANKE

 

werde berichten, ob´s passt.

[hegl 10]

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

[Wordo 11]

Hmmm ... ist bei der Firewall die vor dem Remote steht auch Port 4500/UDP frei?

[hegl 10]

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...

[hegl 10]

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

[hegl 10]

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

[hegl 10]

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?