6
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 143993
Url: https://administrator.de/contentid/143993
Ausgedruckt am: 22.11.2024 um 14:11 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 !!
Also ich habs jetzt auf Endian A versucht mit :
route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.1.5 dev ipsec0 # (192.168.1.5 = gw grünes Netz B)
und
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.5.5 dev ipsec0 # (192.168.5.5 = gw oranges Netz B)
leider kommt jedesmal der Fehler : SIOCADDRT: Network is unreachable
Kannst du mir auf die Sprünge helfen ?
viele Grüße
tkbeat
route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.1.5 dev ipsec0 # (192.168.1.5 = gw grünes Netz B)
und
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.5.5 dev ipsec0 # (192.168.5.5 = gw oranges Netz B)
leider kommt jedesmal der Fehler : SIOCADDRT: Network is unreachable
Kannst du mir auf die Sprünge helfen ?
viele Grüße
tkbeat
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 !
Zitat von @aqui:
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 !!
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 !!
danke für deine Antwort, leider ist das nicht ganz richtig
im Tunnel wird kein eigenes Netz gefahren, ich kenn allerdings von anderen OpenVPN Konfigurationen dass das dort der Fall ist. hier aber nicht.
vieleicht ist das bei ipsec nicht so ?!
Beim ping direkt von der Endian A (192.168.1.5) auf das Gateway in Netz B (192.168.2.5) kommt keine Antwort , auch auf sämtliche anderen Maschinen in Netz B nicht.
Alle Clients in Netz A kommen aber problemlos auf Maschinen in Netz B.
Und von Clients in A ist auch das Gateway von B (192.168.2.5) pingbar.
Ein ifconfig auf der Endian A hab ich mal angehängt :
br0 Link encap:Ethernet HWaddr 00:22:B0:BC:XX:XX
inet addr:192.168.1.5 Bcast:192.168.30.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:44093166 errors:0 dropped:0 overruns:0 frame:0
TX packets:47311908 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2057392826 (1.9 GiB) TX bytes:839993455 (801.0 MiB)
eth0 Link encap:Ethernet HWaddr 00:22:B0:BC:XX:XX
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:42713203 errors:0 dropped:0 overruns:0 frame:0
TX packets:48648586 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2415690941 (2.2 GiB) TX bytes:1270589910 (1.1 GiB)
Interrupt:21 Base address:0x5000
eth1 Link encap:Ethernet HWaddr 00:21:27:C7:XX:XX
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:18325767 errors:0 dropped:0 overruns:0 frame:0
TX packets:17789625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1550064756 (1.4 GiB) TX bytes:1904150321 (1.7 GiB)
Interrupt:18 Base address:0x5400
eth2 Link encap:Ethernet HWaddr 00:30:05:5B:XX:XX
inet addr:1.1.1.1 Bcast:1.1.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68366030 errors:0 dropped:0 overruns:0 frame:0
TX packets:59500772 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:833599878 (794.9 MiB) TX bytes:683580432 (651.9 MiB)
Base address:0x4000 Memory:e0100000-e0120000
ipsec0 Link encap:Point-to-Point Protocol
inet addr:öffentliche IP Mask:255.255.255.255
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:822172 errors:0 dropped:0 overruns:0 frame:0
TX packets:777425 errors:102 dropped:960 overruns:0 carrier:102
collisions:0 txqueuelen:10
RX bytes:432627473 (412.5 MiB) TX bytes:127538536 (121.6 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:240968 errors:0 dropped:0 overruns:0 frame:0
TX packets:240968 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21836514 (20.8 MiB) TX bytes:21836514 (20.8 MiB)
ppp0 Link encap:Point-to-Point Protocol
inet addr:öffentliche IP P-t-P:öffentlicher Peer des ISP Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:15862248 errors:0 dropped:0 overruns:0 frame:0
TX packets:15693543 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:3450823801 (3.2 GiB) TX bytes:2867559684 (2.6 GiB)
tap1 Link encap:Ethernet HWaddr 00:FF:7A:FF:XX:XX
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:1382198 errors:0 dropped:0 overruns:0 frame:0
TX packets:1479472 errors:0 dropped:88 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:368126659 (351.0 MiB) TX bytes:540773840 (515.7 MiB)
ist der einzige Ausweg, die Route direkt auf den Clients in A zu setzen ?
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 !!!
Danke für deine Antwort.
Der Ping wurde direkt auf der Endian (per SSH) versucht, da hängt keine FW dazwischen.
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...)
Ich konnte mit
route add -net 192.168.5.0 netmask 255.255.255.0 dev ipsec0
eine route in der FW hinzufügen. route gibt nun folgendes aus :
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 * 255.255.255.0 U 0 0 0 ipsec0
Dh er weiss jetzt das das Netz 192.168.5.0 über das dev ipsec0 zu erreichen ist.
Ping funktioniert aber leider immernoch nicht - weder vom Client in Netz A (auch bei abgeschalteter Win FW), noch von der Endian direkt.
Die Konfig sieht ziemlich vermurkst aus. Sehr bedenkliche Punkte sind:
sowas ?? Richtig wäre .1.255 !
nur der etwas erfolglose versuch den echten privaten IP Bereich für den Post hier zu verschleiern *g*
Beim nexten mal prüf ich auch die Broadcast-Adresse ;)
soweit verstanden.
das ist der Punkt
gruss tkbeat
Zitat von @aqui:
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 !!
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 !!
Der Ping wurde direkt auf der Endian (per SSH) versucht, da hängt keine FW dazwischen.
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...)
Ich konnte mit
route add -net 192.168.5.0 netmask 255.255.255.0 dev ipsec0
eine route in der FW hinzufügen. route gibt nun folgendes aus :
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.0 * 255.255.255.0 U 0 0 0 ipsec0
Dh er weiss jetzt das das Netz 192.168.5.0 über das dev ipsec0 zu erreichen ist.
Ping funktioniert aber leider immernoch nicht - weder vom Client in Netz A (auch bei abgeschalteter Win FW), noch von der Endian direkt.
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 ??
sowas ?? Richtig wäre .1.255 !
nur der etwas erfolglose versuch den echten privaten IP Bereich für den Post hier zu verschleiern *g*
Beim nexten mal prüf ich auch die Broadcast-Adresse ;)
* 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 dasTunnelinterface 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...
5er Netz erreichen kann andernafalls ist es für sie eine Adresse im Internet !
Und da verschwinden die 5er Pakete dann...
soweit verstanden.
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 !!!
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 !!!
das ist der Punkt
gruss tkbeat
