Grundsätzliches zu ACLs auf ASA vs. IOS-Router

[Whistleblower 45]

Hi,

 

ich habe noch etwas Verständnisprobleme mit ACLs auf der ASA hinsichtlich der Richtung (in/out), an irgendeiner Stelle mache ich da einen Denkfehler und deswegen machen meine ACLs nicht das, was sie sollen. :(

Konkrete Beispiele wären z.B.

• Traffic, der von einem mobilen VPN-Client kommt (Netz 192.168.60.0/24) in das interne LAN (172.16.1.0/24) und vice versa zu erlauben
  
• ausgehenden Traffic vom internen Netz nur zu bestimmten Diensten (http, https, DNS) zuzulassen
  

 

Letzteres soll als Übung nur getestet werden, erstes muss gehen.

Internetzugriff vom LAN funktioniert soweit, das Aufbauen der Verbindung über den VPN-Client funktioniert von einem anderen Provider auch soweit.

[Stonehedge 12]

Was ist denn dein Problem? Du weißt nicht wann in und wann out? Du musst es dir einfach aus der Sicht den Ports vorstellen auf dem du die ACL anwendest.

[Otaku19 33]

bei VPN hat man halt so seine Möglichkeiten wie man das umsetzt was du möchtest, das kann man direkt an der outside ACL machen oder eben per User regeln

[hegl 10]

bei VPN hat man halt so seine Möglichkeiten wie man das umsetzt was du möchtest, das kann man direkt an der outside ACL machen oder eben per User regeln

 

Welchen Ansatz nimmst Du für "per User"?

 

Das sind so Dinger, die mir noch unter den Fingernägeln brennen. Bis dato sage ich halt über die ACL, was das VPN-Netz darf.

Per User könnte ich es konktreter definieren.

[Otaku19 33]

per user natürlich bei einem client VPN, nicht ein User der sich in einem Netz befindet das per L2L angebunden ist

[Whistleblower 45]

Grundsätzlich habe ich z.Zt. einen IOS-Router, der durch die ASA abgelöst werden soll. Somit habe ich einen Haufen an extended ACLs, die ich so leider nicht 1:1 in die ASA übernehmen kann.

 

Folgende ACLs kommen auf dem Router derzeit vor:

 

inside_rule (gebunden an vlan1:

ip access-group inside_rule out

beinhaltet u.a., welche privaten Netze auf das interne LAN zugreifen dürfen.

z.B.

permit ip 172.16.2.0 0.0.0.255 17.16.1.0 0.0.0.255

 

NAT_rule (gebunden an route-map)

Legt Ausnahmen für NAT fest (alles natten, ausser Verbindungen zw. priv. Netzen über VPN

z.B.

remark NAT-Ausnahme StandortXY
deny   ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255

 

dmz_rule (derzeit nicht genutzt, (gebunden an vlan99:

ip access-group dmz_rule out

war mal vorgesehen für Zugriff auf DMZ-VLAN

 

mgmt_rule (gebunden an vty 0 4:

ip access-group mgmt_rule in

regelt Zugriff auf den Router

 

outside_rule (gebunden an dialer1:

ip access-group outside_rule in

Welche Dienste werden von extern zugelassen

z.B.

permit esp host x.x.x.x host pubIP
permit udp host x.x.x.x host pubIP eq isakmp

 

vpn_rule01 ... vpn_rule05

diverse VPNs, regelt den Zugriff der priv. Netze untereinander

z.B.

remark NAT-Ausnahme StandortXY
permit   ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255
deny ip any any

 

Dass ich statt inversen Maske jeweils die Subnetz-Maske auf der ASA angeben muss, ist soweit auch bekannt.

Die Frage ist halt, warum geht z.B. kein Traffic von einem per VPN-Client eingewählten Client vom VPN-Client-Netz (über entsprechenden DHCP-Pool eingerichtet) zum internen Netz durch, wenn er eigentlich erlaubt sein sollte.

Dazu sollte doch eine inside-ACL und eine entsprechende NAT-ACL ausreichend sein?

 

Am besten poste ich nachher nochmal eine Konfig von der ASA, muss ich mal sehen, wie ich die entsprechend kürze, dass sie hier reinpasst... :D

[Whistleblower 45]

Bin einen Schritt weiter - Zugriff vom VPN-Client funktioniert jetzt. :)

Fehlerquelle war vermutlich noch NAT oder ACL vom Router, hinter dem der VPN-Client hing. Von einem anderen DSL-Anschluss mit SOHO-Kiste war der Zugriff problemlos möglich.

[Whistleblower 45]

Jetzt habe ich aber ein anderes konkretes Problem.

Der Router baut auch diverse L2L-VPNs auf.

Z.B.

 

NetzA: internes LAN

NetzA2: DHCP-Range VPN-Clients

 

NetzB: internes LAN zweiter Standort

 

NetzC: internes LAN dritter Standort

 

VPN1: NetzA zu NetzB

VPN2: NetzA zu NetzA2 (VPN-Clients)

VPN3: NetzA zu NetzC

 

Derzeit ist es so, dass auch Zugriff von NetzB zu NetzC über NetzA zugelassen wird, Traffic kommt also über Tunnel von NetzB rein, wird decrypted und wieder encrypted und nach NetzC geschickt.

Ähnliches ist für die VPN-Clients konfiguriert, Einwahl in NetzA und von dort über bestehende Tunnel nach NetzB und NetzC.

 

Auf dem (abzulösenden) Router habe ich dazu jeweils eine statische crypto map, mit entsprechenden Verweisen aufs ISAKMP-Profil und die ACLs, z.B.:

 

crypto map staticmap 1 ipsec-isakmp
description Tunnel zu NetzB
set peer x.x.x.x
set transform-set XYZ
set pfs-group 2
set isakmp-profile NetzBprofile
match address vpn_NetzB

crypto isakmp profile NetzBprofile
description ...
keyring NetzBkeyring
match identity address x.x.x.x 255.255.255.255

ip access-list extended vpn_NetzB
permit ip (NetzA) (NetzB)
permit ip (NetzA2) (NetzB)
permit ip (NetzB) (NetzC)
deny ip any any

 

So, wenn ich das jetzt auf die ASA übertragen will, habe ich dabei Schwierigkeiten, weil ich (zumindest wenn ich mit dem ASDM arbeite) unter den IPSec-Rules quasi immer nur eine Zuordnung der Netze angeben kann (Source/Destination). Ich kann zwar vorher Netze entsprechend zusammenfassen (z.B. NetzA und NetzA2 zu einer Gruppe und NetzB und NetzC zu einer zweiten Gruppe), aber dadurch hätte ich auch eine Beziehung NetzA2 zu NetzC, welche gar nicht gewünscht ist.

Vielleicht ist das auch nur eine Einschränkung durch den ASDM, und über die Konsole könnte ich das alte Konzept wie gewünscht umsetzen??

Ich hoffe, jemand versteht mein Problem und kann ein paar Tipps geben... :)

 

Achja, noch eine Kleinigkeit - wie kann man eigentlich an der Konsole die Ausgabe von "show run" u.ä. abbrechen, wenn man nicht bis zum Ende durchblättern will? :confused:

[Otaku19 33]

einfach q drücken bei der ausgabe, dann mochmal enter und schon kannst du wieder was eingeben

[Whistleblower 45]

einfach q drücken bei der ausgabe, dann mochmal enter und schon kannst du wieder was eingeben

 

Supi, danke für den Tipp!

Damit macht die Konsole auch gleich mehr Spass :)

 

Hab mittlerweile festgestellt, dass ich auch mehrere Regeln für die VPN-Verbindungen angeben kann. Hab's über die Konsole gemacht, und scheinbar geht's auch im ASDM - wobei ich mehr zur Konsole tendiere, da kann ich wenigstens die Nomenklatur für die ACLs beinflussen, so dass da vielleicht auch mal ein Kollege durchsteigt :D