JastiU

@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.

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

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?

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.

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 ...

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...

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.