VPN Client kein Traffic zurück

[-= Brummbär =- 10]

Hallo,

 

Ich hab eine ASA 5505. Die VPN-Clienteinwahl klappt. Jetzt habe ich mal hinter die ASA ein Gerät gestellt, um den Traffic zu testen. Dabei habe ich festgestellt, dass ich eine Einbahnstraße definiert habe.

 

Auf der ASA sehe ich, dass der Ping von außen kommt, und vom Gerät im Hausnetz auch beantwortet wird. Aber die Antwort schafft es dann nicht durch den Tunnel zurück. Kann mir jemand einen Tipp geben, was ich da verbockt habe?

 

object-group network Hausnetz
description Lokales Netz in CSS
network-object 192.168.1.0 255.255.255.0
object-group network VPN-Clients
description Subnetz der VPN Clients
network-object 192.168.250.0 255.255.255.0
access-list outside-i extended permit icmp any object-group Hausnetz object-group ICMP_aus_Internet 
access-list outside-i extended permit ip object-group VPN-Clients object-group Hausnetz 
access-list inside-i extended permit icmp any any 
access-list inside-i extended permit ip object-group Hausnetz object-group VPN-Clients 
access-list inside-i extended permit tcp object-group Hausnetz any object-group InternetdiensteTCP 
access-list inside-i extended permit udp object-group Hausnetz any object-group InternetdiensteUDP 
access-list vpn-remoteuser_splitTunnelAcl standard permit 192.168.1.0 255.255.255.0 
access-list inside_nat0_outbound extended permit ip object-group Hausnetz object-group VPN-Clients 

 

! ====================== Tunnel Richtlinien ==================================
!
group-policy vpn-remoteuser internal
group-policy vpn-remoteuser attributes
dns-server value 192.168.2.1 192.168.2.1
vpn-tunnel-protocol IPSec 
split-tunnel-policy tunnelspecified
split-tunnel-network-list value vpn-remoteuser_splitTunnelAcl
!
!
! ====================== Tunnel Gruppe =======================================
!
!tunnel-group vpn-remoteuser type remote-access
!
tunnel-group vpn-remoteuser type ipsec-ra
tunnel-group vpn-remoteuser general-attributes
address-pool vpn-pool
default-group-policy vpn-remoteuser
!
tunnel-group vpn-remoteuser ipsec-attributes
pre-shared-key vpn-psk

 

Ich hoffe mir kann jemand erklären, was ich falsch gemacht habe.

[-= Brummbär =- 10]

Langsam verzweifel ich an der Geschichte. Hat niemand eine Idee warum es hakt?

[Wordo 11]

Das Testgeraet hat auch die ASA als Defaultgateway? Schon mal einen Capture auf der ASA gemacht und schaut ob intern die Antworten ankommen?

[hegl 10]

Das Einzige was mir im Vergleich zu meiner config auffällt ist, dass Du eine Standard ACL für die crypto-ACL verwendest. Teste doch einfach mal anstatt

access-list vpn-remoteuser_splitTunnelAcl standard permit 192.168.1.0 255.255.255.0

diese hier

access-list vpn-remoteuser_splitTunnelAcl extended permit ip object-group Hausnetz object-group VPN-Clients

[-= Brummbär =- 10]

Sorry das ich erst jetzt antworte. Eben ging es für einen Moment. Dann habe ich nach wr mem einen reload gemacht und das Problem ging von vorne los. Ich muss dazu sagen, dass die ASA eine höhere IOS Version eingespielt bekommen hat. Die scheint sie bei dem Reload "verloren" zu haben. Zumindest zeigte mir die ASA wieder 7.x an statt 8.0(3).

 

@ Wordo

 

Ja das Gateway ist drin. Ich hab auf der ASA den eingehenden und den ausgehenden Ping gesehen. Ohne Translating oder ähnliches. Daher hatte ich schon das split-tunneling im Visier. Merkwürdig ist, dass mein VPN-Client beim Transparent Tunneling: inactive anzeigt.

 

@ hegl

Ich meine ich hab gestern die Access-List mehrfach in verschiedensten Richtungen getestet. Es kann doch nur an dem Split liegen, oder nicht?

[hegl 10]

Sorry das ich erst jetzt antworte. Eben ging es für einen Moment. Dann habe ich nach wr mem einen reload gemacht und das Problem ging von vorne los. Ich muss dazu sagen, dass die ASA eine höhere IOS Version eingespielt bekommen hat. Die scheint sie bei dem Reload "verloren" zu haben. Zumindest zeigte mir die ASA wieder 7.x an statt 8.0(3).

