nichtsnutz
Goto Top

AVM IPSEC Standortkopplung - (statische?) IP-Adressen im Remote-Netzwerk

Hallo ins Forum, hallo aqui,
Alle Fritten-Verweigerer und Freunde der Kommandozeile mögen diese Zeilen bitte mit einem überlegenem Lächeln ignorieren...:

Seit Monaten arbeiten wir daran, die Sicherheit unserer Fritzbox-Netzwerke zu verbessern, indem wir eine Lancom R&S UF Firewalls zwischen Fritzbox und Ziel-LAN installieren. Die Firewall übernimmt dann die ursprüngliche LAN IP der Fritzbox und macht das Gateway. Die FB darüber bekommt ein anderes Netzwerk und stellt VoIP, WLAN, Fax und DECT jenseits der Firewall bereit.
Das funktioniert soweit ganz gut doch es wird immer dann kompliziert wenn die Fritzboxen VPN bereitstellen.
Insbesondere wenn die Homeoffice-User von zu Hause per RDT auf Ihre Rechner in der Firma zugreifen möchten.
Hier meine Frage:
Wenn sich bei einer IPSEC-Kopplung zwei Fritzboxen miteinander verbinden, erhält doch jede der beiden FB eine IP-Adresse im jeweiligen Remote-LAN (oder?) Wie /wo kann ich die ggf. in den CFG-Dateien fixieren / modifizieren?
Ich brauche diese Adresse, um in der Firewall dahinter eine entsprechende Regel zu definieren.

Die umgedrehte Richtung - z.B. externes Backup aus (!) dem Firmen-LAN auf das NAS zu Hause- haben wir im Griff - das funktioniert ohne Sicherheitskompromisse.
Falls ich nicht in der Lage war, mich ausreichend auszudrücken, skizziere ich das Szenario nochmal mit den entsprechenden IP-Adressen.

Vielen Dank und viele Grüße von der Ostsee!

Jens

Content-ID: 655117

Url: https://administrator.de/forum/avm-ipsec-standortkopplung-statische-ip-adressen-im-remote-netzwerk-655117.html

Ausgedruckt am: 22.12.2024 um 20:12 Uhr

147448
147448 23.02.2021 um 21:38:46 Uhr
Goto Top
Lass nochmal den Ostsee Wind drüber blassen, und

bring die Skizze ans Tageslicht !
aqui
Lösung aqui 23.02.2021 um 22:19:12 Uhr
Goto Top
den Ostsee Wind drüber blassen
Der Ostsee Wind ist aber keinesfalls blass sondern immer frisch und kräftig ! face-wink
erhält doch jede der beiden FB eine IP-Adresse im jeweiligen Remote-LAN (oder?)
Nein das ist technisch nicht richtig !
Die FBs nutzen IPsec im Tunnel Mode.
esp
Im Schnellverfahren...
Die Phase 2 SAs im IPsec bestimmen welcher Traffic verschlüsselt und mit einem ESP Header versehen und getunnelt wird.
Hat eine FB das lokale 10.1.1.0/24 Netz und die andere 10.2.2.0/24 und die SAs bestimmen diese beiden Netze, dann wird jeglicher Traffic mit diesen Absneder und Ziel IPs verschlüsselt und in den ESP Header gepackt, der als Absender immer die lokale öffentliche IP und als Ziel die remote öffentliche IP enthält. Am Ziel wird das Packet dann ausgepackt und an die lokale Zieladresse geforwardet. Keine der FritzBoxen hat lokale Interfaces mit remoten IP Adressen ! Lesen und verstehen:
https://de.wikipedia.org/wiki/IPsec#Vergleich_Transport-_und_Tunnelmodus
In den jeweiligen remoten LANs siehst du dann also Absender und Ziel immer auch nur die lokalen 10er IP Adressen die dann auch für das Firewall Regelwerk gelten.
Eigentlich ein ganz simples Verfahren.
147448
Lösung 147448 23.02.2021 um 23:45:17 Uhr
Goto Top
@aqui

Kommt der auch, da auf der einen Seite noch ein LANCOM hängt durch das NAT durch, wenn man es nicht aufmacht ?

