20
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
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6782940066
Url: https://administrator.de/contentid/6782940066
Printed on: July 7, 2024 at 17:07 o'clock
20 Comments
Latest comment
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? 🤔
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
https://www.heise.de/select/ct/2016/24/1479992026108405
2
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
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
2
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
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…
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.
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
Gruss Penny.
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.
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.
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.
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
1
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.
1
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!
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!
How can I mark a post as solved?
How can I mark a post as solved?
Sorry, ist erledigt
Die Lösung spricht immer noch gegen den standard wie schon oft gesagt.
1Zitat 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.
