Whistleblower

Hi, habe derzeit einige feste VPN-Tunnel auf einem Cisco 871 konfiguriert. Für gewöhnlich sind das L2L-Verbindungen, bei einem soll jetzt aber der Zugriff auf einzelne Hosts eingeschränkt werden. Habe dementsprechend eine ACL angelegt bzw angepasst und die auf das externe Interface (Fast Eth4) gebunden. Sie scheint aber nicht zu greifen, denn ich habe auch weiterhin noch durch den Tunnel Zugriff auf andere Hosts... Wahrscheinlich mache ich hier einen Denkfehler und muss als ACL dieselbe verwenden, die ich als IPSec-ACL (also welcher Traffic verschlüsselt werden soll) verwende? Greift die ACL auf Fast Eth4 evtl. nur für Verbindungen, die mit öffentl. IP reinkommen?

Hallo zusammen, haben hier zwei 2003-Server als Fileserver an zwei Standorten in Betrieb. Diese werde täglich synchronisiert. Im Anmeldeskript des zusätzlichen 2003 DCs sind net use-Verweise auf die jeweiligen Freigaben. Momentan sind diese noch manuell gepflegt, zukünftigt soll die Entscheidung, welcher User zu welchem der beiden Fileserver verbunden wird, aber über das Skript abgefragt werden, also z.B. anhand der Netz-Adresse des Users. Also z.B. in der Weise: if gateway==192.168.200.1 then net use x: \\Server2\Freigabe else net use x: \\Server1\Freigabe Habt Ihr sowas schon einmal umgesetzt, am besten wäre es ohne VBS, wenn möglich... ?

Hi Wordo! Ja, das Thema ist noch aktuell, war nur ein paar Tage krank... :-( Die IOS Version ist C870-ADVSECURITYK9-M 12.4(9)T1, aber unterstützt scheinbar auch noch kein QoS, zumindest habe ich im SDM nicht die Möglichkeit, QoS zu konfigurieren... Was mich ja etwas irritiert, ist die Tatsache, dass VoIP über feste Tunnel problemlos funktioniert (derzeit 3 feste Tunnel), aber bei SIP über den Cisco VPN-Client quasi gar nichts verständlich rüberkommt. Kann man bei dem Client eigentlich QoS einrichten? Was kann ich ansonsten noch auf dem Router testen? Evtl. Bandbreiten reservieren?

Das ganze ist meist komplett abgehackt, und mit nem dicken delay (1-2 Sec). Dachte erst, es würde an der Verbindung des Clients liegen (erster Test ging über UMTS), da waren schon ping-Zeiten ins Internet bei ca. 400-500ms, bei Einwahl über ISDN oder ADSL (ping heise.de bei 60ms) ist es aber auch nicht wirklich besser... Mit den anderen Daten muss ich Dich später mal versorgen, den SIP-Server habe ich nicht aufgesetzt... Das VPN läuft über den Cisco VPN-Client. Der Router ist mit T-DSL 3000/512 angebunden, wir hatten allerdings schon immer Probleme mit Fragmentierung, evtl. muss ich da auch nochmal an der MSS/MTU drehen, wobei wir bald auf 16000/1024 umsteigen... Da lohnt das Austesten des alten Anschlusses wohl nicht mehr...

N'Abend Daking! Schönen Dank schon mal für die Info! Thema SIP ist auch gerade recht neu für mich, habe da noch keinen wirklichen Plan von. Bin mir auch nicht sicher, ob das IOS auf dem Router (Cisco 871 mit Adv. Sec/IPSec) die von Dir vorgeschlagenen Einstellungen unterstützt, muss ich mal verifizieren. Der Hintergrund ist der, dass unsere "Roadwarrior" sich per VPN auf den Cisco connecten (das läuft mittlerweile auch alles sehr zufriedenstellend) und dann über ein Softphone sich an unserem (bisher nur) internen SIP-Server anmelden. Bis dahin klappt das auch, allerdings ist die Sprachqualität miserabel bis gar nicht vorhanden. Ein "normales" IP-Endgerät, was sich über den Tunnel ebenfalls an unserer VoIP (nicht SIP)-Anlage anmelden, zeigt da hingegen keine Probleme. Evtl. kann es auch am Softphone liegen, müsste ich mal sehen, ob ich da noch ein alternatives zum testen finde. Intern hingegen funzt das Telefonieren über Softphone und SIP-Server hingegen wieder... Also vermutlich doch eher Probleme über die VPN-Verbindung...

Hi! FROHES NEUES! Hat sich hier eigentlich schon mal jemand mit dem Thema SIP beschäftigt und der entsprechenden Priorisierung dazu auf Cisco-Routern? Ist da ein identisches CoS/QoS wie bei "normalem" VoIP-Verkehr vonnöten, oder ist bei SIP noch etwas anderes zu beachten?

Ja, das hab ich auch schon mitbekommen, dass er das dauerhaft speichert (12.4 läuft auf dem Cisco). Ist ja auch in Ordnung soweit, sonst hätte man VPN-technisch mit nem selfsigned Cert echt Trouble, wenn sich der Key nach jedem Stromausfall/reboot wieder ändert... Ich werde das wohl bei Gelegenheit mal im Lab mit self-signed Certs versuchen, sollte ja eigentlich gehen...

Hm, wär noch ne Idee, wo hast Du das denn wieder hergezaubert? Im Buch finde ich sonst nur schwerpunktmäßig was zu CA...

So, bin jetzt erstmal auf PSK ausgewichen, damit gibts keine Probleme... Würde mich aber trotzdem mal interessieren, ob und wie das ganze mit selfsigned Certis geht...

Damit kann ich leider nicht dienen, nicht meine Baustelle... Habe aber noch ein anderes Problem... Habe auf dem Cisco nochmal alle Keys gelöscht (zeroize rsa) und anschließend einen neuen key angelegt, und damit ein selfsigned Cert erstellt. Wenn ich das jetzt exportiere und unter Windows zum Anschauen öffnen will, bekomme ich die Fehlermeldung Ich vermute mal, dass das an der Passphrase liegt, die Cisco zwingend beim Export verlangt? Kann ich das irgendwie umgehen?

So, hab mal ein neues Thema aufgemacht, der alte Thread passt ja nicht mehr ganz zur Überschrift... ;-) Ich kämpfe gerade damit, zwei Standorte mit einem zertifikatsbasierten VPN zu verbinden. Früher setzten beide Lokationen Linux-Server (BenHur/Collax) mit selfsigned Certis ein. Jetzt steht auf einer Seite ein Cisco 871, die andere Seite ist Linux wie gehabt. Eine CA-Struktur ist nicht vorgesehen. Der Cisco hat ein selfsigned Certifikat, die Gegenseite ist als Trustpoint mit ihrem public key auf dem Cisco eingetragen. Bekomme trtozdem noch folgende Fehlermeldungen: Daraus entnehme ich zwei Probleme: - Der Cisco akzeptiert keine selfsigned Certs (warum auch immer) - Die Gegenstelle hat evtl. mein Cert nicht (richtig) installiert Wie bekomme ich den Cisco dazu, das Cert der Gegenseite zu akzeptieren? Der Publickey als auch der Fingerprint sind ihm schon bekannt...

