Routing Problematik Server 2019
Hallo Kollegen und mitleidtragende 
Ich beschäftige mich mit einem merkwürdigen Phänomen.
Cloud Infrastruktur Test bei Hetzner.
1. Wir haben einen VPN Server Wireguard (172.30.30.2), der eine VPN Verbindung in unsere Netz
Firmennetz mit der Adresse 172.20.20.0 verbindet. Die VPN Verbindung zwischen
172.20.20.0 und 172.30.30.0 Hetzner internes Netz funktioniert.
2. Wir haben mehrere Windows Server aufgebaut und jetzt das kuriose. Wenn ich
beide Nics aktiviert lasse funzt Internet und teilweise internes Netz.
Ping 172.20.20.2 geht ins leere
Ping 172.20.20.21 funktioniert
Ping wird ausgeführt für 172.20.20.21 mit 32 Bytes Daten:
Antwort von 172.20.20.21: Bytes=32 Zeit=18ms TTL=125
Antwort von 172.20.20.21: Bytes=32 Zeit=16ms TTL=125
Antwort von 172.20.20.21: Bytes=32 Zeit=15ms TTL=125
Antwort von 172.20.20.21: Bytes=32 Zeit=16ms TTL=125
Tracert zu 172.20.20.2 geht über die internet Nic -> öffentliche Schnittstelle was
laut angehängter Routingtabelle eigentlich nicht sein sollte
Routenverfolgung zu myserver.domain.local [172.20.20.2]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 172.31.1.1
2 <1 ms <1 ms <1 ms 15197.your-cloud.host [49.12.25.249]
3 12 ms 24 ms 8 ms static.225.25.12.49.clients.your-server.de
[49.12.25.225]
4 2 ms 1 ms <1 ms static.213.239.235.45.clients.your-server.de
[213.239.235.45]
5 <1 ms <1 ms <1 ms core23.fsn1.hetzner.com [213.239.239.137]
6 3 ms 3 ms 3 ms core12.nbg1.hetzner.com [213.239.203.121]
7 7 ms 7 ms 5 ms juniper7.dc1.nbg1.hetzner.com [213.239.252.89]
DC1 unser erster DC
Routenverfolgung zu DC1.domain.local [172.20.20.21]
über maximal 30 Hops:
1 5 ms 3 ms 4 ms 172.30.30.1
2 1 ms <1 ms <1 ms 172.30.30.2
3 16 ms 21 ms 20 ms 10.10.10.2
4 20 ms 18 ms 20 ms DC1.domain.local [172.20.20.21]
Routen sind im Netzwerkbereich bei Hetzner eingetragen und Route sind auch in der
Routingtabelle drin.
Wenn jetzt die öffentliche Schnittstelle deaktiviert ist, funktioniert unser
komplettes internes Netz aber kein Internet, haben zwar ein Squid Proxy
eingerichtet der dann über 172.30.30.2 (Wireguard VPN Server) ins Internet geht und funktioniert aber nur
WinHTTP und Browser geht dann, spezial Programme die Proxy API von Windows nicht
benutzen gehen dann nicht.
Ping wird ausgeführt für 172.20.20.2 mit 32 Bytes Daten:
Antwort von 172.20.20.2: Bytes=32 Zeit=18ms TTL=125
Antwort von 172.20.20.2: Bytes=32 Zeit=21ms TTL=125
Antwort von 172.20.20.2: Bytes=32 Zeit=16ms TTL=125
Antwort von 172.20.20.2: Bytes=32 Zeit=16ms TTL=125
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 172.30.30.1 172.30.30.4 15
0.0.0.0 0.0.0.0 172.31.1.1 168.119.111.176 15
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
168.119.111.176 255.255.255.255 Auf Verbindung 168.119.111.176 271
172.20.20.0 255.255.255.0 172.30.30.2 172.30.30.4 16
172.30.30.0 255.255.255.0 172.30.30.1 172.30.30.4 16
172.30.30.1 255.255.255.255 Auf Verbindung 172.30.30.4 16
172.30.30.4 255.255.255.255 Auf Verbindung 172.30.30.4 271
172.31.1.1 255.255.255.255 Auf Verbindung 168.119.111.176 16
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 168.119.111.176 271
224.0.0.0 240.0.0.0 Auf Verbindung 172.30.30.4 271
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 168.119.111.176 271
255.255.255.255 255.255.255.255 Auf Verbindung 172.30.30.4 271
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
10.10.10.0 255.255.255.0 172.30.30.2 1
172.20.20.0 255.255.255.0 172.30.30.2 1
IPv6-Routentabelle
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
1 331 ff00::/8 Auf Verbindung
Ständige Routen:
Keine
Firewallregeln können es nicht sein da Windows Firewall deaktiviert.
So das wars erstmal. Vielen Dank für die Rückmeldung
Ich beschäftige mich mit einem merkwürdigen Phänomen.
Cloud Infrastruktur Test bei Hetzner.
1. Wir haben einen VPN Server Wireguard (172.30.30.2), der eine VPN Verbindung in unsere Netz
Firmennetz mit der Adresse 172.20.20.0 verbindet. Die VPN Verbindung zwischen
172.20.20.0 und 172.30.30.0 Hetzner internes Netz funktioniert.
2. Wir haben mehrere Windows Server aufgebaut und jetzt das kuriose. Wenn ich
beide Nics aktiviert lasse funzt Internet und teilweise internes Netz.
Ping 172.20.20.2 geht ins leere
Ping 172.20.20.21 funktioniert
Ping wird ausgeführt für 172.20.20.21 mit 32 Bytes Daten:
Antwort von 172.20.20.21: Bytes=32 Zeit=18ms TTL=125
Antwort von 172.20.20.21: Bytes=32 Zeit=16ms TTL=125
Antwort von 172.20.20.21: Bytes=32 Zeit=15ms TTL=125
Antwort von 172.20.20.21: Bytes=32 Zeit=16ms TTL=125
Tracert zu 172.20.20.2 geht über die internet Nic -> öffentliche Schnittstelle was
laut angehängter Routingtabelle eigentlich nicht sein sollte
Routenverfolgung zu myserver.domain.local [172.20.20.2]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms 172.31.1.1
2 <1 ms <1 ms <1 ms 15197.your-cloud.host [49.12.25.249]
3 12 ms 24 ms 8 ms static.225.25.12.49.clients.your-server.de
[49.12.25.225]
4 2 ms 1 ms <1 ms static.213.239.235.45.clients.your-server.de
[213.239.235.45]
5 <1 ms <1 ms <1 ms core23.fsn1.hetzner.com [213.239.239.137]
6 3 ms 3 ms 3 ms core12.nbg1.hetzner.com [213.239.203.121]
7 7 ms 7 ms 5 ms juniper7.dc1.nbg1.hetzner.com [213.239.252.89]
DC1 unser erster DC
Routenverfolgung zu DC1.domain.local [172.20.20.21]
über maximal 30 Hops:
1 5 ms 3 ms 4 ms 172.30.30.1
2 1 ms <1 ms <1 ms 172.30.30.2
3 16 ms 21 ms 20 ms 10.10.10.2
4 20 ms 18 ms 20 ms DC1.domain.local [172.20.20.21]
Routen sind im Netzwerkbereich bei Hetzner eingetragen und Route sind auch in der
Routingtabelle drin.
Wenn jetzt die öffentliche Schnittstelle deaktiviert ist, funktioniert unser
komplettes internes Netz aber kein Internet, haben zwar ein Squid Proxy
eingerichtet der dann über 172.30.30.2 (Wireguard VPN Server) ins Internet geht und funktioniert aber nur
WinHTTP und Browser geht dann, spezial Programme die Proxy API von Windows nicht
benutzen gehen dann nicht.
Ping wird ausgeführt für 172.20.20.2 mit 32 Bytes Daten:
Antwort von 172.20.20.2: Bytes=32 Zeit=18ms TTL=125
Antwort von 172.20.20.2: Bytes=32 Zeit=21ms TTL=125
Antwort von 172.20.20.2: Bytes=32 Zeit=16ms TTL=125
Antwort von 172.20.20.2: Bytes=32 Zeit=16ms TTL=125
IPv4-Routentabelle
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 172.30.30.1 172.30.30.4 15
0.0.0.0 0.0.0.0 172.31.1.1 168.119.111.176 15
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
168.119.111.176 255.255.255.255 Auf Verbindung 168.119.111.176 271
172.20.20.0 255.255.255.0 172.30.30.2 172.30.30.4 16
172.30.30.0 255.255.255.0 172.30.30.1 172.30.30.4 16
172.30.30.1 255.255.255.255 Auf Verbindung 172.30.30.4 16
172.30.30.4 255.255.255.255 Auf Verbindung 172.30.30.4 271
172.31.1.1 255.255.255.255 Auf Verbindung 168.119.111.176 16
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 168.119.111.176 271
224.0.0.0 240.0.0.0 Auf Verbindung 172.30.30.4 271
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 168.119.111.176 271
255.255.255.255 255.255.255.255 Auf Verbindung 172.30.30.4 271
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
10.10.10.0 255.255.255.0 172.30.30.2 1
172.20.20.0 255.255.255.0 172.30.30.2 1
IPv6-Routentabelle
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
1 331 ff00::/8 Auf Verbindung
Ständige Routen:
Keine
Firewallregeln können es nicht sein da Windows Firewall deaktiviert.
So das wars erstmal. Vielen Dank für die Rückmeldung
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 629345
Url: https://administrator.de/forum/routing-problematik-server-2019-629345.html
Ausgedruckt am: 03.06.2025 um 16:06 Uhr
6 Kommentare
Neuester Kommentar
Wieso "Leidtragende" ? Da hast du wohl was grundsätzlich missverstanden... 
Das Tutorial und die Anmerkungen dazu hast du gelesen ??
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Bei Winblows ist immer die Bindungsreihenfolge bzw. neu Metrik bei multiplen NICs entscheident. Zudem kann Windows nicht mit 2 Default Gateways umgehen. Hier ist also ggf. statisches Routing erforderlich. Siehe Tutorial.
Traceroute (tracert) ist zur Routing Hop Verfolgung wie immer dein bester Freund.
Das Tutorial und die Anmerkungen dazu hast du gelesen ??
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Bei Winblows ist immer die Bindungsreihenfolge bzw. neu Metrik bei multiplen NICs entscheident. Zudem kann Windows nicht mit 2 Default Gateways umgehen. Hier ist also ggf. statisches Routing erforderlich. Siehe Tutorial.
Traceroute (tracert) ist zur Routing Hop Verfolgung wie immer dein bester Freund.
Vielen dank, man sieht doch den Wald vor lauter Bäumen nicht mehr
Ich habe die Default Route von der internen Schnittstelle entfernt und eine statische mit dem Gateway 1 am Ende hinzugefügt. VPN Gateway wollte nicht funktionieren.
Aber nun funktioniert es.
Ich habe die Default Route von der internen Schnittstelle entfernt und eine statische mit dem Gateway 1 am Ende hinzugefügt. VPN Gateway wollte nicht funktionieren.
Aber nun funktioniert es.
Sorry wollte mit Leitragende ein Witz mit einbauen
Zudem kann Windows nicht mit 2 Default Gateways umgehen.
Das war der Fehler und mir nicht so bekannt, da kamen dann komische Ergebnisse raus trotz tracert bei windows.
Zudem kann Windows nicht mit 2 Default Gateways umgehen.
Das war der Fehler und mir nicht so bekannt, da kamen dann komische Ergebnisse raus trotz tracert bei windows.
Das war der Fehler und mir nicht so bekannt
Wenn du selber in der Windows Kiste drinstecken würdest und siehst 2 gleichwertige Gateway Einträge welchen würdest du denn nehmen ?Genau in dem Dilemma steckt Winblows auch es kann ja (noch) keine Gedanken seines Administrators lesen...
Es nimmt dann immer den Adapter der in der Bindungsreihenfolge (Metrik) an erster Stelle steht. Denn anderen ignoriert er dann.Das ist bei Winblows schon seit Jahrzehnten so und kennen eigentlich alle Winblows Knechte.
nur wundert es mich dann warum windows bei mehreren Schnittstellen trotzdem den default Gateway so hinschustert Wenn es seit jahrzehnten nicht funktionieren kann.
Aber du hast recht bei zwei Default Gateways entscheidet das Los wenn gleiche Metriken.
Wenn es seit jahrzehnten nicht funktionieren kann.Aber du hast recht bei zwei Default Gateways entscheidet das Los
wenn gleiche Metriken.
Hinschustern ist es eigentlich nicht. Das OS versucht immer irgendwie eine Eindeutigkeit herzustellen weil es ja nicht entscheiden kann welches Gateway gültig sein soll.
In älteren Windows Versionen entschied das einzig und allein die statische Bindungsreihenfolge die man ggf. im Setup umstellen musste.
Modernere Versionen machen das mit einer Schnittstellen Metrik wobei die NIC mit der besten Metrik immer ausschlaggebend ist. Die andere NIC mit schlechterer Metrik wird solange ignoriert bis die primäre NIC ausfällt, dann greift die schlechtere Metrik bzw. das 2te Gateway.
Etwas logischer und Netzwerk gerechter als früher, dann da war das nur mit manueller Intervention möglich.
In älteren Windows Versionen entschied das einzig und allein die statische Bindungsreihenfolge die man ggf. im Setup umstellen musste.
Modernere Versionen machen das mit einer Schnittstellen Metrik wobei die NIC mit der besten Metrik immer ausschlaggebend ist. Die andere NIC mit schlechterer Metrik wird solange ignoriert bis die primäre NIC ausfällt, dann greift die schlechtere Metrik bzw. das 2te Gateway.
Etwas logischer und Netzwerk gerechter als früher, dann da war das nur mit manueller Intervention möglich.