Ich würde das ohne die Konfig zu kenne anzweifeln !
Nichtsnutz
Nichtsnutz 24.02.2021 um 07:36:44 Uhr
Goto Top
Ich habe es natürlich noch nicht komplett verstanden und werde erst am Abend dazu kommen, zu lesen und zu verstehen.
Das hilft mir aber zunächst weiter weil ich weiß, daß schon mein Ansatz falsch war. Ich hatte mich dabei vom AVM-VPN-Client leiten lassen, bei dessen Konfiguration man dediziert angibt, welche IP-Adresse der Client im Remote-LAN bekommt.
Daraus kann man dann eine Regel für die Firewall generieren...
Darum geht es mir. Ohne alle "Tore zu öffnen" sollen User hinter der "Zuhause-Fritzbox" RDT im Firmen-LAN öffnen können...
Ich werde lesen und nachdenken.
Vielen Dank.

...und der Ostseewind schwächelt seit 10 Tagen. Als er im Januar aus Nordost (Russland) kam, war es unerträglich...
aqui
Lösung aqui 24.02.2021 um 12:50:46 Uhr
Goto Top
Kommt der auch, da auf der einen Seite noch ein LANCOM hängt durch das NAT durch
Der Tunnel selber macht kein NAT bei der FritzBox. Wenn dahinter (oder davor) natürlich noch ein NAT Router kommt dann sieht das natürlich anders aus. Da wirds dann nix ohne Port Forwarding.
Der TO schrieb aber nichts davon das im Datenfluss irgendwie noch NAT gemacht wird so das man von einem transparenten Routing ausgehen musste.
Ich hatte mich dabei vom AVM-VPN-Client leiten lassen
Du darfst ein Client VPN auch niemals mit einem Site to Site VPN vergleichen. 2 unterschiedlichen Baustellen ! Der Ansatz war dann also in der Tat falsch.
Daraus kann man dann eine Regel für die Firewall generieren...
Absolut !
sollen User hinter der "Zuhause-Fritzbox" RDT im Firmen-LAN öffnen können...
Das können sie auch ganz ohne VPN wenn man RDP im Browser macht und per HTTPS verschlüsselt. Dann reicht ein simpler Webbrowser zuhause und remote... face-wink
Nichtsnutz
Nichtsnutz 24.02.2021 um 13:27:00 Uhr
Goto Top
"Das können sie auch ganz ohne VPN wenn man RDP im Browser macht und per HTTPS verschlüsselt. Dann reicht ein simpler Webbrowser zuhause und remote... "
Dazu brauche ich Lektüre... Hast Du einen Link?
aqui
Lösung aqui 24.02.2021 um 14:51:47 Uhr
Goto Top
Da müssen sich mal die Citrix und Windows RDP Profis hier äußern....
Dani
Lösung Dani 24.02.2021 um 21:49:40 Uhr
Goto Top
Moin,
Dazu brauche ich Lektüre... Hast Du einen Link?
wenn es kostenlose und Open Source sein soll, Apache Guacamole. Gibt dazu ein paar wenige gute Anleitungen.

@aqui
Da müssen sich mal die Citrix und Windows RDP Profis hier äußern....
Citrix = disqualifiziert mich, Profi = disqualifiziert mich. Bin in der VMware World zu Hause. face-wink


Gruß,
Dani
Nichtsnutz
Nichtsnutz 28.02.2021 um 18:49:57 Uhr
Goto Top
Update:
"RDP im Browser SSl-verschlüsselt" ist sicher eine Lösung.
Sie erfordert aber einen Windows Server , der als DC konfiguriert wurde.
In einigen kleinen LAN laufen meine Server aber inzwischen nicht mehr als DC.

Es geht -wie gesagt- um das Home-Office-Szenario, daß eine Fritzbox zu Hause mit einer Fritzbox in der Firma via IPSEC Standortkopplung verbunden sind. Zwischen Firmennetzwerk und Firmen-Fritzbox läuft eine Lancom UF-Firewall.

