Vpro Zugriff via DDNS Dienst

skylake1151

New Member
Guten Abend liebe Forumsmitglieder,
ich bin neu im Forum und freue mich auf konstruktiven Kenntnisaustausch. Ich hoffe auch ich habe das richtige Genre gewählt, da ich keines mit Fernwartung/Fernzugriff finden konnte, es gibt lediglich noch das Genre Monitoring, welches zwar einen Fernzugriff impliziert, aber wahrscheinlich eher auf Monitoring Tools abzielt, wie ich vermute. Falls ich mich irre bitte ich dies zu verzeihen!

Wie der Titel schon verrät, handelt es sich um den KVM over IP Dienst von Intel, sprich Vpro. Ich muss zuvor anmerken, dass ich in dieser Thematik gerade selbst erst am probieren bin und kein erfahrener Anwender mit Vpro bzw. KVM over IP bin.
Ich habe zu Testzwecken ein Skylake System aufgebaut und versuche momentan mich in das Thema Fernsteuerung via Vpro (u.a. auf Bios Ebene) über das Internet kundig zu machen.

Folgende Komponenten sind im Einsatz:
Asus Q170m-c Motherboard
Intel i5 6400
Gskill DDR4 Ram (kein ECC!)
Samsung EVO 850 512GB SSD im RAID

Betriebssystem ist Windows 10 Pro x64 (also kein Server Betriebssystem)

Wiegesagt handelt es sich um ein Testsystem und dient aktuell nur der Kenntnisschöpfung für Vpro von Intel welches von den Q-Serie Mainboards unterstützt wird und ebenso von den I7 und I5 CPUs von Intel (Skylake).

Nun zu meiner Frage:
Ich habe das KVM ober IP mittels Vpro bereits im Netzwerk unverschlüsselt einwandfrei zum Laufen bekommen. Lediglich der Zugriff via DDNS bei einer nicht festen IP scheitert. Ich stelle den Zugriff mittels dem RealVNC Viewer Plus her. Der Router der das Netzwerk verwaltet ist eine Fritzbox 7490 und es sind auf den Client Rechner mit Vpro folgende Portfreigeben eingerichtet:
16992/16993 UDP und TCP
Ebenso für den Remotedesktop der 3389 (hat aber hier meines Wissens keinen Einfluss).
Ebenso ist ein DDNS aufgrund der wechselnden IP eingerichtet und voll funktional (getestet mit WOL und Remotedesktop).
Das Eigenartige ist, wenn ich via DDNS auf den Rechner zugreifen will, erscheint sogar das Login Fenster für Benutzername und Passwort im RealVNC Viewer Plus, so wie bei der Lokalen Verbindung auch, allerdings wenn ich dann den Benutzer und das Passwort eintrage, bricht dieser nach einer ca. 2 Minütigen Warteschleife mit der Fehlermeldung: "KVM Tunnel disconnected" ab. ich vermute, dass ggf. in irgendeiner KVM config hier noch eine Prüfung und Übergabe des Nameservers und der DDNS Verbindung zu hinterlegen sind. Ggf. auch im Bios unter der MEBx (ME) Einrichtung.
Ich weiß leider nur nicht, wo diese KVM config ggf. zu finden ist unter Windoof 10. Ebenso ist dies auch nur eine Spekulation, ggf. ist es ja bereits mit einer Parameterübergabe im VNC Viewer gelöst. Hier habe ich bereits folgendes (erfolglos) probiert (Die IP adresse ist nur beispielhaft gewählt!):
1. DNSDomain => ich konnte mich einloggen werde aber mit der Fehlermeldung nach einer langen Wahlschleife mit der oberen Fehlermeldung "KVM Tunnel disconnect" herausgeschmissen.
2. DNSDomain/192.168.178.10 => Nimmt RealVNC nicht an
3. DNSDomain:192.168.178.10 => Selbiges wie Punkt 1
4. DNSDomain\192.168.178.10 => Nimmt er nicht an
5. 192.168.178.10.DNSDomain => Siehe Punkt 1
6. DNSDomain.192.168.178.72 => Nimmt er nicht
7. DNSDomain:16992 => Siehe Punkt 1
8. SystemName. DNSDomain => Siehe Punkt 1
9. 192.168.178.10. SystemName.fritz.box.DNSDomain => Siehe Punkt 1
10. 192.168.178.10. SystemName.DNSDomain => Siehe Punkt 1
11. DNSDomain:192.168.178.10.SystemName.fritz.box => Siehe Punkt 1

