tvprog1
Goto Top

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ß
netz

Content-Key: 304529

Url: https://administrator.de/contentid/304529

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: aqui
aqui 14.05.2016 um 11:34:25 Uhr
Goto Top
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 face-sad

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 face-wink
Also Fazit: Mehr infos bitte zur FW Konfiguration !
Mitglied: tvprog1
tvprog1 14.05.2016 aktualisiert um 23:12:37 Uhr
Goto Top
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.

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 face-sad
Genau, deshalb wird auch die DMZ IP (20.1.1.100) vom Server angepingt wie in der Beschreibung zu lesen ist face-smile

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

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

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.

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

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


Update

In Wireshark ist mir noch folgendes aufgefallen:
icmp
Mitglied: aqui
aqui 15.05.2016 um 14:12:45 Uhr
Goto Top
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
Mitglied: tvprog1
tvprog1 15.05.2016 aktualisiert um 15:34:20 Uhr
Goto Top
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 face-smile

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?