VPN Tunnel in mehrere gleiche unique Subnetze

andy · Beitrag von **andy** » Mi 05.08.2009, 10:00

Hallo.

Wir haben mehrere Kunden mit dem selben Subnetz, z.B. das
192.168.100.0/24 wird gerne genommen.
Leider können wir nur 1 Tunnel bauen, das die Subnetze unique sein müssen.

Jetzt meine Frage, gibt es nicht irgendeinen Trick / Kniff das hinzukriegen?

z.B. das man mehrere Tunnel hat die man bei Bedraf aktiv schaltet.
oder villeicht kann man irgendwie mit Nat oder virutellen IP Adressen arbeiten,
das man die Server mit einer anderen IP anspricht und die Securepoint das dann umsetzt.

Also liegt das an der Securepoint, oder geht das gar nicht, oder hat sich da noch keiner Gedanken gemacht ?

Für tolle Ideen wäre ich dankbar,

Gruß andy

carsten · Beitrag von **carsten** » Mi 05.08.2009, 10:26

andy hat geschrieben: Jetzt meine Frage, gibt es nicht irgendeinen Trick / Kniff das hinzukriegen?

oder villeicht kann man irgendwie mit Nat oder virutellen IP Adressen arbeiten,
das man die Server mit einer anderen IP anspricht und die Securepoint das dann umsetzt.

Für tolle Ideen wäre ich dankbar,

Gruß andy

Moin,

ich werde das mal Skizzieren

FirmaA (100.0/24) ---------------------- (100.0/24) FirmaB
Tunnel (172.16.0.0/24) --------- (10.0.0.0/24)

Man könnte die Firmen über zwei virtuelle Netze verbinden. Firma B greift dann über die 172.16.0.x auf die Rechner in FirmaA zu und FirmaA über die 10.0.0.x in FirmaB.

Wie richte ich das ein?

- Die Tunnel wie gewohnt einrichten nur mit den virtuellen Netzen
- Auf FirmaA eine der virtuellen IPs auf das eth1 interface binden, das ganze auch für FirmaB
- Ein HideNAT einrichten die die Zugriffe auf die virtuellen IPs hinter der virtuellen IP des eth1 interfaces versteckt
- Ein Portforward einrichten. Das Netzwerkobjekt hat die wirkliche IP im Netz und beim statischen Nat die virtuelle über die der Zugriff erfolgen soll
- Dann damit eine Regel anlegen: remote ipsec_netz -> Netzwerkobjekt -> any

Dies muss leider für jeden Zugriff einzeln angelegt werden.

Petasch · Beitrag von **Petasch** » Mi 05.08.2009, 14:52

also ich hab das einfacher gelöst, ohne portforwarding.
und zwar stellt ihr auf der seite, VON der ihr zugreifen müsst, einfach auf dem internen interface eine virtuelle ip ein. irgendein anderen bereich, dann richtet ihr die vpn ein, und gebt auf der gegenseite als remote-subnet dieses virtuelle netz ein. jetzt in der firewall mit dem virtuellen netz noch eine hide-nat. also beispiel : intranet > virtuelle ip der fw > remote netz > nicht ausnehmen. damit stellt ihr sicher das alle anfragen in das remote netz genattet werden mit der virtuellen ip... funktioniert super, allerdings nur von euch zum kunden, nicht andersrum. allerdings reicht uns das aus, der kunde muss ja nich bei uns ins netz

andy · Beitrag von **andy** » Do 06.08.2009, 16:52

Danke für die Antworten.
Ich versuche deine Umsetzung Petasch, aber ich komm nicht weiter.

Also ich habe folgendes Gemacht:
Ziel ist Zugriff von
192.168.3.0/24 (Wir) -----> 192.168.100.0/24 (KundeA)
192.168.3.0/24 (Wir) -----> 192.168.100.0/24 (KundeB)
192.168.3.0/24 (Wir) -----> 192.168.100.0/24 (KundeC)

Habe jetzt auf FW-Wir auf das interne FW Interface 192.168.3.1/24
Die IP 192.168.80.1/24 hinzugefügt.

Dann ein VPN Site to Site Tunnel gebaut, mit den Subnetz
192.168.3.0/24 --> 192.168.80.0/24

Dann Hide Nat Regel auf der FW-Wir
192.168.3.0 --> 192.168.80.1 --> 192.168.100.0

