Probleme mit Routing interner LANs

Hallo PeterS,

Da du hinter der Astaro nochmals eine Firewall hast, welche wiederum selber NATen tut  so wird dieses Konzept nicht funktionieren.
Beispiel:
Wenn jetzt jemand aus dem LAN III Surft, dieser als Standard Gateway WLAN Router II hat, WLAN Router II wiederum als Standard Gateway die Astaro so kommt bei der Astaro nur jeweils eine IP an, nämlich diese vom WLAN Router II. (192.168.200.1)
Dieses Problem hast du bei DMZ I und DMZ II. Dass heisst du kannst hier nur mit der IP des WLAN Router II Einschränkungen treffen, dies gilt dann aber für alle Hosts welche hinter dem WLAN Router II sind, ausser du beschränkst ebenfalls auf dem WLAN Router II mittels Packet Filter.
Du musst alle Netze auf der Astaro hinterlegen auf den NICs (pro Interface, oder Additional) ebenfalls müssen die Physikalisch verbunden sein. Sprich LAN III und LAN II auf dedizierten NIC Patchen. (oder 1x LAN Netz als Additional auf gleiche LAN NIC)
Nur so kann die Astaro die verschiedenen Netze sehen und Routen! (Übrigens nicht nur Astaro, sondern alle Firewalls, da dies Netzwerktechnisch bedingt ist, ausser man macht das Routing auf den Switches)
Du benötigst dann mind. 5 Ethernet Ports, welche für DMZ und LAN zuständig sind, ebenfalls noch zwei zusätzliche für die Redundante WAN Anbindung. (Insgesammt 7 NIC's).
Danach kannst du per Packet Filter einrichten, wo welcher Traffic in den Segmenten durchgelassen wird und wo in welches eben nicht.
So klappts dann auch mit dem Routing [;)].


Grüsse,
Rezax

Hallo PeterS,

Da du hinter der Astaro nochmals eine Firewall hast, welche wiederum selber NATen tut  so wird dieses Konzept nicht funktionieren.
Beispiel:
Wenn jetzt jemand aus dem LAN III Surft, dieser als Standard Gateway WLAN Router II hat, WLAN Router II wiederum als Standard Gateway die Astaro so kommt bei der Astaro nur jeweils eine IP an, nämlich diese vom WLAN Router II. (192.168.200.1)

?!? Warum sollte das Surfen so nicht funktionieren? Masquerading hinter Masquerading ist überhaupt kein Problem und funktioniert solange wie es der Hopcount zulässt.

Natürlich verhindert Masquerading die direkte Kommunikation untereinander, d.h. Rechner aus LAN II können nicht direkt mit Rechnern aus LAN III kommunizieren und umgekehrt (genauso LAN I mit II & III). Das macht spezielles NAT erforderlich.

Allerdings ist das ein sehr häßliches Setup, zugegeben. Aber wenn die internen Netze nicht uneingeschränkt untereinander kommunizieren müssen, ist das gar kein Problem, surfen und Verbindungen nach Aussen über die ASG funktionieren.

Um aber der Frage des Threads nachzukommen: Statt der beiden NAT/Masquerading-Router musst Du Standardrouter hernehmen. Wenn das billige Soho-Router für den Heimgebrauch sind, ist das Konfigurieren von eigenen Routen höchstwahrscheinlich damit nicht möglich. Wenn Du dort aber Routen anstatt Masquerading konfigurieren kannst, so musst Du der ASG die jeweiligen Netze hinter den Routern bekannt machen (als Statische Routen auf der ASG, über die jeweiligen Router).

Die ASG unterstützt als Routing-Protokoll OSPF, damit ließe sich das Problem elegant lösen wenn die anderen Router das auch unterstützen.

Übrigens:

in unserem Projekt sollen 3 LAN Segmente ...

Du hast hier VIEL mehr Segmente als nur 3. Bei einem geswitchten LAN wie bei Dir beschreibt im Prinzip jede einzelne Kabelverbindung ein eigenes Segment. Bei Ethernet ist ein Segment eine Kollisionsdomäne. Bei einer Punkt-zu-Punkt-Verbindung, wie es bei geswitchten LANs der Fall ist, gibt es keine Kollisionen, da jede Verbindung ein dediziertes Segment ist. Nur mit Repeatern (=Hubs) kann man bei Twisted Pair größere Kollisionsdomänen schaffen. Früher waren Kollisionen wirklich ein Problem und Bridges (=Switches) waren sehr teuer.

