Windows Server - 2 NICs - 2 Firewalls - 2 Gateways
Hallo zusammen!
Ich habe da eine Verständnisfrage zum Routen bzw. zum Portmapping der Firewall.
Basis:
FW 1 192.168.0.2
FW 2 192.168.0.3
Server 192.168.0.4
FW 1 nimmt Pakete vom Internet an routet diese an einen internen Server (sagen wir mal Port 80) mit Portmapping
FW 2 nimmt Pakete vom Internet und routet diese an den gleichen Server (sagen wir Port 443) mit Portmapping
Wenn ich am internen Server nun als Gateway FW 1 eintrage, gehen Pakete von FW 2 nicht durch und umgekehrt. Unter Linux läuft das, unter Windows scheinbar nicht.
Es liegt zu 100% am Gateway, ein Test mit einer 2ten NIC und dem Gateway von FW 2 hat zeigt, dass nun beide FWs mit dem Server kommunizieren können.
Nun ist mir natürlich klar, dass 2 Gateways eine, nennen wir es mal, suboptimale Einstellung ist, auch wenn ich die Metrik der 2 NIC schon auf 100 egändert habe.
Wie würdet ihr sowas lösen?
Danke & lg
Ich habe da eine Verständnisfrage zum Routen bzw. zum Portmapping der Firewall.
Basis:
FW 1 192.168.0.2
FW 2 192.168.0.3
Server 192.168.0.4
FW 1 nimmt Pakete vom Internet an routet diese an einen internen Server (sagen wir mal Port 80) mit Portmapping
FW 2 nimmt Pakete vom Internet und routet diese an den gleichen Server (sagen wir Port 443) mit Portmapping
Wenn ich am internen Server nun als Gateway FW 1 eintrage, gehen Pakete von FW 2 nicht durch und umgekehrt. Unter Linux läuft das, unter Windows scheinbar nicht.
Es liegt zu 100% am Gateway, ein Test mit einer 2ten NIC und dem Gateway von FW 2 hat zeigt, dass nun beide FWs mit dem Server kommunizieren können.
Nun ist mir natürlich klar, dass 2 Gateways eine, nennen wir es mal, suboptimale Einstellung ist, auch wenn ich die Metrik der 2 NIC schon auf 100 egändert habe.
Wie würdet ihr sowas lösen?
Danke & lg
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6782940066
Url: https://administrator.de/forum/windows-server-2-nics-2-firewalls-2-gateways-6782940066.html
Ausgedruckt am: 04.04.2025 um 05:04 Uhr
27 Kommentare
Neuester Kommentar
Dual WAN Firewall ist bekanntlich die elegante Lösung für sowas. 
https://www.heise.de/select/ct/2016/24/1479992026108405
https://www.heise.de/select/ct/2016/24/1479992026108405
Könnte auch noch funktionieren wenn deine Firewall, die nicht als Standard-Gateway auf dem Server gesetzt ist, gegenüber dem Server NAT macht. Ist natürlich Moppelkotze aber das sind zwei Gateways auch. Wenn du zwei Gateways unter Windows tatsächlich einträgst, wird glaube ich nur das erste auch verwendet (das erste nach NIC Reihenfolge).
Zitat von @Polfi1210:
Hm, also irgendwie scheint die Sache wohl schwieriger zu sein als gedacht.
Eigentlich dachte ich, wenn das Paket von FW 2 kommt (kommt ja über die interne IP) spielt das Gateway keine Rolle, weil der Initiator eben im gleichen LAN ist und deshalb kein Routing stattfinden muss.
Hm, also irgendwie scheint die Sache wohl schwieriger zu sein als gedacht.
Eigentlich dachte ich, wenn das Paket von FW 2 kommt (kommt ja über die interne IP) spielt das Gateway keine Rolle, weil der Initiator eben im gleichen LAN ist und deshalb kein Routing stattfinden muss.
Falsch gedacht. Das Paket kommt nicht von den Firewalls. Solange Du kein NAT machst, bleibt die Absenderadresse erhalten und die Antwortpakete müssen daher sehr wohl geroutet werden.
Von daher verwundert es much, daß es unter Linux funktioniert haben soll.
Ich werde weiter experimentieren und gebe, wenn ich eine Lösung habe, hier ein Update.
Die Lösungen sind eigentlich vorgegeben:
- Nur eine Firewall
- oder Policy Routing
- oder NAT
- multiple Interfaces in getrennten IP-Netzen.
lks
Zitat von @Polfi1210:
Hm, also irgendwie scheint die Sache wohl schwieriger zu sein als gedacht.
Eigentlich dachte ich, wenn das Paket von FW 2 kommt (kommt ja über die interne IP) spielt das Gateway keine Rolle, weil der Initiator eben im gleichen LAN ist und deshalb kein Routing stattfinden muss.
Ich werde weiter experimentieren und gebe, wenn ich eine Lösung habe, hier ein Update.
Hm, also irgendwie scheint die Sache wohl schwieriger zu sein als gedacht.
Eigentlich dachte ich, wenn das Paket von FW 2 kommt (kommt ja über die interne IP) spielt das Gateway keine Rolle, weil der Initiator eben im gleichen LAN ist und deshalb kein Routing stattfinden muss.
Ich werde weiter experimentieren und gebe, wenn ich eine Lösung habe, hier ein Update.
Moin,
da liegt ja auch dein gedanklicher Fehler.
Rein kommen die Pakete ja auch korrekt. Jedoch wird dein Server seine Antwort im default immer zum Default-Gateway schicken. Der Server vermittelt hier nicht auf Port basis in irgend eine Richtung. Das funktioniert so nicht.
Bei einer OPNsense z.B. müsste für dieses Knstrukt der Traffic geflagged werden, damit die Antwort über den korrekten WAN Anschluss raus geht. Windows kann sowas garnicht.
Gruß
Spirit
Edit: Wenn das unter Linux funktioniert, arbeitet der Netzwerk Stack dort tatsächlich besser. Entspricht aber nicht dem Standard, da der Kommunikationsweg eindeutig sein muss.
Eigentlich dachte ich, wenn das Paket von FW 2 kommt (kommt ja über die interne IP) spielt das Gateway keine Rolle, weil der Initiator eben im gleichen LAN ist
Damit widersprichst du dich ja im eigenen Satz!!! ☹️Oben schreibst du das du die Pakete per Port Forwarding bekommst, sprich also aus dem Internet mit einer öffentlichen Internet Adresse als Absender
Dann oben wieder ist mit einmal der Server Initiator also Absender. Ja was denn nun...??
Nur um dir die Fakten nochmal nahezubringen:
- Kollege @Spirit-of-Eli hat es oben schon gesagt: Der Winblows Server supportet keine 2 Default Gateways!! Es "gewinnt" immer nur das Gateway was am Interface mit der höchsten Metrik definiert ist. Das andere Gateway ist tot und kann wenn, dann nur mit statischen Routen aktiviert werden.
- Traffic zu IP Zieladressen die der Server NICHT kennt bzw. die nicht lokal oder per statisch definierten Routen vorgegeben sind schickt der Server an die Default Gateway IP. Welche das ist...siehe oben.
- Kommt Traffic aus dem Internet durch ein Loch in der Firewall per Port Forwarding und wird dies Port Forwarding z.B. an FW2 auf den Server geforwardet, dann landet dessen Antworttraffic an die Absender IP an dem Gateway das der Server als Default Gateway definiert hat. Worst Case ist das die FW1 die das Paket dann ans Ziel weiterleitet. Das Ziel "sieht" dann das Return Traffic mit einmal von einer fremden Absender IP (FW1) kommt als der Traffic den es ursprünglich gesendet hat. Sowas ist im TCP/IP grundsätzlich nicht erlaubt und der Zielrechner killt dann sofort diese TCP/IP Session kommentarlos.
Wie mehrfach gesagt: Profis lösen sowas mit einer Dual WAN Firewall.
Zitat von @Polfi1210:
Und unter Linux funktioniert das wirklich, wir haben dort eine Firewall die NICHT als als Gateway auf den Servern eingetragen ist. Auch hier wird über NAT weitergeleitet (Ubuntu 22). Deswegen hat mich das Verhalten von Windows auch etwas irritiert.
Und unter Linux funktioniert das wirklich, wir haben dort eine Firewall die NICHT als als Gateway auf den Servern eingetragen ist. Auch hier wird über NAT weitergeleitet (Ubuntu 22). Deswegen hat mich das Verhalten von Windows auch etwas irritiert.
Du sagst, daß über NAt weitergeleitet wurde. ist das NAt in richtugn LAN oder in Richtung WAN?
Ich habe eher den Veracht, daß Du unte rLinux ein ganz anderes setup hast als unter Windows.
Mach mal eine Paketmitschnitt vom verbindungsaufbau auf Port 80 und auf Port 443 aus dem Internet (mit wireshark, die ersten drei bis vier Pakete der verbindung mitschneiden).
lks
Also fangen wir doch mal Firewall an.
Also bei Sophos mit Country Blocking ist das kein Problem.
Du erstellst z.B. die Rule alle bis auf die Löndern dürfen auf den service zugreifen.
Und ne zweite rule alle ländern dürfen auf den anderen service zugreifen.
Zur Not mit Exceptions.
Muss deine Firewall doch auch beherrschen.
Dann kannst dir den ganzen Käse mit doppel moppel routings...
Oder wenn schon dann routest du von der Firewall ohne Country Blocking zur anderen rüber und diese routet dann zum server, und wenn das rückwärts geht, gehts halt rückwärts. Und das muss halt schon auch immer mit NAT laufen.
Also bei Sophos mit Country Blocking ist das kein Problem.
Du erstellst z.B. die Rule alle bis auf die Löndern dürfen auf den service zugreifen.
Und ne zweite rule alle ländern dürfen auf den anderen service zugreifen.
Zur Not mit Exceptions.
Muss deine Firewall doch auch beherrschen.
Dann kannst dir den ganzen Käse mit doppel moppel routings...
Oder wenn schon dann routest du von der Firewall ohne Country Blocking zur anderen rüber und diese routet dann zum server, und wenn das rückwärts geht, gehts halt rückwärts. Und das muss halt schon auch immer mit NAT laufen.
All das löst aber sein eigentliches Problem nicht, nämlich das von Löchern die er in beide Firewalls gebohrt hat fürs Port Forwarding, eingehender externer Traffic auf den Server gelangt und der entsprechende Rücktraffic dann auch wieder zu der entsprechenden Firewall muss die den Traffic geforwardet hat. Ansonsten endet das mit asymetrischem Routing und sofortigem Session Abbruch wie oben beschrieben. Zu mindestens wenn das stimmt was der TO zuerst beschrieben hat und ohne "Initiator" Verwirrspiele. 
Mit nur einem Default Gateway und ohne Policy Based Routing oder Dual WAN Firewall ist das nicht möglich, eben weil Windows das nicht supportet.
Es ist also weniger ein Problem des Regelwerkes denn des IP Routings.
Mit nur einem Default Gateway und ohne Policy Based Routing oder Dual WAN Firewall ist das nicht möglich, eben weil Windows das nicht supportet.
Es ist also weniger ein Problem des Regelwerkes denn des IP Routings.
Bitte dann auch nicht vergessen deinen Thread hier als erledigt zu markieren!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Zitat von @ThePinky777:
Also fangen wir doch mal Firewall an.
Also bei Sophos mit Country Blocking ist das kein Problem.
Also fangen wir doch mal Firewall an.
Also bei Sophos mit Country Blocking ist das kein Problem.
Doch in dem Punkt stimme ich mit @ThePinky777 überein. Der Wunsch, Country Blocking selektiv auf Ports anzuwenden, hat zu seinem Konstrukt geführt. Wenn die Firewall das könnte, bräuchte er nur den einen Router und der Server hätte auch nur ein Gateway und eine NIC. Also er würde das Konstrukt dann einfach so nicht haben oder haben wollen.
Allerdings habe ich hier eine Sophos SG und da ist es genauso wie mit der Kerio. Country Blocking ist an oder aus, es hängt vor der Firewall. Vielleicht ist das bei Sophos XG oder XGS anders aber bei einer SG wüsste ich nicht, wie man das selektiv nutzen könnte.
Das ist IPtechnischer Unsinn! Eine Gateway IP hat rein gar nichts mit der NAT Funktion zu tun.
Ein Endgerät kann logischerweise auch niemals 2 Default Gateways haben! Wie sollte das Betriebssystem denn ohne Klassifizierung von Traffic entscheiden können welcher Zieltraffic denn zu welchem der 2 Gateways gehen soll??
Technisch unmöglich ohne Gedankenlesen beim Admin zu können und simpelste IP Routing Logik.
Da Winblows mit 2 Gateways gleicher Metrik und ohne Klassifizierung nicht umgehen kann ist das schlicht und einfach nicht supportet dort.
Ein Endgerät kann logischerweise auch niemals 2 Default Gateways haben! Wie sollte das Betriebssystem denn ohne Klassifizierung von Traffic entscheiden können welcher Zieltraffic denn zu welchem der 2 Gateways gehen soll??
Technisch unmöglich ohne Gedankenlesen beim Admin zu können und simpelste IP Routing Logik.
Da Winblows mit 2 Gateways gleicher Metrik und ohne Klassifizierung nicht umgehen kann ist das schlicht und einfach nicht supportet dort.
...und eine Route für 0.0.0.0 müsste sich wie ein Gateway verhalten, das dem Default Gateway vorgeschaltet ist, also immer gewinnt.
Die Sache ist eigentlich ganz simpel: Dein Server möchte ein Paket an eine andere IP verschicken. Dabei ist völlig unerheblich, ob das z.B. ein von ihm ausgehender Ping ist oder eine Antwort auf eine Anfrage, die er bekommen hat. Wichtig ist ausschließlich, welche IP der Empfänger hat.
Angenommen, es handelt sich um eine Anfrage von 1.2.3.4 und dein Server hat die IP 192.168.0.100/24, Default Gateway ist 192.168.0.1.
1) Er prüft, liegt die IP im Subnetz einer meiner NICs, also 192.168.0.0, das ist nicht der Fall.
2) Dann prüft er, gibt es eine Route zum Ziel, normalerweise nein. Wenn du eine Route für Traffic nach 0.0.0.0 setzt, dann ja. Dann nimmt er immer das Gatway dieser Route, also IMMER die 192.168.0.3.
3) Gibt es diese Route nicht, oder keine Route, die den Absender einschließt, dann nimmt er das Default Gateway. Mit Route 0.0.0.0 kann es nicht dazu kommen, weil die alle IP Adressen einschließt.
Bei NAT (gegenüber dem eigenen Server, normalerweise macht man das eher nach außen gerichtet!) passiert jetzt folgendes: Das Paket kommt von 1.2.3.4 aber der Router, der es an nimmt, ersetzt 1.2.3.4 durch seine eigene IP, also z.B. 192.168.0.3 (Der Router merkt sich das, weiß also für den Fall einer Antwort bescheid).
Der Server bekommt das Paket von 192.168.0.3. Diese IP liegt in seinem eigenen Subnetz, er schickt es schon in Schritt 1 zur 192.168.0.3 und nicht zu irgend einem Gateway. Der Server macht immer die selben drei Schritte und hat eigentlich keine Ahnung, er denkt, die Anfrage kam von intern. Du hast auch in den Logs oder unter netstat nur interne Verbindungen für alles, was über die 192.168.0.3 kommt.
Die Sache ist eigentlich ganz simpel: Dein Server möchte ein Paket an eine andere IP verschicken. Dabei ist völlig unerheblich, ob das z.B. ein von ihm ausgehender Ping ist oder eine Antwort auf eine Anfrage, die er bekommen hat. Wichtig ist ausschließlich, welche IP der Empfänger hat.
Angenommen, es handelt sich um eine Anfrage von 1.2.3.4 und dein Server hat die IP 192.168.0.100/24, Default Gateway ist 192.168.0.1.
1) Er prüft, liegt die IP im Subnetz einer meiner NICs, also 192.168.0.0, das ist nicht der Fall.
2) Dann prüft er, gibt es eine Route zum Ziel, normalerweise nein. Wenn du eine Route für Traffic nach 0.0.0.0 setzt, dann ja. Dann nimmt er immer das Gatway dieser Route, also IMMER die 192.168.0.3.
3) Gibt es diese Route nicht, oder keine Route, die den Absender einschließt, dann nimmt er das Default Gateway. Mit Route 0.0.0.0 kann es nicht dazu kommen, weil die alle IP Adressen einschließt.
Bei NAT (gegenüber dem eigenen Server, normalerweise macht man das eher nach außen gerichtet!) passiert jetzt folgendes: Das Paket kommt von 1.2.3.4 aber der Router, der es an nimmt, ersetzt 1.2.3.4 durch seine eigene IP, also z.B. 192.168.0.3 (Der Router merkt sich das, weiß also für den Fall einer Antwort bescheid).
Der Server bekommt das Paket von 192.168.0.3. Diese IP liegt in seinem eigenen Subnetz, er schickt es schon in Schritt 1 zur 192.168.0.3 und nicht zu irgend einem Gateway. Der Server macht immer die selben drei Schritte und hat eigentlich keine Ahnung, er denkt, die Anfrage kam von intern. Du hast auch in den Logs oder unter netstat nur interne Verbindungen für alles, was über die 192.168.0.3 kommt.
Zitat von @Polfi1210:
Noch ein kleines Update:
Wir hatten am Wochenende intensive Gespräche mit 2 Netzwerk-"Gurus".
Die meinten, es wäre sinnvoller eine Route am Server hinzuzufügen. Also nicht in den Einstellungen der NIC sondern über die CMD und zwar mit einer hohen Metric.
route -p add 0.0.0.0 MASK 0.0.0.0 192.168.0.3 METRIC 100
Damit bleibt das Default Gateway erhalten (das in der NIC, scheint auch bei route print als Default auf) und das NAT über die 2te FW funktioniert auch., und das auch mit nur einer NIC.
Mir ist schon klar, dass das alles mehr oder weniger ein Quirks ist, aber wie schon geschrieben, die Kerio kann leider beim GEO-Blocking nicht unterscheiden.
Noch ein kleines Update:
Wir hatten am Wochenende intensive Gespräche mit 2 Netzwerk-"Gurus".
Die meinten, es wäre sinnvoller eine Route am Server hinzuzufügen. Also nicht in den Einstellungen der NIC sondern über die CMD und zwar mit einer hohen Metric.
route -p add 0.0.0.0 MASK 0.0.0.0 192.168.0.3 METRIC 100
Damit bleibt das Default Gateway erhalten (das in der NIC, scheint auch bei route print als Default auf) und das NAT über die 2te FW funktioniert auch., und das auch mit nur einer NIC.
Mir ist schon klar, dass das alles mehr oder weniger ein Quirks ist, aber wie schon geschrieben, die Kerio kann leider beim GEO-Blocking nicht unterscheiden.
Moin,
Deine "Netzwerkgurus" sind ja tolle Spezialisten. Murks bleibt Murkjs, auch wenn das "Gurus" verkünden.
Dein Problem ist, daß Du auf Kerio fixiert bist, statt einer ordentliche Firewall hinzustellen, die Deinen Anforderungen genügt. z.B. eine pfsense.
Du wirst mit dieser Murks-Lösung garantiert noch Probleme bekommen, die Dir noch mehr Kopfzerbrechen bereiten werden. Mein Tipp wäre das einmal rodentlich zu machen statt jedesmal nachbessern zu müssen, wenn wieder ein Problem auftaucht.
lks