6
Eingehenden und ausgehenden Datenverkehr über zwei WAN Anschlüsse trennen
Hallo zusammen,
aktuell ist mein LAN über einen KDG Anschluss mit dem Rest der Welt verbunden.
Der Aufbau ist dabei: Internet --> KDG Modem / Router --> Endian Firewall (Community 2.5.1) --> LAN (Server + Clients)
Im Internet steht noch ein angemieteter virtueller Server, der für den Exchange im LAN als Relay dient (genau genommen ist der Endian Mailserver auch noch dazwischen). Läuft auch alles wunderbar.
Ich habe allerdings zunehmend das Problem, dass die dynamischen KDG IPs bei bestimmten reputationsbasierten Webfiltern eher schlecht gescored werden. Das führt dazu, dass z.B. Outlook Web Access oder Remote Web Workplace aus bestimmten Netzen nicht zu erreichen sind (da der A Eintrag der Domain auf eine dynamische KDG IP zeigt).
Jetzt habe ich hier noch einen (langsamen) DSL Zugang mit statischer IP, bei dem das Filterproblem nicht besteht.
Folgendes ist mein Wunschszenario:
Domain abc.de --> A Eintrag auf die statische IP Adresse des DSL Zugangs, so dass über die abc.de ein Zugriff auf OWA und RWW möglich ist (eingehender Datenverkehr). Internetaufrufe aus dem LAN (ausgehender Datenverkehr) sollen aus Performancegründen wie bisher über den KDG Zugang laufen, auch der Mailaustausch.
Nun funktioniert es offensichtlich leider nicht, den DSL Router einfach neben den KDG Router vor die Endian zu hängen. Der DSL Router ist zwar aus dem Internet erreichbar, das Port-Forwarding DSL-Router --> Endian läuft aber (im Gegensatz zum Port-Forwarding KDG-Router --> Endian) ins Leere. Möglicherweise weil in der Endian das Standard Gateway auf den KDG Router zeigt?! Würde ein zusätzlicher Uplink in der RED ZONE funktionieren?
Wie kann ich den DSL Zugang integrieren, damit o.g. Szenario funktioniert?
Bin für jeden Tip dankbar.
VG
Eike
aktuell ist mein LAN über einen KDG Anschluss mit dem Rest der Welt verbunden.
Der Aufbau ist dabei: Internet --> KDG Modem / Router --> Endian Firewall (Community 2.5.1) --> LAN (Server + Clients)
Im Internet steht noch ein angemieteter virtueller Server, der für den Exchange im LAN als Relay dient (genau genommen ist der Endian Mailserver auch noch dazwischen). Läuft auch alles wunderbar.
Ich habe allerdings zunehmend das Problem, dass die dynamischen KDG IPs bei bestimmten reputationsbasierten Webfiltern eher schlecht gescored werden. Das führt dazu, dass z.B. Outlook Web Access oder Remote Web Workplace aus bestimmten Netzen nicht zu erreichen sind (da der A Eintrag der Domain auf eine dynamische KDG IP zeigt).
Jetzt habe ich hier noch einen (langsamen) DSL Zugang mit statischer IP, bei dem das Filterproblem nicht besteht.
Folgendes ist mein Wunschszenario:
Domain abc.de --> A Eintrag auf die statische IP Adresse des DSL Zugangs, so dass über die abc.de ein Zugriff auf OWA und RWW möglich ist (eingehender Datenverkehr). Internetaufrufe aus dem LAN (ausgehender Datenverkehr) sollen aus Performancegründen wie bisher über den KDG Zugang laufen, auch der Mailaustausch.
Nun funktioniert es offensichtlich leider nicht, den DSL Router einfach neben den KDG Router vor die Endian zu hängen. Der DSL Router ist zwar aus dem Internet erreichbar, das Port-Forwarding DSL-Router --> Endian läuft aber (im Gegensatz zum Port-Forwarding KDG-Router --> Endian) ins Leere. Möglicherweise weil in der Endian das Standard Gateway auf den KDG Router zeigt?! Würde ein zusätzlicher Uplink in der RED ZONE funktionieren?
Wie kann ich den DSL Zugang integrieren, damit o.g. Szenario funktioniert?
Bin für jeden Tip dankbar.
VG
Eike
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: 220827
Url: https://administrator.de/contentid/220827
Printed on: April 23, 2024 at 16:04 o'clock
6 Comments
Latest comment
Moin,
Du suchst nach Policy Based Routing, die Suchfunktion wird dein Freund sein.
VG,
Thomas
Du suchst nach Policy Based Routing, die Suchfunktion wird dein Freund sein.
VG,
Thomas
Ein Dual Port WAN Router wie Cisco 886va oder Draytek 29xx löst das Problem im Handumdrehen !
Bedenke allerdings immer das du keine Flow basierte Trennung hinbekommst wenn du mit NAT Routern arbeitest ! Also keine per Paket Trennung.
Das ist auch klar wenn man sich die Grundmechanismen von TCP/IP mal vor Augen führt.
Am Zielhost kommen deine lokalen Pakete durch NAT (Adress Translation) am Router immer mit der öffentlichen Absender IP des Routers an.
Der Zielhost wird dann natürlich auch alle Pakete einer Session zwingend immer an diese IP Adresse zurücksenden. Würdest du das verändern, kommt es zu einen IP Adress Mismatch in der Session was zum sofortigen Abbruch selbiger führt.
Du kannst also immer nur ein sessionbasiertes PBR (Policy Based Routing) machen, was die obigen Systeme problemlos erledigen. Ob die Endian PBR kann ist unbekannt. Generell können Firewalls wie z.B. pfsense_/_Monowall PBR. Deine restliche verwendete HW kann generell kein PBR deshalb muss dein Ansatz damit schon im Grundsatz scheitern, was er ja auch tut wie man oben lesen kann.
Bedenke allerdings immer das du keine Flow basierte Trennung hinbekommst wenn du mit NAT Routern arbeitest ! Also keine per Paket Trennung.
Das ist auch klar wenn man sich die Grundmechanismen von TCP/IP mal vor Augen führt.
Am Zielhost kommen deine lokalen Pakete durch NAT (Adress Translation) am Router immer mit der öffentlichen Absender IP des Routers an.
Der Zielhost wird dann natürlich auch alle Pakete einer Session zwingend immer an diese IP Adresse zurücksenden. Würdest du das verändern, kommt es zu einen IP Adress Mismatch in der Session was zum sofortigen Abbruch selbiger führt.
Du kannst also immer nur ein sessionbasiertes PBR (Policy Based Routing) machen, was die obigen Systeme problemlos erledigen. Ob die Endian PBR kann ist unbekannt. Generell können Firewalls wie z.B. pfsense_/_Monowall PBR. Deine restliche verwendete HW kann generell kein PBR deshalb muss dein Ansatz damit schon im Grundsatz scheitern, was er ja auch tut wie man oben lesen kann.
Hallo,
danke für die Rückmeldungen.
Folgendes habe ich gemacht & funktioniert:
1. Uplink in der Firewall (Gateway = KDG Router) aufgebaut wie folgt:
Internet --> Kabel Deutschland Router (Port Forwarding) --> Endian FW --> LAN
dynamische WAN-IP --> 192.168.1.1 --> 192.168.1.2 --> 192.168.0.x
Dieser Uplink ist als Hauptuplink aktiviert, so dass aller Traffic aus dem LAN in Richtung Internet über den KDG Anschluss läuft (kein Balancing).
Mit einer weiteren Netzwerkkarte einen zusätzlichen Uplink (Gateway = DSL Router) in der FW eingerichtet:
Internet --> DSL Router (Port Forwarding) --> Endian FW --> LAN
statische WAN IP --> 192.168.2.1 --> 192.168.2.2 --> 192.168.0.x
Alles was an der öffentlichen IP des DSL Routers ankommt wird über den 2. Uplink ins LAN gerouted.
Danke,
Eike
danke für die Rückmeldungen.
Folgendes habe ich gemacht & funktioniert:
1. Uplink in der Firewall (Gateway = KDG Router) aufgebaut wie folgt:
Internet --> Kabel Deutschland Router (Port Forwarding) --> Endian FW --> LAN
dynamische WAN-IP --> 192.168.1.1 --> 192.168.1.2 --> 192.168.0.x
Dieser Uplink ist als Hauptuplink aktiviert, so dass aller Traffic aus dem LAN in Richtung Internet über den KDG Anschluss läuft (kein Balancing).
Mit einer weiteren Netzwerkkarte einen zusätzlichen Uplink (Gateway = DSL Router) in der FW eingerichtet:
Internet --> DSL Router (Port Forwarding) --> Endian FW --> LAN
statische WAN IP --> 192.168.2.1 --> 192.168.2.2 --> 192.168.0.x
Alles was an der öffentlichen IP des DSL Routers ankommt wird über den 2. Uplink ins LAN gerouted.
Danke,
Eike
So gehts natürlich auch...aber ohne ein PBR Routing wärst du dann vom Endgerät und dessen Gateway Eintrag abhängig !
Beispiel:
Du kommst rein über die öffentliche IP des DSL Routers (der dann vom remoten Absender die Ziel IP ist) wirst über die Firewall auf das gemeinsame LAN 192.168.0.x /24 auf ein Endgerät dort geroutet was soweit ja funktioniert.
Hat dieses Endgerät jetzt aber über die FW den KDG Router als default Gateway, dann kommt am vorigen Absender ein Antwortpaket mit einer anderen Absender IP an nämlich der des KDG Routers.
Der Absender erwartet aber ein Antwortpaket mit der DSL Router IP und verwirft sofort die Session. So kann das also niemals funktionieren. Ausnahme natürlich du hast in der FW eine PBR Regel die diesen Traffic trotz Gateway Eintrag auf den KDG Router dann als next Hop an den DSL Router sendet.
Dann funktioniert es wieder. Die Endian muss also zwingend irgendeine Art von PBR machen.
Beispiel:
Du kommst rein über die öffentliche IP des DSL Routers (der dann vom remoten Absender die Ziel IP ist) wirst über die Firewall auf das gemeinsame LAN 192.168.0.x /24 auf ein Endgerät dort geroutet was soweit ja funktioniert.
Hat dieses Endgerät jetzt aber über die FW den KDG Router als default Gateway, dann kommt am vorigen Absender ein Antwortpaket mit einer anderen Absender IP an nämlich der des KDG Routers.
Der Absender erwartet aber ein Antwortpaket mit der DSL Router IP und verwirft sofort die Session. So kann das also niemals funktionieren. Ausnahme natürlich du hast in der FW eine PBR Regel die diesen Traffic trotz Gateway Eintrag auf den KDG Router dann als next Hop an den DSL Router sendet.
Dann funktioniert es wieder. Die Endian muss also zwingend irgendeine Art von PBR machen.
Hallo aqui,
danke für Dein Feedback - ich kenne mich in den Tiefen von TCP/IP Routing wahrlich nicht aus
Server und Clients im LAN haben als Standardgateway die FW.
Ich vermute, dass die FW aufgrund der jetzigen Konfiguration mit 2 WAN Schnittstellen (129.168.1.x und 192.168.2.x) die Antwort aus dem LAN - bspw. vom IIS - wieder an das Gateway / den Router schickt, von dem die Anfrage her kam.
Zumindest sind jetzt die Dienste ansprechbar - auch aus Netzen, aus denen es vorher über den KDG Router nicht ging.
VG
Eike
danke für Dein Feedback - ich kenne mich in den Tiefen von TCP/IP Routing wahrlich nicht aus
Server und Clients im LAN haben als Standardgateway die FW.
Ich vermute, dass die FW aufgrund der jetzigen Konfiguration mit 2 WAN Schnittstellen (129.168.1.x und 192.168.2.x) die Antwort aus dem LAN - bspw. vom IIS - wieder an das Gateway / den Router schickt, von dem die Anfrage her kam.
Zumindest sind jetzt die Dienste ansprechbar - auch aus Netzen, aus denen es vorher über den KDG Router nicht ging.
VG
Eike
OK, wenns jetzt irgendwie geht ist ja gut....