Es wäre sehr cool, wenn hier ggf. ein KVM over IP Profi der Erfahrung mit Vpro hat einen Tipp für mich hätte!

In diesem Sinne einen schönen Abend!
 
Last edited by a moderator:
Alle Varianten bis auf die erste und siebte sind ziemlich unsinnig. Per DDNS bekommt du ja nur die IP deines Internet-Anschluß zurück.
Sofern du in deinem internen Netz keinen speziellen Port im VNC-Viewer eingeben mußt, dann fehlt dir einfach noch die Portweiterleitung des Ports 5900 (Standard-VNC-Port) in der Fritzbox auf die vPro-IP.
Es kann natürlich auch möglich sein, dass dein Provider dir keine echte öffentliche IP zuweißt, sondern mit NAT arbeitet (bei vielen TV-Kabelprovidern der Fall) - dann wird es schwierig.
 
Alle Varianten bis auf die erste und siebte sind ziemlich unsinnig. Per DDNS bekommt du ja nur die IP deines Internet-Anschluß zurück.
Sofern du in deinem internen Netz keinen speziellen Port im VNC-Viewer eingeben mußt, dann fehlt dir einfach noch die Portweiterleitung des Ports 5900 (Standard-VNC-Port) in der Fritzbox auf die vPro-IP.
Es kann natürlich auch möglich sein, dass dein Provider dir keine echte öffentliche IP zuweißt, sondern mit NAT arbeitet (bei vielen TV-Kabelprovidern der Fall) - dann wird es schwierig.

Hallo Danton,
erst einmal vielen Dank für deine Antwort! Es wird noch eine reguläre IPv4 und IPv6 zugewiesen (Es ist kein Kabelprovider oder neuer Vertrag, der via NAT regelt). Der DNS ist foll funktional über Remotedesktop, Fritzboxfernzugriff und WOL Magic Packet Sender, daher schließe ich diesen aus. Ich habe wie von dir empfohlen den 5900 Port (TCP) freigegeben, allerdings leider auch ohne Erfolg über DNS. Wiegesagt lokal über die IP oder den Gerätenamen komme ich sofort via VNC Viewer Plus in KVM Modus und kann ins Bios oder OS starten. Es geht nur nicht über den DNS. Hier lässt er mich zwar den Vpro Benutzernamen und das Passwort eintragen, bricht danach aber mit der Meldung "KVM Tunnel Disconnected" ab.
Eventuell gibt es ja speziell für eine DNS Verbindung eine Konfiguration, die hier getroffen werden muss.
In diesem Sinne einen schönen Sonntag!
 
Deine Parameterübergabeversuche lassen bei mir nur den Schluß zu, dass Du nicht weißt, wie eine URL aufgebaut ist:

https://de.wikipedia.org/wiki/Uniform_Resource_Locator

Für Eingaben in seperate Programme (wie VNC) gelten ähnliche Konventionen, daher kann es nicht schaden, sich dies genauer anzusehen.