Mein Sohn hat deshalb mit Lancom telefoniert. Wir suchen nach wie vor eine Lösung, um eine Firewall-Regel zu generieren, die es nur speziellen IP-Adressen aus dem Remote-LAN erlaubt , RDT-Verbindungen zu einzelnen, speziellen Hosts im Firmen-LAN zu ermöglichen.
Lancom meint, daß zunächst die Lancom-UF-Firewall der Firma direkt mit der Fritzbox zu Hause verbunden werden sollte (IPSEC Standortkopplung). Mein Sohn zieht das in den nächsten Tagen mal durch und dann melde ich mich mit dem Ergebnis.

Grundsätzlich installieren wir zunehmend zwischen Fritzbox und Firmen-LAN eine UF-Firewall, um die Sicherheit der Fritzbox-Netzwerke zu verbessern. Die praktische FB kümmert sich dann jenseits des Firmen-LAN um VoIP, (Gäste-) WLAN, DECT, Fax usw. ... Das funktioniert inzwischen gut doch bei VPN wird es knifflig , wenn von außen (sicher) ins Firmennetz zugegriffen werden soll. Von innen nach außen (externes Backup via robocopy auf NAS zu Hause) funktioniert es gut. Wenn alle Probleme gelöst sind, dokumentiere ich das Vorgehen.

Zu folgendem Problem möchte ich keinen neuen Thread aufmachen:
Es stört , wenn ein AVM VPN-Client bei der Einwahl auf alle Hosts im Ziel-LAN zugreifen kann.
Szenario:
  1. Firmen-LAN 10.200.100.0 / 255.255.255.0
  2. Der VPN-Client bekommt bei der Einwahl die Adresse 10.200.100.231
  3. Der VPN Client soll nur auf den Host 10.200.100.111 zugreifen dürfen

In der Client-Config steht:
accesslist = "permit ip any 10.200.100.0 255.255.255.0";

In der Fritzbox Config steht:
accesslist = "permit ip 10.200.131.0 255.255.255.0 10.200.131.231 255.255.255.255";

Wie muß ich die Einträge korrigieren, damit nur die 10.200.100.111 für den Teleworker erreichbar ist?
Muß ich in beiden Config die selben Einträge vornehmen?

Vielen Dank und viele Grüße von der eisigen Ostsee (2 Grad)!

Jens
aqui
Lösung aqui 28.02.2021 aktualisiert um 19:20:03 Uhr
Goto Top
Sie erfordert aber einen Windows Server , der als DC konfiguriert wurde.
Nicht wenn man mit Citrix arbeitet ! Kostet aber... face-wink
die es nur speziellen IP-Adressen aus dem Remote-LAN erlaubt , RDT-Verbindungen zu einzelnen, speziellen Hosts im Firmen-LAN zu ermöglichen.
Mit entsprechender Router oder Firewall HW ist das kein Thema. Fast alle bieten die Option am VPN Tunnelinterface entsprechende Regeln zu generieren so das das im Handumdrehen erledigt ist.
Lancom meint, daß zunächst die Lancom-UF-Firewall der Firma direkt mit der Fritzbox zu Hause verbunden werden sollte (IPSEC Standortkopplung)
Ist auch eine vernünftige Idee ! Obwohl bei vielen externen Usern nicht wirklich skalierbar und fast unmöglich mit einem vernünftigen IP Adress Plan.
Zumal hast du bei einem Client Dialin der einzelnen User immer die Möglichkeit die Client IP Adresse fest zu bestimmen und damit dann problemlos ein wasserdichtes Regelwerk auf der Firewall zu etablieren, was bei einer Site to Site Kopplung so unmöglich ist und die Sache dann massiv erschwert.
In der Beziehung ist also ein Client Dialin die bessere Wahl.
Wie muß ich die Einträge korrigieren, damit nur die 10.200.100.111 für den Teleworker erreichbar ist?
Das ist so mit der FritzBox und einer Site to Site Anbindung technisch unmöglich.
Das geht nur bei einem Client VPN Dialin.

