ISG-4000 VLAN-Routing VPN-Gegenstelle

[Nick]

Hallo zusammen,
ich betreibe ein ISG-4000 als VPN Gateway in Kombination mit einem GS-2328. Auf dem Gateway laufen mehrere VPN-Gegenstellen auf.
Weiterhin wurden für die lokalen Netze drei VLANs konfiguriert, mit verschiedenen Schnittstellentags wodurch per Firewallregel die einzelenen Zugriffe gesteuert werden.

Managment - 192.168.100.0 /24 - Tag 1
VLAN 10 - 192.168.99.0 /24 - Tag 10
VLAN 20 - 192.168.98.0 /24 - Tag 20

Für die Einzelen VPN-Gegenstellen wurde jeweils eine entprechende Route mit Routingtag 0 konfiguriert.
Ich versuche verzweifelt aus den verschiedenen VLANs die VPN-Gegenstellen anzusprechen.
Wenn ich im Managment-VLAN das Schnittstellentag auf 0 ändere ist eine Komunikation möglich.
Aus den anderen beiden VLANs habe ich noch keinen Lösungsansatz gefunden.
Zu erwähnen ist noch das in der Firewall eine deny all Regel existiert.
Ist dies über eine entsprechende Firewallregel zu lösen?

[Jirka]

Hallo,

Für die Einzelen VPN-Gegenstellen wurde jeweils eine entprechende Route mit Routingtag 0 konfiguriert.

diese Routen greifen nicht für lokale LANs mit Schnittstellen-Tag ungleich 0. Es gilt die Regel, dass wenn es keine Default-Route ist, dann muss das Routing-Tag stimmen.
Bedeutet: Kopiere Deine Routen und versehe sie mit dem Routing-Tag entsprechend des Schnittstellen-Tags des lokalen Netzes was darauf Zugriff haben soll.
Ausnahme: Bei Nutzung des VCM und Anmeldung von SIP-Benutzern über VPN braucht man zusätzlich mitunter Routen mit Routing-Tag 0.

Davon unabhängig müssen natürlich auch die Netzbeziehungen/SAs stimmen - auch auf der Gegenseite.
Und natürlich die Firewall-Regeln.

Viele Grüße,
Jirka

[Nick]

Hallo Jirka,
erstmal vielen Dank für die Rückmeldung.

IP-Netzwerke.JPG

Routingtabelle.JPG

Die VPN-Gegenstellen sollen sowohl im Intranet als auch im VLAN10 verfügbar sein.

Ich hab bereits schon beim Intranet das das Schnittstellen Tag auf 1 geändert und bei der entprechenden Gegenstelle das Routingtag angepasst, was auch funktioniert. Die entsprechende Gegenstelle soll jedoch auch aus dem VLAN10 erreichbar sein. Auch wenn ich eine Weitere Route mit dem Routingtag 10 anlege ist das leider nicht der Fall.

[Jirka]

Zum ersten Screenshot: An der VLAN-ID 1 sehe ich, dass Du das VLAN-Modul aktiviert hast. Das wäre jetzt nicht nötig gewesen, ist aber ein anderes Thema. Es ist nicht falsch, aber auch nicht nötig. Wenn Du das VLAN-Modul jetzt aber wieder deaktivierst, denke daran gleichzeitig die VLAN-ID 0 wieder dem lokalen LAN zuzuordnen, sonst sperrst Du Dich aus (Tipp: WAN-seitig und seriell geht natürlich dann immer noch, ggf. auch die anderen VLANs.).
Ansonsten wurden die Schnittstellen-Tags so mit Bedacht gewählt? Also Intranet mit 0?

Zum grundsätzlichen Problem: Ist denn bei der entsprechenden Gegenstelle oder den Gegenstellen auch eine Route in das VLAN10, also mit Ziel 192.168.99.0/255.255.255.0 vorhanden? Sind die VPNs mit automatischer oder manueller Regelerzeugung konfiguriert? Stimmen die Netzbeziehungen (überein)? (show vpn auf der Konsole) Grundsätzlich ist es kein Problem und auch recht einfach, die VPN um das VLAN10 zu erweitern.

Viele Grüße,
Jirka

[PappaBaer]

diese Routen greifen nicht für lokale LANs mit Schnittstellen-Tag ungleich 0. Es gilt die Regel, dass wenn es keine Default-Route ist, dann muss das Routing-Tag stimmen.

Moin Jirka,

hier möchte ich mich aus dem Fenster lehnen und behaupten, dass das so nicht stimmt. Es gibt hier keine Beschränkungen auf Default-Routen.
Kann man auch wunderbar über die effektive Routing-Tabelle sehen.

Grüße,
Torsten

[Jirka]

Hi,

was ich meine und hier erwarte, denn die Routen mit Routing-Tag 0 führen ja offensichtlich nicht zum Ziel, ist hier genauer dokumentiert:
viewtopic.php?f=14&t=16599&p=93788
Hatte das jetzt nicht so ausführlich erläutert, hatte nicht so viel Zeit.

Viele Grüße,
Jirka

[PappaBaer]

Alles klar, Du hast Dich hier auf die automatische Regelerzeugung bezogen. Und ich dachte, Du meinst das allgemeine ARF-Verhalten.
Da ich die Regeln immer manuell erzeuge, ist mir das noch gar nicht aufgefallen.

Viele Grüße,
Torsten

[Nick]

Hallo Jirka,
danke für die Rückmeldung.
Wie immer saß das Problem vor dem Rechner... Natürlich war es der fehlende Routeneintrag auf der Gegenstelle.
Manchmal sieht man einfach vor lauter Bäumen keinen Wald mehr.

Zu deiner Anmekrung mit dem Schnittstellentag 0 für das Netz Intranet. Grundsätzlich soll dieses Netz Zugriff zu allen Netzwerkressourcen haben,
daher die Wahl.
Spricht hierbei etwas dagegen und sollte ich dahin gehend einen anderen Lösungsansatz verfolgen?