Hyper-V unter Windows 10 und Fritz!Fernzugang

[JastiU 0]

Moin,

 

hallo allerseits. >Neuer User< hier.

 

Mein Anliegen:

Ich hab' mir auf einem Windows 10 Client einen Hyper-V installiert und darauf weitere Windows 10 VMs angelegt.

Ich nutze zwecks Verbindung der VMs den >Default Switch< des Hyper-V, was auch ordentlich funktioniert. Soweit so gut.

Auf einer der VMs habe ich nun einen Fritz!Fernzugang installiert und nutze dafür eine Konfiguration, die auf meinem Laptop bereits funktioniert.

In der VM kann ich mich unter Verwendung des dyndns Eintrags von "myfritz.de" auch wunderbar per Firefox auf die Fritzbox verbinden.

 

Allein: Das VPN baut sich nicht auf.

Die Fehlermeldung lautet etwa: "Verbindungsaufbau fehlgeschlagen. Die Gegenseite konnte nicht erreicht werden"

(Etwa ... weil die Meldung im Statusbereich des Fensters viel zu schnell verschwunden ist, als dass man sie ganz erfassen könnte )

 

Aus den Logfiles die einzige vorhandene Fehlermeldung:
avmike: <*****>.myfritz.net: Phase 2 failed (initiator): timeout, abort.

(<*****> Host entfernt - ist aber über Webbrowser erreichbar, nslookup zeigt auch eine fehlerfreie Auflösung)

Fritz!Fernzugang hab' ich in der Firewall der VM bereits freigegeben (f. privat u. öffentlich)

