Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 1 subscriber
  • Views 1138 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Verständnis Route oder Problem

Photographix
Hallo Leute folgendes Problem stellt sich mir schon seit gestern.

Im Bild anbei ist unsere aktuelle Konfig der Firewall abgebildet.
Der blaue Teil ist der Teil der problemlos funktioniert. Dieser steht bei uns im Haus.

Um die Hochverfügbarkeit sicher zu stellen verlagern wir Teile der DMZ und des Intranets in ein RZ (lila).
Der Anbieter des RZ hat uns dazu einen Router konfiguriert und wir mussten diesen nur noch anstecken.

Hier im Haus sollte ich nur zwei Routen einrichten (siehe Bild) damit alles wieder wie gewohnt funktioniert.
Leider war dies dank "Murphy" nicht so.

Jetzt weiss ich nicht genau wo das Problem liegt.
Was muss ich wo drehen damit alles wieder wie vorher ist.
Angeblich soll ja alles transparent für uns sein.

Auf den Rechner im Netz 192.168.10.x kann ich problemlos zugreifen.
Auf den Rechner im Netz 172.20.10.x nicht.

Anbei die Routen der Firewall:

default via 192.168.0.60 dev eth1 table 1 
default via 172.20.0.10 dev eth2 table 2 
default via 213.x.x.A dev eth0 table 200 proto static onlink 
default via 213.x.x.A dev eth0 table default proto kernel onlink 
10.242.2.2 dev tun0 proto kernel scope link src 10.242.2.1 
172.20.0.0/28 dev eth2 proto kernel scope link src 172.20.0.1 
213.x.x.C /28 dev eth0 proto kernel scope link src 213.x.x.B 
10.242.2.0/24 via 10.242.2.2 dev tun0 
192.168.0.0/23 dev eth1 proto kernel scope link src 192.168.0.2 
127.0.0.0/8 dev lo scope link 
local 10.242.2.1 dev tun0 table local proto kernel scope host src 10.242.2.1 
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
broadcast 172.20.0.0 dev eth2 table local proto kernel scope link src 172.20.0.1 
local 172.20.0.1 dev eth2 table local proto kernel scope host src 172.20.0.1 
broadcast 172.20.0.15 dev eth2 table local proto kernel scope link src 172.20.0.1 
broadcast 192.168.0.0 dev eth1 table local proto kernel scope link src 192.168.0.2 
local 192.168.0.2 dev eth1 table local proto kernel scope host src 192.168.0.2 
broadcast 192.168.1.255 dev eth1 table local proto kernel scope link src 192.168.0.2 
broadcast 213.x.x.C dev eth0 table local proto kernel scope link src 213.x.x.B
local 213.x.x.B dev eth0 table local proto kernel scope host src 213.x.x.B 
broadcast 213.x.x.D dev eth0 table local proto kernel scope link src 213.x.x.B
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1


This thread was automatically locked due to age.
  • 0
    Hum, ich gehe mal davon aus, dass die Router auf der anderen Seite nicht eure gesamte Netzstruktur inne haben. Von daher müsstest du wohl Masquerading nutzen, da quasi das Paket zur Gegenstelle rausgeht, die Gegenstelle aber nicht weis wer du bist und aus dem Grund (fehlende Rückroute) nicht auf dem korrekten Weg antworten kann.
    Lege einfach mal eine Masq Regel "Interne Netze" -> eth2 an und schau mal ob es dann klappt.

    Grüße

    Schroeder
  • 0 in reply to Schroeder
    Hallo Schroeder,

    danke für die schnelle Antwort.

    Es gibt/gab aber schon wegen der DMZ eine Regel

    Intranet eth1 [192.168.0.2/23] an DMZ eth2 [172.20.0.1/28]
  • 0 in reply to Photographix
    Threat kann geschlossen werden.
    Entweder haben die Jungs vom RZ etwas gemacht oder es lang an Richtlinienroutung vs. statisches Routing.

    Zumndest geht es jetzt :-)