Gelöst: VPN und Routing von und in verschiedene VLAN

[cambies]

Hallo, mir platzt bald der Kopf und in nicht allzu ferner Zukunft auch der Kragen:
Ich richte einen 7100 (LCOS 7.80) ein, dessen ETH-4 auf ein DSL-MODEM geht.

Die Situation:
--------------
Ich muss mit 4 LANs über 3 portbezogene VLANs arbeiten, wobei die Schnittstellen ETH-1 bis 3 "immer" taggen. Die Konfig sieht als kurz zusammengefasst so aus:

ETH1: Netz-VLAN- und Port-VLAN-ID 1, Netzwerk 1, 192.168.1.254/24
ETH2: Netz-VLAN- und Port-VLAN-ID 2, Netzwerk 2, 192.168.2.254/24
ETH3: Netz-VLAN- und Port-VLAN-ID 3, Netzwerk 3, 10.0.8.254/24 und Netz-VLAN4, Netzwerk 4, 0.0.0.0

Es gibt keine Schnittstellen- bzw. Routing-Tags. Die Routing-Tabelle ist bis auf die blockenden Einträge für private Adressbereiche leer. Im LAN darf (vorerst) jeder Dienst von einem in die jeweils anderen VLANs geschickt werden.
Er läuft zudem als DNS (statisch u. dynamisch) und im VLAN 2 als DHCP-Server.

Der Wunsch:
--------------
Ich möchte, dass unsere Advanced VPN Clients sich mit Adressen aus einem weiteren, fünften, Netzbereich einwählen, am besten in ein eigenes Netz, z.B. 10.0.10.0/24, und dann nur Zugriff zu den Netzen 1 (VLAN1) und 2 (VLAN2) erhalten.

Ich habe mir also ein solches "VPN"-Netz unter TCP/IP->Netzwerke mit Router-IP 10.0.10.254/24 angelegt und auch den Adressbereich für Einwahlzugänge entsprechend eingetragen (10.0.10.1 bis 10.0.10. 100).

Es gibt natürlich für die Gegenstelle eine entsprechende Firewall-VPN-Regel von allen Stationen nach der jeweiligen Gegenstelle für alle Dienste ALLOW_ALL. Die VPN-Regel-Automatik ist ausgeschaltet.


Das Problem:
--------------
So, nun wird, zumindest mit PSK, ein prima Tunnel gebastelt. Als DNS-IP des AVC erhalte ich merkwürdigerweise die Router-IP aus LAN1 mit 192.168.1.254.
Die DNS-Aulösung am Client klappt dann auch ganz toll (NSLOOKUP), nur bekomme ich nicht einmal ein Ping auf eine der Stationen in irgendeines der beiden VLANS 1 und 2 (3 und 4 habe ich nicht getestet, weil eigentl. irrelevant). Ich gehe einfach davon aus, das es Probleme mit der Rückroute gibt.
Hieve ich den Einwahladressbereich in das VLAN2, also 192.168.2.0/24, erhält der Client immer noch als DNS den 192.168.2.254, (rück-)routet aber korrekt in den Tunnel.

Der LANCOM kennt doch alle Netze; lokal, also im LAN, routet er auch prima von einem VLAN ins ein anderes, nur über VPN klappt das nicht?!

Vielleicht habe ich nur einen schweren Denkste-Fehler und seh den Wald vor lauter Bäumen nicht.

Wie kann ich die Rückrouten in den Tunnel , wenn es denn daran liegt, realisieren, eine explizite Routingregel: 10.0.10.0/24 --> Gegenstelleneintrag
hat keine Abhilfe geschaffen.
Oder liegt der Fehler ganz woanders?
Wenn ich Schnittstellen- und Routing-Tags benutzen müsste, würde ich auf einmal auch ganz traurig, aber wenn nur so etwas hilft, nun ja.... ich schieß ja schon mal ganz gern mit Kanonen auf Spatzen;-)

Schon mal vielen Dank vorab für Eure Hilfe

[cambies]

Ich musste feststellen, dass das "Routing" auch nicht klappt, wenn das VLAN-Modul ausgeschaltet ist, d.h. das Problem hat erstmal nichts mit den eingerichteten VLANs zu tun. (Das LanConfig kann das VLAN-Modul gar nicht leiden!)

Ich hab jetzt erstmal die pragmatische Lösung gewählt und teile den einwählenden Clients IP-Adressen aus einem der vorhandenen Netzwerke zu, nur kann das ja nicht der Weisheit letzter Schluß sein?

Gruß, cambies

[cambies]

Ha! Manchmal kann man sich auch mal kräftig in den .... naja, nichts für ungut.

Also, das Geheimnis ist, daß man in der Firewall natürlich das Routen über die VPN-Route zulassen muß, wenn man sich vorher eine Deny-All-Regel eingerichtet hat.

Jetzt klappts auch mit eingeschaltetem VLAN-Modul. Jetzt widme ich mich noch den NO_PROPOSAL_CHOSEN in Phase 2 bei Zertifikat-Einwahl und dann kann das Wochenende kommen.

Daran hätte ich nun weiß Gott nicht mehr gedacht bei all dem Rumgehopse von Dialog nach Register nach Untermenü im LanConfig....

Also, schönes Wochenende unter der Aschewolke

[ottotester]

Routen über die VPN-Route zulassen

wo hast du was gemacht?? hacken gesetzt, zu einfach? oder doch

Bitte Idiodensicher
ich hab genau das gleiche? problem
LANCOM Advanced VPN-Client kommen nicht in das 2. netz
VPN Clients -> LAN1 192.168.10.0 < VPN > LAN2 192.168.20.0

Ping von LAN1 zu LAN2 klappt
Ping von VPN Clients zu LAN1 klappt
Ping von VPN Clients zu LAN2 klappt nicht

in der FW sind Regeln Eingetragen
Quelle beliebig
Quelldienst Alle
Ziel VPN Client
Zieldienst Alle
übertragen sofort

Grüsse otto

[cambies]

Hallo, ich hab einfach entsprechende VPN-FW-Regeln erstellt, die den sich einwählenden VPN-Gegenstellen erlaubt, in beiden erlaubten Netze zu gehen. Diese haben eine höhere Prio als die VPN-Deny-All-Regel:

VPN-Gegenstellen -> Netz1 -> Accept (nur wenn VPN-Route); "Diese Regel wird zur Einrichtung von VPN-Regeln herangezogen":ein; Regel ist für Firewall aktiv": aus

VPN-Gegenstellen -> Netz2 -> Accept (nur wenn VPN-Route); "Diese Regel wird zur Einrichtung von VPN-Regeln herangezogen":ein; Regel ist für Firewall aktiv": aus

VPN-Gegenstellen -> alle anderen Netze -> Reject; "Diese Regel wird zur Einrichtung von VPN-Regeln herangezogen":ein; Regel ist für Firewall aktiv": aus

So einfach ist's

Ggf. noch ein Nachtrag zum von mir angeschn ittenen Thema "...Jetzt widme ich mich noch den NO_PROPOSAL_CHOSEN in Phase 2 bei Zertifikat-Einwahl...", falls jemand per Suchfunktion hierüber stolpert:

Nach zig Tests zusammen mit dem Support hat sich 'rausgestellt, das die von mir mit XCA erstellten Zertifikate die Ursache waren. Jetzt erstelle ich die Zertifikate "manuell" mit OpenSSL (mit ein paar Scripten kann man XCA da locker ersetzen) und alles läuft super bis hin zur CRL.