Bevor Du wild rumprobierst, solltest Du lieber systematisch vorgehen und dabei die Dokumentation Deines Mainboards und den User Guide von VNC Viewer Plus ( https://www.realvnc.com/docs/_downloads/VNC_Viewer_Plus_User_Guide.pdf insbesondere ab S18) ansehen.

Einige Punkte:
Auf S47 steht folgendes:
Intel AMT requires the following ports to be accessible on the host computer:
• 16993 and 16995 (for encrypted connections)
• 16992 and 16994 (for unencrypted connections)

Offensichtlich reicht also 16992 alleine nicht aus. 16994 muss auch noch freigegeben sein (für unverschlüsselte Verbindungen ( http:// ). Womöglich wird dieser Port genau für den zweiten Schritt benötigt und ist nicht weitergeleitet.

Zu Deinen haarsträubenden Versuchen möchte ich Dir gerne sagen, was sie bedeuten:
2. DNSDomain/192.168.178.10 => Ist auf der Website "DNSDomain" der Unterordner "192.168.178.10". Macht null Sinn.

3. DNSDomain:192.168.178.10 => ":" hinter einem DNS Namen gibt immer einen Port an. Das wäre also theoretisch DNSDomain mit Port "192.168.178.10", wobei das so nicht existiert, Ports gibt es nur von 0 bis 65535 ( siehe und verstehe!! https://de.wikipedia.org/wiki/Port_(Protokoll) ). Macht null Sinn.

4. DNSDomain\192.168.178.10 => Das wäre (in einem Windows Anmeldebildschirm) der Benutzer "192.168.178.10" am Rechner oder dem Active Directory "DNSDomain". Macht null Sinn.

5. 192.168.178.10.DNSDomain => Ist eine "Pseudo-TLD" (z.B. ".local" für kleine lokale Netzwerke, von deren Nutzung abgeraten wird ( https://en.wikipedia.org/wiki/.local ).

6. DNSDomain.192.168.178.72 => Komplett sinnfrei!

7. DNSDomain:16992 => "DNSDomain" mit Port 16992 ansteuern (eine der wenigen Dinge, die zumindest eine richtige Schreibweise haben. Ob hinter dem Port 16992 jedoch was kommt, hängt von der Weiterleitung im Router und dem Service auf dem Zielrechner ab.

8. SystemName. DNSDomain => Ist eine lokale PseudoTLD (siehe 5.), in diesem Zusammenhang ziemlich sinnfrei, mit Leerzeichen sogar falsch.

9. 192.168.178.10. SystemName.fritz.box.DNSDomain => kompletter Käse.

10. 192.168.178.10. SystemName.DNSDomain => Noch mehr Käse.

11. DNSDomain:192.168.178.10.SystemName.fritz.box => Käse mit KRONE im ausgeschlagenen Fass!!!?!? :eek:
 
MOD EDIT: Fullquote entfernt.

Hallo Thunderbyte,
danke für die Hinweise, es war tatsächlich der unencrypted Port, der nicht freigegeben war und somit der KVM Tunnel disconnected wurde! Auch mit dem Domainaufbau liegst du absolut richtig und danke für die Links, diese werden definitiv als Lesezeichen gespeichert! Das meine Versuche nach Punkt 1 an sich Müll waren dachte ich mir schon fast.
Aber im Ernst, vielen Dank für deine Hinweise, ich werde alle beherzigen.
Die unverschlüsselte Verbindung steht nun und ich bin schon mal sehr froh. Zu meiner Schande muss ich gestehen, dass ich das mit den Ports sogar gelesen hatte, jedoch dachte 16992 und 16993 gehören zusammen und somit nur diese beiden geöffnet hatte (Asche über mein Haupt!).
Da du hier sichtlich bereits eine Menge Erfahrung vorweisen kannst, hast du ggf. für mich noch einen Tipp in Bezug auf TLS Verschlüsselung mit dem Real VNC Viewer? Ich denke Stufe zwei sollte unbedingt ein VPN und eine TLS Verschlüsselung sein, wenn ich irgendwann tatsächlich Vpro nutzen möchte (ich hoffe hier liege ich zumindest richtig)?

In diesem Sinne vielen Dank Thunderbyte und einen schönen Sonntag Abend!
 
Last edited by a moderator:
Zu VNC kann ich nicht viel sagen, da ich es nicht verwende (RDP für MS Server, SSH für Linux).

Verschlüsselung hin oder her. Ich würde den BIOS Zugriff niemals übers Internet erreichbar machen, da Dir ein Angreifer so den Rechner unbrauchbar machen kann. Ich würde viel eher im Router einen VPN Server konfigurieren, mich über diesen von außen einwählen und dann o.g. Geschichte "lokal" im VPN machen. So kommst Du zum gleichen Ergebnis, kannst noch viel mehr Dienste (auch alle bisher genannten) "lokal" nutzen und setzt Dich nicht dem Sicherheitsrisiko aus, dass die VPro Implementation von Intel / dem MB Produzenten löchrig ist.

EDIT: Und bitte mach keine Fullquotes. Diese müsste ich das nächste Mal verwarnen.;)
 
Last edited by a moderator:
Hallo Thunderbyte,
danke für deine Informationen, das mit den Quotes ist vermerkt und wird in Zukunft nur noch entsprechend auf eine Aussage angewandt!

In diesem Sinne, einen optimalen Wochenstart!
 
Back
Top