So, ich konnte noch etwas klären... Die Gegenseite verwendet auch nur self-signed Zertis, keine CA, also werde ich auch mit self-signed arbeiten... Die Frage ist nur - wie? Und vor allem, wie bringe ich dem Cisco bei, dass er das self-signed von der Gegenstelle annimmt? Aktuell verwirft er es noch: Muss ich noch einen Trustpoint für diese Gegenstelle auf dem Cisco einrichten? Zum Thema self-signed findet man leider recht wenig...

Klar, die Sinnhaftigkeit des ganzen habe ich auch schon angezweifelt... Aber was hilfts, wenn der Standort unbedingt mit Zertis arbeiten will... :-( Da ist dann wohl mal unternehmensweite Abstimmungsarbeit erforderlich...

Hm, vielleicht, ganz klar ist mir das noch nicht... Ich habe auf jeden Fall hier eine CA auf dem 2003-Server. Am anderen Standort ist mit Sicherheit auch eine CA, ob es sich dabei um die gleiche Linux-Maschine handelt, wie die auf der das VPN läuft, weiss ich nicht. Meine CA erstellt mir für den Cisco ein gültiges Zertifikat. Dieses Zertifikat (bzw. der public key davon) muss der Gegenstelle bekannt sein. Ebenso muss meinem Cisco bzw. meiner CA das Zerti des anderen Stanorts bekannt sein, oder? Korrigiert mich, wenn ich noch Denkfehler mache...

Hm, wo finde ich die IIS-Logs? Vielleicht nochmal ein paar Details, was gemacht werden soll: Zu einem Standort soll ein zertififkatsbasiertes VPN gemacht werden. Dort wird eine Linux-Lösung für das VPN verwendet. Öffentlicher Teil des Zertis liegt vor, lässt sich auch ohne weiteres auf der CA installieren. Einerseits brauche ich jetzt von dem hiesigen Cisco-Router den public key, um ihn am anderen Standort installieren zu können. Wollte ich über SCEP bewerkstelligen, funzt aber ja noch nicht so richtig... Andererseits muss der Schlüssel des anderen Standortes auf den Cisco bzw. auf die CA (aber da ist er ja schon installiert)... Wo ist mein Buch??? ;-)