Dort vergibst du, wie oben schon gesagt, je nach Usernamen eine feste Client IP im Tunnel. Mit dieser fest auf den Client bezogenen IP Adresse setzt du dann ein entsprechendes Regelwerk auf der Firewall auf.
Mit einem Client bordeigenen IPsec oder L2TP VPN ist das im Handumdrehen erledigt und hat den Vorteil das man auf keinerlei Plattform (Winblows, Apple, Linux, Smarphones) extra VPN Software benötigt.
Wie man sowas schnell, einfach und kostenfrei aufsetzt erklärt dir z.B. die Client VPN Einrichtung auf einer pfSense oder OPNsense Firewall:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Die erste Variante hat auch noch den entscheidenden Vorteil durch das VPN Server Zertifikat das dir keiner einen fremden VPN Server unterjubelt und so die Clients "entführt" !
Mit dem entsprechenden Client IP Regelwerk was die einzelnen User filtert je nach Policy und auch auf Port TCP 3389 begrenzt ist das dann die rundrum sorglos Lösung und erfordert alle deine Anforderungen mit einem sehr leicht zu managen Setup.
Was willst du also mehr....?!
Nichtsnutz
Nichtsnutz 28.02.2021 um 19:51:24 Uhr
Goto Top
Du hast mit der pfsense natürlich Recht aqui!
Das könnte dann in einigen Monaten der nächste Schritt sein.
Vorerst geht es mir aber darum, explizit die vielen Fritzbox-Netzwerke mit den Lancom-Firewalls sicherer zu machen.
Wir sind da aus meiner Sicht auf einem guten Weg. Diese Fritzboxen laufen meist in kleinen LAN, wo "Unwissende" wie ich werkeln, die damit in einem Handstreich die Themen, VoIP, WLAN, Fax, DECT, LAN, VPN erledigen. Die Sicherheit dieser kleinen Firmen möchte ich -möglichst nach Schema - durch die Firewalls verbessern.
Bei größeren Sachen setzen wir ausschließlich Lancom-Router ein. Mit denen bin ich so zufrieden, daß die Firewalls auch Lancom heißen. Ich kenne somit auch den Unterschied in der VPN-Performance.

Mein zweites Anliegen (Wie muß ich die Einträge korrigieren, damit nur die 10.200.100.111 für den Teleworker erreichbar ist?) hat nichts mit dem Firewall-Thema zu tun. Es geht dabei rein um AVM. Wenn es bei Site-to-Site unmöglich ist, will ich es zumindest bei Client-VPN Einwahl verbessern - kriege es aber nicht hin face-sad.

"Das ist so mit der FritzBox und einer Site to Site Anbindung technisch unmöglich.
Das geht nur bei einem Client VPN Dialin.
Dort vergibst du, wie oben schon gesagt, je nach Usernamen eine feste Client IP im Tunnel. Mit dieser fest auf den Client bezogenen IP Adresse setzt du dann ein entsprechendes Regelwerk auf der Firewall auf."
Das habe ich verstanden und denke darüber nach. Mein Sohn hat mir das ähnlich erklärt.

Deine pfsense Manuals lese ich regelmäßig alle paar Monate und verstehe dabei jedes Mal etwas mehr...
aqui
Lösung aqui 28.02.2021 aktualisiert um 20:41:44 Uhr
Goto Top
Die Sicherheit dieser kleinen Firmen möchte ich -möglichst nach Schema - durch die Firewalls verbessern.
Das ist auch absolut OK, so erfordert aber, wie oben schon gesagt, für eine Site to Site Kopplung eine saubere IP Adress Policy Planung.
Siehe dazu auch hier: VPNs einrichten mit PPTP
Hast du 3 Firmen die alle die Fritz Standard Adressierung nutzen .178.0 hast du schon das erste Problem.
Mit denen bin ich so zufrieden, daß die Firewalls auch Lancom heißen.
Ist auch OK, die Hardware ist da letztlich Wumpe, denn die Client IP Adressierungs Optionen bieten sie alle je nach verwendetem VPN Protokoll. Im FritzBox Umfeld ist das dann immer native IPsec.
Wie muß ich die Einträge korrigieren, damit nur die 10.200.100.111 für den Teleworker erreichbar ist?
Das ist kinderleicht. Die Regel sieht dann so aus:
PERMIT: Protokoll: IP, Source IP: ANY, Source Port: ANY, Destination IP: 10.200.100.111, Destination Port: ANY