Guten Abend,

zunächst mal allen recht herzlichen Dank für die umfangreichen Informationen.

Im Testaufbau befinden sich einfache WLAN-Router von TP.LINK hinter der ASG. Die Konfigurationsmöglichkeiten sind da sehr beschrankt. 

Ich bin noch auf der Suche nach einfachen Routern. Da es sich um eine kleinen, gemeinnützigen Verein handelt, soll es auch nicht so viel Geld kosten. Mir ist klar, dass ich mit "normalen" Routern das Netz einfacher aufbauen kann. Bis jetzt habe ich aber nichts unter der "Cisco" Klasse gefunden. Vielleicht hat ja einer von Euch noch eine Idee.

Meine Erfahrungen mit Astaro halten sich auch noch in Grenzen, so dass ich eigentlcui noch am Lernen bin. Deshalb nochmal besten Dank für die Antworten, die ich noch in aller Ruhe auswerten werden.

Wenn's Änderungen in der Landschaft gibt, melde ich mich wieder,

Gruss Peter

PS. Ich komme mit dem BulletinBoard auch noch nicht so gut zurecht. Ich konnte keinen individuellen Reply finden.

Wenn man auf die beiden Router verzichten kann, dann würde ich diese weglassen und die 5 Lansegmente direkt an der ASG anschliessen. (5 Netzwerkkarten)
Ob ein einfacher Router zwischen DMZ1 und LAN2 wirklich die SQL und FTP Server schützt, wage ich mal zu bezweifeln.
Und wenn in DMZ2 keine Rechner drin sind, kann man dieses Segment auch weglassen und LAN3 direkt an der ASG anschliessen.

Gregor Kemter

Schon wieder das böse "Segment"-Wort [:D]

Wer es einfach nicht glauben will: http://www.itwissen.info/definition/lexikon/LAN-Segment-LAN-segment.html

Einen sehr guten und günstigen Soho-Router habe ich ja bereits genannt.

Moin,

ich würde alle Lans direkt an die ASG anschliessen.
Ggf. je nach Switch Konstellation über VLANS.

Port 1 Admin Port, Port 2 Vlan2 und Vlan3 für DMZ1 und 2, Port3 Vlan4 und5 für Lan 2 und 3.

Sven

Schon wieder das böse "Segment"-Wort [:D]

Wer es einfach nicht glauben will: LAN-Segment :: LAN segment :: Definition :: IT-Lexikon

Was ist an dem Lan-Segment-Wort so böse ? [:S]


Gregor Kemter

Was ist an dem Lan-Segment-Wort so böse ? [:S]


Gregor Kemter

Nun ich versuche zu erklären, dass es etwas anderes bedeutet als hier offenbar mehrfach angenommen wird.

Sorry, I can't get my brain to write everything in German right now...

You are right Mario, it's sloppy of us to use "segment" when we are talking about routed subnets.

But, I don't understand that you say there's no probnlem with double natting (masquerading)  when IPSec and, I thought, other protocols have difficulty with it.  Can you be more specific?

Entschuldigt mein Englisch zurück auf Deutsch, bitte.

vD im Voraus - Bob

Nun ich versuche zu erklären, dass es etwas anderes bedeutet als hier offenbar mehrfach angenommen wird.

OK, also für mich ist ein Lan-Segment (sehr vereinfacht dargestellt):
ein Switch wo nur Geräte angeschlossen sind, die sich das selbe IP-Netz teilen.

Mann kann natürlich via VLAN eine quasi Trennung auf dem Switch bewirken,
oder mit mehreren IPs auf der selben Hardware eine logische Trennung bewirken.
Ich meinte aber aber eine strikte physikalische Trennung also mehrere Lan-Segmente. Oder habe ich wieder was was falsch verstanden ? 

Gregor Kemter

Wenn die Netze physikalisch getrennt sind (Durch Router), spricht man von mehreren Netzen und nicht von Segmenten. Denn genau das sind sie [:D]

Segmente _sind_ physikalisch getrennt (Bei Verwendung von Switches statt Hubs). Sonst könnte man an jedem Port am Switch den gesamten Verkehr der anderen Ports mithören (Wie bei einem Hub), wenn tatsächlich dasselbe Medium verwendet würde.