Dann Zugriffsregel FW-Wir
192.168.3.0 -> 192.168.100.0 -> ANY

Zugriffsregel FW-KundeA
192.168.80.0 -> 192.168.100.0 -> ANY

Jetzt sollte ich doch z.B. mit einem Ping auf den Server 192.168.100.5 beim KundeA ankommen.
Was hab ich vergessen bzw. falsch verstanden?

Beitrag von **Erik** » Do 06.08.2009, 16:57

Hallo,
die Lösung von Petasch funktioniert nur in eine Richtung. Soll die Kommunikation in beide Richtungen erfolgen müssen Sie Carstens Weg wählen und mit statischen NATs arbeiten.

€dith meint, dass man Carstens Lösung analog für mehrere gleiche Remote-Netze verwenden kann.

Petasch · Beitrag von **Petasch** » Do 06.08.2009, 19:31

@andy, erik hat recht. so wir du die netze geschrieben hast funktioniert meine lösung nicht...
denn wir wölltest du von deinen client aus auf beispielsweise den client 192.168.100.5 zugreifen? eure firewall weiß jagar nicht in welchen tunnel das geroutet werden müsste. meine lösung funktioniert bei folgender situation

Wir (192.168.1.0/24) - Kunde Zentrale (192.168.100.0/24) - Kunde Niederlassung (192.168.1.0/24)

Also unser Netz ist mit dem Zentralen Netz des Kunden verbunden. Die Zentrale des Kunden wiederrum mit ihrer Niederlassung. Die Niederlassung hat das gleiche Netz wie wir. (192.168.1.0/24) Das bedeutet auf der Firewall in der Zentrale könnte dementsprechend nicht beide VPNs eingerichtet werden, da ja zu zwei VPN Tunnel das 1. Netz wäre, was ja nicht geht (Unique Subnetz).
Also hab ich unserer Firewall auf dem internen Interface eine virtuelle IP gegeben (192.168.80.1). Dann auf der Firewall in der Zentrale des Kunden einmal die VPN normal zu der Zweigstelle, und einmal die VPN zu uns eingerichtet. Hier habe ich als Remotenetz 192.168.80.0 eingegeben. Damit unsere Clients auf mit einer 80. Adresse "rausgehen" zum Kundennetz habe ich bei uns noch eine Hidenat eingerichtet:
Internal_Network > 192.168.80.1 > Kundennetz > nicht ausnehmen.

So funktioniert meine Lösung. Wir gesagt, in deim Fall kannst du nur die Variante von carsten nehmen!!!

@erik,carsten: Aber wo wir gleich dabei sind... Kann ich, wenn wir bei dem Beispiel grad sind, also Wir --- VPN --- Kunde --- VPN --- Kunde Filialie (unabhängig von den Netzen und so) irgendwie es so einrichten, dass ich auf die Kunden-Filialie zugreifen kann?! Da ein Kunde ca. 20 Aussenstellen hat, muss ich über unsere VPN immer erst auf unseren "Managment-PC" beim Kundennetzwerk per Remotedesktop drauf, um von dort aus weiter in die Filialien zu machen. kann man das irgendwie mit Routing hinbekommen??? Wäre toll, wenn ihr einen Lösungsansatz habt, da ich es schonmal probiert habe, aber leider erfolglos...

Beitrag von **Erik** » Do 06.08.2009, 20:21

Guten Abend,
unter der Voraussetzung, dass alle Netze unterschiedlich sind, ist das gar kein Problem (obwohl ich Ihnen von einer sternförmigen Vernetzung abraten muss

).
Beispiel:

[Netz A] [Zentrale] [Netz B]

Konfiguration Firewall A:
Tunnel: [Firewall A] -> [Firewall Zentrale] => [Netz A] -> [Netz B]
Regel: [Netz A] -> [Netz B] -> accept
HideNAT: [Netz A] -> [Netz B] -> exclude

Konfiguration Firewall Zentrale:
Tunnel: [Firewall Zentrale] -> [Firewall A] => [Netz B] -> [Netz A]
Tunnel: [Firewall Zentrale] -> [Firewall B] => [Netz A] -> [Netz B]
Regeln: [Netz A] -> [Netz B] -> any, [Netz B] -> [Netz A] -> any
HideNAT: [Netz A] -> [Netz B] -> exclude, [Netz B] -> [Netz A] -> exclude

