4
ICMP reply Pakete werden nicht an das Standard Gateway geschickt
Hallo zusammen,
folgende Konstellation: Der Client mit der IP-Adresse 40.1.1.1 schickt ein ICMP request an den Server mit der IP-Adresse 20.1.1.100. Dieser befindet sich hinter einer Firewall bei der zwei Netze eingerichtet sind (s. Skizze). Der Server hat jeweils eine NIC in beiden Netzten -> 20.1.1.100/24 + 192.168.1.100/24. Das heißt der ICMP request kommt bei der Firewall auf dem Interface mit der IP-Adresse 20.1.1.1 an und wird direkt an die NIC1 (20.1.1.100) vom Server geschickt. Das funktioniert auch -> geprüft mit Wireshark.
Nun sollte der dazugehörige ICMP reply vom Server über NIC2 (192.168.1.100) verschickt werden, da als Standard Gateway beim Server die IP-Adresse 192.168.1.1 eingetragen ist. Das funktioniert allerdings nicht -> ebenfalls mit Wireshark geprüft. Es ist überhaupt kein ICMP reply in Wireshark zu sehen.
Wird nun bei dem Server eine statische Route eingetragen, bei der Pakete für die Ziel IP-Adresse 40.1.1.1 an das Gateway 20.1.1.1 geschickt werden sollen, so kommt erfolgreich ein ICMP ping zustande und es sind auch ICMP request + ICMP reply Pakete in Wireshark zu sehen.
Die Frage ist nun, warum der Server die ICMP reply Pakete nicht an sein Standard Gateway schickt wenn die statische Route fehlt?
Es liegt natürlich nahe zu vermuten, dass die Firewall etwas blockiert. Das kann aber ausgeschlossen werden, da Wireshark direkt auf dem Server ausgeführt wird und da ja schon keine ICMP reply Pakete zu sehen sind. Bei dem Server selbst handelt es sich um einen Windows Server 2012 R2 bei dem keine Firewall aktiv ist. Und ja, in Wireshark sind die Filter richtig gesetzt -> alle Pakete von beiden Schnittstellen.
Gruß
folgende Konstellation: Der Client mit der IP-Adresse 40.1.1.1 schickt ein ICMP request an den Server mit der IP-Adresse 20.1.1.100. Dieser befindet sich hinter einer Firewall bei der zwei Netze eingerichtet sind (s. Skizze). Der Server hat jeweils eine NIC in beiden Netzten -> 20.1.1.100/24 + 192.168.1.100/24. Das heißt der ICMP request kommt bei der Firewall auf dem Interface mit der IP-Adresse 20.1.1.1 an und wird direkt an die NIC1 (20.1.1.100) vom Server geschickt. Das funktioniert auch -> geprüft mit Wireshark.
Nun sollte der dazugehörige ICMP reply vom Server über NIC2 (192.168.1.100) verschickt werden, da als Standard Gateway beim Server die IP-Adresse 192.168.1.1 eingetragen ist. Das funktioniert allerdings nicht -> ebenfalls mit Wireshark geprüft. Es ist überhaupt kein ICMP reply in Wireshark zu sehen.
Wird nun bei dem Server eine statische Route eingetragen, bei der Pakete für die Ziel IP-Adresse 40.1.1.1 an das Gateway 20.1.1.1 geschickt werden sollen, so kommt erfolgreich ein ICMP ping zustande und es sind auch ICMP request + ICMP reply Pakete in Wireshark zu sehen.
Die Frage ist nun, warum der Server die ICMP reply Pakete nicht an sein Standard Gateway schickt wenn die statische Route fehlt?
Es liegt natürlich nahe zu vermuten, dass die Firewall etwas blockiert. Das kann aber ausgeschlossen werden, da Wireshark direkt auf dem Server ausgeführt wird und da ja schon keine ICMP reply Pakete zu sehen sind. Bei dem Server selbst handelt es sich um einen Windows Server 2012 R2 bei dem keine Firewall aktiv ist. Und ja, in Wireshark sind die Filter richtig gesetzt -> alle Pakete von beiden Schnittstellen.
Gruß
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: 304529
Url: https://administrator.de/forum/icmp-reply-pakete-werden-nicht-an-das-standard-gateway-geschickt-304529.html
Ausgedruckt am: 18.04.2025 um 06:04 Uhr
4 Kommentare
Neuester Kommentar
Um das genau zu verstehen ein paar Zusatzfragen:
1.)
Es sieht so aus, nach der FW IP Adressierung zu urteilen, das das 20er Segment einen DMZ mit öffentlicher IP ist die transparent geroutet wird und das 192.168er Segment eins mit privaten RFC 1918 IPs ist das mit NAT (IP Adress Translation) ins Netz geht ??
Ist dem so oder sind das willkürliche Platzhalter für IP Adressen ??
RFC 1918 IPs werden im Internet NICHT geroutet sind folglich auch ohne NAT niemals von außen erreichbar bzw. direkt anpingbar.
Hier ist deinen Beschreibung leider recht schwammig
2.)
Falls dem so ist kannst du dann natürlich niemals die 192.168..1.100er IP des Servers direkt anpingen vom 40er Client, das wäre in einem NAT Umfeld IP technisch unmöglich !
Folgefrage wenn NAT im Spiel ist: Was für eine Ziel IP pingst du denn ??
Logisch müsste es mit NAT dann die Internet FW IP sein wenn die FW ein Port Forwarding fürs 192.168er Netz eingetragen hat.
Daraus ergeben sich wieder andere Fehler deiner Schilderung...
Du schreibst ja selber: (Zitat) "schickt ein ICMP request an den Server mit der IP-Adresse 20.1.1.100 "
Folglich pingst du also direkt den Server an, was dann wieder die Frage von oben aufwirft: Direkte öffentliche IP ohne NAT an der FW.
Wenn das der Fall ist geht das IP ICMP Paket nicht direkt zur Firewall, sie ist vielmehr nur ein Hop auf dem Ziel zur Server IP !!
Der Server empfängt also den ICMP Request DIREKT und muss auch direkt darauf antworten mit einem ICMP Echo Reply auf die 40.1.1.1 Adresse des Clients !
Hier kommt nun der spannende Punkt. Du schreibst das es ein Winblows Server ist.
Für den (und seine ICMP Antwort) ist es nun essentiell wichtig WO sein Default Gateway definiert ist ??
Windows kann nur ein einziges Default Gateway haben niemals aber 2.
Zeigt das auf die NIC 2 also das 192.168.er FW Interface wird es niemals ein Reply geben. Gesetzt den Fall du machst da NAT in der FW (was wir ja leider nicht wissen ?!) dann sendet die FW den Reply mit der öffentlichen NAT IP.
Der Client sieht einen Absender IP Adress Mismatch und dropped sofort das Paket...kein Reply also !
Warst du so leichtsinnig und hast 2 Default Gateways eingetragen bei der Winblows Server Gurke kann Winblows damit nicht umgehen und es entscheidet dann rein die Bindungsreihenfolge der NIC Adapter.
Ist NIC 2 in der Bindungreihenfolge vorn passiert das gleiche wie oben, denn dann gilt das Def. Gateway da.
Ist es das nicht gewinnt NIC 1 und der Reply kommt an weil dann das 20er netz gewinnt was ohne NAT (vermutlich ?) transparent geroutet wird.
Das gleiche passiert natürlich wenn du mit einer dedizierten statischen Route diesen Weg erzwingst ! Dein Test bestätigt das ja auch eindeutig !
"Wird nun bei dem Server eine statische Route eingetragen, bei der Pakete für die Ziel IP-Adresse 40.1.1.1 an das Gateway 20.1.1.1 geschickt werden sollen, so kommt erfolgreich ein ICMP ping zustande"
Works as designed !!!
Hier können wir nur im freien Fall raten, was natürlich zu nix führt !
Deshalb musst du hier etwas präziser werden !
Also Fazit: Mehr infos bitte zur FW Konfiguration !
1.)
Es sieht so aus, nach der FW IP Adressierung zu urteilen, das das 20er Segment einen DMZ mit öffentlicher IP ist die transparent geroutet wird und das 192.168er Segment eins mit privaten RFC 1918 IPs ist das mit NAT (IP Adress Translation) ins Netz geht ??
Ist dem so oder sind das willkürliche Platzhalter für IP Adressen ??
RFC 1918 IPs werden im Internet NICHT geroutet sind folglich auch ohne NAT niemals von außen erreichbar bzw. direkt anpingbar.
Hier ist deinen Beschreibung leider recht schwammig
2.)
Falls dem so ist kannst du dann natürlich niemals die 192.168..1.100er IP des Servers direkt anpingen vom 40er Client, das wäre in einem NAT Umfeld IP technisch unmöglich !
Folgefrage wenn NAT im Spiel ist: Was für eine Ziel IP pingst du denn ??
Logisch müsste es mit NAT dann die Internet FW IP sein wenn die FW ein Port Forwarding fürs 192.168er Netz eingetragen hat.
Daraus ergeben sich wieder andere Fehler deiner Schilderung...
Das heißt der ICMP request kommt bei der Firewall auf dem Interface mit der IP-Adresse 20.1.1.1 an
Nein ! Das tut er nur wenn du auch die 20.1.1.1 direkt anpingst. Das ist bei dir aber ausdrücklich NICHT der Fall !!Du schreibst ja selber: (Zitat) "schickt ein ICMP request an den Server mit der IP-Adresse 20.1.1.100 "
Folglich pingst du also direkt den Server an, was dann wieder die Frage von oben aufwirft: Direkte öffentliche IP ohne NAT an der FW.
Wenn das der Fall ist geht das IP ICMP Paket nicht direkt zur Firewall, sie ist vielmehr nur ein Hop auf dem Ziel zur Server IP !!
Der Server empfängt also den ICMP Request DIREKT und muss auch direkt darauf antworten mit einem ICMP Echo Reply auf die 40.1.1.1 Adresse des Clients !
Hier kommt nun der spannende Punkt. Du schreibst das es ein Winblows Server ist.
Für den (und seine ICMP Antwort) ist es nun essentiell wichtig WO sein Default Gateway definiert ist ??
Windows kann nur ein einziges Default Gateway haben niemals aber 2.
Zeigt das auf die NIC 2 also das 192.168.er FW Interface wird es niemals ein Reply geben. Gesetzt den Fall du machst da NAT in der FW (was wir ja leider nicht wissen ?!) dann sendet die FW den Reply mit der öffentlichen NAT IP.
Der Client sieht einen Absender IP Adress Mismatch und dropped sofort das Paket...kein Reply also !
ebenfalls mit Wireshark geprüft. Es ist überhaupt kein ICMP reply in Wireshark zu sehen.
Richtig..ist auch zu erwarten und der TCP/IP Stack verhält sich hier standardkonform !!Warst du so leichtsinnig und hast 2 Default Gateways eingetragen bei der Winblows Server Gurke kann Winblows damit nicht umgehen und es entscheidet dann rein die Bindungsreihenfolge der NIC Adapter.
Ist NIC 2 in der Bindungreihenfolge vorn passiert das gleiche wie oben, denn dann gilt das Def. Gateway da.
Ist es das nicht gewinnt NIC 1 und der Reply kommt an weil dann das 20er netz gewinnt was ohne NAT (vermutlich ?) transparent geroutet wird.
Das gleiche passiert natürlich wenn du mit einer dedizierten statischen Route diesen Weg erzwingst ! Dein Test bestätigt das ja auch eindeutig !
"Wird nun bei dem Server eine statische Route eingetragen, bei der Pakete für die Ziel IP-Adresse 40.1.1.1 an das Gateway 20.1.1.1 geschickt werden sollen, so kommt erfolgreich ein ICMP ping zustande"
Works as designed !!!
Es liegt natürlich nahe zu vermuten, dass die Firewall etwas blockiert.
Könnte sein aber das können wir nicht beurteilen weil du uns nur oberflächliche Angaben über das Firewall Setup machst.Hier können wir nur im freien Fall raten, was natürlich zu nix führt !
Deshalb musst du hier etwas präziser werden !
da Wireshark direkt auf dem Server ausgeführt wird und da ja schon keine ICMP reply Pakete zu sehen sind.
Klar, ohne Port Forwarding für ICMP kann da auch logischerweise nicht mal ein Request ankommen via NIC 2 sofern die FW NAT macht für das 192.168er Segment ?? Leider, wie bereits gesagt, ist deine Beschreibung da sehr oberflächlich.Windows Server 2012 R2 bei dem keine Firewall aktiv ist. Und ja, in Wireshark sind die Filter richtig gesetzt -> alle Pakete von beiden Schnittstellen.
Das sagen sie alle aber wir wollen dir mal glauben, da du ja sonst schon recht professionell und richtig vorgegangen bist um das zu analysieren Also Fazit: Mehr infos bitte zur FW Konfiguration !
Zitat von @aqui:
Es sieht so aus, nach der FW IP Adressierung zu urteilen, das das 20er Segment einen DMZ mit öffentlicher IP ist die transparent geroutet wird und das 192.168er Segment eins mit privaten RFC 1918 IPs ist das mit NAT (IP Adress Translation) ins Netz geht ??
Ist dem so oder sind das willkürliche Platzhalter für IP Adressen ??
Ja, dem ist so. Wobei es für diesen Fall hier egal ist, ob das Netz 192.168.1.0/24 genattet wird oder nicht.Es sieht so aus, nach der FW IP Adressierung zu urteilen, das das 20er Segment einen DMZ mit öffentlicher IP ist die transparent geroutet wird und das 192.168er Segment eins mit privaten RFC 1918 IPs ist das mit NAT (IP Adress Translation) ins Netz geht ??
Ist dem so oder sind das willkürliche Platzhalter für IP Adressen ??
RFC 1918 IPs werden im Internet NICHT geroutet sind folglich auch ohne NAT niemals von außen erreichbar bzw. direkt anpingbar.
Hier ist deinen Beschreibung leider recht schwammig
Genau, deshalb wird auch die DMZ IP (20.1.1.100) vom Server angepingt wie in der Beschreibung zu lesen ist Hier ist deinen Beschreibung leider recht schwammig
Falls dem so ist kannst du dann natürlich niemals die 192.168..1.100er IP des Servers direkt anpingen vom 40er Client, das wäre in einem NAT Umfeld IP technisch unmöglich !
Folgefrage wenn NAT im Spiel ist: Was für eine Ziel IP pingst du denn ??
Logisch müsste es mit NAT dann die Internet FW IP sein wenn die FW ein Port Forwarding fürs 192.168er Netz eingetragen hat.
Nein, wie gesagt es wird die DMZ IP (20.1.1.100) vom Server angepingt...Folgefrage wenn NAT im Spiel ist: Was für eine Ziel IP pingst du denn ??
Logisch müsste es mit NAT dann die Internet FW IP sein wenn die FW ein Port Forwarding fürs 192.168er Netz eingetragen hat.
Daraus ergeben sich wieder andere Fehler deiner Schilderung...
Sorry für das Missverständnis, ich wollte damit sagen das über das FW Interface mit der IP-Adresse 20.1.1.1 der ICMP request zur Server IP 20.1.1.100 geschickt wird. Sprich es ist der letzte Hop auf dem Ziel zur Server IP.Das heißt der ICMP request kommt bei der Firewall auf dem Interface mit der IP-Adresse 20.1.1.1 an
Nein ! Das tut er nur wenn du auch die 20.1.1.1 direkt anpingst. Das ist bei dir aber ausdrücklich NICHT der Fall !!Du schreibst ja selber: (Zitat) "schickt ein ICMP request an den Server mit der IP-Adresse 20.1.1.100 "
Folglich pingst du also direkt den Server an, was dann wieder die Frage von oben aufwirft: Direkte öffentliche IP ohne NAT an der FW.
Wenn das der Fall ist geht das IP ICMP Paket nicht direkt zur Firewall, sie ist vielmehr nur ein Hop auf dem Ziel zur Server IP !!
Genau, siehe eins weiter oben.Folglich pingst du also direkt den Server an, was dann wieder die Frage von oben aufwirft: Direkte öffentliche IP ohne NAT an der FW.
Wenn das der Fall ist geht das IP ICMP Paket nicht direkt zur Firewall, sie ist vielmehr nur ein Hop auf dem Ziel zur Server IP !!
Der Server empfängt also den ICMP Request DIREKT und muss auch direkt darauf antworten mit einem ICMP Echo Reply auf die 40.1.1.1 Adresse des Clients !
Korrekt.Hier kommt nun der spannende Punkt. Du schreibst das es ein Winblows Server ist.
Für den (und seine ICMP Antwort) ist es nun essentiell wichtig WO sein Default Gateway definiert ist ??
Windows kann nur ein einziges Default Gateway haben niemals aber 2.
Zeigt das auf die NIC 2 also das 192.168.er FW Interface wird es niemals ein Reply geben. Gesetzt den Fall du machst da NAT in der FW (was wir
ja leider nicht wissen ?!) dann sendet die FW den Reply mit der öffentlichen NAT IP.
Ja, der Server hat nur ein Standard Gateway und das zeigt auf das FW Interface mit der IP 192.168.1.1 und ist bei der NIC2 eingetragen. Mir ist schon klar, dass der Client so kein ICMP reply zurückbekommt wenn das Netz 192.168.1.0/24 auf keine öffentliche IP genattet wird. Und selbst wenn dann würde es der Client wie du weiter unten schreibst verwerfen. ABER das ist auch gar nicht das Ziel! Mir geht es lediglich darum zu verstehen, warum der Server kein ICMP reply an sein Standard Gateway schickt? Es ist vollkommen egal ob das beim Client ankommen würde...Für den (und seine ICMP Antwort) ist es nun essentiell wichtig WO sein Default Gateway definiert ist ??
Windows kann nur ein einziges Default Gateway haben niemals aber 2.
Zeigt das auf die NIC 2 also das 192.168.er FW Interface wird es niemals ein Reply geben. Gesetzt den Fall du machst da NAT in der FW (was wir
ja leider nicht wissen ?!) dann sendet die FW den Reply mit der öffentlichen NAT IP.
Der Client sieht einen Absender IP Adress Mismatch und dropped sofort das Paket...kein Reply also !
Warum ist es zu erwarten dass der Server den ICMP reply nicht an sein Standard Gateway schickt? Wie gesagt, es geht nicht darum dass der ICMP reply nicht beim Client ankommt...ebenfalls mit Wireshark geprüft. Es ist überhaupt kein ICMP reply in Wireshark zu sehen.
Richtig..ist auch zu erwarten und der TCP/IP Stack verhält sich hier standardkonform !!Update
In Wireshark ist mir noch folgendes aufgefallen:
Wobei es für diesen Fall hier egal ist, ob das Netz 192.168.1.0/24 genattet wird oder nicht.
Jein ! Dir sollte nur dann klar sein das du keine IP Adresse im NIC 2 Segment dann von außen anpingen kannst !Das ist dann mit NAT logischerweise nicht möglich !
Zu senden via 20er Interface und den Reply via 192er zu schicken würde ein asymetrische Routing ergeben und einen Sequence Mismatch. Das würde logischerweise auch nicht gehen.
Genau, deshalb wird auch die DMZ IP (20.1.1.100) vom Server angepingt wie in der Beschreibung zu lesen ist
Das geht natürlich, war aber nicht ganz klar da du schriebst das das ICMP Paket bei der Firewall ankommt, was so nicht ganz korrekt bzw. verwirrend ist.Es kommt ja final am Server an und nicht an den zahllosen Interimshops der Router dazwischen. Die leiten ja logischerweise nur weiter anhand der Ziel IP im Paket.
OK, der TCP/IP Stack des Servers kann die Antwort nicht senden da die Sequence Number nicht stimmt bzw. er keine matchende hat für sein NIC2 Interface. Deshalb dropt der Stack den Reply intern über NIC2
Jein ! Dir sollte nur dann klar sein das du keine IP Adresse im NIC 2 Segment dann von außen anpingen kannst !
Ja, das ist klar und passt auch so...Zu senden via 20er Interface und den Reply via 192er zu schicken würde ein asymetrische Routing ergeben und einen Sequence Mismatch. Das würde logischerweise auch nicht gehen.
Du meinst via 20er Interface empfangen anstatt senden? Genau das wäre asymmetrisches Routing. Warum geht das nicht? Was hat es mit dem sequence mismatch auf sich? Mein Experiment wäre abgeschlossen, wenn das FW Interface 192.168.1.1 den ICMP reply sieht. Ist das nicht möglich? Wenn nein, kannst du mir bitte erklären warum nicht OK, der TCP/IP Stack des Servers kann die Antwort nicht senden da die Sequence Number nicht stimmt bzw. er keine matchende hat für sein NIC2 Interface. Deshalb dropt der Stack den Reply intern über NIC2
Das ist für mich leider nicht nachvollziehbar. Asymetrisches Routing ist doch nichts außergewöhnliches?
