04.07.2024

2768

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

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: 29.04.2025 um 14:04 Uhr

27 Kommentare

Neuester Kommentar

Hi.

Nun, ich kenne die Grundlagen so:

Wenn das gegenüber eine Anfrage an die externe Adresse von GW2 sendet, erwartet dieser auch eine Antwort von dort ...

... wenn du aber mit der externen Adresse von GW1 antwortest, stimmt das Paket nicht ...

... möglich, das Linux da etwas cleverer agiert? 🤔

Dual WAN Firewall ist bekanntlich die elegante Lösung für sowas.

https://www.heise.de/select/ct/2016/24/1479992026108405

Moin,

Kann so nicht ohne weiteres funktionieren, solange Du kein Policy-Routing auf dem Server hast. d.h. Pakete mit Port 80 als Absender auf GW1 und Pakete mit Port 443 als Absender auf GW 2 leitest.

Oder die beiden Firewalls konsolidieren und diese das Polcy-Routing mchen lassen.

lks

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

Sorry, irgendwie ist das wie Fahradfahren mit zwei Lenkern.

Kreuzberger

Moin,

Wenn deine uns unbekannten Router etwas mehr Funktionalität mitbringen, könntest du es mal mit SNAT probieren.
Source: Any
Service: TCP 80 bzw. TCP 443
Destination: IP des Servers
Maskerading IP: das LAN-IP des jeweiligen Routers

Schön ist aber was anderes…

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

Frage, was ist der Sinn hinter diesem Konstrukt

2 NICs - 2 Firewalls - 2 Gateways?

Was willst Du damit erreichen?

Gruss Penny.

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.

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

Ich sehe, ihr seid an den Details dieser eigenwilligen Konstruktion interessiert:
Auf FW1 läuft ein GEO-IP Filter, der etliche Länder ausschließt (eingehend), auf FW2 nicht.

Sinn der Sache ist, einen Port über den GEO-Filter zu schützen (es dürfen also nicht alle rein), den anderen aber "weltweit" offen zu halten.

Deshalb eben auch 2 FWs. Mit Destination NAT klappt das eben ohne Gateway nicht.

Das mit den getrennten Netzen habe ich mir auch schon überlegt, werde ich am Wochenende testen, wobei ich hier aber auch wieder 2 Gateways hätte.

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.

Achja, die FW ist eine (oder ebsser 2) Kerio Control.

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.

Eigentlich doch eine ganz simple und einfache Logik!
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.

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.

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.

Danke für die vielen Tipps und Infos.

Leider kann die Kerio den GEO-IP nicht auf Rules oder Ports legen sondern aktiv oder nicht aktiv, das war ja auch der Grund für die gewagte Frage. Auch dann nicht, wenn mehr als NIC in de rKerio steckt.
Würde die Kerio das können, würden wir uns hier nicht lesen

Gelöst haben wir das jetzt so:

1 NIC – 1 Gateway am Server *jubel*

FW 1 nimmt die Anfrage auf (443) und leitet dieses an FW 2 mit Portübersetzung auf einen Port 10000+ mit NAT weiter, FW 2 geht dann mit Portüberetzung 443 auf den Server und so geht es dann lustig wieder zurück.

War zwar etwas Gefummel, funktioniert jetzt aber.

Warum die Portübersetzung: Wenn der Port auf 443 gleich geblieben wäre, hätte auch die entsprechende Regel auf der FW 2 aktiv bleiben müssen, was dann bedeutet, dass ich über beide FW ins Netz komme. So lauscht die FW 2 eben nur auf diesen hohen Port, schreibt wieder auf 443 um und alles ist gut.

Klar könnte man jetzt mit der IP und den lauschenden Port den GEO-Filter umgehenund direkt auf die FW 2 zugreifen, dann sollte aber der Hostheader Check des Server greifen.

Nicht elegant, aber es funktioniert.

Danke nochmals an alle!

Bitte dann auch nicht vergessen deinen Thread hier als erledigt zu markieren!
Wie kann ich einen Beitrag als gelöst markieren?

Sorry, ist erledigt

Die Lösung spricht immer noch gegen den standard wie schon oft gesagt.

Zitat von @ThePinky777:

Also fangen wir doch mal Firewall an.
Also bei Sophos mit Country Blocking ist das kein Problem.

Zitat von @aqui:

All das löst aber sein eigentliches Problem nicht

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.

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.

Warum setzt du dann nicht das Default Gateway auf 192.168.0.3? Jetzt sollte kein Traffic mehr beim Default Gateway ankommen.

Weil ich, wie schon geschrieben, prinzipiell 2 Gateways (zu FW 1 als auch zu FW 2) benötige, damit das NAT funktioniert.

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.

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

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.

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