Hallo zusammen,
wir haben hier folgendes Szenario:
1x 8011 im Rechenzentrum
1x 1711 bei Kunde A
1x 1711 bei Kunde B
Im Rechenzentrum auf dem 8011er gibt es mehrere Subnetze (172.16.11.0, 172.16.12.0, 172.16.13.0, usw.).
Die Kunden sind mittels Standortkoppelung ans RZ angebunden und können aus ihren Büros auf ihr virtuelles Netz bei uns im RZ zugreifen.
Der VPN Einwahl IP Bereich ist: 172.16.10.0
Wenn ein Mitarbeiter eines Kunden sich bei uns ins RZ einwählt kommt auch er nur auf das jeweile Netz seiner virtuellen Server.
Nun möchte aber ein Kunde, dass wenn er bei uns im RZ eingewählt ist, er gleichzeitig auch auf die Ressourcen seines Büros zugreifen kann. Nachdem wir aus dem RZ ja eine Standortkoppelung zum Kunden haben, sollte das grundsätzlich ja auch möglich sein. Firewalltechnisch haben wir das Netz freigegeben. Ich vermute allerdings, dass ich noch eine Route o.Ä. irgendwo eintragen muss. Haben es bisher hinbekommen, dass wir jeden VPN User in jedes lokale Netz gebracht haben, allerdings haben wir es noch nicht hinbekommen, dass wir einen eingewählten VPN User zu einem entfernten VPN Netz weiterrouten.
Habt Ihr mir einen Tip was ich tun muss, dass die Weiterleitung funktioniert?
Gruß
SW VPN User weiter routen in standortgekoppeltes Netz
Moderator: Lancom-Systems Moderatoren
Hi itsure
dafür brauchst du a in den Kunden-Routern eine Route über die sie den VPN-Einwahlbereich des RZ erreichen können, d.h. 172.16.10.x muß auf den VPN-Tunnel zum RZ geroutet werden. Andererseits brauchst du im RC für jeden Kunden, der das haben will noch eine zusätzliche VPN-Regel, damit der Einwahlbereich überhaupt zum Kunden geroutet wird:
Das Ganze hat nun allerdings den Nachteil, daß *jeder* der sich in das Rechenzentrum einwählt auch direkt zum Kunden kommt. Hier mußt du ggf. noch mit Routing-Tags oder Firewallregeln die Sichtbarkeiten eingrenzen.
Gruß
Backslash
dafür brauchst du a in den Kunden-Routern eine Route über die sie den VPN-Einwahlbereich des RZ erreichen können, d.h. 172.16.10.x muß auf den VPN-Tunnel zum RZ geroutet werden. Andererseits brauchst du im RC für jeden Kunden, der das haben will noch eine zusätzliche VPN-Regel, damit der Einwahlbereich überhaupt zum Kunden geroutet wird:
Code: Alles auswählen
[x] Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen
Aktion: übertragen
Quelle: 172.16.1.0/255.255.255.0 (VPN-Einwahlbereich)
Ziel: Filial-Netz des Kunden (Netz hinter dem 1711)
Dienset: alle Dienste.
Gruß
Backslash
Hallo itsure,
da ich mich Backslash nur anschließen kann hätte ich die Idee einfach den Kunden per AVC auf seinen Standort-Router dann hast Du im Rechenzentrum keine Probleme und da er mit seinem Client eine IP vom Standort bekommt kann er auch nur auf sein freigegebene Bereiche und Du mußt nichts ändern.
FT
da ich mich Backslash nur anschließen kann hätte ich die Idee einfach den Kunden per AVC auf seinen Standort-Router dann hast Du im Rechenzentrum keine Probleme und da er mit seinem Client eine IP vom Standort bekommt kann er auch nur auf sein freigegebene Bereiche und Du mußt nichts ändern.
FT
Danke schonmal für die Antworten. Das bringt schon etwas Licht ins Dunkle.
Grundsätzlich habt Ihr Recht. Es wäre sicherheitstechnisch besser, wenn wir die Kunden per AVC immer auf ihre Büro-Lancoms verbinden lassen und von dort weiter gehen. Leider ist es aber so, dass ca. 90% des Traffics auf die virtuellen Server im RZ läuft und nur minimal am Standort. Dazu kommt, dass wir im RZ mit 100 MBit/s up/down angebunden sind und bei den Kunden manchmal nur mit ADSL6000 dyn. IP.
Wenn wir einen AVC User im RZ per WIZ anlegen darf, wird folgendes erstellt:
Übertragen: accept
Von: Jeder Station
Nach: <<GEGENSTELLE_AVC_USER>>
Was wir nun gemacht haben, war folgendes:
Übertragen: accept
Von: 172.16.11.0/24
192.168.40.0
Nacht: <<GEGENSTELLE_AVC_USER>>
In diesem Fall ist 172.16.11.0 das Netz für die virtuellen Server im RZ und 192.168.40.0 das Intranet des Kunden bei sich selbst. Durch setzen dieser Regel haben wir es erreicht, dass trotz komplett offenem Split Tunneling der AVC User nur in das 172.16.11.0 Netz kommt. In das 192.168.40.0 Netz kommt er allerdings noch nicht. Hier denke ich, dass wir mal das mit der Route 172.16.10.0 -> 192.168.40.0 probieren.
Grundsätzlich habt Ihr Recht. Es wäre sicherheitstechnisch besser, wenn wir die Kunden per AVC immer auf ihre Büro-Lancoms verbinden lassen und von dort weiter gehen. Leider ist es aber so, dass ca. 90% des Traffics auf die virtuellen Server im RZ läuft und nur minimal am Standort. Dazu kommt, dass wir im RZ mit 100 MBit/s up/down angebunden sind und bei den Kunden manchmal nur mit ADSL6000 dyn. IP.
Wenn wir einen AVC User im RZ per WIZ anlegen darf, wird folgendes erstellt:
Übertragen: accept
Von: Jeder Station
Nach: <<GEGENSTELLE_AVC_USER>>
Was wir nun gemacht haben, war folgendes:
Übertragen: accept
Von: 172.16.11.0/24
192.168.40.0
Nacht: <<GEGENSTELLE_AVC_USER>>
In diesem Fall ist 172.16.11.0 das Netz für die virtuellen Server im RZ und 192.168.40.0 das Intranet des Kunden bei sich selbst. Durch setzen dieser Regel haben wir es erreicht, dass trotz komplett offenem Split Tunneling der AVC User nur in das 172.16.11.0 Netz kommt. In das 192.168.40.0 Netz kommt er allerdings noch nicht. Hier denke ich, dass wir mal das mit der Route 172.16.10.0 -> 192.168.40.0 probieren.
Hallo,
Du mußt aufpassen was Du änderst !
Es muß eine Firewall-Regel für die SA aushandlung existieren also Du hast pro User min 1 Regeln.
Ich gehe davon aus das Du jedem User (AVC) eine feste IP passend zu seinem Netz vergeben hast, (zu finden unter Routing/Routing-Tabelle).
Dann gibt es eine Regel für SA
[x] Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen
[x] Diese Regel hält die Verbindungszustände nach (empfohlen)
Aktion: Accept
Quelle: Jeder Station
Ziel: AVC_User
Dienset: alle Dienste.
Jetzt sollten die passenden SA ausgehandelt werden, die Du brauchst.
Zum Kontrollieren unter Telnet im Gerät show vpn eingeben
Da Du für den Tunnel zur LAN-LAN Kopplung eine Aushandlung der SA 172.16.11.0/24 zu 192.168.40.0/24 hast und der Client eine IP aus dem 172.16.11.0 bekommen hat, laut Routing-Tabelle sollte er auch erstmal dort hinkommen.
Wenn Du nichts weiter eingestellt hast, wie z.B. Denny-All regeln oder so.
naja und jetzt sollte die Verbindung funktionieren
Dann zum Verfeinern noch Firewall-Regeln und alles ist gut .....
Viel Spaß
Du mußt aufpassen was Du änderst !
Es muß eine Firewall-Regel für die SA aushandlung existieren also Du hast pro User min 1 Regeln.
Ich gehe davon aus das Du jedem User (AVC) eine feste IP passend zu seinem Netz vergeben hast, (zu finden unter Routing/Routing-Tabelle).
Dann gibt es eine Regel für SA
[x] Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen
[x] Diese Regel hält die Verbindungszustände nach (empfohlen)
Aktion: Accept
Quelle: Jeder Station
Ziel: AVC_User
Dienset: alle Dienste.
Jetzt sollten die passenden SA ausgehandelt werden, die Du brauchst.
Zum Kontrollieren unter Telnet im Gerät show vpn eingeben
Da Du für den Tunnel zur LAN-LAN Kopplung eine Aushandlung der SA 172.16.11.0/24 zu 192.168.40.0/24 hast und der Client eine IP aus dem 172.16.11.0 bekommen hat, laut Routing-Tabelle sollte er auch erstmal dort hinkommen.
Wenn Du nichts weiter eingestellt hast, wie z.B. Denny-All regeln oder so.
naja und jetzt sollte die Verbindung funktionieren

Dann zum Verfeinern noch Firewall-Regeln und alles ist gut .....
Viel Spaß
