Whistleblower
-
Gesamte Inhalte
368 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Whistleblower
-
-
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
Diese Datei ist für folgende Verwendung ungültig: Sicherheitszertifikat.
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:
052348: Dec 20 07:46:15.758 UTC: CRYPTO_PKI: looking for cert in handle=..., digest=
...
052349: Dec 20 07:46:15.758 UTC: CRYPTO_PKI: Cert record not found, returning E_NOT_FOUND
052350: Dec 20 07:46:15.758 UTC: CRYPTO_PKI: chain received from peer contained only self-signed certs and they were discarded
052351: Dec 20 07:47:32.765 UTC: %CRYPTO-4-IKMP_NO_SA: IKE message from x.x.x.x has no SA and is not an initialization offer
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:
... chain received from peer contained only self-signed certs and they were discarded
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... ?
Authentication has failed. The error code returned indicates the following
reason for failure:
There was an error receiving the CA certificate. The CA server did
not respond for one of the following reasons:
-The enrollment URL entered is incorrect
-The router could not reach the CA server
-The CA server could be offline.
-
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:
-
Die Sachen hier können bestimmt noch raus:
crypto isakmp policy 1
evtl. auch:
crypto isakmp key ***** address x.x.x.x no-xauth
(steht ja alles auch im profile bzw. keyring)
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:
aaa new-model
!
!
aaa authentication login default local
aaa authentication login remoteaccess local
aaa authorization exec default local
aaa authorization network allusers local
!
aaa session-id common
!
[...]
username userxyz privilege 15 secret 5 *************
!
!
crypto keyring L2Lkeyring
description PSK fuer L2L Peers mit dynamischen IPs
pre-shared-key address 0.0.0.0 0.0.0.0 key ******
crypto keyring mainkeyring
description PSK fuer Peer mit fester IP
pre-shared-key address x.x.x.x key ******
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
crypto isakmp key ***** address x.x.x.x no-xauth
!
crypto isakmp client configuration group allusers
key ******
dns 10.10.1.3
wins 10.10.1.3
domain tec.wtg
pool clientpool
crypto isakmp profile mainprofile
description Tunnel feste IPs
keyring mainkeyring
match identity address x.x.x.x 255.255.255.255
crypto isakmp profile allusersprofile
description Remote access users profile
match identity group allusers
client authentication list remoteaccess
isakmp authorization list allusers
client configuration address respond
crypto isakmp profile L2Lprofile
description All L2L peers
keyring L2Lkeyring
match identity address 0.0.0.0
!
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
!
crypto dynamic-map dynmap 5
set transform-set ESP-3DES-SHA
set isakmp-profile allusersprofile
crypto dynamic-map dynmap 65535
set transform-set ESP-3DES-SHA
set isakmp-profile L2Lprofile
match address 110
!
!
!
crypto map staticmap 1 ipsec-isakmp
description Tunnel to router2
set peer x.x.x.x
set transform-set ESP-3DES-SHA
set isakmp-profile mainprofile
match address 101
crypto map staticmap 65535 ipsec-isakmp dynamic dynmap
!
[...]
!
interface FastEthernet4
description $ES_WAN$$FW_OUTSIDE$
ip address x.x.x.x 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
no ip virtual-reassembly
ip route-cache flow
speed 100
full-duplex
crypto map staticmap
!
interface Vlan1
description Inside
ip address 172.16.1.1 255.255.0.0
ip access-group 100 in
no ip proxy-arp
ip nat inside
no ip virtual-reassembly
ip route-cache flow
ip tcp adjust-mss 1452
!
ip local pool clientpool 192.168.11.240 192.168.11.254
ip route 0.0.0.0 0.0.0.0 x.x.x.x
!
no ip http server
ip nat inside source route-map SDM_RMAP_1 interface FastEthernet4 overload
!
access-list 100 remark auto generated by Cisco SDM Express firewall configuration
access-list 100 remark SDM_ACL Category=1
access-list 100 permit ip any any
access-list 100 permit udp any any
access-list 100 permit tcp any any
access-list 101 remark SDM_ACL Category=4
access-list 101 remark IPSec Rule
access-list 101 permit ip 172.16.0.0 0.0.255.255 10.10.0.0 0.0.255.255
access-list 101 permit ip 172.16.0.0 0.0.255.255 192.168.10.0 0.0.0.255
access-list 101 permit ip 192.168.11.0 0.0.0.255 10.10.0.0 0.0.255.255
access-list 101 permit ip 192.168.15.0 0.0.0.255 10.10.0.0 0.0.255.255
access-list 102 remark IPSec Rule
access-list 102 deny ip 172.16.0.0 0.0.255.255 10.10.0.0 0.0.255.255
access-list 102 deny ip 172.16.0.0 0.0.255.255 192.168.10.0 0.0.0.255
access-list 102 deny ip 172.16.0.0 0.0.255.255 192.168.11.0 0.0.0.255
access-list 102 deny ip 172.16.0.0 0.0.255.255 192.168.15.0 0.0.0.255
access-list 102 permit ip 172.16.0.0 0.0.255.255 any
access-list 110 permit ip 172.16.0.0 0.0.255.255 192.168.15.0 0.0.0.255
no cdp run
!
!
route-map SDM_RMAP_1 permit 1
match ip address 102
!
!
[...]
-
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:
crypto dynamic-map dynmap 5
description Mobile_VPN-Clients
set transform-set ESP-3DES-SHA
set isakmp-profile allusersprofile
match address 105
crypto dynamic-map dynmap 65535
description Tunnel_zum_Netgear
set transform-set ESP-3DES-SHA
set isakmp-profile L2Lprofile
match address 110
!
!
!
crypto map staticmap 1 ipsec-isakmp
description Tunnel nach router2
set peer x.x.x.x
set transform-set ESP-3DES-SHA
match address 101
...
access-list 101 permit ip 172.16.0.0 0.0.255.255 10.10.0.0 0.0.255.255
access-list 105 permit ip 172.16.0.0 0.0.255.255 192.168.11.0 0.0.0.255
access-list 110 permit ip 172.16.0.0 0.0.255.255 192.168.15.0 0.0.0.255
und für NAT:
access-list 102 deny ip 172.16.0.0 0.0.255.255 10.10.0.0 0.0.255.255
access-list 102 deny ip 172.16.0.0 0.0.255.255 192.168.11.0 0.255.255.255
access-list 102 deny ip 172.16.0.0 0.0.255.255 192.168.15.0 0.255.255.255
access-list 102 permit ip 172.16.0.0 0.0.255.255 any
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):
access-list 101 permit ip 172.16.0.0 0.0.255.255 192.168.10.0 0.255.255.255
access-list 101 permit ip 192.168.10 0.255.255.255 172.16.0.0 0.0.255.255
access-list 102 deny ip 172.16.0.0 0.0.255.255 192.168.10.0 0.255.255.255
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:
ACLs greifen für VPN-Verbindung nicht?
in Cisco Forum — Allgemein
Geschrieben
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?