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