czappb

Naja... WoL funktioniert mittels eines Broadcasts... Also wenn du in ein anderes VLAN Broadcasten willst bruachst du 1. einen WoL-Software die directed Broadcasts kann 2. musst du die directed broadcasts auf dem router zulassen. (auf dem ziel-vlan ggf. mit acl "ip directed broadcast ACL-Nr.")

Was verbindet sich denn über den Router ins Internet? Kann es sein, dass tatsächlich irgendwas online ist, oder wie hast du das ausgeschlossen?

Soll ich raten? Nimm mal 2 unterschiedliche Subnetze für beides. Sonst wird Windows die Verbindung mit besserer Metrik nehmen um zu kommunizieren, und das ist nunmal die LAN-Verbindung. Daher geht dann UPnP auch nicht mehr...

Es gibt verschiedene Möglichkeiten aber sieh selber: Comparing the bandwidth and priority Commands of a QoS Service Policy [QoS Packet Marking] - Cisco Systems Ich glaube da sind auch die Links zu weiterführenden Dokumenten drin Ich persönlich würde zu CBWFQ tendieren.

also ich könnte wetten du machst was falsch... zuerst auf die console dann in den privileged-mode name>"enable" (dann prompt: name#) dann "conf t" und dann konfigurieren. irgendwie bin ich sicher das klappt

Und bei "show interfaces" werden keine Runts oder ähnliches angezeigt, das es doch an einem duplex problem liegt? Welche switche werdn benutzt?

Wenn man die Switche mit Gigabit verbindet kommt natürlich das Problem auf, dass statt des Engpasses bei den Clients nun der Engpass früher oder später am Uplink auftritt. Eine Abhilfe wären höchsten Portchannel. Die Frage ist natürlich wohin die Daten überhaupt übertragen werden. Sollten die Daten nur im 1.OG auf den Switches laufen würde sich evtl. ein Stack anbieten, da stände erheblich mehr Bandbreite zur Verfügung. (Jedenfalls bei 3750ern, sind 3560er ähnlich Stackable?)

Ich würde auf die PPTP-Tunnel tippen. Nachdem wir die bei uns abgeschaltet haben waren alle merkwürdigen Probleme mit Paketverlusten, abgehacken Gesprächen etc. vorbei.

Das ist kein Problem. Der IP-Helper arbeitet wie ein DHCP-Relay-Agent und damit sollte Novell doch auch zurecht kommen.

Joa dann hast du natürlich ein kleines Problem... ich nehme nicht an, dass du auf alle anderen Ports des VLANs eine eingehende ACL binden willst. Da du die ACLs auf den Switchport binden möchtest nehme ich an der Server ist im gleichen Subnetz und VLAN wie die vor denen du ihn schützen willst? Falls dieser Server oder auch die Server in einem eigenen Subnetz sind wäre eine ACL auf dem router evtl eine alternative.

Ich behaupte mal du hast einfach einen denkfehler mit in und out "ip access-group 102 in" bedeutet das ACL 102 auf allen Verkehr der über diesen Port in den SWITCH EINGEHT angewendet wird. Wenn du also den Verkehr über den Port zum Rechner filtern willst braucht du eine "out" ACL... Für logging: schreib einfach ein "access-list 101 deny ip any any log" dahinter und alles taucht im Syslog (show logging) auf.

1x Wikipedia oder google und man hat es... Für die Kommunikation werden der Server-Port 1723 (TCP) sowie das Protokoll 47 (GRE) verwendet.

Ich würde es so sehen, dass das NAT nur für die Adressübersetzung da ist und gar nicht den Zugriff kontrollieren soll. Daher habe ich auch keine Beschränkungen in den NAT-Access-Lists. Und damit eine Zugriffskontrolle stattfindet filtere ich den Netzwerkverkehr der ins Inside Interface kommt.

genau davon ging ich aus! ;) Allerdings schlage ich vor NAT und Zugriffskontrolle zu trennen: NAT: Du kannst ganz kleine Access-Listen schreiben, eine für jedes Netz das eine eigene externe IP haben soll: access-list NAT_10 permit ip 10.10.10.0 255.255.255.0 any access-list NAT_11 permit ip 10.10.11.0 255.255.255.0 any ... global (outside) 10 80.80.80.80 255.255.255.255 global (outside) 11 80.80.80.81 255.255.255.255 ... nat (inside) 10 access-list NAT_10 nat (inside) 11 access-list NAT_11 ... Zugriffskontrolle: weiter war ich davon ausgegangen das all diese Netze über ein Interface mit der Firewall reden und du daher die Zugriffskontrolle über eine ACL auf dem Interface machen kannst: access-list inside-access-in permit tcp object-group Special_User any object-group EMail_Ports access-list inside-access-in permit tcp object-group ALL_User any object-group Web_Ports access-list inside-access-in deny ip any any access-group inside-access-in in interface inside

