Eigene SA definieren

[Avalanche]

Angenommen, ich wähle mich mit einem Lancom auf einer Astaro ein. Auf dem Lancom sind mehrere Netze definiert:
1) 192.168.0.1/24
2) 192.168.1.1/24
3) 192.168.2.1/24

In der Zentrale gibt es das Netz 10.10.10.0/24

Wie kann ich dem Lancom Router sagen, dass er folgende SA aufbauen soll: 192.168.0.0/16 <=> 10.10.10.0/24? Ich will also in der Zentrale nicht alle Netze als einzelne Netzbeziehung pflegen.

[Avalanche]

In der Zwischenzeit habe ich rausgefunden, wie es prinzipiell geht: Man muss bei der VPN-Verbindung die Regelerzeugung von "Automatisch" auf "Manuell" setzen. Und dann passende Firewallregeln für die SAs erzeugen. So weit, so gut.

Allerdings ergeben sich aus dieser Erkenntnis mehr Fragen als mir lieb sind:

• Ich habe pro Netzbeziehung zwei Regeln definiert (jeweils mit Quelle und Ziel vertauscht) und Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen aktiviert. Die SA wird allerdings an die Gegenseite erst dann annonciert, wenn es tatsächlich auch eine Route in das über die SA definierte Netz gibt. Fehlt der Eintrag in der Routing Tabelle werden die beiden Regeln ignoriert. Das erscheint mir unlogisch, da die SAs mit dem eigentlichen Routing erst mal nichts zu tun haben.
• Was hat in diesem Zusammenhang bei der Firewall-Regel für die SA der Haken "Hält Verbindungszustände nach" zu bedeuten? Wirkt sich der überhaupt aus? Soll der gesetzt sein oder nicht?
• In der Dokumentation steht als Hinweis Verwenden Sie für diese Einschränkungen eigene Regeln, die nur für die Firewall gelten und nicht zur Erzeugung von VPN-Regeln herangezogen werden. Kombinierte Firewall/VPN-Regeln können sehr leicht komplex und schwer überschaubar werden. Wenn ich das richtig verstehe, benötige ich bei einer Deny-All-Strategie für jede SA mindestens zwei Regeln plus zwei Regeln für die Firewall. Mir erscheint dieses Häckchen also eher als eine Vereinfachung.
  Ich könnte mir vorstellen, dass es unübersichtlich wird, wenn man SA Beziehung und eine Firewall-Regel mit QoS bzw. Portbereichen miteinander vermischt. Ist das damit gemeint?
• Was passiert, wenn man für eine VPN-Regel als Quelle und Ziel mehrere Netzwerke einträgt? Beispielsweise Quelle: Netz A, Netz B und Ziel Netz C, Netz D?
• Was ist, wenn man pro SA A <> B nur eine Regel anlegt (entweder nur A > B oder Quelle A, B und Ziel A, B)? Explodiert dann der Router?

Zur Usability: die Tatsache, dass man zur Definition einer Netzbeziehung für eine VPN Verbindung Einträge in der Firewall und der Routing-Tabelle machen muss, von denen aber im UI beide keinerlei Bezug zur entsprechenden VPN-Verbindung haben, erscheint mir "suboptimal". Die Tatsache, dass man in der Liste der Firewall-Regeln pro SA zwei Einträge hat, die noch nicht einmal beieinander stehen, macht es leider nicht besser.

Richtig cool wäre es noch im Quick Monitoring (STRG+M auf dem Geräteeintrag) unter der VPN-Verbindung auch die aufgebauten SAs sehen könnte.

Ich habe schon einiges ausprobiert und würde mich freuen, wenn einer der Profis zu diesem Thema mir ein paar Tipps geben könnte.

[MariusP]

Hi,
Ich kenn mich zwar nicht wirklich auf dem LanMonitor aus.
Aber das was du sichst findest du auf der CLI unter "show vpn sadb". Alle show vpn befehle findest du unter "show vpn ?".
Gruß

[Avalanche]

Danke für den Hinweis. show vpn sadb kenne ich. Dachte nur, dass das halt im GUI auch praktisch wäre, so wie auch die Adresse der Gegenstelle angezeigt wird.

[backslash]

Hi Avalance,

Ich habe pro Netzbeziehung zwei Regeln definiert (jeweils mit Quelle und Ziel vertauscht) und Diese Regel wird zur Erzeugung von VPN-Regeln herangezogen aktiviert.

Der Haken muß nur an der "abgehenden" Regeln gesetzt werden.

Die SA wird allerdings an die Gegenseite erst dann annonciert, wenn es tatsächlich auch eine Route in das über die SA definierte Netz gibt. Fehlt der Eintrag in der Routing Tabelle werden die beiden Regeln ignoriert. Das erscheint mir unlogisch, da die SAs mit dem eigentlichen Routing erst mal nichts zu tun haben.

