ASA5500Series - Split-Tunneling

[mr._oiso 10]

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

[Wordo 11]

Ist das ne Phishing-Site wo man da hinkommt? ;)

[hegl 10]

Die Client's aus 10.10.11.0/24 sollen durch den Tunnel nach 192.168.20.0/24

 

Und was ist jetzt local und was remote?

 

Wieso arbeitest Du eigentlich nicht mit network-objects?

[mr._oiso 10]

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 ?

[mr._oiso 10]

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

[hegl 10]

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

 

Nöö, gabs schon bei der PIX mit Version 6.x

 

Das andere mus ich mir mal in Ruhe anschauen, bin noch nicht so richtig schlau aus deinem Roman geworden ...

[mr._oiso 10]

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

[mr._oiso 10]

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

[hegl 10]

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

 

Habe ich mir fast gedacht...

...leider habe ich damit auch (noch) keine Erfahrung - sorry.

 

Die samples sind aber eigentlich so, dass es funktionieren sollte. Vielleicht kontrollierst du nochmals die ACL´s.

 

Gibts denn keine Fehlermeldung?

[mr._oiso 10]

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

[hegl 10]

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.

 

Das würde mich allerdings auch interessieren. Habe ich mir auch noch keine Gedanken drüber gemacht, sollte man allerdings wissen!

[mr._oiso 10]

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