Ich habe seit kurzem einen Lancom 1621 Router mit lc.os 5.02 im Einsatz.
Ich habe eine Deny_all Regel angelegt und anschließen mit Allow - Regeln http, ftp und E-Mail sowie DNS forwarding freigeschaltet. Funktioniert alles wunderbar.
Die vom Setup Assistenten erzeugte Regel für den VPN Zugang kommt aber anscheinend nicht zum Tragen.
Lanconfig und Lanmonitor funktionieren problemlos über VPN.
Anfragen an das Netzwerk(z. B. Explorer) über VPN werden von der Deny_all Regel geblockt. Bei abgeschalteter Deny_all Regel funktioniert alles wie gewünscht.
Über einen Schubser in die richtige Richtung wäre ich sehr erfreut.
deny_all und VPN
Moderator: Lancom-Systems Moderatoren
Hallo cruiser,
der Assistent legt eben keine Firewall-Regel an, sondern nur eine VPN-Regel. Achte mal auf die Häkchen. (Diese VPN-Regeln sind meines Erachtens nach "unglücklich" mit in den Firewall-Dialog reingequetscht.) Dementsprechend müsstest Du Dich selbst um eine Firewall-Regel kümmern.
Der Router selbst ist erreichbar, weil diese Anfragen nicht über die Firewall laufen. VPN, Ping etc. sind also grundsätzlich immer erreichbar; für die routereigenen Dienste (ssh, https etc.) hat der Router seine eigenen Sicherheitsmechanismen, die kann man ja in einem anderen Dialog differenziert für LAN/WAN/WLAN mit und ohne VPN freigeben.
Gruß,
omd
der Assistent legt eben keine Firewall-Regel an, sondern nur eine VPN-Regel. Achte mal auf die Häkchen. (Diese VPN-Regeln sind meines Erachtens nach "unglücklich" mit in den Firewall-Dialog reingequetscht.) Dementsprechend müsstest Du Dich selbst um eine Firewall-Regel kümmern.
Der Router selbst ist erreichbar, weil diese Anfragen nicht über die Firewall laufen. VPN, Ping etc. sind also grundsätzlich immer erreichbar; für die routereigenen Dienste (ssh, https etc.) hat der Router seine eigenen Sicherheitsmechanismen, die kann man ja in einem anderen Dialog differenziert für LAN/WAN/WLAN mit und ohne VPN freigeben.
Gruß,
omd
LC 1811 / LCOS 5.08
Kann ich nur bestätigen. Bin da auch tagelang gegengelaufen. Warum reicht die Angabe des VPN-Tunnels als "Router" in der Routing-Tabelle nicht, um den Tunnel stabil hochzuziehen? Anhand der Routing-Tabelle wird doch bereits entschieden wo der Datenverkehr lang geht. Wie kommt man denn auf sowas wie "VPN-Regeln"??cruiser hat geschrieben:Danke für die schnellen Antworten.
Über den Unterschied von VPN-Regeln und Firewall-Regeln hatte ich zwar gelesen, aber das Ganze hatte sich mir nicht so recht erschlossen.
Ich hatte jedenfalls den Tunnel als Router angegeben, dazu noch ein paar Firewall-Regeln gebaut und es funktionierte einige Zeit tadellos. DAS war ja das Gemeine! Erst nach 1-2 Stunden ging der Tunnel aus unerklärlichen Gründen (keinerlei Fehlermeldungen im LAN-Monitor und nichtmal im trace + vpn) down und machte auch keine Antstalten mehr für ein Rekeying, half nur der Kaltstart
Daß man zusätzlich noch "VPN-Regeln" braucht, damit das Ganze mal stabil läuft und im Handbuch lediglich darauf verwiesen wird, daß man keine kombinierten FW-VPN-Regeln erstellen soll, grenzt schon an eine Hinterhältigkeit. Ich bin erstmal ziemlich satt mit der Thematik Lancom + VPN
Hi 1711-User
Das bedeutet gleichzeitig, daß du explizite Regeln erstellen mußt, wenn deine Netzebeschreibung von der automatisch erstellten abweicht. Wenn du z.B. ein weiteres Netz hast, daß über den VPN-Tunnel erreicht werden soll:
Dann reicht es auf der einen Seite aus, einfach beide Netze in der Routing-Tabelle einzutragen. Auf der anderen Seite hingegen wird die Regel für das eine Netz automatisch erzeugt (Intranet darf mit der Gegenstelle). Für das andere Netz mußt du eine explizite VPN-Regel erstellen, da die Software keine Kristallkugel eingebaut hat, mit der sie erahnen könnte, daß du tatsächlich ein weiteres Netz über den Tunnel erreichen willst...
Und wieso sollte man keine kombinierten FW-VPN-Regeln erstellen dürfen. Es ist nur sinnvoller, dies getrennt zu machen, um nicht die Übersicht zu verlieren...
Es ist halt so, daß du in Firewall-Regeln meist noch Ports einträgst (z.B. HTTP ist erlaubt). Wenn du so etwas in eine VPN-Regel einträgst, dann mußt du es auch auf der anderen Seite in die VPN-Regel eintragen, weil sonst die IKE-Verhandlung scheitert...
Allein deshalb ist es schon sinnvoll, keine kombinierten VPN- und Firewallregeln zu erstellen - verboten ist es jedoch nicht...
Gruß
Backslash
Das reicht normalerweise auch aus. Wenn in der VPN Verbindungsliste für eine Gegenstelle automatische Regelerzeugung eingestellt ist, dann wird eine VPN-Regel erstellt, die eine Verbindung zwischen dem Intranet und dem Netz der Gegenstelle erlaubt.Kann ich nur bestätigen. Bin da auch tagelang gegengelaufen. Warum reicht die Angabe des VPN-Tunnels als "Router" in der Routing-Tabelle nicht, um den Tunnel stabil hochzuziehen? Anhand der Routing-Tabelle wird doch bereits entschieden wo der Datenverkehr lang geht
Weil es die RFCs zum IPSec nunmal so vorschreiben ist: Ein Tunnel darf nur aufgebaut werden, wenn eine vollständige Netzbeschreibung vorliegt...Wie kommt man denn auf sowas wie "VPN-Regeln"??
Das bedeutet gleichzeitig, daß du explizite Regeln erstellen mußt, wenn deine Netzebeschreibung von der automatisch erstellten abweicht. Wenn du z.B. ein weiteres Netz hast, daß über den VPN-Tunnel erreicht werden soll:
Dann reicht es auf der einen Seite aus, einfach beide Netze in der Routing-Tabelle einzutragen. Auf der anderen Seite hingegen wird die Regel für das eine Netz automatisch erzeugt (Intranet darf mit der Gegenstelle). Für das andere Netz mußt du eine explizite VPN-Regel erstellen, da die Software keine Kristallkugel eingebaut hat, mit der sie erahnen könnte, daß du tatsächlich ein weiteres Netz über den Tunnel erreichen willst...
Mit so einem Problem solltest du dich an den LANCOM-Support wenden... Ggf. hast du auch nur etwas falsch konfiguriert.Ich hatte jedenfalls den Tunnel als Router angegeben, dazu noch ein paar Firewall-Regeln gebaut und es funktionierte einige Zeit tadellos. DAS war ja das Gemeine! Erst nach 1-2 Stunden ging der Tunnel aus unerklärlichen Gründen (keinerlei Fehlermeldungen im LAN-Monitor und nichtmal im trace + vpn) down und machte auch keine Antstalten mehr für ein Rekeying, half nur der Kaltstart
Wenn du einfach nur zwei Netze verbinden willst, dann reichen die Eintäge in der Routing-Tabelle. Dafür sind keine definitiv zusätzlichen VPN-Regeln nötig.Daß man zusätzlich noch "VPN-Regeln" braucht, damit das Ganze mal stabil läuft und im Handbuch lediglich darauf verwiesen wird, daß man keine kombinierten FW-VPN-Regeln erstellen soll, grenzt schon an eine Hinterhältigkeit. Ich bin erstmal ziemlich satt mit der Thematik Lancom + VPN
Und wieso sollte man keine kombinierten FW-VPN-Regeln erstellen dürfen. Es ist nur sinnvoller, dies getrennt zu machen, um nicht die Übersicht zu verlieren...
Es ist halt so, daß du in Firewall-Regeln meist noch Ports einträgst (z.B. HTTP ist erlaubt). Wenn du so etwas in eine VPN-Regel einträgst, dann mußt du es auch auf der anderen Seite in die VPN-Regel eintragen, weil sonst die IKE-Verhandlung scheitert...
Allein deshalb ist es schon sinnvoll, keine kombinierten VPN- und Firewallregeln zu erstellen - verboten ist es jedoch nicht...
Gruß
Backslash
Hallo,
als ich mit LANCOM/LANconfig Bekanntschaft machte, hatte ich mich auch über die ominös gehaltenen VPN-Regeln geärgert. Vor allem, weil sie so behelfsmäßig und sinnentstellend in den FW-Dialog mit "reingequetscht" wurden.
Meines Erachtens gehören sie mit eigenem Dialog in die VPN-Konfiguration, zusammen mit einer vernünftigen Beschreibung des obigen Sachverhaltes. Der nichtssagende Name "VPN-Regel" sollte dabei auch verworfen werden. Letztlich sind es ja Netzwerkzuordnungen, und keine Regeln wie sie etwa ein Paketfilter besitzt.
Gruß
omd
als ich mit LANCOM/LANconfig Bekanntschaft machte, hatte ich mich auch über die ominös gehaltenen VPN-Regeln geärgert. Vor allem, weil sie so behelfsmäßig und sinnentstellend in den FW-Dialog mit "reingequetscht" wurden.
Meines Erachtens gehören sie mit eigenem Dialog in die VPN-Konfiguration, zusammen mit einer vernünftigen Beschreibung des obigen Sachverhaltes. Der nichtssagende Name "VPN-Regel" sollte dabei auch verworfen werden. Letztlich sind es ja Netzwerkzuordnungen, und keine Regeln wie sie etwa ein Paketfilter besitzt.
Gruß
omd
LC 1811 / LCOS 5.08
Nein, aber es wird von Lancom höchstselbst nicht empfohlen. Zitat aus dem LCOS-Handbuch 5.00:backslash hat geschrieben:Hi 1711-UserWenn "falsch konfiguriert" = "nicht so konfiguriert, daß es der 1711 dauerhaft macht" heißt, dann jaMit so einem Problem solltest du dich an den LANCOM-Support wenden... Ggf. hast du auch nur etwas falsch konfiguriert.Ich hatte jedenfalls den Tunnel als Router angegeben, dazu noch ein paar Firewall-Regeln gebaut und es funktionierte einige Zeit tadellos. DAS war ja das Gemeine! Erst nach 1-2 Stunden ging der Tunnel aus unerklärlichen Gründen (keinerlei Fehlermeldungen im LAN-Monitor und nichtmal im trace + vpn) down und machte auch keine Antstalten mehr für ein Rekeying, half nur der Kaltstart
Wie gesagt, es ging 1-2 Stunden und dann knackte es. Das war aber nicht immer so, am Anfang ging es durchaus 1-2 Tage. Also ziemlich schwer nachvollziehbar.
Nein, das Gegenteil ist der Fall.Und wieso sollte man keine kombinierten FW-VPN-Regeln erstellen dürfen. Es ist nur sinnvoller, dies getrennt zu machen, um nicht die Übersicht zu verlieren...Daß man zusätzlich noch "VPN-Regeln" braucht, damit das Ganze mal stabil läuft und im Handbuch lediglich darauf verwiesen wird, daß man keine kombinierten FW-VPN-Regeln erstellen soll, grenzt schon an eine Hinterhältigkeit. Ich bin erstmal ziemlich satt mit der Thematik Lancom + VPN
Es ist bedeutend übersichtlicher einfach einen Haken zu setzen, als nochmal 2 komplett neue Regeln für "REIN" und "RAUS" zu bauen.
Wie gesagt, es lief ja:
1. VPN-Tunnel-Angaben gemacht
2. in die Routing-Tabelle eingetragen welches Netz durch den VPN-Tunnel angeflogen wird
3. noch einige Ports mit FW-Regeln erlaubt (UND das Häkchen gesetzt, daß diese Ports auch bei der VPN-Verbindung benutzt werden) und alle anderen Ports gesperrt (deny ALL)
4.Konfig geschrieben
VPN-Aushandlung mit Gegenstelle (TDT-Router) wohlwollend per Trace beobachtet, User beim Arbeiten beobachtet, nach Haus gefahren.
Nächsten Tag Telefon: "Nichts geht mehr".
Hingefahren, alle Regeln geprüft, Router aus-/an-geschaltet. Alles geht wieder, Kaffee, zur Sicherheit 3 Stunden vor Ort aufgehalten, Kaffee, Nach Haus.
Und täglich grüßte das Murmeltier.
Wenn es wenigstens von Anfang an nicht geklappt hätte.
Aber so??? War echt zum Haare raufen und fing schon langsam an Geld + Zeit zu kosten.
Bis ich dann den Hinweis im Handbuch fand.
Langsam kommen wie des Pudels Kern näherEs ist halt so, daß du in Firewall-Regeln meist noch Ports einträgst (z.B. HTTP ist erlaubt). Wenn du so etwas in eine VPN-Regel einträgst, dann mußt du es auch auf der anderen Seite in die VPN-Regel eintragen, weil sonst die IKE-Verhandlung scheitert...
Allein deshalb ist es schon sinnvoll, keine kombinierten VPN- und Firewallregeln zu erstellen
Selbstverständlich habe ich Filter auf bestimmte Ports drin. Die User sollen doch nicht alles dürfen. Und das gemeine war, es ging einige Zeit und knackte DANN irgendwann, als ich nicht mehr vor Ort war, also klappte die "IKE-Verhandlung" zunächst durchaus, daher stimmt deine Aussage leider nicht ganz.
- verboten ist es jedoch nicht...
"Die Firewall-Regeln zum Erzeugen von VPN-Netzbeziehungen mit Angabe der Tunnelendpunkte (IP-Quell- und Ziel-Adressen) sollten auf jeden Fall von Firewall-Regeln zum Filtern getrennt werden."
Und dazu sage ich: Wenn man diesen schlauen Hinweis schon irgendwo im Handbuch versteckt, warum erlaubt man dann per Conifg-Oberfläche das Setzen der Häkchen "Diese Regel ist für die Firewall aktiv" UND gleichzeitig "Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen"? Wenn Lancom weiß, daß das Setzen beider Häkchen zu Problemen führt, könnte man doch einen Option- oder Radio-Button nehmen statt einer (mehrfach Selektion erlaubenden) Checkbox. Dann würde man den Anwender davor "schützen" in beides ein Häkchen zu setzen. So wie es derzeit ist, wird man jedoch gerade dazu eingeladen. Und DAS finde ich nicht OK.
Hi 1711-User
Daher ist es in deinem Fall halt sinnvoller eine reine VPN-Regel für die Netzbeziehung zu erstellen (Haken bei VPN-Regelerzeugung an und bei Firewallaktivität aus) und gezielte Allow-Regeln für einzelne Ports allein für die Firewall.
Wenn man aber im VPN alles erlauben will (was i.A. der Fall ist, da das VPN als vertrauenswürdig angesehen wird), dann ist es durchaus sinnvoll die Regel sowohl für die VPN-Netzbeziehung als auch die Firewall zu aktivieren. Und genau deshalb können beide Schalter gesetzt werden...
Gruß
Backslash
wenn man genau weiss, was man da tut, dann ist es kein Problem. Wenn man portbehaftete Regeln für das VPN erstellt und nicht genau weiss, was man da tut, dann passiert es halt, daß der Aufbau in der einen Richtung funktioniert und es im Falle eines von der Gegenseite angestartenen Rekeyings scheitert, weil dort die Regeln nicht passend stehen...Und dazu sage ich: Wenn man diesen schlauen Hinweis schon irgendwo im Handbuch versteckt, warum erlaubt man dann per Conifg-Oberfläche das Setzen der Häkchen "Diese Regel ist für die Firewall aktiv" UND gleichzeitig "Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen"? Wenn Lancom weiß, daß das Setzen beider Häkchen zu Problemen führt, könnte man doch einen Option- oder Radio-Button nehmen statt einer (mehrfach Selektion erlaubenden) Checkbox. Dann würde man den Anwender davor "schützen" in beides ein Häkchen zu setzen. So wie es derzeit ist, wird man jedoch gerade dazu eingeladen. Und DAS finde ich nicht OK
Daher ist es in deinem Fall halt sinnvoller eine reine VPN-Regel für die Netzbeziehung zu erstellen (Haken bei VPN-Regelerzeugung an und bei Firewallaktivität aus) und gezielte Allow-Regeln für einzelne Ports allein für die Firewall.
Wenn man aber im VPN alles erlauben will (was i.A. der Fall ist, da das VPN als vertrauenswürdig angesehen wird), dann ist es durchaus sinnvoll die Regel sowohl für die VPN-Netzbeziehung als auch die Firewall zu aktivieren. Und genau deshalb können beide Schalter gesetzt werden...
Gruß
Backslash
Ist es so, daß die Gegenseite ein Rekeying anstoßen darf? Dachte bisher, daß das nur der Initiator der Verbindung (also "meine" Seite) darf. Korrigier mich, falls ich irre!backslash hat geschrieben: Wenn man portbehaftete Regeln für das VPN erstellt und nicht genau weiss, was man da tut, dann passiert es halt, daß der Aufbau in der einen Richtung funktioniert und es im Falle eines von der Gegenseite angestartenen Rekeyings scheitert, weil dort die Regeln nicht passend stehen...