Also nochmal:
Switch oder Router/Rechner  Switch oder Router/Rechner
=> Dann ist genau das eine Kabel genau ein Segment.

Switch oder Router/Rechner  Hub  Switch oder Router/Rechner
=> Dann ist es auch genau ein Segment.

Switch oder Router/Rechner  Switch  Switch oder Router/Rechner
=> Dann sind es 2 Segmente.

Ist doch ganz einfach?

But, I don't understand that you say there's no probnlem with double natting (masquerading)  when IPSec and, I thought, other protocols have difficulty with it.  Can you be more specific?

Well. Surfing using one Masquerading Router seems no problem for you, right? Every Soho-Router does it so one can assume it just works [:P].

So, what do the two Masquerading Routers do here?

Lets assume the SQL-Server in LAN II wants to access the web. It sends the packet to its default Gateway which should be Router I. Router I translates the SOURCE-IP of the SQL-Server to its own IP of its interface in DMZ I and keeps a record for that translation in its NAT-Table (including unchanged DEST-IP) so that answer-packets can be translated back to the SQL-Server. That translated packet is now being send to the ASG which sould be default gateway of Router I. The ASG translates the SOURCE-IP of Router I to its public Internet-IP and keeps a record for that translation in its NAT-Table (including unchanged DEST-IP) so that answer-packets can be translated back to the  ASG. Then it sends the packet into the Internet.

When the answer comes from the Internet, the ASG translates it back to Router I and Router I translates it to the SQL-Server. That works as long as the Masquerading Routers still have the matching record for that packet in their NAT table.

So:
Masquerading does NAT for a whole IP-Network with very simple configuration. The NAT-Table is filled and maintained fully automatically.

NAT on its own just describes the actual translation of IP-Adresses and/or IP-Port numbers (for UDP/TCP). S/D/FNAT are _single_ NAT configurations. The NAT-Table is filled and maintained manually.

But both methods can be combined.

IPSec does not necessarily work because IPSec disallows by design the manipulation of the IP packet itself - which happens during NATing.

Other connections are just blocked if there is no NAT entry for them. Thats why many users think their Masquerading Router is some sort of firewall and it in fact is. Only connections that have been _initiated from the inside_ can pass trough (except manual NAT entries, also called "Port Forwardings" in Soho-Routers).

Ooops sorry habe erst zum schluss gemerkt dass ich hier eigentlich  im deutschen Forum bin...

But, I don't understand that you say there's no probnlem with double natting (masquerading)  when IPSec and, I thought, other protocols have difficulty with it.  Can you be more specific?

Well. Surfing using one Masquerading Router seems no problem for you, right? Every Soho-Router does it so one can assume it just works [:P].

So, what do the two Masquerading Routers do here?

Lets assume the SQL-Server in LAN II wants to access the web. It sends the packet to its default Gateway which should be Router I. Router I translates the SOURCE-IP of the SQL-Server to its own IP of its interface in DMZ I and keeps a record for that translation in its NAT-Table (including unchanged DEST-IP) so that answer-packets can be translated back to the SQL-Server. That translated packet is now being send to the ASG which sould be default gateway of Router I. The ASG translates the SOURCE-IP of Router I to its public Internet-IP and keeps a record for that translation in its NAT-Table (including unchanged DEST-IP) so that answer-packets can be translated back to the  ASG. Then it sends the packet into the Internet.

When the answer comes from the Internet, the ASG translates it back to Router I and Router I translates it to the SQL-Server. That works as long as the Masquerading Routers still have the matching record for that packet in their NAT table.

So:
Masquerading does NAT for a whole IP-Network with very simple configuration. The NAT-Table is filled and maintained fully automatically.

NAT on its own just describes the actual translation of IP-Adresses and/or IP-Port numbers (for UDP/TCP). S/D/FNAT are _single_ NAT configurations. The NAT-Table is filled and maintained manually.

But both methods can be combined.

IPSec does not necessarily work because IPSec disallows by design the manipulation of the IP packet itself - which happens during NATing.

Other connections are just blocked if there is no NAT entry for them. Thats why many users think their Masquerading Router is some sort of firewall and it in fact is. Only connections that have been _initiated from the inside_ can pass trough (except manual NAT entries, also called "Port Forwardings" in Soho-Routers).

Ooops sorry habe erst zum schluss gemerkt dass ich hier eigentlich  im deutschen Forum bin...