Kontrolliere mit

sh run | i boot 

das boot image und korrigiere es gegebenenfalls so

boot system disk0:/asa803-k8.bin

 

@ Wordo

 

Ja das Gateway ist drin. Ich hab auf der ASA den eingehenden und den ausgehenden Ping gesehen. Ohne Translating oder ähnliches. Daher hatte ich schon das split-tunneling im Visier.

 

Wenn Du den ein-und ausgehenden Verkehr siehst, sollte doch mit split-tunneling allles ok sein...

 

Merkwürdig ist, dass mein VPN-Client beim Transparent Tunneling: inactive anzeigt.

 

Dann hast Du nat-traversal deaktiviert; zum aktivieren:

isakmp nat-traversal 10

 

@ hegl

Ich meine ich hab gestern die Access-List mehrfach in verschiedensten Richtungen getestet. Es kann doch nur an dem Split liegen, oder nicht?

 

siehe oben

[-= Brummbär =- 10]

Die Version ist jetzt die richtige.

 

Den Ping sehe ich nur auf der ASA im Debug. Er kommt scheinbar nicht am VPN-Client an, denn dieser empfängt überhaupt keine Pakete. Als es eben einmal kurzzeitig ging, stand im Client Transparent Tunneling: Active on UDP Port anstelle von inactive. Vielleicht bringt uns das ja einen Schritt weiter.

[hegl 10]

Die Version ist jetzt die richtige.

 

Den Ping sehe ich nur auf der ASA im Debug. Er kommt scheinbar nicht am VPN-Client an, denn dieser empfängt überhaupt keine Pakete. Als es eben einmal kurzzeitig ging, stand im Client Transparent Tunneling: Active on UDP Port anstelle von inactive. Vielleicht bringt uns das ja einen Schritt weiter.

 

 

siehe meinen Nachtrag oben zu nat-traversal!

[-= Brummbär =- 10]

Na toll. Jetzt bin ich an so einer ****** Zeile gescheitert. Vorab: es läuft. Zumindest macht es im Moment den Eindruck. Mal sehen, ob es nach dem nächsten Reload auch noch das tut was ich will.

 

Und ich habe auch noch im vorherigen Thread gefragt, warum ich bei meinen Configs in der PIX isakmp identity address und isakmp nat-traversal 30 stehen habe. Jetzt weiß ich zumindest, dass das zweite wichtig ist :-) Macht das erste auch Sinn?

 

Wenn ich es richtig verstehe ist nat-traversal dafür da, dass ich mit IPSec über das NAT hinweg komme.

[hegl 10]

Na toll. Jetzt bin ich an so einer ****** Zeile gescheitert. Vorab: es läuft. Zumindest macht es im Moment den Eindruck. Mal sehen, ob es nach dem nächsten Reload auch noch das tut was ich will.

 

Kontrolliere dabei auch das nat-traversal. In der 8.0.2 wars noch ein Bug, dass dieses nach einem relaod verloren ging....

 

Und ich habe auch noch im vorherigen Thread gefragt, warum ich bei meinen Configs in der PIX isakmp identity address und isakmp nat-traversal 30 stehen habe.

 

Sry, habe ich übersehen...

 

Jetzt weiß ich zumindest, dass das zweite wichtig ist :-) Macht das erste auch Sinn?

 

Standardmäßig verwendet der Tunnel FQDN als identy. Also macht es auf jeden Fall Sinn. Bin damit mal bei einer site-to-site auf die Nase gefallen....

 

Wenn ich es richtig verstehe ist nat-traversal dafür da, dass ich mit IPSec über das NAT hinweg komme.

 

So genau kann ich Dir das auch nicht erklären, aber bei NAT und VPN gibts Probleme. Also immer schön das nat-traversal konfigurieren...

 

Zur Info: http://onair.funkwerk-ec.com/brueckenschlag_zwischen_nat_und_ipsec.html

[-= Brummbär =- 10]

Das sollte kein Vorwurf sein. Ich könnt mich nur tierisch ärgern, dass es mir nicht selber aufgefallen ist. Wobei ich das mindestens einmal mit hinzugefügt habe. Aber vielleicht hat mich da der Reload getroffen. Ich teste das jetzt gleich mal in Ruhe durch.

 

Nochmals besten Dank. Jetzt bin ich schon mal wieder einen Schritt weiter.