50
Cisco Netzwerk Asistent VLAN ACL Anlegen
Hallo,
Ich habe ein Cisco Catalyst 3550 Switch. Ich möchte auf diesen nun eine ACL Anlegen die in VLAN 11 jeden Zugriff auf's VLAN1 blockiert. Der Switch soll aber alles an 10.141.0.1 in VLAN1 10.141.0.0/22 routen. Nur halt die Clients sollen nicht auf die Fritzbox oder ein anderes Gerät zugreifen können.
Es geht hier um ein Gäste W-Lan. Und da möchte ich natürlich nicht das der Besuch zugreifen kann auf meine Netzwerk Freigaben und und und.
Gruß an die IT-Welt,
J Herbrich
Ich habe ein Cisco Catalyst 3550 Switch. Ich möchte auf diesen nun eine ACL Anlegen die in VLAN 11 jeden Zugriff auf's VLAN1 blockiert. Der Switch soll aber alles an 10.141.0.1 in VLAN1 10.141.0.0/22 routen. Nur halt die Clients sollen nicht auf die Fritzbox oder ein anderes Gerät zugreifen können.
Es geht hier um ein Gäste W-Lan. Und da möchte ich natürlich nicht das der Besuch zugreifen kann auf meine Netzwerk Freigaben und und und.
Gruß an die IT-Welt,
J Herbrich
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 339798
Url: https://administrator.de/contentid/339798
Printed on: April 19, 2024 at 20:04 o'clock
50 Comments
Latest comment
Moin,
na dann mach das doch einfach....
Gruß
em-pie
€dit:
und wenn du nicht weisst wie, dann lies dich hier ein.
Fahrrad fahren lernt man ja auch nicht, in dem man dabei zuschaut, wie jemand anderes mein Fahrrad fährt
na dann mach das doch einfach....
Gruß
em-pie
€dit:
und wenn du nicht weisst wie, dann lies dich hier ein.
Fahrrad fahren lernt man ja auch nicht, in dem man dabei zuschaut, wie jemand anderes mein Fahrrad fährt
Hallo,
Ich habe im Netzwerk Asistenten nur VLAN1. Die anderen VLANs habe ich aber definiert. Deswegen die Frage wie ich die ACL auf das entsprechende VLAN Anwenden kann.
Die Kommunikation mit der Fritzbox (wegen Routing) ist ja dann so wie ich es sehe nicht von der ACL betroffen weil der Switch das Default Gateway ist. Also geht es wirklich nur um das Binden der ACL an's VLAN11.
Gruß an die IT-Welt,
J Herbrich
Ich habe im Netzwerk Asistenten nur VLAN1. Die anderen VLANs habe ich aber definiert. Deswegen die Frage wie ich die ACL auf das entsprechende VLAN Anwenden kann.
Die Kommunikation mit der Fritzbox (wegen Routing) ist ja dann so wie ich es sehe nicht von der ACL betroffen weil der Switch das Default Gateway ist. Also geht es wirklich nur um das Binden der ACL an's VLAN11.
Gruß an die IT-Welt,
J Herbrich
Hallo,
Also, ich mache es jetzt einfach über die CLI. So, jetzt komme ich bei einer kleinigkeit nicht weiter. Undzwar möchte ich den kompletten Traffic ins VLAN1 blockieren. Aber Ausnahmen bestätigen die Regel. Und in meinen Fall ist die Ausnahme halt eben der UDP Port 53 den ich für die Server 10.141.0.151 und 10.141.0.19 zulassen möchte.
Wie kann ich eine ACL Anlegen die diese Ausname hat aber sonst nichts durchlässt?
Gruß an die IT-Welt,
J Herbrich
Also, ich mache es jetzt einfach über die CLI. So, jetzt komme ich bei einer kleinigkeit nicht weiter. Undzwar möchte ich den kompletten Traffic ins VLAN1 blockieren. Aber Ausnahmen bestätigen die Regel. Und in meinen Fall ist die Ausnahme halt eben der UDP Port 53 den ich für die Server 10.141.0.151 und 10.141.0.19 zulassen möchte.
Wie kann ich eine ACL Anlegen die diese Ausname hat aber sonst nichts durchlässt?
Gruß an die IT-Welt,
J Herbrich
Wie wäre es, wenn du mal kurz skizzierst, wie dein Netz aufgebaut ist?
Auch bei dir funktionieren unsere Glaskugeln nicht. Und in deinem Ausgangspost ist nicht mal ne Frage gewesen...
Wenn mich des Weiteren nicht alles täuscht (ich mag mich auch Irren, müsste jemand anderes mal zur Sicherheit noch verifizieren), ist der Cisco 3550 "nur" ein Layer3 Switch. Du willst aber auf Layer4 (Protocol-based) agieren. Wie soll ein Switch, der mit Protokollen nichts anfangen kann, entsprechende ACLs abhandeln?
Du könntest ggf. aber einen kleinen Pi/ eine VM als DNS-Server in dei VLAN11 platzieren und die ACL so anpassen, dass nur der VLAN-interne DNS-Server "nach draußen" kommunizieren darf... bedeutet dann aber auch: wird der DNS-Server kompromittiert, könnte man über diesen wieder "überall" hin... also gilt aus auch den zu härten. Vermutlich haben andere hier aber auch noch andere Ideen....
Auch bei dir funktionieren unsere Glaskugeln nicht. Und in deinem Ausgangspost ist nicht mal ne Frage gewesen...
Wenn mich des Weiteren nicht alles täuscht (ich mag mich auch Irren, müsste jemand anderes mal zur Sicherheit noch verifizieren), ist der Cisco 3550 "nur" ein Layer3 Switch. Du willst aber auf Layer4 (Protocol-based) agieren. Wie soll ein Switch, der mit Protokollen nichts anfangen kann, entsprechende ACLs abhandeln?
Du könntest ggf. aber einen kleinen Pi/ eine VM als DNS-Server in dei VLAN11 platzieren und die ACL so anpassen, dass nur der VLAN-interne DNS-Server "nach draußen" kommunizieren darf... bedeutet dann aber auch: wird der DNS-Server kompromittiert, könnte man über diesen wieder "überall" hin... also gilt aus auch den zu härten. Vermutlich haben andere hier aber auch noch andere Ideen....
Hallo,
So weit bin ich schon gekommen
Also, das Netzwerk ist recht einfach aufgebaut. Ich habe eine Fritzbox, dort hängt ein HP Procurve Switch dran. An diesen sind Server und einige AP,s angeschlossen und noch einmal ein LevelOne Switch an den die Rechner hängen und halt noch der Cisco an diesen sind meine Aironets angeschlossen.
Ich kann mich inzwischen mit den W-Lan Verbinden aber bekomme keine IP von DHCP Server. Dieser hängt im VLAN1 und ist unter der IP 10.141.0.151 zu erreichen.
Die DHCP-Requests sollen weiter geleitet werden, das habe ich in VLAN11 mit dieser Zeile auch so eingestellt.
Ich vermute mal das es an der ACL liegen könnte. Ich verstehe noch nicht so ganz ob diese auch für den Switch selber greift oder nur für Angeschlossene Geräte?
Gruß an die IT-Welt,
J Herbrich
So weit bin ich schon gekommen
interface Vlan11
ip address 10.161.0.1 255.255.252.0
ip access-group SecureJenniNet out
ip helper-address 10.141.0.151
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.141.0.1
ip http server
!
ip access-list extended SecureJenniNet
deny ip any 10.141.0.0 0.0.3.255 log
permit udp any host 10.141.0.151 eq domain
permit udp any host 10.141.0.19 eq domain
!
!Also, das Netzwerk ist recht einfach aufgebaut. Ich habe eine Fritzbox, dort hängt ein HP Procurve Switch dran. An diesen sind Server und einige AP,s angeschlossen und noch einmal ein LevelOne Switch an den die Rechner hängen und halt noch der Cisco an diesen sind meine Aironets angeschlossen.
Ich kann mich inzwischen mit den W-Lan Verbinden aber bekomme keine IP von DHCP Server. Dieser hängt im VLAN1 und ist unter der IP 10.141.0.151 zu erreichen.
Die DHCP-Requests sollen weiter geleitet werden, das habe ich in VLAN11 mit dieser Zeile auch so eingestellt.
ip helper-address 10.141.0.151Ich vermute mal das es an der ACL liegen könnte. Ich verstehe noch nicht so ganz ob diese auch für den Switch selber greift oder nur für Angeschlossene Geräte?
Gruß an die IT-Welt,
J Herbrich
Deine ACL weicht auch 180° vom Standard ab.
Grundsätzlich:
1) Die letzte Zeile ist immer ein 'deny any any'
2) Darüber lässt du dann verschiedene Sachen zu
3) Nach deiner Aussage ganz oben
Grundsätzlich:
1) Die letzte Zeile ist immer ein 'deny any any'
2) Darüber lässt du dann verschiedene Sachen zu
3) Nach deiner Aussage ganz oben
die in VLAN 11 jeden Zugriff auf's VLAN1 blockiert
brauchst du keine OUT-ACL auf VLAN11, sondern eine IN-ACL auf VLAN1, weil du Traffic von VLAN11 IN VLAN1 hinein blocken willst
Hallo,
Ok vielen dank für die Hilfe. Werde es gleich änern. Und die Clear Rule habe ich nach unten verschoben. Aber wen die ACL auch auf dem Switch greift; wie mache ich das mit den Routing?
Gruß an die IT-Welt,
J Herbrich
Ok vielen dank für die Hilfe. Werde es gleich änern. Und die Clear Rule habe ich nach unten verschoben. Aber wen die ACL auch auf dem Switch greift; wie mache ich das mit den Routing?
Gruß an die IT-Welt,
J Herbrich
Die ACL greift nur auf deinem Switch.
Ich denke, das Konzept ist nicht ganz klar, du willst mit deinem 3550er routen, also brauchst du vornedran einen DHCP-Server, auf welchem man mehrere Scopes anlegen kann, was die Fritzbox nicht kann.
Die Fritzbox hat nur eine interne Firewall, um eine Client-Isolation zwischen LAN und Gastnetz aufzubauen, eigentlich das, was du mit dem 3550er obendrauf nochmal erzwingen willst.
Ich denke, das Konzept ist nicht ganz klar, du willst mit deinem 3550er routen, also brauchst du vornedran einen DHCP-Server, auf welchem man mehrere Scopes anlegen kann, was die Fritzbox nicht kann.
Die Fritzbox hat nur eine interne Firewall, um eine Client-Isolation zwischen LAN und Gastnetz aufzubauen, eigentlich das, was du mit dem 3550er obendrauf nochmal erzwingen willst.
Hallo,
Ok, ich habe jetzt die config korregiert
Gruß an die IT-Welt,
J Herbrich
Ok, ich habe jetzt die config korregiert
interface Vlan11
ip address 10.161.0.1 255.255.252.0
ip access-group SecureJenniNet in
ip helper-address 10.141.0.151
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.141.0.1
ip http server
!
ip access-list extended SecureJenniNet
permit udp any host 10.141.0.151 eq domain
permit udp any host 10.141.0.19 eq domain
deny ip any 10.141.0.0 0.0.3.255 log
!
!Gruß an die IT-Welt,
J Herbrich
Nein, die ACL muss VLAN1 IN, nicht 11 ;)
Bau mal einen Netzplan, was du genau vorhast.
Bau mal einen Netzplan, was du genau vorhast.
Hallo,
Ja das weiß ich auch. Die Fritzbox hat den DHCP ja auch aus. Ein Windows Server 2016 kümmert sich um die DHCP Dienste Und auf diesen wird ja auch die DHCP Anfrage weiter geleitet. So ist zumindest der Plan.
Ja, ist mir auch bekannt. Das Problem ist nur das ich ein Kabel zur Frite verlegt habe und da die Telefondose nicht im Serverraum steht wird's schwierig ein zweites Kabel zum Switch zu kriegen :/
Wie heißt das DHCP Protokoll in Cisco Netzwerk Assistenten? hostname oder?
<edit>
Ahso ok. Ich denke ich muss mich echt noch besser in Cisco einarbeiten.
</edit>
Gruß an die IT-Welt,
J Herbrich
Ich denke, das Konzept ist nicht ganz klar, du willst mit deinem 3550er routen, also brauchst du vornedran einen DHCP-Server, auf welchem man mehrere Scopes anlegen kann, was die Fritzbox nicht kann.
Ja das weiß ich auch. Die Fritzbox hat den DHCP ja auch aus. Ein Windows Server 2016 kümmert sich um die DHCP Dienste
Und auf diesen wird ja auch die DHCP Anfrage weiter geleitet. So ist zumindest der Plan.Die Fritzbox hat nur eine interne Firewall, um eine Client-Isolation zwischen LAN und Gastnetz aufzubauen, eigentlich das, was du mit dem 3550er obendrauf nochmal erzwingen willst.
Ja, ist mir auch bekannt. Das Problem ist nur das ich ein Kabel zur Frite verlegt habe und da die Telefondose nicht im Serverraum steht wird's schwierig ein zweites Kabel zum Switch zu kriegen :/
Wie heißt das DHCP Protokoll in Cisco Netzwerk Assistenten? hostname oder?
<edit>
Nein, die ACL muss VLAN1 IN, nicht 11 ;)
Ahso ok. Ich denke ich muss mich echt noch besser in Cisco einarbeiten.
</edit>
Gruß an die IT-Welt,
J Herbrich
Ok, jetzt habe ich mich ausgespeert. Hilft nichts, ich muss an die Konsole ran :/
Gruß an die IT-Welt,
J Herbrich
Gruß an die IT-Welt,
J Herbrich
Hallo,
DHCP Protocol
http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation ...
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configurat ...
Gruß,
Peter
DHCP Protocol
http://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation ...
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configurat ...
Also, das Netzwerk ist recht einfach aufgebaut
Nicht reden, malen. male dein "Recht einfaches netzwerk" doch auf papier, trage jeden belegten Port und Gerät ein, trage ebenfalls die vergebenen IPs Masken, Gateways ein und stelle das dann hir rein. Deine Beschreibung deines einfachen Netzes kann wirklich keine genaustens nachvollziehen und bei deine ganzen Konfig-Änderungen blickt auch keiner mehr durch was du denn nun hast oder nicht hast. Gruß,
Peter
<offtopic>
Kennt jemand ein freeware tool dafür? Der CNA zeigt nur die Cisco geräte :/
</offtopic>
Gruß an die IT-Welt,
J Herbrich
Kennt jemand ein freeware tool dafür? Der CNA zeigt nur die Cisco geräte :/
</offtopic>
Gruß an die IT-Welt,
J Herbrich
Hallo,
Nennt sich Papier und Bleistift
Gruß,
Peter
Nennt sich Papier und Bleistift
Der CNA zeigt nur die Cisco geräte
Dann Schreib FritzBox oder HP Procurve Switch oder levelOne und deren bezeichnungen dran Gruß,
Peter
Jopp...
Schau mal auf deinem Desktop nach den Apps
Habe damit gute Erfahrungen gemacht. Kostet nichts und lässt sich leicht bedienen
Schau mal auf deinem Desktop nach den Apps
- Pencil
- Paper
- Camera
Habe damit gute Erfahrungen gemacht. Kostet nichts und lässt sich leicht bedienen
Hallo,
So, ich habe das ganze Netzwerk jetzt grafisch dargestellt.
Die Aironets haben eine SSID Gast, die geht ins VLAN11. Und das VLAN11 wird nur auf den Cisco Switch geroutet (Layer-3 Routing hat er^^) und soll dann durch das VLAN1 ins Internet (also zur Fritzbox). Ich möchte jedoch nicht dass man von VLAN11 auf Dienste (außer DNS) in VLAN1 zugreifen kann. (Was der Cisco Netzwerk Assistent auch in seinen ACL,s anbietet, dort heißt dns halt domain).
Was muss ich in der Inbound ACL in VLAN1 einstellen dass nur alles aus VLAN11 geblockt wird? Ich habe als Quelle 10.161.0.0 und die Wildcard 0.0.3.255 (also 22.er Subnetz) eingestellt und als Destination im Grunde genommen das selbe nur mit 10.141.0.0 0.0.3.255 .
Gruß an die IT-Welt,
J Herbrich
So, ich habe das ganze Netzwerk jetzt grafisch dargestellt.
Die Aironets haben eine SSID Gast, die geht ins VLAN11. Und das VLAN11 wird nur auf den Cisco Switch geroutet (Layer-3 Routing hat er^^) und soll dann durch das VLAN1 ins Internet (also zur Fritzbox). Ich möchte jedoch nicht dass man von VLAN11 auf Dienste (außer DNS) in VLAN1 zugreifen kann. (Was der Cisco Netzwerk Assistent auch in seinen ACL,s anbietet, dort heißt dns halt domain).
Was muss ich in der Inbound ACL in VLAN1 einstellen dass nur alles aus VLAN11 geblockt wird? Ich habe als Quelle 10.161.0.0 und die Wildcard 0.0.3.255 (also 22.er Subnetz) eingestellt und als Destination im Grunde genommen das selbe nur mit 10.141.0.0 0.0.3.255 .
Gruß an die IT-Welt,
J Herbrich
Hmm... drei Dinge fallen mir auf, bei denen ich dachte, dass du sie - aufgrund deiner schon längeren Zeit hier - mittlerweile wüsstest...
Folgende ToDos also für dich:
- Es fehlt an sämtlichen Informationen zum Thema VLAN. Ich gehe mal davon aus, dass dein VLAN 1 zwischen dem Routerboard und dem Pi hängt!?
- Ein Netzwerk, welches bei 16 Devices nur 5 IP-Adressen aufweist... vermutlich kommunizieren die übrigen über Rauchsignale und die Router wissen anhand der Dichte, welcher Rechner seine Pakete gerade wohin senden möchte...
- Wenn du das Bild noch ein wenig kleiner machst, ist es gut anonymisiert...
Folgende ToDos also für dich:
- ergänze bitte mal, was in welchem VLAN hängt
- schreibe an alle relevanten Devices eine IP-Adresse...
- Stelle das Bild in einer lesbaren Qualität ein. Es müssen ja keine 20MP sein, aber etwas mehr als das jetzige darf es schon sein...
Hallo,
Alles hängt in VLAN1 (Native VLAN). Der Cisco Switch und die Aironets haben VLAN11 als Trunk.
Na klar hat jeder Host im Netzwerk seine eigene IP
Mein momentanes Problem ist ich bekomme leider keine IP von DHCP. Ich habe die ip helper adress configuriert auf den DHCP Server (10.141.0.151) in VLAN1. Wen ich die IP des VLAN,s eingebe (10.161.0.1) komme ich auf den Switch drauf. Also das VLAN Routing funktioniert ja schon mal (ist ja auch nicht so schwer^^) also müsste der Cisco doch die DHCP weiterleiten können?
Gruß an die IT-Welt,
J Herbrich
Alles hängt in VLAN1 (Native VLAN). Der Cisco Switch und die Aironets haben VLAN11 als Trunk.
Ein Netzwerk, welches bei 16 Devices nur 5 IP-Adressen aufweist... vermutlich kommunizieren die übrigen über Rauchsignale und die Router wissen anhand der Dichte, welcher Rechner seine Pakete gerade wohin senden möchte...
Na klar hat jeder Host im Netzwerk seine eigene IP
Mein momentanes Problem ist ich bekomme leider keine IP von DHCP. Ich habe die ip helper adress configuriert auf den DHCP Server (10.141.0.151) in VLAN1. Wen ich die IP des VLAN,s eingebe (10.161.0.1) komme ich auf den Switch drauf. Also das VLAN Routing funktioniert ja schon mal (ist ja auch nicht so schwer^^) also müsste der Cisco doch die DHCP weiterleiten können?
Gruß an die IT-Welt,
J Herbrich
Hallo,
Also mein Problem ist dass obowhl ich in conf t service dhcp eingegeben habe taucht dieser nicht in der running-config (show running-config) auf. Also scheint der Switch wohl aus irgendeinem Grund kein DHCP machen zu wollen. Hat jemand eine Idee?
Gruß an die IT-Welt,
J Herbrich
Also mein Problem ist dass obowhl ich in conf t service dhcp eingegeben habe taucht dieser nicht in der running-config (show running-config) auf. Also scheint der Switch wohl aus irgendeinem Grund kein DHCP machen zu wollen. Hat jemand eine Idee?
Gruß an die IT-Welt,
J Herbrich
Um dir bei deiner ACL zu helfen, wäre es aber schon schön zu wissen, welche IP z.B. deine Fritte hat...
Denn im am 3550 musst du ja Inboud quasi alle Pakete verbieten, bis auf die zur Fritzbox
Denn wenn dein Cisco den DHCP-Request anfragt, fragt er für eine IP für 10.141.0.0/22 an (wie viele Gäste erwartest du eigentlich? für 1000 Gäste ist deine Hardware vermutlich nicht latent genug...). Wenn dein DHCP-Server aber keinen Scope für den Bereich 10.141.0.0/22 hat, word das nichts...
Wäre so, als wenn du bei Kabel BaWü eine Rufnummer für Köln anfragst, Kabel BaWü für dort für Köln keine Rufnummern verwalten kann (/darf)...
Denn im am 3550 musst du ja Inboud quasi alle Pakete verbieten, bis auf die zur Fritzbox
Mein momentanes Problem ist ich bekomme leider keine IP von DHCP.
Hast du auf dem DHCP-Server denn auch einen Bereich für das VLAN11 eingerichtet?Denn wenn dein Cisco den DHCP-Request anfragt, fragt er für eine IP für 10.141.0.0/22 an (wie viele Gäste erwartest du eigentlich? für 1000 Gäste ist deine Hardware vermutlich nicht latent genug...). Wenn dein DHCP-Server aber keinen Scope für den Bereich 10.141.0.0/22 hat, word das nichts...
Wäre so, als wenn du bei Kabel BaWü eine Rufnummer für Köln anfragst, Kabel BaWü für dort für Köln keine Rufnummern verwalten kann (/darf)...
Hallo,
Dann schreibe die auch dazu inklusiver deiner etwas doch sehr merkürdiger Netzwerkmaske sofern die von 255.255.255.0 (CIDR /24) abweicht. Auch was als gateway eingestellt ist nicht unerheblich zu wissen. Ebenson wo ist dein mehrmals erwähnter DHCP Server. Du machst jedem wirklich schwer dir zu helfen.
Gruß,
Peter
Dann schreibe die auch dazu inklusiver deiner etwas doch sehr merkürdiger Netzwerkmaske sofern die von 255.255.255.0 (CIDR /24) abweicht. Auch was als gateway eingestellt ist nicht unerheblich zu wissen. Ebenson wo ist dein mehrmals erwähnter DHCP Server. Du machst jedem wirklich schwer dir zu helfen.
DHCP Server (10.141.0.151) in VLAN1.
Wo ist der denn? Ich seh nur nen 0.191 und nen 0.19Wen ich die IP des VLAN,s
Ein VLAN hat eine IP? Wow - ganz was neues.eingebe (10.161.0.1) komme ich
Wo kommt das denn plötzlich her?Also das VLAN Routing funktioniert ja schon mal (ist ja auch nicht so schwer^^)
Dann sollte doch alles bei dir nun laufen, oder?also müsste der Cisco doch die DHCP weiterleiten können?
Schau in dessen Protokolle oder Logs was der sagt. Kommt beim DHCP Server die Anfrage an, wohin geht dessen Antwort?Gruß,
Peter
Hallo,
VLAN1 = 10.141.0.0/22
VLAN11 = 10.161.0.0/22
Die Fritzbox hat die IP 10.141.0.1
Der DHCP Server (Windows) hat die IP 10.141.0.151
Auf den DHCP ist der SCOPE für 10.161.0.0/22 (VLAN11) ja auch eingerichtet. Gut, Ping zwischen den VLANS klappt auch alles (ACL werde ich implementieren wen alles läuft). Also so wie ich es verstehe müsste der Windows DHCP Server ja das Relay Packet annehmen und dann eine Konfiguration für das Subnetz des VLAN11 zurück senden (DHCP Option 82)?
Gruß an die IT-Welt,
J Herbrich
VLAN1 = 10.141.0.0/22
VLAN11 = 10.161.0.0/22
Die Fritzbox hat die IP 10.141.0.1
Der DHCP Server (Windows) hat die IP 10.141.0.151
Auf den DHCP ist der SCOPE für 10.161.0.0/22 (VLAN11) ja auch eingerichtet. Gut, Ping zwischen den VLANS klappt auch alles (ACL werde ich implementieren wen alles läuft). Also so wie ich es verstehe müsste der Windows DHCP Server ja das Relay Packet annehmen und dann eine Konfiguration für das Subnetz des VLAN11 zurück senden (DHCP Option 82)?
Gruß an die IT-Welt,
J Herbrich
Hallo,
Was willst du denn machen? Du hast doch einen DHCP Server oder nicht?
Gruß,
Peter
Was willst du denn machen? Du hast doch einen DHCP Server oder nicht?
Also scheint der Switch wohl aus irgendeinem Grund kein DHCP machen zu wollen. Hat jemand eine Idee?
Warum soll ein Switch der auch DHCP Server machen kann sich weigern seinen DHCP Server anzuschmeißen wenn der soweit korrekt Konfiguriert wird?Gruß,
Peter
Hallo,
Der DHCP Dienst muss ja auch für den dhcp relay betrieb laufen oder nicht? Ich habe ja für VLAN11 die richtige DHCP (helper ip) eingegeben). In Windows Log steht das 2 Geräte in Quarantäne sind warum auch immer aber ansonsten nichts interessantes.
Gruß an die IT-Welt,
J Herbrich
Der DHCP Dienst muss ja auch für den dhcp relay betrieb laufen oder nicht? Ich habe ja für VLAN11 die richtige DHCP (helper ip) eingegeben). In Windows Log steht das 2 Geräte in Quarantäne sind warum auch immer aber ansonsten nichts interessantes.
Gruß an die IT-Welt,
J Herbrich
WER soll denn nun DHCP-Server bei dir spielen? Switch oder Windows-Server?
Schicke mal für die richtige Antwort auf diese Frage dann die entsprechende Switchconfig mit. Also wenn der Switch DHCP machen soll, dann eben die Parameter, die du dafür eingedaddelt hast. Wenn es der WIndow-Server übernehmen soll, dann eben die Parameter für das DHCP-Relaying (ip helper-adress) auf dem Switch.
Mal ein grundsätzlich gut gemeinter Rat:
Wenn du ein Problem hast, dann
€dit:
Und aktualisiere jetzt bitte mal die obige Zeichnung von dir.... das ist ja grauselig....
Schicke mal für die richtige Antwort auf diese Frage dann die entsprechende Switchconfig mit. Also wenn der Switch DHCP machen soll, dann eben die Parameter, die du dafür eingedaddelt hast. Wenn es der WIndow-Server übernehmen soll, dann eben die Parameter für das DHCP-Relaying (ip helper-adress) auf dem Switch.
Mal ein grundsätzlich gut gemeinter Rat:
Wenn du ein Problem hast, dann
- Poste eingangs alle relevanten Informationen
- Schildere dein Problem
- Schildere was du bereits "genau" gemacht hast (oder auch nicht gemacht hast)
- Nehme die Rückmeldungen der Helfenden hier "ernst" und liefere alles ab, was die von dir wissen möchten und schiebe nicht alles in 28 Posts kleckerweise nach. Das macht das alles etwas unübersichtlich und man verliert zudem den roten faden
- Und lass dir nicht alles aus der Nase herausziehen...
€dit:
Und aktualisiere jetzt bitte mal die obige Zeichnung von dir.... das ist ja grauselig....
Hallo,
Was ich bis her gemacht habe.
1. Auf der Fritzbox (10.141.0.1) in VLAN1 eine Route zum Switch eingerichtet (10.161.0.0 255.255.252.0 10.141.0.40)
2. Auf den Cisco VLAN11 eingerichtet und den VLAN die IP 10.161.0.1 zugewiesen
3. Auf den Windows Server eine neue DHCP Scope angelegt
4. Auf den Switch (10.141.0.40) für VLAN11 das DHCP Relay konfiguriert
Hier mal meine komplette Config von Switch
Gruß an die IT-Welt,
J Herbrich
Was ich bis her gemacht habe.
1. Auf der Fritzbox (10.141.0.1) in VLAN1 eine Route zum Switch eingerichtet (10.161.0.0 255.255.252.0 10.141.0.40)
2. Auf den Cisco VLAN11 eingerichtet und den VLAN die IP 10.161.0.1 zugewiesen
3. Auf den Windows Server eine neue DHCP Scope angelegt
4. Auf den Switch (10.141.0.40) für VLAN11 das DHCP Relay konfiguriert
Hier mal meine komplette Config von Switch
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname w37-karow
!
enable secret 5 XXXXXXXXXXXXXXXXXXX
enable password 1234
!
ip subnet-zero
ip routing
ip dhcp relay information option
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
!
!
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/2
switchport mode dynamic desirable
!
interface FastEthernet0/3
switchport mode dynamic desirable
!
interface FastEthernet0/4
switchport mode dynamic desirable
!
interface FastEthernet0/5
switchport mode dynamic desirable
!
interface FastEthernet0/6
switchport mode dynamic desirable
!
interface FastEthernet0/7
switchport mode dynamic desirable
!
interface FastEthernet0/8
switchport mode dynamic desirable
!
interface FastEthernet0/9
switchport mode dynamic desirable
!
interface FastEthernet0/10
switchport mode dynamic desirable
!
interface FastEthernet0/11
switchport mode dynamic desirable
!
interface FastEthernet0/12
switchport mode dynamic desirable
!
interface FastEthernet0/13
switchport mode dynamic desirable
!
interface FastEthernet0/14
switchport mode dynamic desirable
!
interface FastEthernet0/15
switchport mode dynamic desirable
!
interface FastEthernet0/16
switchport mode dynamic desirable
!
interface FastEthernet0/17
switchport mode dynamic desirable
!
interface FastEthernet0/18
switchport mode dynamic desirable
!
interface FastEthernet0/19
switchport mode dynamic desirable
!
interface FastEthernet0/20
switchport mode dynamic desirable
!
interface FastEthernet0/21
switchport mode dynamic desirable
!
interface FastEthernet0/22
switchport mode dynamic desirable
!
interface FastEthernet0/23
switchport mode dynamic desirable
!
interface FastEthernet0/24
switchport mode dynamic desirable
!
interface GigabitEthernet0/1
switchport mode dynamic desirable
!
interface GigabitEthernet0/2
switchport mode dynamic desirable
!
interface Vlan1
ip address 10.141.0.40 255.255.252.0
!
interface Vlan11
ip address 10.161.0.1 255.255.252.0
ip helper-address 10.141.0.151
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.141.0.1
ip http server
!
ip access-list extended SecureJenniNet
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
permit udp host 10.161.0.1 10.141.0.0 0.0.3.255
permit tcp host 10.161.0.1 10.141.0.0 0.0.3.255
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
!
!
snmp-server community public RO
!
line con 0
exec-timeout 0 0
line vty 0 4
password 1234
login
line vty 5 15
password 1234
login
!
endGruß an die IT-Welt,
J Herbrich
Ich habe jetzt noch mal die Netzwerk Map etwas überarbeitet
Soo, 28 Posts später, fernab von deiner eigentliche Frage:
Dein catalyst hat zwei eine IP im VLAN 11, aber es gibt kein Interface, welches auch im VLAN 11 hängt..
Bisher gibt es nur den FE0/1, der als Porttype Trunk definiert hat. aber dort ist nicht definiert, welche VLANs er darüber taggen soll
Daraus schließe ich, dass deine 3 APs selbst zwar am Switch via VLAN1 erreichbar sind, aber mehr auch nicht. Die Pakete, die via VLAN11 über die entsprechede SSID versendet werden sollen, bleiben auf den APs, da der Switch an den AP-Ports alles verwirft, was nicht VLAN 1 ist..
Deine Gast-Clients sind also am AP gestrandet bzw. von der einsamen Insel nie weggekommen...
Stelle also alle Port auf TRUNK-MODE um, an denen deine APs hängen und füge die Ports als tagged dem VLAN 11 zusätzlich hinzu..
Danach sehen wir mal weiter
€dit: kleine Wissenkorrektur. Alle Ports handeln mit dem Partner aus, ob sie als Access oder Trunk verwendet werden sollen. In meinen Augen ein Sicherheits-Leck... setze alle auf Access und nur die Ports mit den APs auf Trunk...
Dein catalyst hat zwei eine IP im VLAN 11, aber es gibt kein Interface, welches auch im VLAN 11 hängt..
Bisher gibt es nur den FE0/1, der als Porttype Trunk definiert hat. aber dort ist nicht definiert, welche VLANs er darüber taggen soll
Daraus schließe ich, dass deine 3 APs selbst zwar am Switch via VLAN1 erreichbar sind, aber mehr auch nicht. Die Pakete, die via VLAN11 über die entsprechede SSID versendet werden sollen, bleiben auf den APs, da der Switch an den AP-Ports alles verwirft, was nicht VLAN 1 ist..
Deine Gast-Clients sind also am AP gestrandet bzw. von der einsamen Insel nie weggekommen...
Stelle also alle Port auf TRUNK-MODE um, an denen deine APs hängen und füge die Ports als tagged dem VLAN 11 zusätzlich hinzu..
Danach sehen wir mal weiter
€dit: kleine Wissenkorrektur. Alle Ports handeln mit dem Partner aus, ob sie als Access oder Trunk verwendet werden sollen. In meinen Augen ein Sicherheits-Leck... setze alle auf Access und nur die Ports mit den APs auf Trunk...
Hallo,
Ja das leck ist mir bekannt. Stichwort Böse Defaults
Ich habe ja erst angefangen den Switch einzurichten.
Also gut, ich habe jetzt auf den 802.1q Trunk umgestellt (was ISL ist weiß ich nicht genau, ich denke mal das ist ein Properitärer kram von Cisco (könnte auch gehen aber 802.1q ist besser weil das geht definitiv). Gut, nun zur eigentlichen Frage: Wie muss jetzt die ACL aussehen das man ins Internet kommt und die DNS Server benutzen kann aber sonst nichts aus VLAN1??
Aber auf die Idee mir die Trunks anzuschauen hätte ich ja auch selber kommen können. Ich glaube ich muss die Cisco Sprache mal lernen :D
Gruß an die IT-Welt,
J Herbrich
Ja das leck ist mir bekannt. Stichwort Böse Defaults
Ich habe ja erst angefangen den Switch einzurichten.Also gut, ich habe jetzt auf den 802.1q Trunk umgestellt (was ISL ist weiß ich nicht genau, ich denke mal das ist ein Properitärer kram von Cisco (könnte auch gehen aber 802.1q ist besser weil das geht definitiv). Gut, nun zur eigentlichen Frage: Wie muss jetzt die ACL aussehen das man ins Internet kommt und die DNS Server benutzen kann aber sonst nichts aus VLAN1??
Aber auf die Idee mir die Trunks anzuschauen hätte ich ja auch selber kommen können. Ich glaube ich muss die Cisco Sprache mal lernen :D
Gruß an die IT-Welt,
J Herbrich
Also geht der DHCP-Krempel nun?
Zum Thema ACL:
Lies dir das Dokument mal durch:
http://www.w3service.net/ccna_zertifizierung/INFOs/sem2/Access-Listen-0 ...
Dann zum logischen Aufbau:
Du willst/ solltest alles Inbound reglementieren. Was auch sinniger ist, da es die Pakete abgreift, bevor diese überhaupt am Routing-Process ankommen..
Wenn es eingehend ist. Kommst du immer VON deinem VLAN 11 (also dein übergroßes 161er Netz) und willst immer in andere VLANS reglementieren:
Der Weg fürs Internet:
Source: 10.161.0.0/22
Destination: 10.141.0.1/22
Protocol: Any
Port: Any
Restriction Permit
Der Weg fürs DNS:
Dann:
Source: 10.161.0.0/22
Destination: 10.141.0.1/22
Protocol: UDP
Port: 53
Restriction Permit
Zu Guter letzt:
Source: Any
Destination: Any
Protocol: Any
Port: Any
Restriction: Deny
ACL falsch, s.u.
Das an dein VLAN 11 angeheftet und es sollte alles klappen
Vom Grundsatz her empfinde ich dein Konstrukt aber für sicherheitstechnisch bedebklich:
Deine Gäste passieren immer dein produktives Netz.
Schließe ich zufällig einen Router an deinen Catalyst an, mit der IP 10.141.0.1/22 ist die Chance vermutlich recht hoch, dass alle Anfragen bei mir ankommen... danach fange ich mal an, einfach dein Netz auf den Kopf zu stellen...
Fertig...
Zum Thema ACL:
Lies dir das Dokument mal durch:
http://www.w3service.net/ccna_zertifizierung/INFOs/sem2/Access-Listen-0 ...
Dann zum logischen Aufbau:
Du willst/ solltest alles Inbound reglementieren. Was auch sinniger ist, da es die Pakete abgreift, bevor diese überhaupt am Routing-Process ankommen..
Wenn es eingehend ist. Kommst du immer VON deinem VLAN 11 (also dein übergroßes 161er Netz) und willst immer in andere VLANS reglementieren:
Der Weg fürs Internet:
Source: 10.161.0.0/22
Destination: 10.141.0.1/22
Protocol: Any
Port: Any
Restriction Permit
Der Weg fürs DNS:
Dann:
Source: 10.161.0.0/22
Destination: 10.141.0.1/22
Protocol: UDP
Port: 53
Restriction Permit
Zu Guter letzt:
Source: Any
Destination: Any
Protocol: Any
Port: Any
Restriction: Deny
ACL falsch, s.u.
Das an dein VLAN 11 angeheftet und es sollte alles klappen
Vom Grundsatz her empfinde ich dein Konstrukt aber für sicherheitstechnisch bedebklich:
Deine Gäste passieren immer dein produktives Netz.
Schließe ich zufällig einen Router an deinen Catalyst an, mit der IP 10.141.0.1/22 ist die Chance vermutlich recht hoch, dass alle Anfragen bei mir ankommen... danach fange ich mal an, einfach dein Netz auf den Kopf zu stellen...
- Packe den Catalyst und die Fritte in ein Transfernetz (30er Maske, VLAN 2), aber neuer IP-Kreis
- Dein Produktives Netz kannst du da belassen wo es ist, gibst jedoch dem Catalyst die 10.141.0.1/22 (warum auch hier so ein risieges Netz?)
- Gäste belässt du auch im VLAN 11, wobei die Fritte DNS spielt.. die Gste brauchen vermutlich nicht auf DNS-Einträge deines Windows-Servers zugreifen, oder?
Fertig...
Hallo,
Ok, ich habe mich mal schlau gemacht. Als letzte (unsichtbare) regel bei den ACL,s gilt immer als verweigern. Deswegen habe ich mich auch ausgespeert. Und ja ich habe als erste die ACL in VLNA11 angeheftet aber mir wurde gesagt es mache mehr sinn dass alles im VLAN1 inbound zu handhaben.
Was mich jetzt interessiert ist: Wie kann ich oder kann ich das überhaupt über die ACL verhindern das die Gäste auf die Oberfläche der Fritzbox raufkommen?
Kann man in der ACL zwischen einen Paket das Geroutet werden soll und einen Packet das direkt an die Fritzbox addresiert ist unterscheiden?
Ja, geht alles nur halt doch etwas zu gut. Momentan kann ich noch von Gästenetz schön im Internen Netz rumsurfen und dass gilt es jetzt anzupacken Noch ist das Gästenetz mit einen WPA2 Key gesichert.
Gruß an die IT-Welt,
J Herbrich
Ok, ich habe mich mal schlau gemacht. Als letzte (unsichtbare) regel bei den ACL,s gilt immer als verweigern. Deswegen habe ich mich auch ausgespeert. Und ja ich habe als erste die ACL in VLNA11 angeheftet aber mir wurde gesagt es mache mehr sinn dass alles im VLAN1 inbound zu handhaben.
Was mich jetzt interessiert ist: Wie kann ich oder kann ich das überhaupt über die ACL verhindern das die Gäste auf die Oberfläche der Fritzbox raufkommen?
Kann man in der ACL zwischen einen Paket das Geroutet werden soll und einen Packet das direkt an die Fritzbox addresiert ist unterscheiden?
Also geht der DHCP-Krempel nun?
Ja, geht alles nur halt doch etwas zu gut. Momentan kann ich noch von Gästenetz schön im Internen Netz rumsurfen und dass gilt es jetzt anzupacken
Noch ist das Gästenetz mit einen WPA2 Key gesichert.Gruß an die IT-Welt,
J Herbrich
Habe oben einen Gedankenfehler gehabt (markiere ich auch gleich)...
Die ACLs oben sind völlig daneben..
Mit der obigen Regel kommst du quasi nur auf die Fritte und den DNS-Server
Deine Gäste sollen ja NICHT in dein produktives LAN..
Daher müsste es eigentlich wie folgt sein (auch in dieser Reihenfolge)
Der Weg fürs DNS:
Source: 10.161.0.0/22
Destination: 10.141.0.151/22
Protocol: UDP
Port: 53
Restriction Permit
Verbot für den Rest:
Source: 10.161.0.0/22
Destination: 10.141.0.0/22
Protocol: Any
Port: Any
Restriction Deny
Der Weg fürs Internet:
Source: Any
Destination: Any
Protocol: Any
Port: Any
Restriction: permit
Denn, wenn man sich ein TCP/IP-Paket anschaut, steht als Ziel ja nicht die Fritte drin, sondern die des zu erreichendes Gegenübers...
€dit: Wobei man bei der letzten ACL sich überlegen sollte, welche Dienste nur nach draußen dürfen (80, 443, 465, 587, 995, 110)
Ja, geht alles nur halt doch etwas zu gut. Momentan kann ich noch von Gästenetz schön im Internen Netz rumsurfen und dass gilt es jetzt anzupacken Noch ist das Gästenetz mit einen WPA2 Key gesichert.
Und was haben Äpfel jetzt mit Birnen zu tun?
Mit einer Umstellung von WPA2 auf WPA2 Enterprise/ 802.1x verhinderst du aber nicht, dass die Clients nach erhaltener IP ins prod. LAN dürfen
Die ACLs oben sind völlig daneben..
Mit der obigen Regel kommst du quasi nur auf die Fritte und den DNS-Server
Deine Gäste sollen ja NICHT in dein produktives LAN..
Daher müsste es eigentlich wie folgt sein (auch in dieser Reihenfolge)
Der Weg fürs DNS:
Source: 10.161.0.0/22
Destination: 10.141.0.151/22
Protocol: UDP
Port: 53
Restriction Permit
Verbot für den Rest:
Source: 10.161.0.0/22
Destination: 10.141.0.0/22
Protocol: Any
Port: Any
Restriction Deny
Der Weg fürs Internet:
Source: Any
Destination: Any
Protocol: Any
Port: Any
Restriction: permit
Denn, wenn man sich ein TCP/IP-Paket anschaut, steht als Ziel ja nicht die Fritte drin, sondern die des zu erreichendes Gegenübers...
€dit: Wobei man bei der letzten ACL sich überlegen sollte, welche Dienste nur nach draußen dürfen (80, 443, 465, 587, 995, 110)
Also geht der DHCP-Krempel nun?
Ja, geht alles nur halt doch etwas zu gut. Momentan kann ich noch von Gästenetz schön im Internen Netz rumsurfen und dass gilt es jetzt anzupacken Noch ist das Gästenetz mit einen WPA2 Key gesichert.
Mit einer Umstellung von WPA2 auf WPA2 Enterprise/ 802.1x verhinderst du aber nicht, dass die Clients nach erhaltener IP ins prod. LAN dürfen
Hallo,
Ja, jetzt läuft es genau wie gewünscht. Man kann ins Internet (über 80 und 443 was effektiv verhindert das man Torrenden kann oder sonstigen mist machen kann) und man kommt nicht ins interne Netzwerk rein. Also jetzt alles bestens! Danke!
Ganz einfach, während der Einrichtung und während ich das Teste will ich nicht das jeder der zufällig ein offenes W-Lan findet sich verbinden kann mit Zugriff auf's Interne Netzwerk.
DNS geht deswegen über den Internen Server weil man Internetseiten speeren muss. (Neues Gesetz zu offenen W-Lans).
Gruß an die IT-Welt,
J Herbrich
Ja, jetzt läuft es genau wie gewünscht. Man kann ins Internet (über 80 und 443 was effektiv verhindert das man Torrenden kann oder sonstigen mist machen kann) und man kommt nicht ins interne Netzwerk rein. Also jetzt alles bestens! Danke!
Und was haben Äpfel jetzt mit Birnen zu tun?
Mit einer Umstellung von WPA2 auf WPA2 Enterprise/ 802.1x verhinderst du aber nicht, dass die Clients nach erhaltener IP ins prod. LAN dürfenGanz einfach, während der Einrichtung und während ich das Teste will ich nicht das jeder der zufällig ein offenes W-Lan findet sich verbinden kann mit Zugriff auf's Interne Netzwerk.
DNS geht deswegen über den Internen Server weil man Internetseiten speeren muss. (Neues Gesetz zu offenen W-Lans).
Gruß an die IT-Welt,
J Herbrich
Hallo,
Damit ist es kein Offenenes Netz, ausser du hast der ganzen Welt den Schlüßel gegeben.
Ein Offenens Netz ist nicht per WEP, WPA, WPA2 gesichert. Da ist nüscht und auch kein Captive Portal oder eine andere Form von Authentifizierung.
Gruß,
Peter
Zitat von @Herbrich19:
Ganz einfach, während der Einrichtung und während ich das Teste will ich nicht das jeder der zufällig ein offenes W-Lan findet sich verbinden kann mit Zugriff auf's Interne Netzwerk.
Aber du hast doch gesagtGanz einfach, während der Einrichtung und während ich das Teste will ich nicht das jeder der zufällig ein offenes W-Lan findet sich verbinden kann mit Zugriff auf's Interne Netzwerk.
Noch ist das Gästenetz mit einen WPA2 Key gesichert.
Ein Offenens Netz ist nicht per WEP, WPA, WPA2 gesichert. Da ist nüscht und auch kein Captive Portal oder eine andere Form von Authentifizierung.
DNS geht deswegen über den Internen Server weil man Internetseiten speeren muss. (Neues Gesetz zu offenen W-Lans).
Wo ist deine Quelle?Gruß,
Peter
Ohh.. wusste nicht, dass du ein öffnetliches W-LAN betreiben willst...
Na dann Prost Mahlzeit mit deiner Lösung...
dann trage ich (Gast) anstelle deines DNS-Servers einen öffentlich zugänglichen in meinen Netzwerkeinstellungen ein, gerne sogar den von google und surfe dann trotzdem die Seiten an, die ich will....
In solchen Fällen tangiert man quasi nie das Produktivnetz.
Das läuft idealweise immer vorbei an diesem (virtuell betrachtet):
Wie oben erwähnt:
€dit: eine Ergänzung noch zu oben:
Wenn du ein neues Subnet etablierst, muss immer ie ACL angefasst/ neugeschrieben werden, da du nach einer Blacklist und nicht nach einer Whitelist arbeitest. Es wäre daher vermutlich sinnvoller, den zweiten Eintrag (Verbot für prod. LAN) auf eine 8er Netzmaske zu ändern, und zusätzlich noch um die Netze 172.16.0.0/12 und 192.168.0.0/16 zu erweitern. Somit wären dann alle privaten Netze verboten....
Zwar umständlicher, aber nun gut...
Na dann Prost Mahlzeit mit deiner Lösung...
dann trage ich (Gast) anstelle deines DNS-Servers einen öffentlich zugänglichen in meinen Netzwerkeinstellungen ein, gerne sogar den von google und surfe dann trotzdem die Seiten an, die ich will....
In solchen Fällen tangiert man quasi nie das Produktivnetz.
Das läuft idealweise immer vorbei an diesem (virtuell betrachtet):
Wie oben erwähnt:
- Transfernetz etablieren
- ins Gästenetz einen transparenten SQUID o.Ä. (mit DNS) einbinden, welcher die Websites blockiert
- Des Weiteren ein Captive Portal integrieren (aquis HowTo solltest du hier finden)
- DHCP kommt direkt vom Switch oder auch von der Kiste die SQUID, CaptivePortal und DNS-(Relay) macht
€dit: eine Ergänzung noch zu oben:
Wenn du ein neues Subnet etablierst, muss immer ie ACL angefasst/ neugeschrieben werden, da du nach einer Blacklist und nicht nach einer Whitelist arbeitest. Es wäre daher vermutlich sinnvoller, den zweiten Eintrag (Verbot für prod. LAN) auf eine 8er Netzmaske zu ändern, und zusätzlich noch um die Netze 172.16.0.0/12 und 192.168.0.0/16 zu erweitern. Somit wären dann alle privaten Netze verboten....
Zwar umständlicher, aber nun gut...
Hallo,
Klar kann man einen eigenen DNS Server einstellen. Das Problem ist nur das der Cisco diese anfragen verwerfen wird da er nur TCP 80 und TCP 443 weiterleitet.
Für's Internet surfen reichen diese Ports und für mehr ist das ding auch nicht gedacht.
Gruß an die IT-Welt,
J Herbrich
Klar kann man einen eigenen DNS Server einstellen. Das Problem ist nur das der Cisco diese anfragen verwerfen wird da er nur TCP 80 und TCP 443 weiterleitet.
Für's Internet surfen reichen diese Ports und für mehr ist das ding auch nicht gedacht.
Gruß an die IT-Welt,
J Herbrich
Dann ändere deine ACL im ersten Eintrag ab:
Source: 10.161.0.2/22
Destination: 10.141.0.1/22
Protocol: UDP
Port: 53
Restriction Permit
dann darf nur der DNS-Server (wenn er die 10.161.0.2 hätte) auf die FritzBox zwecks DNS-Anfragen zugreifen.
Alternativ einen anderen, zuverlässigen öffentlichen DNS-Server verwenden, an den sich der VLAN-interne DNS-Server wenden kann....
wenn du hier nicht fündig werden solltest (was mich dank den Anleitung, primär von aqui, wundern, würde), kannst du auch hier mal schauen:
https://www.google.de/search?q=Best+practice+guest+Vlan
Source: 10.161.0.2/22
Destination: 10.141.0.1/22
Protocol: UDP
Port: 53
Restriction Permit
dann darf nur der DNS-Server (wenn er die 10.161.0.2 hätte) auf die FritzBox zwecks DNS-Anfragen zugreifen.
Alternativ einen anderen, zuverlässigen öffentlichen DNS-Server verwenden, an den sich der VLAN-interne DNS-Server wenden kann....
wenn du hier nicht fündig werden solltest (was mich dank den Anleitung, primär von aqui, wundern, würde), kannst du auch hier mal schauen:
https://www.google.de/search?q=Best+practice+guest+Vlan
Hallo,
Ja, ich werde mal drüber nachdenken. Auf jeden Fall bin ich vorerst mit der ACL Konfiguration sehr zufrieden. Ich denke dass Interne Netz ist auch entsprechend abgesichert da man nicht auf das Interne Netz zugreifen kann mit Ausnahme der DNS Server die alerdings denke ich mal keine Vertraulichen Daten liefern können.
Gruß an die IT-Welt,
J Herbrich
Ja, ich werde mal drüber nachdenken. Auf jeden Fall bin ich vorerst mit der ACL Konfiguration sehr zufrieden. Ich denke dass Interne Netz ist auch entsprechend abgesichert da man nicht auf das Interne Netz zugreifen kann mit Ausnahme der DNS Server die alerdings denke ich mal keine Vertraulichen Daten liefern können.
Gruß an die IT-Welt,
J Herbrich
Hallo,
Ich rechne mal nach. ein 8.er beduetet konkret folgendes: 10.0.0.1 - 10.255.255.254, da ist ja auch das 10.161.0.0/22.er Netz drinnen was wiederum ja gewünscht ist das man es nutzt. (Ohne IP kein Internet :P). Nun, alles was mit 192 beginnt nutze ich so wieso nicht einfach aus dem Grund weil es damit fast immer Ärger betreffend VPN gibt. Und 172.er IP,s werden höchstens in LAB-Net verwendet (Virtualisierte Kisten zum Experimentieren) aber auch nur via NAT angeschlossen.
Klar macht es sinn Private Netze zu blockieren aber ich habe bei der Plahnung meines Netzwerks weit voraus gedacht das die IP,s nicht so schnell knapp werden. Ein 22.er reicht ewig für ein Privat Netzwerk.
Mein Root Server routet von 10.141.0.0 bis 10.149.255.255 (also diese Routen gehen auf über's VPN zum Root Server) und momentan ist eh nur 10.141.0.0 und 10.140.0.0 (Root Server Netzwerk / ESXi vCenter Netzwerk) in Benutzung.
Gruß an die IT-Welt,
J Herbrich
Ich rechne mal nach. ein 8.er beduetet konkret folgendes: 10.0.0.1 - 10.255.255.254, da ist ja auch das 10.161.0.0/22.er Netz drinnen was wiederum ja gewünscht ist das man es nutzt. (Ohne IP kein Internet :P). Nun, alles was mit 192 beginnt nutze ich so wieso nicht einfach aus dem Grund weil es damit fast immer Ärger betreffend VPN gibt. Und 172.er IP,s werden höchstens in LAB-Net verwendet (Virtualisierte Kisten zum Experimentieren) aber auch nur via NAT angeschlossen.
Klar macht es sinn Private Netze zu blockieren aber ich habe bei der Plahnung meines Netzwerks weit voraus gedacht das die IP,s nicht so schnell knapp werden. Ein 22.er reicht ewig für ein Privat Netzwerk.
Mein Root Server routet von 10.141.0.0 bis 10.149.255.255 (also diese Routen gehen auf über's VPN zum Root Server) und momentan ist eh nur 10.141.0.0 und 10.140.0.0 (Root Server Netzwerk / ESXi vCenter Netzwerk) in Benutzung.
Gruß an die IT-Welt,
J Herbrich
Dann reicht ja auch statt der 0.255.255.255 "Scheunentor" Wildcard in der Access Liste auch ein permit 10.140.0.0 0.1.255.255
Übrigens ist das DNS Protokoll explizit für UDP und TCP spezifiziert:
https://de.wikipedia.org/wiki/Domain_Name_System
Was manche Clients auch nutzen. Insofern solltest du ggf. die ACL noch um:
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
erweitern ?!
Damit wäre deine ip access-list extended SecureJenniNet dann komplett allerdings geift sie nicht solange du kein:
interface Vlan11
description Gastnetzwerk
ip address 10.161.0.1 255.255.252.0
ip helper-address 10.141.0.151
ip access-group SecureJenniNet in
!
dort konfigurierst.
Alles in allem ist die ACL etwas unlogisch, denn wozu erlaubst du zuerst nur den UDP 53 Zugriff auf die beiden Server IPs wenn du dann danach so oder so jeglichen UDP und TCP Zugriff auf das gesamte Netzwerk dieser Server erlaubst und damit auch auf die Server ?!
Das macht doch logisch keinen Sinn. Du willst ja vermutlich nur DNS und DHCP auf diese Server erlauben aber sonst nix, oder ??
Dann wäre das hier sinnvoller:
ip access-list extended SecureJenniNet
permit udp any eq bootps any --> Lässt DHCP Broadcasts zu (Source: 0.0.0.0, Dest: 255.255.255.255)
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.119 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
deny ip 10.161.0.0 0.0.3.255 host 10.141.0.19
deny ip10.161.0.0 0.0.3.255 host 10.141.0.151
permit ip host 10.161.0.1 10.141.0.0 0.0.3.255 --> Damit darf der Cisco selber dann raus.
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
Das würde dann einzig nur den Zugriff auf Port 53 und DHCP aus dem VLAN 11 auf die Server zulassen und sonst nix. Endgeräte können also eigentlich gar nichts machen in dem VLAN 11 außer das sie eine IP bekommen und DNS auflösen können, so das es mehr oder minder sinnfrei wäre.
Damit Endgeräte im VLAN 11 dann überhaupt irgendwas machen können musst du auch was erlauben. Z.B. nur surfen:
ip access-list extended SecureJenniNet
permit udp any eq bootps any
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.119 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
deny ip 10.161.0.0 0.0.3.255 host 10.141.0.19
deny ip10.161.0.0 0.0.3.255 host 10.141.0.151
permit ip host 10.161.0.1 10.141.0.0 0.0.3.255
permit tcp 10.161.0.0 0.0.3.255 any eq www
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
Übrigens ist das DNS Protokoll explizit für UDP und TCP spezifiziert:
https://de.wikipedia.org/wiki/Domain_Name_System
Was manche Clients auch nutzen. Insofern solltest du ggf. die ACL noch um:
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
erweitern ?!
Damit wäre deine ip access-list extended SecureJenniNet dann komplett allerdings geift sie nicht solange du kein:
interface Vlan11
description Gastnetzwerk
ip address 10.161.0.1 255.255.252.0
ip helper-address 10.141.0.151
ip access-group SecureJenniNet in
!
dort konfigurierst.
Alles in allem ist die ACL etwas unlogisch, denn wozu erlaubst du zuerst nur den UDP 53 Zugriff auf die beiden Server IPs wenn du dann danach so oder so jeglichen UDP und TCP Zugriff auf das gesamte Netzwerk dieser Server erlaubst und damit auch auf die Server ?!
Das macht doch logisch keinen Sinn. Du willst ja vermutlich nur DNS und DHCP auf diese Server erlauben aber sonst nix, oder ??
Dann wäre das hier sinnvoller:
ip access-list extended SecureJenniNet
permit udp any eq bootps any --> Lässt DHCP Broadcasts zu (Source: 0.0.0.0, Dest: 255.255.255.255)
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.119 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
deny ip 10.161.0.0 0.0.3.255 host 10.141.0.19
deny ip10.161.0.0 0.0.3.255 host 10.141.0.151
permit ip host 10.161.0.1 10.141.0.0 0.0.3.255 --> Damit darf der Cisco selber dann raus.
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
Das würde dann einzig nur den Zugriff auf Port 53 und DHCP aus dem VLAN 11 auf die Server zulassen und sonst nix. Endgeräte können also eigentlich gar nichts machen in dem VLAN 11 außer das sie eine IP bekommen und DNS auflösen können, so das es mehr oder minder sinnfrei wäre.
Damit Endgeräte im VLAN 11 dann überhaupt irgendwas machen können musst du auch was erlauben. Z.B. nur surfen:
ip access-list extended SecureJenniNet
permit udp any eq bootps any
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.19 eq domain
permit udp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.119 eq domain
permit tcp 10.161.0.0 0.0.3.255 host 10.141.0.151 eq domain
deny ip 10.161.0.0 0.0.3.255 host 10.141.0.19
deny ip10.161.0.0 0.0.3.255 host 10.141.0.151
permit ip host 10.161.0.1 10.141.0.0 0.0.3.255
permit tcp 10.161.0.0 0.0.3.255 any eq www
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
Hallo,
Die ACL macht was sie soll, ich kann von VLAN11 im Internet surfen aber weder auf die Fritzbox kommen noch kann ich auf ein anderes Gerät zugreifen. Und mir ist der TCP Port 53 sehr wohl bekannt der wird aber hauptsächlich für AXFR (also Zone Transfers) genutzt. So welche Dienste sind aber im VLAN11 nicht von nöten.
Gruß an die IT-Welt,
J Herbrich
Endgeräte können also eigentlich gar nichts machen in dem VLAN 11 außer das sie eine IP bekommen und DNS auflösen können
Die ACL macht was sie soll, ich kann von VLAN11 im Internet surfen aber weder auf die Fritzbox kommen noch kann ich auf ein anderes Gerät zugreifen. Und mir ist der TCP Port 53 sehr wohl bekannt der wird aber hauptsächlich für AXFR (also Zone Transfers) genutzt. So welche Dienste sind aber im VLAN11 nicht von nöten.
Gruß an die IT-Welt,
J Herbrich
ich kann von VLAN11 im Internet surfen
Das wäre ein IP technisches Wunder !!! (Bug in der Cisco ACL kann man ausschliessen)Jedenfalls mit deiner originalen ACL ist das vollommen unmöglich oder du nutzt einen Proxy Server in einem der freigegebenen RFC 1918 IP Netze bei dir.
Ansonsten kann man dir das nicht wirklich glauben...oder du hast noch einen anderen Fehler in der Konfig gemacht und dein Client ist gar nicht in VLAN 11
Hallo,
10.141.0.151 udp 53 erlaubt
10.141.0.19 udp 53 erlaubt
10.141.0.0/22 blockiert
0.0.0.0/0 tcp 80 erlaubt
0.0.0.0/0 tcp 443 erlaubt
Also, Internet geht, Netzwerkzugriff aber nicht (mit Ausnahme der DNS-Server) ;)
Dass ist die aktuell laufende ACL und die sollte doch ok sein oder nicht?
Gruß an die IT-Welt,
J Herbrich
10.141.0.151 udp 53 erlaubt
10.141.0.19 udp 53 erlaubt
10.141.0.0/22 blockiert
0.0.0.0/0 tcp 80 erlaubt
0.0.0.0/0 tcp 443 erlaubt
Also, Internet geht, Netzwerkzugriff aber nicht (mit Ausnahme der DNS-Server) ;)
Das wäre ein IP technisches Wunder
Kann ich jetzt nicht verstehen, der Cisco Switch macht ga genau das was in der ACL drinnen steht ip access-list extended SecureJenniNet
permit udp any host 10.141.0.151 eq domain
permit udp any host 10.141.0.19 eq domain
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
permit tcp any any eq www
permit tcp any any eq 443
ip radius source-interface Vlan1
!
!Dass ist die aktuell laufende ACL und die sollte doch ok sein oder nicht?
Gruß an die IT-Welt,
J Herbrich
OK, diese ACL ist aber anders als die urspünglich gepostete. Sie enthält aber auch wieder laienhafte "Scheunentore die nicht sein müssten. Besser wäre:
ip access-list extended SecureJenniNet
permit udp any host 10.141.0.151 eq domain
permit udp any host 10.141.0.19 eq domain
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
permit tcp 10.161.0.0 0.0.3.255 any eq www
permit tcp 10.161.0.0 0.0.3.255 any eq 443
Das VLAN 11 Segment hat ja eine IP 10.161.0.1 255.255.252.0 Es kann von dort also niemals etwas mit "any" kommen und genau DAS will man ja auch nicht also sollte man folglich die Absender IP darauf begrenzen wenn man es etwas professioneller macht.
Mit der "any" Regel klappt dann natürlich das Internet, das ist klar.
ip access-list extended SecureJenniNet
permit udp any host 10.141.0.151 eq domain
permit udp any host 10.141.0.19 eq domain
deny ip 10.161.0.0 0.0.3.255 10.141.0.0 0.0.3.255 log
permit tcp 10.161.0.0 0.0.3.255 any eq www
permit tcp 10.161.0.0 0.0.3.255 any eq 443
Das VLAN 11 Segment hat ja eine IP 10.161.0.1 255.255.252.0 Es kann von dort also niemals etwas mit "any" kommen und genau DAS will man ja auch nicht also sollte man folglich die Absender IP darauf begrenzen wenn man es etwas professioneller macht.
Mit der "any" Regel klappt dann natürlich das Internet, das ist klar.
Hallo,
Hmm ja dass ANY ist durch aus etwas zu viel des guten, habe an Klicks gespart aber im Grunde genommen sollte es doch keine Probleme verursachen können da dass ANY konkret ja auch nur alles im VLAN11 abdeckt und dass sind ja nur 10.161.0.0 IP,s.
Oder kann man tatsächlich nur dass Manuelle einstellen einer 10.141.er IP das VLAN11 verlassen und sich im VLAN1 frei bewegen?
Gruß an die IT-Welt,
J Herbrich
Hmm ja dass ANY ist durch aus etwas zu viel des guten, habe an Klicks gespart aber im Grunde genommen sollte es doch keine Probleme verursachen können da dass ANY konkret ja auch nur alles im VLAN11 abdeckt und dass sind ja nur 10.161.0.0 IP,s.
Oder kann man tatsächlich nur dass Manuelle einstellen einer 10.141.er IP das VLAN11 verlassen und sich im VLAN1 frei bewegen?
Gruß an die IT-Welt,
J Herbrich
habe an Klicks gespart
Igitt....machst du sowas etwa mit einem Klicki Bunti GUI statt CLI ??? Das ist ja abartig...Durch das "Any" kannst du dann Frames mit jeder beliebigen Absender IP an den Switch selber senden. Der forwardet dann alles. Um das zu unterbinden müsste man uRPF aktivieren...oder eben die ACL etwas dichter ziehen.
Es ist eben letztlich eine Frage der Sicherheitsanforderung die du hast.
Hallo,
Was ist am Cisco Netzwerk asistenten igit? Und nein das meiste habe ich über die inzwischen nicht mehr zugreifbare CLI gemacht
Gruß an die IT-Welt,
J Herbrich
Igitt....machst du sowas etwa mit einem Klicki Bunti GUI statt CLI ??? Das ist ja abartig...
Was ist am Cisco Netzwerk asistenten igit? Und nein das meiste habe ich über die inzwischen nicht mehr zugreifbare CLI gemacht
Gruß an die IT-Welt,
J Herbrich
Wie "nicht mehr zugreifbare CLI" ?? Direkt an der Konsole hast du immer Zugriff !
Hast du dich immer noch ausgesperrtt mit Telnet und SSH und dem obigen Radius Fehler oder was ??
Sicher die Konfig als Text Datei, setz den Switch auf Werkseinstellungen zurück und cut and paste die korrigierte ! Konfig wieder rein.
Das ist doch in 5 Minuten erledigt und schafft dir wieder Freiheit beim CLI wie es sich für einen richtigen Netzwerker gehört ?!
Hast du dich immer noch ausgesperrtt mit Telnet und SSH und dem obigen Radius Fehler oder was ??
Sicher die Konfig als Text Datei, setz den Switch auf Werkseinstellungen zurück und cut and paste die korrigierte ! Konfig wieder rein.
Das ist doch in 5 Minuten erledigt und schafft dir wieder Freiheit beim CLI wie es sich für einen richtigen Netzwerker gehört ?!
1
Hallo,
Ich muss ihn doch eig nicht mal wieder zurücksetzen oder? Würde es nicht reichen wen ich ein Interrupt senden würde beim Booten (CLI über Serial Port) und dann die config.txt zur Laufzeit laden würde?
Und ich habe ja noch die Möglichkeit level15 Befehle über den ip http Server aus zu führen? Und ja ich bevorzuge auch die CLI weil die GUI einfach zu blöd ist. Ist halt doch einfach sich über eine Console im System voran zu bewegen
Gruß an die IT-Welt,
J Herbrich
Ich muss ihn doch eig nicht mal wieder zurücksetzen oder? Würde es nicht reichen wen ich ein Interrupt senden würde beim Booten (CLI über Serial Port) und dann die config.txt zur Laufzeit laden würde?
Und ich habe ja noch die Möglichkeit level15 Befehle über den ip http Server aus zu führen? Und ja ich bevorzuge auch die CLI weil die GUI einfach zu blöd ist. Ist halt doch einfach sich über eine Console im System voran zu bewegen
Gruß an die IT-Welt,
J Herbrich
