Jump to content

Frittenbude

Members
  • Gesamte Inhalte

    43
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Frittenbude

  1. Okay, habe es jetzt so übernommen - in der Hoffnung, dass die DNS-Server-Adressen sich nicht in den nächsten Monaten ändern. Für den Fall der Fälle wäre mir daher ne dynamische Zuweisung schon lieber gewesen. Aber so tut's es erst einmal auch. Gruß, Frittenbude
  2. Hab ich so drin: ip dhcp pool DSL_Modem_1 import all ... ! interface Dialer1 ppp ipcp dns request ... ! Funktioniert leider aber nicht. Gruß, Frittenbude
  3. @ Otaku19: Okay, ich kann Deinen Einwand nachvollziehen. Andererseits ist die Wahrscheinlichkeit dafür, dass einer von drei Routern ausfällt höher als bei einem Gerät. Klar, dafür steht dann natürlich alles, wenn denn der Router defekt ist. An ein Ersatzgerät komme ich relativ zeitnah. Die DSL-Zugänge sind bei Ausfällen für einen gewissen Zeitraum für die Nutzer zu verkraften. Ich denke der Einsatz des Cisco-Routers ist sowohl für sie als auch für uns zukünftig eine erleichterung. Drei separate Router hätte ich auch bevorzugt. Nur ob ich die für das Projekt bekommen werde ist leider fraglich. Daher bin ich erst mal von der Ein-Router-Lösung ausgegangen. @ all: Eine Sache funktioniert leider noch nicht. Und zwar die DNS-Auflösung - sowohl für Clients als auch auf dem Router selbst (im VRF). DNS-Server bekomme ich vom Provider automatisch übermittelt. Für Clients dient der Router mit seiner Router-IP-Adresse als DNS-Server. Hat jemand einen Hinweis? Gruß, Frittenbude
  4. Erst einmal vielen Dank, Servidge. Es funktioniert nun. Mir ist zwar nicht klar, warum das mit dem Pool anstelle der Interfaceangabe nicht funktioniert hat. Aber Hauptsache es läuft nun. ;-) @ Otaku19: Es hat zwei Gründe, warum ich das so gewählt habe. 1. Ich hatte nur einen Router zur Verfügung und sehe auch keinen Mehrwert darin, für jede DSL-Verbindung einen eigenen Cisco-Router einzusetzen. Es sollten drei voneinander getrennte Internetzugänge für unterschiedliche Benutzergruppen sein, die jeweils einen zugesicherten DSL-Anschluss erhalten sollen. Hintergrund: Es gab bisher drei separate DSL-Anschlüsse für drei voneinander getrennte Benutzergruppen (Trennung und Zusicherung der Performance ist erforderlich). Diese waren über einfache Speedport-Router angebunden. Da diese Router jedoch nur schlecht managebar (fernwartbar) sind und häufig mit Instabilität zu kämpfen war, wollte ich die drei Speedport-Router durch einen Cisco-Router ersetzen. Es nervt auch, wenn man alle zwei Wochen einen der Router neustarten muss - gerade, wenn die Geräte nicht direkt in näherer Umgebung sind. Ziel war es also quasi auch, die eigenen Aufwände für die Wartung zu reduzieren, um sinnvollere Aufgaben machen zu können. 2. Ich war daran interessiert zu testen, ob ein solcher Aufbau möglich und wie es im Detail funktioniert. Welche Lösung hättest Du denn gewählt? Gruß, Frittenbude
  5. Danke für die Rückmeldung. Die VRF-Zuweisung habe ich von den DHCP-Pools wieder herausgenommen, da sonst keine IP-Adressen zugewiesen wurden. Könnte aber sein, dass ich gleichzeitig auch andere Änderungen an der Konfiguration vorgenommen hatte. Ich nehme die VRF-Zuweisung morgen testweise noch einmal rein. Also, folgendes geht: - Zuweisung von IP-Adressen per DHCP an Clients im jeweiligen User-VLAN - Aufbau der Internetverbindung (Ping aus VRF DSL_Modem_1 auf eine öffentliche IP-Adresse im Weg geht) - Routingeinträge im VRF DSL_Modem_1 sind korrekt - NAT Eintrag im Router wird erstellt, wenn ein Client eine öffentliche IP-Adresse im Weg anpingt Folgendes geht nicht: - Ein Client erhält beim Pingen einer öffentlichen IP-Adresse im Web keine Antwort (Server im Web ist dabei definitv erreichbar) - Ein Traceroute auf die selbe öffentliche IP-Adresse von dem selben Client führt nur bis zu seinem ersten HOP (also 192.168.101.1). Es kommt also keine Verbindung ins Web zustande. Übrigens habe ich bisher auch nur die Verbindung für das VRF DSL_Modem_1 getestet. Die anderen VRFs sind quasi erst mal nur vorbereitend angelegt. Ich weiß auch nicht, wie ich noch weiter debuggen soll, wenn ich weiß, dass die Routingeinträge stimmen und ein NAT-Eintrag auf dem Router für den Ping (ICMP) erzeugt wird. Gruß, Frittenbude
  6. Hallo zusammen, ich möchte NATing gerne in Verbindung mit VRFs auf einem Cisco Router 1812 nutzen. D.h. auf drei getrennte DSL-Verbindungen soll jeweils ein NAT-Pool für interne Nutzer (in insgesamt 3 VLANs) genutzt werden. Ich habe die Konfiguration auch soweit durchgeführt. NATing wird laut "sh ip nat translations" durchgeführt, wenn ich beispielsweise eine IP-Adresse im Internet von einem Client versuche anzupingen. Die Internetverbindung wird von dem besagten Router über Dialer (PPPoE) aufgebaut und funktioniert soweit. Nachfolgend ein Konfigurationsauszug mit den relevanten Teilen. Kurze Erklärung: Getestet wird erst nur mit einem DSL-Anschluss für Dialer1. Ein Client befindet sich derzeit in VLAN201 an FastEthernet6. Alles weitere sollte aus dem Konfigurationsauszug ersichtlich sein. ... ip cef no ip dhcp use vrf connected ip dhcp excluded-address 192.168.101.1 192.168.101.9 ip dhcp excluded-address 192.168.102.1 192.168.102.9 ip dhcp excluded-address 192.168.103.1 192.168.103.9 ! ip dhcp pool DSL_Modem_1 network 192.168.101.0 255.255.255.0 default-router 192.168.101.1 dns-server 192.168.101.1 lease 0 0 1 ! ip dhcp pool DSL_Modem_2 network 192.168.102.0 255.255.255.0 default-router 192.168.102.1 dns-server 192.168.102.1 lease 0 0 1 ! ip dhcp pool DSL_Modem_3 network 192.168.103.0 255.255.255.0 default-router 192.168.103.1 dns-server 192.168.103.1 lease 0 0 1 ! ! ip vrf DSL_Modem_1 description DSL_Modem_1 ! ip vrf DSL_Modem_2 description DSL_Modem_2 ! ip vrf DSL_Modem_3 description DSL_Modem_3 ! vpdn enable ! vpdn-group 1 ! vpdn-group 2 ! vpdn-group 3 ! ! ! ! ! ! ! ! interface BRI0 no ip address encapsulation hdlc shutdown ! interface FastEthernet6 switchport access vlan 201 ! interface FastEthernet7 description To DSL Modem 3 switchport access vlan 103 no cdp enable ! interface FastEthernet8 description To DSL Modem 2 switchport access vlan 102 no cdp enable ! interface FastEthernet9 description To DSL Modem 1 switchport access vlan 101 no cdp enable ! interface Vlan1 no ip address ! interface Vlan101 description To DSL Modem 1 ip vrf forwarding DSL_Modem_1 no ip address pppoe enable group 1 pppoe-client dial-pool-number 1 ! interface Vlan201 description LAN_1_for_DSL_1 ip vrf forwarding DSL_Modem_1 ip address 192.168.101.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Dialer1 bandwidth 100000 ip vrf forwarding DSL_Modem_1 ip address negotiated ip nat outside ip virtual-reassembly encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer hold-queue 30 dialer-group 1 no cdp enable ppp authentication pap callin ppp chap hostname 0815@t-online.de ppp chap password 7 xxxxx ppp pap sent-username 0815@t-online.de password 7 xxxxx ppp ipcp dns request ! ip route vrf DSL_Modem_1 0.0.0.0 0.0.0.0 Dialer1 ip route vrf DSL_Modem_2 0.0.0.0 0.0.0.0 Dialer2 ip route vrf DSL_Modem_3 0.0.0.0 0.0.0.0 Dialer3 ! ! no ip http server no ip http secure-server ip dns view-list DSL_Modem_1 ip dns server ip nat pool DSL_Modem_1 192.168.101.10 192.168.101.254 prefix-length 24 ip nat inside source list 1 pool DSL_Modem_1 vrf DSL_Modem_1 match-in-vrf overload ! access-list 1 permit 192.168.101.0 0.0.0.255 access-list 2 permit 192.168.102.0 0.0.0.255 access-list 3 permit 192.168.103.0 0.0.0.255 dialer-list 1 protocol ip permit ... Kann mir jemand sagen, was ich noch beachten muss.? Übrigens, es soll kein Load-Balancing oder eine Fall-Back-Lösung für die drei DSL-Zugänge genutzt werden. Lediglich drei voneinander getrennte DSL-Zugänge für unterschiedliche Nutzergruppen. Daher auch die Nutzung von VRFs... Für Hilfe wäre ich Euch sehr dankbar, denn ich komme selbst nicht weiter. Gruß, Frittenbude
  7. Danke Otaku, Deine Idee werde ich in Zukunft berücksichtigen. Nur derzeit reicht die Performance dieses Aufbaus noch. Folgende Frage hätte ich noch zusätzlich. Und zwar soll der in der Grafik gezeigte Aufbau für eine Site-To-Site-Verbindung auf IPSec-Basis genutzt werden. Die Gegenstelle stellt folgende Anforderung. VPN-Endpoint (auf deren Seite): 194.1.1.1 (verfremdet) Deren VPN-Netz: 194.1.1.0/27 Unser öffentlicher Endpunkt: x.x.x.x (wird durch NATing auf die ASA als tatsächlicher VPN-Endpunkt 192.168.1.2 gemappt) Das zu erreichende System: 192.168.16.150/32 Was die Gegenseite möchte ist, dass sie das zu erreichende System über die Adresse 10.1.1.1/32 erreichen. Nach meinem Verständnis muss auf der ASA für diesen Zweck NATing durchgeführt werden. Das System 192.168.16.150 wird quasi nach außen hin versteckt, richtig? Funktioniert das so auf diesem Weg? Wenn ja, welchen Eintrag muss ich dafür setzen? Ist dieser Eintrag korrekt? static (inside,outside) 10.1.1.1 192.168.15.150 netmask 255.255.255.255 0 0 Für einen Hinweis wäre ich Euch dankbar. Viele Grüße, Frittenbude
  8. Danke für Eure schnelle Reaktion. @hegl: Okay, das ist gut zu wissen. Mir war nicht bewusst, dass die VPN-Lösung solche Aufgaben übernimmt. @Otaku19: Deinen Hinweis werde ich berücksichtigen. Könntest Du mir genauer sagen, wie Du die Verbindung zwischen ASA und Router ändern würdest? Mir ist nicht klar, wie ich das doppelte NATing (bzw. NAT auf dem Router) umgehen kann, da der Router die Internetverbindung aufbaut und somit die einzige nach außen bekannte IP-Adresse besitzt. Gerade bin ich mir auch nicht ganz sicher, ob die ASA für Internetverbindungen überhaupt NATing durchführt. Ich meine sogar fast, dass sie nur NATing für VPN nutzt, aber das müsste ich nochmal prüfen. Gruß, Frittenbude
  9. Hallo zusammen, ich habe eine Frage an Euch für ein generelles Verständnis. Dazu sei folgender, anonymisierter Aufbau gegeben (siehe Grafik). Vorab: Ich würde gerne wissen, wie die Kommunikation aus einem VPN-Netz unter der Nutzung von NAT in das interne Netz funktioniert. Kurze Beschreibung des Aufbaus: An dem Catalyst 3560 liegen die Netze 192.168.16.0/24, 192.168.17.0/24 sowie 192.168.18.0/24 an. Das Routing wird mittels Inter-VLAN-Routing an diesem Switch ermöglicht. Das Netz 192.168.19.0/24 wird zwischen dem Catalyst 3560 und der ASA 5500 genutzt - wohlgemerkt ohne VLAN-Trunking-Verbindung, denn VLANs werden in der Ausbaustufe der ASA leider nicht unterstützt. Das Netz 192.168.1.0/24 wird zwischen der ASA 5500 und dem Internetrouter Cisco 876 eingesetzt. Für Internetverbindungen von innen (z.B. 192.168.18.0/24) nach außen (Internet) wird sowohl auf der ASA 5500 als auch auf dem Cisco 876 NAT eingesetzt. Der VPN-Concentrator für Verbindungen von außen nach innen befindet sich in der ASA. Der Internetrouter (Cisco 876) reicht IPSEC-VPN-Anfragen an die ASA weiter. VPN-Clients landen im Netz 192.168.20.0/24. Meine Frage ist nun folgende: Wie kann ein VPN-Client, der beispielsweise die Adresse 192.168.20.1 erhält, eine Kommunikation in ein internes Netz (z.B. 192.168.17.0/24) ausführen. Der VPN-Client hat nach meiner Vorstellung gar keine Routing-Information, um das Netz 192.168.17.0/24 zu erreichen - schließlich gibt es kein "Router-Interface" im VPN-Netz (192.168.20.0/24). Derzeit konfiguriere ich eine Firewall, bei der genau dieser Aufbau funktioniert. Jedoch kann ich das nicht nachvollziehen, denn nach meinem Verständnis bräuchte man normalerweise einen Router mit Interface im VPN-Netz (192.168.20.9/24). Darüber hinaus habe ich bei diesem Aufbau das Problem, dass keine Firewall-Policy (Filterregel) greift, um die Kommunikation aus dem Netz 192.168.20.0/24 in das Netz 192.168.17.0/24 zu verhindern. Ich habe die Kommunikation nicht explizit erlaubt. Selbst wenn ich Deny-Regeln einbinde, greifen diese nicht. Kann es sein, dass durch NATing für die Kommunikation aus dem VPN-Netz in das interne Netz Filterregeln nicht greifen und es quasi einen Pass-Through gibt? Leider kann ich die Konfiguration hier nicht aufführen, da ich die entsprechenden Teile wegen der Anonymisierung umschreiben müsste und mir zudem nicht ganz klar ist, welche Teile davon relevant sind. Ich hoffe, dass dennoch jemand etwas zu dem Phänomen sagen kann und vielleicht auch wie ihr generell eine Umsetzung durchführen würdet, um aus dem VPN-Netz in das interne Netz zu gelangen. Über eine Antwort würde ich mich freuen. Gruß, Frittenbude
  10. Ist das für eine Grundkonfiguration wirklich erforderlich? Ich habe inzwischen einen anderen Switch mit Debugging-Funktionalität verwendet und folgende Meldungen erhalten: Erfolgreiche TACACS-Anmeldung mittels SecurID: 00:27:55: AAA: parse name=tty1 idb type=-1 tty=-1 00:27:55: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1 chan0 00:27:55: AAA/MEMORY: create_user (0x187EF650) user='NULL' ruser='NULL' ds0=0 p) 00:27:55: AAA/AUTHEN/START (568432380): port='tty1' list='' action=LOGIN servicN 00:27:55: AAA/AUTHEN/START (568432380): using "default" list 00:27:55: AAA/AUTHEN/START (568432380): Method=tacacs+ (tacacs+) 00:27:55: TAC+: send AUTHEN/START packet ver=192 id=568432380 00:27:56: TAC+: ver=192 id=568432380 received AUTHEN status = GETUSER 00:27:56: AAA/AUTHEN (568432380): status = GETUSER 00:27:58: AAA/AUTHEN/CONT (568432380): continue_login (user='(undef)') 00:27:58: AAA/AUTHEN (568432380): status = GETUSER 00:27:58: AAA/AUTHEN (568432380): Method=tacacs+ (tacacs+) 00:27:58: TAC+: send AUTHEN/CONT packet id=568432380 00:27:58: TAC+: ver=192 id=568432380 received AUTHEN status = GETPASS 00:27:58: AAA/AUTHEN (568432380): status = GETPASS 00:28:04: AAA/AUTHEN/CONT (568432380): continue_login (user='user1') 00:28:04: AAA/AUTHEN (568432380): status = GETPASS 00:28:04: AAA/AUTHEN (568432380): Method=tacacs+ (tacacs+) 00:28:04: TAC+: send AUTHEN/CONT packet id=568432380 00:28:06: TAC+: ver=192 id=568432380 received AUTHEN status = PASS 00:28:06: AAA/AUTHEN (568432380): status = PASS Fehlerhafte TACACS-Anmeldung mittels Cleartext: 00:29:09: AAA: parse name=tty1 idb type=-1 tty=-1 00:29:09: AAA: name=tty1 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=1 chan0 00:29:09: AAA/MEMORY: create_user (0x187EF930) user='NULL' ruser='NULL' ds0=0 p) 00:29:09: AAA/AUTHEN/START (2102659375): port='tty1' list='' action=LOGIN serviN 00:29:09: AAA/AUTHEN/START (2102659375): using "default" list 00:29:09: AAA/AUTHEN/START (2102659375): Method=tacacs+ (tacacs+) 00:29:09: TAC+: send AUTHEN/START packet ver=192 id=2102659375 00:29:09: TAC+: ver=192 id=2102659375 received AUTHEN status = GETUSER 00:29:09: AAA/AUTHEN (2102659375): status = GETUSER 00:29:11: AAA/AUTHEN/CONT (2102659375): continue_login (user='(undef)') 00:29:11: AAA/AUTHEN (2102659375): status = GETUSER 00:29:11: AAA/AUTHEN (2102659375): Method=tacacs+ (tacacs+) 00:29:11: TAC+: send AUTHEN/CONT packet id=2102659375 00:29:12: TAC+: ver=192 id=2102659375 received AUTHEN status = GETPASS 00:29:12: AAA/AUTHEN (2102659375): status = GETPASS 00:29:18: AAA/AUTHEN/CONT (2102659375): continue_login (user='user2') 00:29:18: AAA/AUTHEN (2102659375): status = GETPASS 00:29:18: AAA/AUTHEN (2102659375): Method=tacacs+ (tacacs+) 00:29:18: TAC+: send AUTHEN/CONT packet id=2102659375 00:29:23: AAA/AUTHEN (2102659375): status = ERROR 00:29:23: AAA/AUTHEN/START (2514039982): port='tty1' list='' action=LOGIN serviN 00:29:23: AAA/AUTHEN/START (2514039982): Restart 00:29:23: AAA/AUTHEN/START (2514039982): Method=ENABLE 00:29:23: AAA/AUTHEN (2514039982): status = GETPASS Es scheint so, dass TACACS keine Freigabe an das Cisco-Gerät sendet. An den RSA Authentication Manager hingegen sendet er nach wie vor eine erfolgreiche Benutzeranmeldung, wenn das der Benutzer mit Cleartext-Anmeldung das richtige PW eingegeben hat. Gruß, Frittenbude
  11. Hallo zusammen, wir testen derzeit eine RSA SecurID Authentifizierung an Cisco-Geräten mit Hilfe von TACACS+. Die Authentifizierung auf einem testweise eingebundenen Catalyst der 29xx-Serie funktioniert über ein SecurID-Token auch soweit über Telnet. Allerdings funktioniert ein Loginversuch mittels eines in der TACACS-Konfiguration angelegten Benutzer (dieser ist kein SecurID-Nutzer, sondern ein lokal angelegter mit cleartext) nicht. Egal, ob das Passwort bei der Abfrage richtig oder falsch eingegeben wurde, folgt ein Fallback auf den Default-Login des Cisco-Geräts (lokale Authentifizierung). Wenn das Passwort richtig eingegeben wurde, zeigt mir der Authentication Monitor des RSA Auth Managers eine erfolgreiche Freigabe via TACACS-Authentifizierung. Dennoch wird das normale lokale Login-PW des CLI abgefragt. Hier die Configs: TACACS: user = test { login = cleartext "test123" } IOS: aaa new-model aaa authentication login default group tacacs+ enable tacacs-server host x.x.x.x tacacs-server key xxx line con 0 password xxx line vty 0 4 password xxx Weiß jemand einen Rat? Vielen Dank vorab. Gruß, Frittenbude
  12. Die Sache hat sich wohl gerade erledigt. Der Switch unterstützt reflexive ACLs doch nicht, obwohl die Option im IOS zur Verfügung steht: Reflexive ACL on 3750 Catalyst 3750 Switch Software Configuration Guide, 12.2(40)SE - Configuring IPv6 ACLs [Cisco Catalyst 3750 Series Switches] - Cisco Systems Gruß, Frittenbude
  13. Ich war vorhin etwas vorschnell mit der Behauptung, es würde auf dem Test-Switch funktionieren. Besser ist es, wenn ich doch mal eine Beispielkonfig poste: Es geht darum, dass aus dem Netz 172.17.1.0/24 nach 172.18.1.0/24 beispielhaft kommuniziert werden soll. Die dynamische Refection-Liste wird nur für einen Spezialfall gefüllt. Dieser wäre, wenn ich vom System 172.17.1.10 nach 172.18.1.1 (Schnittstelle VLAN18 des Switches) beispielsweise einen Ping absetze. Sobald ich jedoch einen Host an einem Port mit VLAN18 versuche zu erreichen, wird keine dynamische Regel erzeugt. Die Rückroute funktioniert dementsprechend auch nicht. Der Vollständigkeithalber zur Information: Die Kommunikation zwischen den Netzen funktioniert, wenn ACLs nicht aktiv sind. Im Prinzip werden die reflexiven ACLs richtig in diesem Fall verwendet, richtig? Gruß, Frittenbude
  14. Hallo zusammen, wir nutzen einen Switch-Stack bestehend aus 3 C3750 bei einem Kunden. Allerdings gibt es Probleme mit ACLs, die scheinbar nicht richtig funktionieren. Zwischen verschiedenen VLANs sollen ACLs greifen, welche automatisch mit Hilfe von reflected ACLs die Rückroute jeder aufbauenden Verbindung erlauben sollen. Leider greifen die Regeln auf dem Switch-Stack überhaupt nicht. Im Normalfall wird durch den Befehl "show access-lists" ein Match für jede Regel angezeigt, die bei der Regelüberprüfung zutreffend war. Matches werden merkwürdigerweise ausschließlich bei einem Deny angezeigt, sofern dieser zutreffend war. Permits erhalten quasi keine Matches. Auch wird beim Verbindungsaufbau (bei der Regel für ausgehenden Verkehr) kein Eintrag in der dynamischen Liste erzeugt, was schon nicht normal ist. Das wäre eigentlich auch kein Problem. Jedoch greifen, trotz richtiger Konfiguration, die Regeln für die Rückroute (mit dynamischen ACLs auf Basis von Reflective ACLs) nicht. Nun haben wir einen baugleichen Switch in Grundkonfiguration genommen und ebenfalls solche Regeln (inkl. Reflective ACLs) auf diesem programmiert. Hier funktioniert alles einwandfrei. Auch Matches werden auf Permits angezeigt. Muss auf dem Switch eine Besonderheit beachtet werden? Wenn es Euch hilft, die Konfiguration des Switches zu sehen, kann ich sie hier verfremdet posten. Ich wäre Euch sehr dankbar, wenn Ihr mir einen Tipp geben könntet. Gruß, Frittenbude
  15. Die Reflective-Sache klingt gut. Kennst Du zufällig ein Tutorial, das einen in die Thematik einführt? Ich würde mich da gerne schlauer machen. EDIT: Unter folgendem Link habe ich etwas gefunden: http://www.firstdigest.com/2009/03/cisco-how-to-use-reflexive-access-list-and-why-they-are-useful/ Vielleicht ist es auch für den ein oder anderen interessant, der die gleiche Problematik hat wie ich. Danke nochmals an alle für die schnelle Hilfe. Gruß, Frittenbude
  16. Ich habe meinen Fehler gefunden. Es lag daran, dass ich Incoming und Outgoing verwechselt habe. Irgendwie hatte ich einen Dreher im Gehirn. ;-) Folgende Config ist richtig: access-list 116 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 80 access-list 116 deny ip any any access-list 136 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 access-list 136 deny ip any any ACL 116 wird auf OUT von Interface VLAN2 angewendet; entsprechend ACL 136 auf IN von Interface VLAN2. Sorry, war einfach ein Denkfehler meinerseits. Aber nochmal zur Problematik, dass ACLs nicht die Funktion einer Stateful Inspection haben: Wie sorgt man dafür, dass für den Rückweg aus VLAN2 zu VLAN1 nicht alle Ports geöffnet werden müssen? Ein HTTP-Server antwortet ja bei einer Anfrage auf Port 80 mit einer zufälligen Portnummer. Ich könnte ja nun garnicht folgenden Fall abdecken: In VLAN1 steht HTTP-Server1, in VLAN2 HTTP-Server2. Clients aus VLAN1 möchten auf HTTP-Server2 zugreifen und analog dazu Clients aus VLAN2 auf HTTP-Server1. In dem Fall habe ich ja nichts gewonnen, wenn ich Port 80 für die Kommunikation aus VLAN1 in VLAN2 öffne und das gleiche für Port 80 aus VLAN2 in VLAN1 tue. Wie handhabt man sowas? Gruß, Frittenbude
  17. DNS lasse ich erstmal außen vor. Ich greife auf den Server vorerst per IP-Adresse zu. Zu dem Eintrag: access-list 116 permit ip 192.168.2.0 0.0.0.255 192.168.2.0 0.0.0.255 Also ohne diesen Eintrag kann ich vom Server z.B. keinen Ping auf die im gleichen Netz liegende Schnittstelle des L3-Switches absetzen. Hier mal der Aufbau in visueller Form. Die rote Verbindung soll eine Trunk-Verbindung darstellen. Gruß, Frittenbude
  18. Oh, da habe ich mich in dem Fall hier nur vertippt. So wie Du es sagst, sollte es eigentlich heißen. Ich korrigiere das eben in meinem Startpost. Gruß, Frittenbude
  19. Hallo zusammen, ich beschäftige mich derzeit mit ACLs zur Absicherung eines LANs, das aus mehreren Subnetzen auf der Basis von VLANs besteht. Das als Zitat markierte Problem ist gelöst! Es ist doch richtig, dass beim Aufbau der HTTP-Verbindung vom Client aus für den Hinweg zur Server Port 80 benötigt wird und ein Antwortpaket vom Server an den Client irgendeiner beliebiger sein kann. Für Hilfe wäre ich Euch dankbar. Gruß, Frittenbude
  20. Okay, danke für die Antworten. Ich habe SVI gestern mal testweise auf dem Packet Tracer 5.1 ausprobiert und es hat auf Anhieb funktioniert. Was mich dabei noch gewundert hat ist, dass ich auf dem routenden Switch mit den virtuellen Interfacen (SVI) lediglich zwei Stück anlegen musste und das Routing zwischen den beiden Netzen funktionierte, ohne dass ich ein Routing-Protokoll wie RIP aktivieren oder eine statische Route setzen musste. Ist das eine Eigenschaft der Inter-VLAN-Kommunikation bei der Nutzung von SVI? Wenn das so wäre, könnten ich ja keine Einschränkungen in den Kommunikationsbeziehungen zwischen verschiedenen auf VLANs basierenden Netzen vornehmen, außer durch ACLs? Grüße, Frittenbude
  21. Du hast Recht. Zwischen den Switchen besteht natürlich eine Trunking-Verbindung. Hab's nur in der Eile falsch wiedergegeben. Was VLANs sind, ist mir durchaus bewusst. Dennoch ist mir nicht klar, wie das Inter-VLAN-Routing über mehrere Switche hinweg mittels Trunking ohne Subinterfaces funktionieren soll. Im CCNA3 habe ich das Ganze nur mit Subinterfaces gelernt - hat einwandfrei geklappt. Ohne Subinterfaces habe ich bisher nur zwischen VLANs oder physikalischen Schnittstellen geroutet - ohne Trunking. Ich ging davon aus, Trunking funktioniere nur in Verbindung mit Subinterfaces. Ich werde es nach Möglichkeit heute mal im Simulator ausprobieren. Grüße, Frittenbude
  22. Danke für die schnelle Antwort. Das hört sich ja gut an. Dann muss ich mich dahingehend mal informieren, denn bisher kenne ich nur Inter-VLAN-Routing mit Subinterfaces. Ich kann also folgende Konfiguration mit SVI abbilden? Switch1: FE1/1 - VLAN1 FE1/2 - VLAN1 FE1/3 - VLAN2 FE1/4 - VLAN3 Switch2: FE1/1 - VLAN3 FE1/2 - VLAN1 FE1/3 - VLAN2 FE1/4 - VLAN2 Angenommen Switch1 (FE1/4) ist mit Switch2 (FE1/1) über VLAN3 verbunden. Können dann Ports aus VLAN1 auf Switch1 problemlos mit Ports aus VLAN1 von Switch2 kommunizieren? ========= VLAN3 ========= =SWITCH1=------------=SWITCH2= ========= ========= | | | | VLAN1 VLAN2 VLAN1 VLAN2 Da der Aufbau hier im Textformat verwurschtelt wurde, habe ich das Ganze nochmal als JPG angehangen. Gruß, Frittenbude
  23. Hallo zusammen, ich habe gerade festgestellt, dass Ciscos L3-Switche scheinbar gar keine Subinterfaces unterstützen, wie ich sie von Cisco-Routern her kenne. Wenn ich nun ein Netz habe und zwischen allen eingesetzten Switchen eine Trunking-Verbindung nutze, brauche ich dann zwingend einen Cisco-Router, um zwischen den VLANs routen zu können? Es geht darum, dass nach Möglichkeit auf jedem Switch jedes VLAN zugewiesen werden kann, ohne dass separate neue Leitungen zwischen Switchen gelegt werden müssen. Unterstützt eines der folgenden Geräte Subinterfaces? Cisco Catalyst 3750 Cisco Catalyst 3560 Cisco Catalyst 2950 Cisco ASA5510 Oder gibt es eine andere Möglichkeit, Trunkingverbindungen zwischen bestehenden Switchen zu nutzen ohne dass Subinterfaces zur Verfügung stehen? Gruß, Frittenbude
  24. Okay, vielen Dank soweit. Dann werde ich die Produkte in die Auswahl nehmen. Gruß, Frittenbude
  25. Habe noch WatchGuard gefunden. Da es im Prinzip Firewalls mit Proxy sind, frage ich mich, wieso es sowas nicht von Cisco gibt. Da muss ich wohl noch mal schauen. EDIT: Ach, jetzt sehe ich erst, dass IronPort zu Cisco gehört...
×
×
  • Neu erstellen...