5
Problem mit Cisco Extended ACL
Hallo,
Komme momentan mit einer ACL nicht weiter. Die Konfig schaut wie folgt aus:
Ein Cisco 2851er Router (IP: 192.168.100.1) baut für zwei VPN Gruppen die Verbindung per Cisco VPN-Client auf. Die eine Gruppe bekommt die IP 10.10.100.0/24 zugewiesen und darf in jedes Vlan hinter dem Router die zweite Gruppe bekommt die 10.10.120.0/24 und darf nur in ein bestimmtes Vlan. Die Beschränkung habe ich über eine OUT ACL gelöst, die auf dem Gi0/1 liegt welches zu dem Layer3 Switch verbindet der die internen Vlans routet. Die ACL schaut wie folgt aus:
ip access-list extended ACLVPNGROUPS
permit ip 10.10.100.0 0.0.0.255 any
permit ip 10.10.120.0 0.0.0.255 192.168.200.0 0.0.0.255
permit ip 10.10.120.0 0.0.0.255 host 192.168.100.1
deny ip 10.10.120.0 0.0.0.255 any
permit ip any any
int gi0/1
ip access-group ACLVPNGROUPS out
Das Problem ist nun das, das der Client mit der 10.10.120.0/24 eine Ressource im Vlan 192.168.200.0/24 per Ping erreicht, jedoch zb. das Webinterface der Ressource nicht erreichbar ist. ein
sh ip access-list
zeigt mir, das beim Aufruf des Webinterfaces bei "deny ip 10.10.120.0 0.0.0.255" any die matches höher zählen. Sollte aber nicht "permit ip 10.10.120.0 0.0.0.255 192.168.200.0 0.0.0.255" alles für das Vlan durchlassen?
Hat jemand eine Idee!?
Komme momentan mit einer ACL nicht weiter. Die Konfig schaut wie folgt aus:
Ein Cisco 2851er Router (IP: 192.168.100.1) baut für zwei VPN Gruppen die Verbindung per Cisco VPN-Client auf. Die eine Gruppe bekommt die IP 10.10.100.0/24 zugewiesen und darf in jedes Vlan hinter dem Router die zweite Gruppe bekommt die 10.10.120.0/24 und darf nur in ein bestimmtes Vlan. Die Beschränkung habe ich über eine OUT ACL gelöst, die auf dem Gi0/1 liegt welches zu dem Layer3 Switch verbindet der die internen Vlans routet. Die ACL schaut wie folgt aus:
ip access-list extended ACLVPNGROUPS
permit ip 10.10.100.0 0.0.0.255 any
permit ip 10.10.120.0 0.0.0.255 192.168.200.0 0.0.0.255
permit ip 10.10.120.0 0.0.0.255 host 192.168.100.1
deny ip 10.10.120.0 0.0.0.255 any
permit ip any any
int gi0/1
ip access-group ACLVPNGROUPS out
Das Problem ist nun das, das der Client mit der 10.10.120.0/24 eine Ressource im Vlan 192.168.200.0/24 per Ping erreicht, jedoch zb. das Webinterface der Ressource nicht erreichbar ist. ein
sh ip access-list
zeigt mir, das beim Aufruf des Webinterfaces bei "deny ip 10.10.120.0 0.0.0.255" any die matches höher zählen. Sollte aber nicht "permit ip 10.10.120.0 0.0.0.255 192.168.200.0 0.0.0.255" alles für das Vlan durchlassen?
Hat jemand eine Idee!?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 173656
Url: https://administrator.de/forum/problem-mit-cisco-extended-acl-173656.html
Ausgedruckt am: 23.12.2024 um 20:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
die ACL stimmt schon mal.
Blockst du an irgendeiner Stelle Ports?
Was Passiert wenn du die Maschine im 192.168.0.0 /24 scannst auf offene Ports?
Ist auf der Maschine eventuell eine Firewall aktiv?
brammer
die ACL stimmt schon mal.
Blockst du an irgendeiner Stelle Ports?
Was Passiert wenn du die Maschine im 192.168.0.0 /24 scannst auf offene Ports?
Ist auf der Maschine eventuell eine Firewall aktiv?
brammer
Servus Brammer,
danke für deine Antwort.
Also auf dem Vlan 192.168.200.0/24 is noch ne out acl drauf.
ip access-list ACLVLAN200
permit tcp 192.168.200.0 0.0.0.255 any www
permit udp 192.168.200.0 0.0.0.255 any domain
permit icmp 192.168.200.0 0.0.0.255 any
deny ip any any
deny tcp any any
deny udp any any
int vlan 200
ip access-group ACLVLAN200 out
Jedoch kann ich netzintern den Host 192.168.200.10 über HTTP aus jedem anderen Vlan erreichen.
Wenn ich die ACLVPNGROUPS runter nehme gehts komischerweise auch über den IPSec Clinent mit VPN-Gruppe 2
danke für deine Antwort.
Also auf dem Vlan 192.168.200.0/24 is noch ne out acl drauf.
ip access-list ACLVLAN200
permit tcp 192.168.200.0 0.0.0.255 any www
permit udp 192.168.200.0 0.0.0.255 any domain
permit icmp 192.168.200.0 0.0.0.255 any
deny ip any any
deny tcp any any
deny udp any any
int vlan 200
ip access-group ACLVLAN200 out
Jedoch kann ich netzintern den Host 192.168.200.10 über HTTP aus jedem anderen Vlan erreichen.
Wenn ich die ACLVPNGROUPS runter nehme gehts komischerweise auch über den IPSec Clinent mit VPN-Gruppe 2
Hallo,
die meisten Webinterfaces arbeiten mit https.
Wenn dem so ist musst du noch https (443) freigeben, www beinhaltet nur http also Port 80.
brammer
die meisten Webinterfaces arbeiten mit https.
Wenn dem so ist musst du noch https (443) freigeben, www beinhaltet nur http also Port 80.
brammer
Was noch sein kann ist das die Webseite Inhalte nachläd die nicht in dem IP Netz des Servers liegen. Dann schlägt natürlich auch die ACL zu !
deny ip 10.10.120.0 0.0.0.255 any
und
permit ip any any
Sind übrigens überflüssiger Ballast in der ACL (letzterer sogar gefährlich). Das letzte Statement der ACL ist immer ein deny any any so das du dir die o.a. Statements sinnvollerweise sparen kannst !
Gilt auch für die überflüssigen deny Statements an der VLAN 200 ACL.
Falls die ACL denn nun mit https funktioniert bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
deny ip 10.10.120.0 0.0.0.255 any
und
permit ip any any
Sind übrigens überflüssiger Ballast in der ACL (letzterer sogar gefährlich). Das letzte Statement der ACL ist immer ein deny any any so das du dir die o.a. Statements sinnvollerweise sparen kannst !
Gilt auch für die überflüssigen deny Statements an der VLAN 200 ACL.
Falls die ACL denn nun mit https funktioniert bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Vielen Dank für eure Beiträge,
ich hab das alles mal ohne ACL geprüft und ein Wireshark Protokoll erstellt. Das Modul hat nur eine HTTP Verbindung und gibt nur nur eigene Inhalte von der IP 192.168.200.10 heraus.
Nachdem ich die ACLs unverändert wie oben wieder in die Config eingetragen habe konnten sich die User der Gruppe 2 auf das Webinterface verbinden.
Eine logische Erklärung hab ich zwar nich, aber zumindest gehts nun wieder.
@aqui: die deny Statements hab ich dann auch gleich weggelassen
, danke nochmal!
ich hab das alles mal ohne ACL geprüft und ein Wireshark Protokoll erstellt. Das Modul hat nur eine HTTP Verbindung und gibt nur nur eigene Inhalte von der IP 192.168.200.10 heraus.
Nachdem ich die ACLs unverändert wie oben wieder in die Config eingetragen habe konnten sich die User der Gruppe 2 auf das Webinterface verbinden.
Eine logische Erklärung hab ich zwar nich, aber zumindest gehts nun wieder.
@aqui: die deny Statements hab ich dann auch gleich weggelassen
, danke nochmal!