Willst du das noch weiter auf die Applikation dicht machen also nur RDP dann lautet sie:
PERMIT: Protokoll: TCP, Source IP: ANY, Source Port: ANY, Destination IP: 10.200.100.111, Destination Port: 3389

Ein DENY any any ist bei Firewalls immer Default so das bei dem Regelwerk rein nur ein Zugriff auf die Ziel IP
10.200.100.111 möglich ist.
Eigentlich ganz simpel und kein Hexenwerk. face-wink
und verstehe dabei jedes Mal etwas mehr...
Eigentlich etwas unverständlich wenn du Lancom Firewall Profi bist und dich dann mit TCP/IP Regeln bestens auskennst, denn dort ist das Regelwerk doch identisch ?!
Ansonsten immer den Wireshark zur Hand nehmen und sich den relevanten Traffic einmal Live ansehen. Das öffnet sofort die Augen. face-wink
Nichtsnutz
Nichtsnutz 28.02.2021 um 22:03:40 Uhr
Goto Top
Ich bin kein Lancom Firewall Profi, aqui!!! - Das macht mein Sohn...
Die Lancom-Router konfiguriere ich meist per "Assistent" und bin mit dem Resultat seit Jahren sehr zufrieden.
Das 192.168.178.0-Problem habe ich (trotzdem) seit längerer Zeit verstanden.
Mit Deiner "kinderleichten" Ansage zu den Permit-Regeln bei AVM werde ich mich morgen befassen wenn die Woche gut anfängt. Muß ich die "Permit-Regel" in beiden Configs IDENTISCH eintragen?
Daß man dabei auch Ports "reglementieren" kann, erweitert meinen Horizont sehr. Ich will wirklich nur das erlauben, was elementar erforderlich ist.
Mit Wireshark habe ich mich schon befasst und werde das vertiefen. Das ist aber in etwa die Grenze meines Horizontes...
Danke aqui! - und komm´gut durch die Woche!
aqui
aqui 01.03.2021 aktualisiert um 10:54:28 Uhr
Goto Top
Muß ich die "Permit-Regel" in beiden Configs IDENTISCH eintragen?
Ja, aber natürlich musst du auf die richtige Reihenfolge der Source und Destination IP Adressen und Source und Destination Ports achten sofern du das ins Regelwerk einbeziehst.
Nur das du das nicht missverstehst: Die o.a. Beispielregel war so eine globale Allerweltsregel weil man die genau Syntax deiner Firewall eben nicht kennt.
Bei einem Cisco Router hiessen die dann so wenn sie als Inbound Regel definiert ist.
ip access-list extended rdp_user
permit tcp any host 10.200.100.111 equal 3389

Bei einer pfSense:
PASS Protokoll: TCP, Source IP: ANY, Source Port: ANY, Destination IP: 10.200.100.111, Destination Port: 3389

Du kannst aber erkennen das die Grundsyntax und Logik solcher simplen Regeln immer gleich ist.
Das war nur mal eine Blaupause für dich wie sowas umzusetzen ist. Die finlae Regelsyntax hängt immer von deiner verwendeten Hardware ab.
Ich will wirklich nur das erlauben, was elementar erforderlich ist.
Das ist auch eine absolut richtige Vorgehensweise und immer best Practise.
Deine To Dos sind also recht einfach:
  • Im VPN Dialin Server den Usernamen feste IP Adressen zuweisen
  • Mit diesen IP Adressen und der RDP Serveradresse wasserdichte Regeln am VPN Tunnelinterface erstellen und auf TCP 3389 filtern
  • Fertisch
So kannst du dann sehr granular pro User einstellen was dieser darf und was nicht. Du weisst selber das mangelndes Fachwissen niemals zu Lasten der Security gehen sollte, das hätte fatale Folgen und genau darauf spekulieren ja Angreifer.