Konfiguration Firewall B:
Tunnel: [Firewall B] -> [Firewall Zentrale] => [Netz B] -> [Netz A]
Regel: [Netz B] -> [Netz A] -> accept
HideNAT: [Netz B] -> [Netz A] -> exclude

Die Netzwerkobjekte in der Zentrale sind jeweils beide in "vpn-ipsec", in den Aussenstellen wie gehabt das lokale Netz "internal", das entfernte Netz "vpn-ipsec".

andy · Beitrag von **andy** » Fr 07.08.2009, 08:26

Moin,
danke für die Antworten.
Also kann ich jetzt mein Szenario
192.168.3.0/24 (Wir) -----> 192.168.100.0/24 (KundeA)
192.168.3.0/24 (Wir) -----> 192.168.100.0/24 (KundeB)
192.168.3.0/24 (Wir) -----> 192.168.100.0/24 (KundeC)
mit Carstens weg abbilden? Ihr habt mich etwas verwirrt

Beitrag von **Erik** » Fr 07.08.2009, 09:38

Guten Morgen,
ja können Sie. Binden Sie die virtuelle IP bei dem Kunden auf ein Interface und bauen dann zwischen dem lokalen (realen) Netz und dem remote (virtuellen) Netz einen Tunnel.
Beispiel:
- Bei Kunde A 172.16.0.1/24 auf das interne Interface binden
- Tunnel zwischen Ihrer Firewall und der von Kunde A sieht dann folgendermaßen aus:
---192.168.3.0/24 -> 172.16.0.1/24
- HideNAT (die Reihenfolge ist wichtig!):
---[Netz A] -> 172.16.0.1 -> [Ihr Netz] -> include
---172.16.0.1 -> eth0 -> [Ihr Netz] -> exclude
- Jetzt brauchen Sie noch ein Portforwarding bei Kunde A (und das für jeden Rechner, den Sie in dem Netz erreichen wollen)

- Bei Kunde B 172.16.1.1/24 auf das interne Interface binden
- Tunnel zwischen Ihrer Firewall und der von Kunde B sieht dann folgendermaßen aus:
---192.168.3.0/24 -> 172.16.1.1/24
- HideNAT (die Reihenfolge ist wichtig!):
---[Netz B] -> 172.16.1.1 -> [Ihr Netz] -> include
---172.16.1.1 -> eth0 -> [Ihr Netz] -> exclude
- auch hier jeweils ein Portforwarding für jeden Rechner, der erreichbar sein muss.

Die Kundennetze erreichen Sie dann nur über die virtuellen IPs (172.16.0.1, 172.16.1.1).

Ich hoffe, das war halbwegs verständlich

Petasch · Beitrag von **Petasch** » Fr 07.08.2009, 10:40

@erik, warum raten sie davon ab?! es entsteht doch eigentlich nicht mehr traffic oder ähnlich. am ende ist es doch das gleiche ob ich jetzt von uns per rdp aufn rechner in der zentrale gehe, und von dort aus weitermache oder direkt von uns auf die filialien zugreife? bitte um erklärung, vielen dank

Beitrag von **Erik** » Fr 07.08.2009, 13:05

Richtig. im Vergleich zu Ihrem aktuellen Setup entsteht nicht mehr Traffic.
Im Idealfall existiert jedoch ein direkter Tunnel zwischen Ihrem Netz und der Filiale des Kunden, wodurch die Leitung und die Firewall in der Kundenzentrale entlastet wird.

Petasch · Beitrag von **Petasch** » Fr 07.08.2009, 18:03

ja gut das mag sein, aber diese aussenstellen haben aufgrund von etwas dörflichen standorten teilweise teilweise nur 1 oder 2 mbit adsl, da will ich nich noch zusätzlich überall ein tunnel zu uns aufbauen! alles klar, dann werd ich das mal so probieren und gebe bescheid obs funktioniert ... da entfällt schon einmal remotedesktop ;o)

andy · Beitrag von **andy** » Mo 10.08.2009, 10:02

Hallo...

so das hat schonmal funktioniert. Vielen Dank! Wobei ich mit dem Hide Nat noch nicht ganz durckblicke. Also ich hab mal die 2 Hide Nat Regel getauscht , und mal rausgenommen und es ging immernoch. Muss ich bei Gelegenheit mal noch ein bisschen rumspielen.
Aber hauptsache es funktioniert erstmal.

Gruß Andy