Hm, irgendwie kann ich vom Cisco noch kein Enrollment ausführen... Server ist erreichbar, SCEP läuft auch, aber evtl. erwartet Cisco die URL in einer anderen Form? gebe bisher http://servername/certserv/mscep/mscep.dll an. Bekomme dann aber vom SDM die Fehlermeldung, dass der Server auf die Anforderung nicht reagiert hat... ?

MS gibt da selbst Hilfestellung zu beim Installieren der Zerti-Dienste... Ansonsten Links hier: Microsoft Certification Authority und direkt zu Stand-Alone CAs ohne zwingendes ADS: MS - Stand-alone Certificate Authority

Die Sachen hier können bestimmt noch raus: Habe in dem Zuge auch gleich den Traffic von den mobilen Clients über den festen Tunnel zur anderen Niederlassung ermöglicht. Die Probleme lagen einerseits in der ACL 101 (zu verschlüsselnder Traffic) andererseits in ACL 102 (Ausnahmen vom NAT). Jetzt hab ich nur noch so ein minimales Problem, und zwar wie ich dem Router selbst sage, dass er Pakete, die von ihm ausgehen (z.B. ein ping) in den entsprechenden Tunnel schickt. Wenn ich also z.B. auf dem Router "ping 10.10.1.1" eingebe, erhalte ich keine Antwort, sondern nur wenn ich als source vlan 1 angebe. Beim ping mag das ja noch okay sein, aber bei einem copy xyz tftp kann ich das vlan nicht als Source angeben... Ist doch bestimmt nur ein Einzeiler, der mir da fehlt, oder?

So, wie versprochen, die entsprechenden Passagen der Konfig:

FUNZT !!! :D :D :D :D Mehr dazu morgen!

Werde ich heute abend nochmal machen... Und ich werde auch nochmal für die beiden dynamic-maps jeweils eine ACL erstellen und als match mit aufnehmen... Dann sollte es ja eigentlich klar sein, welcher Traffic worüber geht: So in der Art: und für NAT: Und damit VPN-Clients vom Router2 auch über den Tunnel auf Router 1 kommen, müsste ich noch sowas einfügen, oder? (lokales Netz der Clients 192.168.10.10 - .20): Und entsprechend auf der Gegenseite... Bei der Gelegenheit werde ich die ACLs auch mal BENENNEN... Steigt man ja sonst nicht mehr durch...

Hm, stimmt... Irgendwie stehen die da nicht drin... :o Aber das Problem muss noch irgendwo anders liegen, die ACLs greifen ja erst in Phase 2, und so wie ich das bis jetzt sehe, scheitert schon Phase 1... Die Debugs habe ich jeweils auf beiden Ciscos angeschmissen...

Achso, dann erlaube in Deinem Profil doch bitte mal, dass ich Dir ne eMail schicken kann... für eine priv. Nachricht ist die Konfig zu lang...

Ich mache NAT, das stimmt, aber die Routemap verweist auf ACL102, die wiederum denys für den Traffic zwischen den Netzen macht (z.B. deny ip 172.16.0.0 0.0.255.255 10.10.0.0 0.0.255.255). Also sage ich damit letztendlich, dass er den Traffic nicht natten soll, alles andere (ip permit 172.16.0.0 0.0.255.255 any) hingegen schon. So hab ich's bisher zumindest verstanden, und war auch ganz einleuchtend für mich... Und, ja entweder SDM oder alles per CLI, ich weiss... Aber alles geht leider auch nicht per SDM, und die Anfangskonfig habe ich "damals" mit dem SDM erstellt... Keine Frage, dass das ganze der Verständlichkeit wegen überarbeitet werden sollte... Werd Dir die Konfig nochmal schicken, muss mal sehen, ob ich die gerade vollständig hier habe, ist ja immer nur eine Testconfig...

Das Profil und den keyring brauche ich, um unterscheiden zu können, ob der Tunnelaufbau durch einen Client oder den Netgear (beides mal dynamische IP) erfolgt. Zumindest habe ich das jetzt so verstanden aus der Anleitung von Cisco: Configuring an IPSec Router Dynamic LAN-to-LAN Peer and VPN Clients [iPSec Negotiation/IKE Protocols] - Cisco Systems