(Auf dem Windows10 Laptop brauch' ich das nicht ... aber man weiss ja nie ...)

Sind evtl. weitere ausgehende Ports manuell zu öffnen?

Edith sagt: Firewall ausgeschaltet => gleiches Problem. D.h. an der Firewall in der VM liegt's nicht.

 

... jetzt ist meines Wissens nach der Fritz!Fernzugang ein IPSec

Ist jemandem bekannt, was man tun muss um IPSec aus einer VM heraus zu ermöglichen?

Die SSL-VPNs der anderen VMs tun alle klaglos.

 

Danke vorab für Eure Zeit.

bearbeitet 30. April 2020 von JastiU

[daabm 1.366]

Ich weiß jetzt nicht, wie dein "Default Switch" konfiguriert ist - wenn der NAT macht, wird das nix. Dem Browser ist das egal, SSL auch, dem IPSec nicht.

[JastiU 0]

Wenn ich Dich richtig interpretiere, bist Du der Meinung, dass der sogenannte "Default Switch" kein NAT-T kann ... und ich fürchte, damit liegst Du richtig.

 

Leider sitzt der "Default Switch" auf meinem einzigen Netzwerkinterface. Siehe mikefrobbins blog zwecks Problembeschreibung. Deshalb funktioniert das Einrichten eines "externen Switches" (zur Umgehung von NAT) in Hyper-V nur begrenzt. Will heißen: Ich kann ihn zwar einrichten, die VMs bekommen trotzdem keine Verbindung zum Netzwerk des Hosts.

 

Ich werde morgen mal schauen, ob ich auf die Schnelle ein zweites Netzwerkinterface auftreiben kann...

bearbeitet 1. Mai 2020 von JastiU

[daabm 1.366]

Du mußt doch nur nen Switch einrichten, der direkt mit dem LAN verbunden ist (bridged)... Edit: "Glaube ich zumindest"

bearbeitet 1. Mai 2020 von daabm

[JastiU 0]

Hiermit beglückt mich Microsoft - sprich: Ich kann's nicht löschen. Es ist einfach da und kommt immer wieder.

 

 

 

Das hab' ich zur Auswahl...

 

 

 

... und dabei ensteht das folgende Problem (vergleiche das Netzwerkinterface mit dem des Defaultswitches)

Zwei Switche auf einem Netzwerkinterface => f'up. Sprich: Da bridged nix sondern es nattet, dank des Default Switches (s.o.)

 

 

 

Wenn Du einen Vorschlag hast ... immer her damit. Ich bin im Moment jedenfalls aufgeschmissen - zumindest bekomme ich das IPSec so nicht zum Laufen.

Edit: Doppelte Bilder raus ...

 

bearbeitet 1. Mai 2020 von JastiU

[daabm 1.366]

"Extern" sieht doch gut aus. Probier's mal. Der Default Switch ist anscheinend #grütze, aber das ist ja nichts neues, daß Defaults Grütze sind.

Edit: Für die doppelten Bilder brauchst Dich nicht entschuldigen, das ist ein Bug der Foren-Software, wenn man die per C&P direkt im Editor einfügt.

bearbeitet 1. Mai 2020 von daabm

[JastiU 0]

Wie gesagt. Der "neue" externe Switch bridged leider nicht er nattet nur ... dank des auf dem gleichen Interface liegenden Dafault Switches.

*sigh*

... ich versuch's morgen mit einer weiteren Netzwerkkarte auf der ich dann hoffentlich einen sauberen "Externen" Switch bekomme. Mal sehen.

bearbeitet 1. Mai 2020 von JastiU

[daabm 1.366]

Dann schmeiß den Default Switch einfach weg - hier isser auch fort...

[JastiU 0]

Echt? Wie??? Bei mir kommt der laufend wieder. Windows 10 einmal neu starten und ich hab' ihn zurück...

Edit: Wie "alt" ist Dein Windows 10. Frisch aufgesetzt?

bearbeitet 1. Mai 2020 von JastiU

[daabm 1.366]

Ja, ok - er ist noch da, aber keiner VM zugeordnet... Ignorier den einfach. Bei Server-OS kann man ihn entsorgen, bei Client anscheinend nicht.

[NilsK 2.957]

Moin,

 

sorry, euch das sagen zu müssen - aber ihr seid heftig auf dem Holzweg. Der Default Switch in Client Hyper-V (also unter Windows 10) ist nicht "Grütze", sondern sinnvoll. Es handelt sich um einen NAT-Switch, mit dem man VMs sehr einfach "ins Internet" bekommt, auch bei wechselnder Anbindung des Hosts (ein Notebook etwa ist ja manchmal über LAN und manchmal über WLAN verbunden). Den zu löschen, ist eine ganz, ganz blöde Idee.

 

Zu dem eigentlich gewünschten Szenario kann ich mangels eigener Erfahrung mit so einem Setup nichts sagen. Aber ihr seid falsch abgebogen. Wenn man den Default Switch nicht nutzen will, dann nutzt man ihn halt nicht. Hat man den mal entfernt oder manipuliert, bekommt man ihn kaum noch repariert.

 

Gruß, Nils

 

[JastiU 0]

vor 37 Minuten schrieb NilsK:

Moin,

 

sorry, euch das sagen zu müssen - aber ihr seid heftig auf dem Holzweg. [...] Den zu löschen, ist eine ganz, ganz blöde Idee. [...] Aber ihr seid falsch abgebogen.

 

Wenn man den Default Switch nicht nutzen will, dann nutzt man ihn halt nicht. Hat man den mal entfernt oder manipuliert, bekommt man ihn kaum noch repariert.

 

Gruß, Nils

 

Ui. Falscher Fuß heute Früh?

 

Ich kann Dich beruhigen. Niemand hat vor eine Mauer... den Default Switch zu löschen. War auch eigentlich nicht das Thema. Ich hätte es nur interessant gefunden wenn und besonders seit wann das möglich gewsesen wäre. Das Löschen des Default Switches hat üblicherweise die hier dargelegten Folgen: mikefrobbins blog (siehe auch weiter oben).
Ob man den Default Switch "braucht" und in wie weit er "sinnvoll" ist, überlasse ich den Philosophen. Windows Server 2019 stellt sowas beispielsweise nicht zwangsweise zur Verfügung (geht also auch ohne). Zudem ist der Default Switch nur ein, um einen DHCP erweiterter "interner" Switch, mit NAT. Ein NAT-Objekt lässt sich seit ... glaube ich 2012 ... per Powershell auf jedem (internen) Switch anlegen.

Klar ist ein "Default Switch" näher am Consumer, der sicher weder Bock hat ein NAT-Objekt zu erzeugen noch einen DHCP Server zu betreiben oder die "richtigen" statischen IPs zu vergeben.

Wer aber nur eine Netzwerkkarte hat (wie vermutlich bei der überwiegenden Anzahl der Windows 10 Systeme), für den kann der Default Switch dann zum Problem werden, wenn er ein Szenario hat, das von MS Standardvorstellungen abweicht. In meinem System sorgt der Default Switch wohl dafür, dass ein neu angelegter "externer Switch" die VMs eben _nicht_  ins Netzwerk des Hosts bridged - was ziemlich ärgerlich ist.
 

Fassen wir zusammen:

- Einzige Netzwerkkarte mit Default Switch belegt

- Default Switch verhindert IPSec (weil sehr wahrscheinlich kein NAT-T)

- Default Switch verhindert Bridging eines weiteren "externen Switches" (Bug?/Feature?)

=> zweite Netzwerkkarte einbauen... mal sehen was dann passiert.

 

Zurück zur eigentlichen Frage:

Falls jemand eine Idee hat wie ich IPSec in der VM trotz/mit NAT zum Laufen bringe ... wäre ich extrem glücklich

[daabm 1.366]

Siehe oben - mit NAT geht das nicht. Erstell nen neuen Switch, der direkt mit dem Netz verbindet, und häng Deine VM an den dran. Wenn das auch nicht geht, bin ich ratlos. Hier jedenfalls funktioniert das mit einem virtuellen DC auf einem Win10 Client prima - der wäre hinter NAT auch nur schwer erreichbar

[JastiU 0]

@daabm: Herzlichen Dank. Deine Antwort ist des Rätsels Lösung.

 

Vorgehensweise:

Ein "externer Switch" auf der (primären) Netzwerkkarte, auf der auch der Default Switch liegt, ist keine Lösung und funktioniert nicht. Deshalb muss eine zweite(!) Netzwerkkarte eingebaut werden.

Auf der zweiten Netzwerkkarte wird ein "externer Switch" für den Hyper-V konfiguriert. Das Bridging dieses externen Switches funktioniert dank der zweiten Netzwerkkarte einwandfrei und wird für die VM verwendet, die das IPSec VPN nutzen soll. In der VM lässt sich die Fritz VPN Verbindung (IPSec) damit erfolgreich aufbauen.

 

Da Microsoft gerne mal Dinge ändert ... Gültigkeitsdatum: Heute Mai April 2020.