Richtiges Routing durch ipsec Tunnel zu entfernter DMZ
Hallo,
Ich bin leider noch neu im Thema Routing über Subnetzgrenzen hinweg, ich hoffe ihr könnt mir helfen:
2 Endian 2.1 Firewalls an 2 Standorten die über einen IPsec Tuhnnel miteinander verbunden sind.
In Netz B ist an der dortigen Endian auch noch eine DMZ konfiguriert.,
grünes Netz A: 192.168.1.0/24
grünes Netz B: 192.168.2.0/24 oranges Netz : 192.168.5.0/24 (DMZ)
Nun möchte ein WinXP Client in Netz A Daten mit einem Rechner in der DMZ von Netz B austauschen was leider so nicht funktioniert.
Was ist zu tun um dem Client in Netz A Zugriff auf die DMZ an der Endian FW bei Netz B zu ermöglichen ?
viele Grüße
tkbeat
Ich bin leider noch neu im Thema Routing über Subnetzgrenzen hinweg, ich hoffe ihr könnt mir helfen:
2 Endian 2.1 Firewalls an 2 Standorten die über einen IPsec Tuhnnel miteinander verbunden sind.
In Netz B ist an der dortigen Endian auch noch eine DMZ konfiguriert.,
grünes Netz A: 192.168.1.0/24
grünes Netz B: 192.168.2.0/24 oranges Netz : 192.168.5.0/24 (DMZ)
Nun möchte ein WinXP Client in Netz A Daten mit einem Rechner in der DMZ von Netz B austauschen was leider so nicht funktioniert.
Was ist zu tun um dem Client in Netz A Zugriff auf die DMZ an der Endian FW bei Netz B zu ermöglichen ?
viele Grüße
tkbeat
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 143993
Url: https://administrator.de/forum/richtiges-routing-durch-ipsec-tunnel-zu-entfernter-dmz-143993.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
6 Kommentare
Neuester Kommentar
Es gibt gar kein Routing innerhalb eines Subnetzes, denn das wäre ja logischerweise gar kein Routing...in der Beziehung ist dein Statement von oben sinnfrei !!
Ein simpler statischer Routing Eintrag fixt dein Problem im Handumdrehen:
Endian Netz A:
Zielnetz: 192.168.5.0 Maske: 255.255.255.0, Gateway: <ip_adresse_vpn_endianB>
Die Endian A muss ja wissen wie es des .5.0er netz erreicht. Gibst du keine statische Route an via VPN Tunnel dann routet sie den Traffic ins Internet (default Route) wo er verschwindet !
Endian Netz B:
Kennt das 192.168.1.0er Netz da es an ihr selbst direkt per VPN dran ist !
Voraussetzung ist aber auch das du der Firewall B sagst aus der DMZ dürfen Pakete ins .1.0er Netz durch und andersrum !!
...eigentlich alles ganz kinderleicht !!
Ein simpler statischer Routing Eintrag fixt dein Problem im Handumdrehen:
Endian Netz A:
Zielnetz: 192.168.5.0 Maske: 255.255.255.0, Gateway: <ip_adresse_vpn_endianB>
Die Endian A muss ja wissen wie es des .5.0er netz erreicht. Gibst du keine statische Route an via VPN Tunnel dann routet sie den Traffic ins Internet (default Route) wo er verschwindet !
Endian Netz B:
Kennt das 192.168.1.0er Netz da es an ihr selbst direkt per VPN dran ist !
Voraussetzung ist aber auch das du der Firewall B sagst aus der DMZ dürfen Pakete ins .1.0er Netz durch und andersrum !!
...eigentlich alles ganz kinderleicht !!
route add net 192.168.1.0 auf Endian B ist wie oben bereits bemerkt überflüssig denn Endian B weiss selber das das .1.0er Netz an ihr dran ist über den VPN Tunnel. Das kannst du also getrost weglassen !
SIOCADDRT heisst das das Gateway falsch ist.
Normalerweise sollte auch
route add -net 192.168.5.0 netmask 255.255.255.0 gw <VPN IP Adresse Endian B> auf Endian A reichen !
Es ist natürlich Unsinn auf Endian A als Gateway 192.168.1.5 anzugeben, denn das ist eine IP Adresse aus dem lokalen LAN !! Das ist natürlich Blödsinn, denn dahinter verbirgt sich ja kein Router !
Als Gateway muss dort die IP Adresse des VPN Tunnelinterfaces von Endian B angegeben werden !! Du fährst ja im Tunnel ein eigenes IP Netz !!
Das Device Statement dev... kannst du dir auch sparen !
SIOCADDRT heisst das das Gateway falsch ist.
Normalerweise sollte auch
route add -net 192.168.5.0 netmask 255.255.255.0 gw <VPN IP Adresse Endian B> auf Endian A reichen !
Es ist natürlich Unsinn auf Endian A als Gateway 192.168.1.5 anzugeben, denn das ist eine IP Adresse aus dem lokalen LAN !! Das ist natürlich Blödsinn, denn dahinter verbirgt sich ja kein Router !
Als Gateway muss dort die IP Adresse des VPN Tunnelinterfaces von Endian B angegeben werden !! Du fährst ja im Tunnel ein eigenes IP Netz !!
Das Device Statement dev... kannst du dir auch sparen !
Das mit dem Pingen ist auch klar. Vermutlich ist das wie immer die Windows Firewall. Normalerweise blockt die alles was nicht lokal ist. Da du aber von dem remoten Netzen kommst mit einer anderen IP ist das dann logisch das in der FW das hängenbleibt.
Du musst den IP Bereich in der Win Firewall cusomizen auf die remoten Netze oder den "Klick " bei "Alle Computer inklusive Internet" machen bei den entsprechenden Diensten.
Bei den ICMP Einstellungen muss der Haken dein "Auf eingehende Echos antworten" gesetzt sein sonst iss nix mit Ping aus remoten Netzen !!
Wenn du in der Route keine IP Adresse der remoten Firewall eingeben kannst, dann reicht es das du das Interface spezifiszierst. Das sähe dann so aus:
Endian Netz A:
Zielnetz: 192.168.5.0 Maske: 255.255.255.0, Gateway: ipsec0 (oder tap1 oder...)
Die Konfig sieht ziemlich vermurkst aus. Sehr bedenkliche Punkte sind:
Fakt ist das du eine statische Route in der Endian A angeben musst ins 5er Netz und die muss logischerweise auf das Tunnelinterface zeigen damit diese Pakete in den VPN Tunnel geroutet werden zur Endian B ! Denn nur so weiss Endian A wie es das 5er Netz erreichen kann andernafalls ist es für sie eine Adresse im Internet !
Und da verschwinden die 5er Pakete dann...
Die Route auf die Clients zu setzen ist kompletter Blödsinn, denn was willst du da denn als next Hop Adresse angeben ?? Das ist doch wieder die Endian IP und dann hast du wieder das gleiche Problem.
Wichtig ist das die Endian A weiss das sie das .5er Netz über ihr VPN Tunnelinterface erreicht !!!
Du musst den IP Bereich in der Win Firewall cusomizen auf die remoten Netze oder den "Klick " bei "Alle Computer inklusive Internet" machen bei den entsprechenden Diensten.
Bei den ICMP Einstellungen muss der Haken dein "Auf eingehende Echos antworten" gesetzt sein sonst iss nix mit Ping aus remoten Netzen !!
Wenn du in der Route keine IP Adresse der remoten Firewall eingeben kannst, dann reicht es das du das Interface spezifiszierst. Das sähe dann so aus:
Endian Netz A:
Zielnetz: 192.168.5.0 Maske: 255.255.255.0, Gateway: ipsec0 (oder tap1 oder...)
Die Konfig sieht ziemlich vermurkst aus. Sehr bedenkliche Punkte sind:
- Interface br0 = inet addr:192.168.1.5 Bcast:@+++192.168.30.255@@ Mask:255.255.255.0 ...wie kommt hier eine .30er Adresse rein ?? Die gibts im ganzen Netz nicht ! Außerdem das Netz ist die .1.0 aber hat eine .30.255er Broadcast Adresse...wie geht denn sowas ?? Richtig wäre .1.255 !
- eth2 = inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0 ...ebenso...wo kommt die her ?
Fakt ist das du eine statische Route in der Endian A angeben musst ins 5er Netz und die muss logischerweise auf das Tunnelinterface zeigen damit diese Pakete in den VPN Tunnel geroutet werden zur Endian B ! Denn nur so weiss Endian A wie es das 5er Netz erreichen kann andernafalls ist es für sie eine Adresse im Internet !
Und da verschwinden die 5er Pakete dann...
Die Route auf die Clients zu setzen ist kompletter Blödsinn, denn was willst du da denn als next Hop Adresse angeben ?? Das ist doch wieder die Endian IP und dann hast du wieder das gleiche Problem.
Wichtig ist das die Endian A weiss das sie das .5er Netz über ihr VPN Tunnelinterface erreicht !!!