Jump to content

shoty

Members
  • Content Count

    90
  • Joined

  • Last visited

Community Reputation

10 Neutral

About shoty

  • Rank
    Junior Member
  • Birthday 04/19/1981
  1. Ich hab den Fehler gefunden. Wenn man bei dem Thumprint auch den richtigen Fingerabdruck der Stammzertifizierung einträgt, funktioniert die Sache auch sauber!! $Thumbprint = ‘Root CA Certificate Thumbprint’ $RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint}) Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force Restart-Service RemoteAccess -PassThru Danke für eure Hilfe...
  2. Die interne IP ist natürlich eine andere wie die externe. Das sollte aber meines Wissens kein Problem sein, da ich hier mit dem dns Namen in der Sperrliste arbeite. Den Client kenne ich, kostet aber nicht ganz wenig!
  3. PKIView sagt, wenn ich es von meinem Admin Rechner Ausführe: Alles OK, bis auf AIA-Speicherort #1 -> Download ist nicht möglich. Ort -> http://xxxx.xxxx.de/ocsp -> was immer das bedeuten mag!?
  4. Guter Plan, ich kann auch gleich den RAS Server ausschalten, dann hab ich auch nicht mehr das Problem Hab ich auch schon gemacht, das merkwürdige dabei, ich sehe keine Anfragen, das der RAS Server überhaupt versucht die CRLs Richtung CA Server abzufragen!? Die CRL ist von extern über einen Reverse Proxy erreichbar, der es dann nach intern zur CA weiterleitet. Die IP, bzw. der Name ist intern sowie extern gleich.
  5. Hi Zahni, der RAS Server steht im DMZ und geht auch nicht über einen Proxy. Der Internetzugriff ist auch blockiert. Es sind nur die Wege ins Interne Netz offen, wie z.B. zur CA und den internen Servern. DMZ: RASServer -> Firewall -> Firewall -> Internes Netz: CA Server
  6. In der Sperrliste stehen nur URLs drin, siehe: [1]Aktuellste Sperrliste Name des Verteilungspunktes: Vollst. Name: URL=http://xxx.xxx.de/pki/XXXStammzertifizierung(1)+.crl diese Adresse ist auch von extern und intern erreichbar und es wird auch das Sperrlistenzertifikat angezeigt.
  7. Microsoft Support hab ich auch schon Kontaktiert, die Antwort war, dass es eine HowTo-Frage sei. Sie würden nur Probleme bearbeiten, die vorher schon mal funktioniert hätten. Ich hab es eskalieren lassen und seit dem nichts mehr gehört! Danke Microsoft! Ich hab nun den Richard Hicks mal angeschrieben, mal schauen...
  8. Hat denn sonst niemand eine Idee, nach was ich noch schauen kann, wenn die Sperrlisten nicht abgerufen werden können? The revocation function was unable to check revocation because the revocation server was offline
  9. Always On VPN ist ja quasi der Nachfolger von Direct Access. Vielleicht hat das noch nie funktioniert! Hab das gerade mal mit dem Computerkonto sperren getestet. Da der Rechner ja im lokalen Zustand hochfährt und dann erst die VPN Verbindung aufbaut, scheint ihn das sperren des Kontos nicht zu interessieren, ich kann trotzdem überall drauf zugreifen!? Hilft mir also auch nicht weiter!
  10. Hallo, ich bin etwas verzweifelt. Ich habe einen RAS Server für eine AlwaysON VPN Einwahl aufgesetzt. Die Clients wählen sich per IKEv2 Computerzertifikat und Devicetunnel automatisch ein. Dies funktioniert auch ohne Probleme. Nun möchte ich ein Computerzertifikat sperren (im Fall eines Notebookdiebstahl z.B.). Nachdem ich das Zertifikat gesperrt habe kann sich aber der Client weiterhin einwählen per VPN!? Die Sperrlisten werden einwandfrei verteilt und sind auch von extern sowie intern erreichbar. Komischerweise bekomme ich immer auf dem RAS Server unter den CAPI2 Eventlog die Meldung: The revocation function was unable to check revocation because the revocation server was offline Über Certutil kann ich auch ohne Probleme die Sperrlisten vom RAS Server abfragen. Die Verbindung scheint hier also kein Problem zu sein. Ich verstehe nicht, woran es noch liegen kann. Hat vielleicht jemand schon mal mit einem gleichen Problem gekämpft? RAS Server - Windows 2019 - steht im DMZ CA Server - Windows 2016
  11. Moin, hier die Konfig des Ports: Hauptverwaltung: interface GigabitEthernet1/0/13 switchport access vlan 10 switchport trunk encapsulation dot1q switchport trunk native vlan 10 switchport voice vlan 20 mls qos trust device cisco-phone mls qos trust cos spanning-tree portfast Außenstellen: interface FastEthernet0/8 switchport access vlan 10 switchport voice vlan 20 mls qos trust device cisco-phone mls qos trust cos spanning-tree portfast Kabel sind alle in Ordnung, am PC merkt man auch keinen bemerkenswerten Ausfall! Manchmal hängt Outlook, aber ob das jetzt damit was zu tun hat?
  12. Die kommen aber momentan auch, wenn der Rechner nicht neu gestartet wird?!
  13. Hi, ich bekomme schon seit längerem auf meinen Switchen z.B.: (C3750E-UNIVERSALK9-M), Version 12.2(40)SE, (C3560-IPBASE-M), Version 12.2(35)SE5 egal welches Stockwerk oder auch in Außenstelle die Meldung LINK-3-UPDOWN An den Ports sind Mini PCs (Zotac Clients mit NIC Realtek) oder auch Laptops (NIC Intel) alle mit Win 7 angeschlossen. Die Ports stehen alle auf Auto und zeigen auch keine Merkwürdigkeiten!, für mich zumindest!? GigabitEthernet1/0/13 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 011g.5452.d61d (bia 021g.5420.d70d) MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX input flow-control is off, output flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output 00:00:00, output hang never Last clearing of "show interface" counters 8y9w Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 17185123 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 9000 bits/sec, 15 packets/sec 1210559194 packets input, 179098283037 bytes, 0 no buffer Received 206717 broadcasts (87426 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 87426 multicast, 0 pause input 0 input packets with dribble condition detected 2798061682 packets output, 2760326933566 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out 065438: .Dec 10 10:21:40 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/9, changed state to down 065439: .Dec 10 10:21:42 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/9, changed state to up 065440: .Dec 10 10:21:45 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/9, changed state to down 065441: .Dec 10 10:21:46 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/9, changed state to down 065442: .Dec 10 10:21:48 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/9, changed state to up 065443: .Dec 10 10:21:49 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/9, changed state to up 065444: .Dec 10 10:22:17 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/9, changed state to down 065445: .Dec 10 10:22:18 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/9, changed state to down 065446: .Dec 10 10:22:20 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/9, changed state to up 065447: .Dec 10 10:22:21 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/9, changed state to up 065448: .Dec 10 12:52:00 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/13, changed state to up 065449: .Dec 10 12:52:01 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/13, changed state to up 065450: .Dec 10 12:52:03 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/13, changed state to down 065451: .Dec 10 12:52:04 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/13, changed state to down 065452: .Dec 10 12:52:07 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/13, changed state to up 065453: .Dec 10 12:52:08 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/13, changed state to up 065454: .Dec 10 12:53:32 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/13, changed state to down 065455: .Dec 10 12:53:33 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/13, changed state to down 065456: .Dec 10 12:53:36 MEZ: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/13, changed state to up 065457: .Dec 10 12:53:37 MEZ: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/13, changed state to up Kann ich diese Meldungen ignorieren? Oder scheint da was nicht in Ordnung zu sein. Die Meldungen sind weit verbreitet und fast auf jedem Switch zu finden. Oder was kann ich auch dagegen tun? Hat jemand schon mal das Problem gehabt?
  14. Bei den lokalen Win 7 Gruppenrichtlinien ist die Einstellung vorhanden! Was auch komisch ist, jetzt hab ich auf meiner Testdomäne geschaut und da ist auch die Einstellung "Dateien aus der Zwischenspeicherung ausschließen" vorhanden! Was ist das denn??? :confused:
×
×
  • Create New...