knibbelmumpf
Goto Top

Routingproblem über ein Zwischennetzwerk hinweg (incl. VPN)

Hallo alle zusammen,
ich hoffe, Ihr könnt mir auf die Sprünge helfen. Ich bin mit meinem Latein am Ende face-sad

Es geht um insgeamt 3 Netze.
A) "mein" eigenes: 171.1.1.0 MASK 255.255.255.0 - hier gibt es eine FireWall mit der IP 171.1.1.65
B) unser befreundets, ebenfalls zur Firma gehörendes Netz 10.0.100.0 MASK 255.255.255.0 - hier hat die FireWall die 10.0.100.2
C) das Netz des Dienstleisters - dort gibt es eine IP, auf die wir zugreifen wollen - 192.168.111.145

Im Endeffekt geht es darum, dass die 192.168.111.145 ein SAP System ist, auf das wir mittels SAP GUI aus Netz A zugreifen wollen.
Zwischen Netz B (befreundet) und C (SAP des Dienstleisters) existiert ein VPN - und über dieses funktioniert auch der Zugriff mittels SAP GUI. Auch der Ping von B auf 192.168.11.145 funktioniert über das VPN.

Wir können nun leider kein eigenes VPN zwischen A ("meins") und C (Dienstleister) einrichten.
Wir haben aber ein funktionierendes VPN zwischen A und B. Hier klappen die Zugriffe und Pings etc. in beide Richtungen.

Eigentlich dachte ich, dass es nun auch einfach sein müsste, dem DefaultGateway von A (das ist dort meine FireWall 171.1.1.65) beizubringen, dass 192.168.111.145 über das VPN zu erreichen ist - und damit der Zugriff von A nach C funktionieren würde.

Leider klappt das nicht ! Ich hoffe, ihr könnt mir helfen.

Folgende Randbedingungen:
Im VPN von B nach C wird geNATet - d.h alle Clients in B erscheinen mit derselben IP (der der dortigen FireWall) bei C. Wäre das nicht so, müsste ich bei C einen Routingeintrag für 171.1.1.0 (Netz A) anlegen lassen. Das geht leider nicht.

Im VPN zwischen A und B habe ich freie Hand.
Dort habe ich alle Varianten von NAT und nichtNAT ausprobiert (kein NAT. NAT nur von A nach B, NAT nur von B nach A, NAT in beide Richtungen) - trotzdem bekome ich beim Ping von A nach C "Zeitüberschreitung der Anforderung" face-sad
Von A nach B kann ich pingen (z.B. von 171.1.1.33 nach 10.0.100.2)
Von B nach C kann ich auch pingen (z.B. von 10.0.100.20 nach 192.168.111.145)

Bei den FireWalls handelt es sich nicht um Windows-rechner sondern um a) Watchguard und b) FortiGate.

Wisst Ihr noch einen Rat ?

Beste Grüße
knibbelmumpf

Content-Key: 114541

Url: https://administrator.de/contentid/114541

Ausgedruckt am: 28.03.2024 um 14:03 Uhr

Mitglied: spacyfreak
spacyfreak 23.04.2009 um 20:07:39 Uhr
Goto Top
Das geht nicht weil Netz A nicht in der Encryption Domain des VPNs von Netz C drin ist.
Daher wird keine Verbindung von A nach C funktionieren.

Daher muss das A Netz entweder in die Encryption Domain zwischen B und C hinzugefügt werden, oder man bedient sich eines NAT-Tricks.
Mit einer Masquerading Rule könnte man dem VPN Server in C vorgaukeln, eine Anfrage von A käme eigentlich vom B Netz.
Dazu muss die A-Ip Adresse via "source NAT" auf VPN Server B übersetzt werden in eine freie (virtuelle) IP-Adresse die zum B-Netz gehört. Dann kann einer aus Netz A über die virtuelle IP aus Netz B auf C zugreifen.
Mitglied: knibbelmumpf
knibbelmumpf 24.04.2009 um 04:19:34 Uhr
Goto Top
Hallo,

danke für Deine Antwort.

Ich war bisher der Meinung, dass dies ja durch das NATen von B nach C erfolgen würde - dadurch kommen aus sich von C (bzw. aus Sich von 192.168.111.145) alle Anfragen von derselben IP-Adresse - nämlich von B, oder ?

Dann dachte ich: doppelt hält besser: Ich habe von A nach B geNATet - d.h. alle Anfragen von A nach B scheinen von der IP des VPN-Endpunkts in B zu kommen (also von 10.0.100.2).
Funktionierte abefr auch nicht...
Wenn ich mich von A auf einen Server in B verbunden habe, sagte der Server, 10.0.100.2 hätte sich mit ihm zu verbinden.
Mein Ping auf 192.168.111.145 kam aber nicht ab - bzw. kam nicht zurück face-sad

Ich werde mich auf jeden Fall mal mit dem Thema "Source NAT" beschäftigen - und gucken, ob ich das auf einer der FireWalls aktivieren kann.

Beste Grüße,
knibbelmumpf
Mitglied: spacyfreak
spacyfreak 24.04.2009 um 12:02:25 Uhr
Goto Top
Ich hab mit solchen Problemen täglich zu tun, das sollte funktionieren. Eventuell auch FW Regeln anpassen, Schritt für Schritt vorgehen und schaun wo die Pakete hängenbleiben wenns nicht funktioniert. Eventuell auch Netzwerksniffer / tcpdump benutzen um zu schauen wo was ankommt oder eben nicht ankommt.