IP von der DMZ in Produktivnetz

[TschungTschung]

Hi Leute,

ich baue mir gerade eine Testumgebung auf mit 2 LANCOM 1711+ hintereinander....
Also im Prinzip so: I-NET-->1711-->DMZ-Netz-->1711-->Produktivnetz (Also ich will eine richtige DMZ)
Jetzt stehe ich etwas auf dem Schlauch oder bin heute vielleicht schon zu viel am Testen.
Wenn ich mit dem VPN Client auf den ersten 1711 (DHCP Server aktiviert) komme (also in die DMZ) will ich mit dieser IP (z.B. 192.168.5.221) weiter ins Produktivnetz (z.B. 192.168.10.0/24). Wie kann ich denn das ermöglichen, dass der zweite 1711 mich ins "Produktivnetz" lässt. Über eine Firewall-Regel oder über einen Routing-Eintrag? Ich will jedenfalls keine Portmappings.... (z.B. nur für RDP 3389)
Danke

[5624]

Ich würde es so aufbauen, dass auf dem inneren Router das NAT auf der Defaultroute abgeschaltet ist, das WAN-Interface steht in der DMZ und der äußere Router kennt über eine Route das innere Netz. Eventuell musst du noch eine oder mehrere der Sperrrouten löschen/überschreiben.

Die Firewall einfach komplett dicht machen und nur das durchlassen, was wirklich sein muss.

Dadurch brauchst du kein NAT, egal ob Portforwarding oder N:N. Zeitgleich ist es ressourcenschonender.

Kurze Gegenfrage: Warum terminierst du dass VPN bereits am äußeren Router und schickst es nicht durch die DMZ an den inneren Router?

[TschungTschung]

Hi, danke für deine Antwort.

Sorry für die Frage, aber:

Kurze Gegenfrage: Warum terminierst du dass VPN bereits am äußeren Router und schickst es nicht durch die DMZ an den inneren Router?

Wie realisiere ich das?
Unter anderem ist es so, dass nur gewisser Leute ins "Produktivnetz" kommen sollen und die anderen in der DMZ verbleiben müssen.

Du meinst also das Prinzip erstmal alles aufmachen (Route), dann alles dicht machen (Firewall) und zum Schluss granular freigeben? Aber was bringt es mir wenn ich die IP-Maskierung deaktiviere von intern zur DMZ?

Aber ich muss doch auch nur eine IP z.B. wie bei nem IP-Filter durchlassen können, oder?

[5624]

Die Gegenfrage entstand aufgrund unzureichender Informationslage.

Es gibt viele Wege, dieses Problem zu lösen. Das war der Vorschlag, wie ich es vorsehen würde, da hierbei keine unnötigen IP-Übersetzungen anfallen. NAT kostet immer mehr Speicher und Performance als es normales Routing tut.

NAT ist auch nur eine Behelfslösung, um die ausgereizten IP-Bereiche länger nutzen zu können. Da du mit IP-Adressen aus dem RFC1918-Bereich arbeitest, ist dieses kein Problem, daher ist die NAT-Krücke nicht nötig.

Jetzt ist es wieder nur eine IP? In deinem Eingangspost ging es um ein komplettes IP-Subnetz, was erreicht werden soll.

[TschungTschung]

Guten Morgen,

Jetzt ist es wieder nur eine IP? In deinem Eingangspost ging es um ein komplettes IP-Subnetz, was erreicht werden soll.

Nein habe ich nicht gesagt, es soll eine ankommende IP in das ProduktivNetz