Solange der Router das Ziel nicht erreichen kann, ist es überflüssig eine Regel dafür zu erstellen. Abgesehen davon schränkt das LANCOM auch bei manueller Regelerstellung das entfernte Netz auf das erreichbare ein, d.h. wenn du dort "0/0" stehen hast, aber keine Default-Route zur Gegenstelle sondern nur eine (odere mehrere) Eingeschränkte, dann werden SAs erststellt, die zu den erreichbaren Routen passen

Was hat in diesem Zusammenhang bei der Firewall-Regel für die SA der Haken "Hält Verbindungszustände nach" zu bedeuten? Wirkt sich der überhaupt aus? Soll der gesetzt sein oder nicht?

Das ist eine Eigensachaft der Regel in der Firewall und hat mit SAs nichts zu tun. Bei aktiver Zustandsüberwachung prüft die Firewall die Konsistenz von TCP-Sessions (z.B. Aufbau und Abbau) und erkennt Protokolle wie FTP, PPTP und IRC um ggf. weitere Ports für diese öffnen zu können. Ohne Zustandsüberwachung ist auch das IDS nur eingeschränkt funktionstüchtig. Hier geht es aber um VPN, also Schluß damit...

Wenn ich das richtig verstehe, benötige ich bei einer Deny-All-Strategie für jede SA mindestens zwei Regeln plus zwei Regeln für die Firewall.

nein... Du brauchst zwei Regeln, die eingehende und abgehende Sessions regeln und nur eine Regel für die SA...

Mir erscheint dieses Häckchen also eher als eine Vereinfachung.

ja, so war das ursprünglich auch gedacht, aber die Realität sieht anders aus... Bei einer Deny-All-Stategie willst du i.A. aber mehr einschränken, als nur den Zugriff auf die Netze. Daher brauchst du eigentlich für jeden erlaubten Dienst eine eigene für die Firewall aktive Regel und eine über die die SA erstellt wird (die für die Firewall *NICHT* aktiv ist).

Was passiert, wenn man für eine VPN-Regel als Quelle und Ziel mehrere Netzwerke einträgt? Beispielsweise Quelle: Netz A, Netz B und Ziel Netz C, Netz D?

dann werden entsprechend viele VPN-Regeln erstellt (A <-> C, A <-> D, B <-> C, B <-> D)...

Was ist, wenn man pro SA A <> B nur eine Regel anlegt (entweder nur A > B oder Quelle A, B und Ziel A, B)? Explodiert dann

du brauchst nur eine Regel anzulegen... (die andere wird sowieso ignorirt, weil sie nicht zur Routing-Tabelle paßt)

Gruß
Backslash

[Avalanche]

Hallo Backslash,

vielen lieben Dank für die Erklärungen. Ich bin wohl irgendwo in der Doku falsch abgebogen und dann davon ausgegangen, dass man zwei Regeln pro SA braucht.

Solange der Router das Ziel nicht erreichen kann, ist es überflüssig eine Regel dafür zu erstellen. Abgesehen davon schränkt das LANCOM auch bei manueller Regelerstellung das entfernte Netz auf das erreichbare ein, d.h. wenn du dort "0/0" stehen hast, aber keine Default-Route zur Gegenstelle sondern nur eine (oder mehrere) Eingeschränkte, dann werden SAs erstellt, die zu den erreichbaren Routen passen

Verstehe ich die Hintergründe richtig: Man benötigt eine VPN-Regel in der Firewall deshalb, weil man nur dort Quellnetze und Zielnetze angeben kann? In der Routing-Tabelle ist nur Gateway und Zielnetz aber kein Quellnetz vorhanden. Erst beides zusammen kombiniert ergibt dann für den Lancom die zu erzeugende SA?

Was passiert, wenn man für eine VPN-Regel als Quelle und Ziel mehrere Netzwerke einträgt? Beispielsweise Quelle: Netz A, Netz B und Ziel Netz C, Netz D?

dann werden entsprechend viele VPN-Regeln erstellt (A <-> C, A <-> D, B <-> C, B <-> D)...

Damit wird das dann ja doch wieder übersichtlich, weil ich dann die Regeln für die SAs deutlich zusammenfassen kann.

[backslash]

Hi Avalanche,

Verstehe ich die Hintergründe richtig: Man benötigt eine VPN-Regel in der Firewall deshalb, weil man nur dort Quellnetze und Zielnetze angeben kann? In der Routing-Tabelle ist nur Gateway und Zielnetz aber kein Quellnetz vorhanden. Erst beides zusammen kombiniert ergibt dann für den Lancom die zu erzeugende SA?

korrekt...

Damit wird das dann ja doch wieder übersichtlich, weil ich dann die Regeln für die SAs deutlich zusammenfassen kann.

du mußt nur aufpassen, daß du damit nicht auch unerwünschte Netzbeziehungen zuläßt... Wenn in deinem Beispiel z.B. B <-> D nicht erlaubt sein soll, mußt du halt doch eigene Regeln für A <-> C,D und B <-> C erstellen....

Gruß
Backslash

[Avalanche]

Ja, so hatte ich das auch verstanden. Vielen Dank für den Hinweis.