Hö?? Nein, die Access-list "inside-access-in" ist doch über eine Access-group einem Interface zugeordnet. Die andere Access-list "NAT_10" ist nur für eins von den NAT-Regeln, hier die 10er.

Hab jetzt nicht wirklich eine PIX hier aber wenn ich es nicht zusehr durcheinander werfe in dieser Art: access-list NAT_10 permit ip 192.168.10.0 255.255.255.0 any global (outside) 10 80.80.80.80 255.255.255.255 nat (inside) 10 access-list NAT_10 usw. für deine verschiedenen internen Netze... access-list inside-access-in permit tcp object-group Special_User any object-group EMail_Ports access-list inside-access-in permit tcp object-group ALL_User any object-group Web_Ports access-list inside-access-in deny ip any any access-group inside-access-in in interface inside Hier wird dann eine ACL für allen Traffic geschrieben. (Ich gehe davon aus das aller Verkehr über ein Interface eingeht.) EDIT: kleinen Fehler mit - und _ in der config korregiert.

Gut, dann kannst du doch fürs NAT Accesslisten schreiben die einfach für alles IP von den Netzen ziehen und für die Zugriffskontrolle eine zusätzliche Accessliste auf dem internen Interface eingehend, über die du die Zugriffe regelst. EDIT: Oder auf dem Externen ausgehend, dann hast du allerdings ggf. Probleme mit den Orginal-Quell-IPs...

Ich versteh noch nicht ganz warum machst du das nicht in eine ACL? Sind die Nat-Einträge wirklich von den Regeln betroffen? Ändert sich an den NAT-Einträgen wirklich öffters was, oder sollen die nur den Hosts aus den verschiedenen Netzen unterschiedliche externen IPs zuordnen?

ip address x.x.x.x x.x.x.x secondary eventuell? (ka ob das auch im gleichen Subnetz geht) Ich verstehe zwar nicht wieso er 2 IPs aus dem gleichen Subnetz haben soll aber ich bin mir sicher, dass das mit 2 VLANs und dem gleichen IP-Subnetz problematisch ist.

Nein, ein 2950 kann das nicht! Ich meine zu wissen, (weiß es aber nicht genau) dass es welche gibt aber soetwas sagen einem die Datenblätter wenn man es wissen muss...

Naja, ich würde es anders formulieren. Wenn du die config wegschreibst (egal ob tftp oder copy&paste oder aufzeichnung) sind in der config nur die Befehle drin die nicht dem default entsprechen. Wenn du nun die startup löschst wird er beim nächsten Hochfahren eine neue running-config erzeugen, die jedoch nicht komplett den Defaultwerten entspricht, es ist z.B. in jedem Interface ein "shutdown". Wenn du nun hingehst und deine gesicherte config mit der schon laufenden running-config kombinierst bleibt "shutdown" stehen. Dagegen wenn du die config per tftp in die startup-config kopierst und dann neustartest (ohne erneut zu speicher natürlich) wird sie wieder 1:1 sein wie sie beim sichern war... Ist halt entweder kombinieren oder kopieren und reload.

Da die PIX ja kein Webserver ist nehme ich an, dass du einen Web-Server der intern steht nach extern verfügbar machen willst? Wenn das der Fall ist würdest du dem Outside-Interface einfach die IP für das VPN geben und für den Web-Server ein Static Nat einrichten.

Naja, wenn die Telekom wirklich nur ein DSL-Modem aufhängt muss auch dieses ja irgendwie angesprochen werden. Da auch bei der Telekom irgendwo durchaus ein Konzept dahinter steckt kann ich mir nicht vorstellen, dass dort dann wieder etwas anderes verwendet wird. Kennen tu ich es auch nur mit Router, aber von der Technik her wäre es auch denkbar SDSL mit PPPoE zu verkaufen.

Ich weiß nicht wer sowas erzählt aber die ASA kann PPPoE http://www.cisco.com/en/US/customer/products/ps6120/products_configuration_guide_chapter09186a008066ebe6.html falls du keinen Zugang hast findest du vielleicht was unter diesem Stichwort: vpdn group group_name request dialout pppoe

ich hab es zwar noch nicht selber gemacht aber werden die evtl vom switch wieder gelöscht oder gibt es einen trust für den DSCP-Wert etwa in der richtung "mls qos trust dscp"