[gelöst] N:N Mapping / Netmapping

[BeFore]

Hallo,

ich suche eine Möglichkeit, Netmapping auf dem IPFire umzusetzen. Eine kurze Erklärung dazu gibt es bspw. hier: https://www2.lancom.de/kb.nsf/1275/4669 ... enDocument

Viele Hersteller von VPN Routern setzen auch dieses Verfahren ein, was auch sehr sinnvoll ist, wenn man viele Netze miteinander verbinden möchte und diese gleich strukturiert sind.

Wir haben bei uns schon viele kleine Standorte mit teuren und weniger leistungsfähigen Routern ausgerüstet und Netmapping in Benutzung. Zukünftig würde ich gerne IPFire einsetzen, doch müsste ebenso das Netmapping umsetzen, da die Netze an den Standorten bereits alle gleich strukturiert sind und es sonst zum IP Adressenkonflikt kommen würde.

Ist dieses Verfahren im IPFire umsetzbar und wenn ja, wie?

Ich denke, dass es im gewerblichen Einsatz für viele interessant sein sollte.

Danke und Grüße B4

[BeFore]

Ich habe noch was dazu gefunden, doch kann ich nicht in "Routen" denken, sodass ich nicht weiß, was für statisches Routing auf beiden Seiten eingerichtet werden müsste, wenn bspw. beide Netze 192.168.100.0/24 sind.

http://www.ipcop-forum.de/forum/viewtop ... 5&start=15

Für euch ist das sicher ein Klacks. Teilt euer Wissen bitte mit mir .

[ummeegge]

Hallo B4,
ich denke das dass Netmapping beim Lancom auch ein SNAT hierfür nutzt wie im IPCop Forum auch. IPfire bietet SNAT ja auch über das webinterface an --> http://wiki.ipfire.org/en/configuration ... source-nat .

Kannst ja mal schauen wie es damit hinhaut.

Grüsse,

UE

[BeFore]

Ah sehr schön: das schaut ja auf den ersten Blick so aus, also ob es das ist, wonach ich suche. Hoffentlich klappt es. Ich werde Spielen und berichten. Danke.

Die IPFire Box, auch wenn leider noch die Revision 1, ist bereits da.

[BeFore]

Hallo,

nach etwas längerer Zeit kann ich mich der Sache nun mal annehmen. Leider funktioniert es nicht, wie erhofft.
Der Dienstleister sagt in seinem Manual, was zu routen ist (das physikalische Netz ist 192.168.178.0/22, das virtuelle Netz 192.168.208.0):

Source NAT rule:
Type: netmap:
Protocol: all
Output interface: openvpn1 - INSYS Connectivity Service
Source IP address: 192.168.178.0/22
Source NAT to address: 192.168.208.0

Destination NAT rule:
Type: netmap:
Protocol: all
Input interface: openvpn1 - INSYS Connectivity Service
Source IP address: 192.168.208.0/22
Source NAT to address: 192.168.178.0

Wenn ich die Regeln so setze sperre ich mich aber komplett aus, da alles von Grün dann auf das virtuelle Netz geroutet wird. Ich habe da sicher Mist gebaut.

[ummeegge]

Hallo BeFore,
kann es sein das deine Quelle kein von IPFire erstellter/importierter Client ist ? Beispiel für eine SNAT Regel könnte z.b. so aussehen:

Für was hast du das DNAT gedacht ? Wie sieht deine Architektur aus ?

. Es gibt auch einige Beispiele im Forum z.b. hier --> https://forum.ipfire.org/viewtopic.php? ... vpn#p72389 oder --> https://forum.ipfire.org/viewtopic.php? ... vpn#p90279 bzw. gibt es auch ein Wiki zum erstellen vom SNAT beim VPN --> http://wiki.ipfire.org/en/optimization/ ... ad_warrior .

UE

[BeFore]

Hallo UE,

Hallo BeFore,
kann es sein das deine Quelle kein von IPFire erstellter/importierter Client ist ? Beispiel für eine SNAT Regel könnte z.b. so aussehen:

Für was hast du das DNAT gedacht ? Wie sieht deine Architektur aus ?

Ja genau das ist der Fall. Daher habe ich das Netz (den Tunnel -> virtuelles Netz) in der GUI nicht zur Auswahl.

. Es gibt auch einige Beispiele im Forum z.b. hier --> https://forum.ipfire.org/viewtopic.php? ... vpn#p72389 oder --> https://forum.ipfire.org/viewtopic.php? ... vpn#p90279 bzw. gibt es auch ein Wiki zum erstellen vom SNAT beim VPN --> http://wiki.ipfire.org/en/optimization/ ... ad_warrior .

UE

Ja das habe ich auch gefunden, doch passt es bei mir halt nicht, da es N2N zwischen IPFires beschreibt. Ggf. müssen bei mir wohl die iptables her, doch dann wird es in Bezug auf meine Kenntnisse lustig. Habe mich ja heute schon ausgesperrt und musste dann die Regeln via Konsole löschen .

https://www.insys-icom.com/bausteine.ne ... 1.pdf?fd=2
Seite 14 beschreibt das Szenario. Der DNAT Eintrag folgte aufgrund der Anweisung im pdf. Nur das ich halt keine insys Router einsetzen möchte (da ich mind. 3 OpenVPN Client Verbindnungen benötige) und somit auf die IPFire Duo Box setzen würde. Eine läuft ja bis jetzt top. Es ist nur noch dieses Netmapping Problem zu lösen und dann kann es in größerem Stil losgehen.

[ummeegge]

Hi,

Ja genau das ist der Fall. Daher habe ich das Netz (den Tunnel -> virtuelles Netz) in der GUI nicht zur Auswahl.

wo ist dann dein Einstiegspunkt (config) ? Bzw. woher soll der Fire die Routen wissen und wie de- und encrypted er ?

Oder anders gefragt, stellst du einen OpenVPN Client (wenn ja wie konfiguriert ) oder einen Server auf dem Fire ?

Als Nebeninfo, wenn du viele unterschiedliche OpenVPN Subnets (eigenes Transfernetz, eigene konfigs, eigenes firewalling, oder SNAT) brauchst dann erstell dir doch Gruppen über den "Static IP address pools" Bereich --> http://wiki.ipfire.org/en/configuration ... /static_ip ...

UE

[BeFore]

Hi,

Ja genau das ist der Fall. Daher habe ich das Netz (den Tunnel -> virtuelles Netz) in der GUI nicht zur Auswahl.

wo ist dann dein Einstiegspunkt (config) ? Bzw. woher soll der Fire die Routen wissen und wie de- und encrypted er ?

Oder anders gefragt, stellst du einen OpenVPN Client (wenn ja wie konfiguriert ) oder einen Server auf dem Fire ?
UE

Der Server ist der insys connectivity Dienstleister. D.h. man bekommt pro Gerät eine OpenVPN Config. Die IPFires sollen also alle als CLient laifen. Aktuell ist es auch so, dass mit der einfachen Config die gesamten Netze des IPFire Netzwerkes erreichbar sind. Woher das ganze Routing dafür herkommt kann ich nur spekulieren, dass es der Server beim Aufbau scheinbar vorgibt, denn in der Config steht nix:

Code: Select all

client

dev tun10
proto udp

remote 1100.ics-vpn.de 2253
resolv-retry infinite

nobind

cipher BF-CBC
comp-lzo

remote-cert-tls server

persist-key
persist-tun
ping 30
ping-restart 60
max-routes 300

verb 3

<ca>
...
</ca>

<cert>
...
</cert>

<key>
...
</key>

Tue Nov 8 09:22:17 2016 /sbin/ip route add 198.18.0.0/16 via 198.18.0.122
Tue Nov 8 09:22:17 2016 /sbin/ip route add 198.18.0.1/32 via 198.18.0.122
Tue Nov 8 09:22:17 2016 /sbin/ip route add 10.10.10.0/24 via 198.18.0.122
Tue Nov 8 09:22:17 2016 /sbin/ip route add 10.11.12.13/32 via 198.18.0.122

Laut Konsolenausgabe werden nur diese Routen erstellt, wobei (da es ein Testsystem ist) das 10.10.10.0/24 das Netz auf WAN-Seite ist.

Wenn ich nur eine SNAT Regel erstellen zu dem virtuellen Netz erstellen (im insys als solches definiert) komme ich nicht mehr aus dem Intranet heraus und von extern auch nicht auf das Netz.

Ich habe jetzt auch mal folgende Regel versucht:

Code: Select all

iptables -t nat -A CUSTOMFORWARD -s tun10 -d 192.168.205.0/24 -j SNAT --to-source 192.168.178.0/24

Hab das virtuelle Netz mal auf 192.168.205/24 geändert damit es am Anfang einfacher ist.
tun10 ist das OVPN Netz. Selbst wenn der Tunnel aufgebaut ist kommt bei der Regel die Meldung, das tun10 nicht existiert .

[ummeegge]

Hallo BeFore,

Der Server ist der insys connectivity Dienstleister. D.h. man bekommt pro Gerät eine OpenVPN Config. Die IPFires sollen also alle als CLient laifen.

OK ich denke das wird dann schnell umfangreich da IPfire offiziel keinen Client Mode für's OpenVPN unterstützt d.h. du musst alles zu Fuss machen. Es gibt ein Wiki Artikel der beschreibt wie IPFire als OpenVPN Client an ein Firmennetzwerk angeschlossen werden kann --> http://wiki.ipfire.org/en/configuration ... ns/addconf allerdings war es das für dein Szenario noch nicht.
Nach dem INSYS Doc brauchts ja noch virtuelle IPs bzw. Aliases, IPfire biete hierfür zwar eine WUI an, welches allerdings nur WAN seitig Verwendung findet --> http://wiki.ipfire.org/en/configuration/network/aliases. Du müsstest sogesehen mittels iproute2 oder ifconfig dir ein Alias ( z.b. --> http://www.cyberciti.biz/faq/linux-crea ... -card-nic/ ) erstellen (und das persistent), hierfür benötigst du dann die entsprechenden IPTables Regeln (am besten in der firewall.local mit CUSTOM* Chains). Hier --> http://www.linuxquestions.org/questions ... ip-364084/ findet sich was in deine Richtung gehen könnte, auch der Hinweis das du das virtuelle Interface nicht mittels "-i" oder "-o" ansprichst sondern über die IP gehst sollte da wichtig sein. Das PREROUTING, FORWARD und dann auch das POSTROUTING wird kurz angesprochen und lässt sich vielleicht auf dein Szenario abstrahieren.

Das ist wohl alles ein längerer Weg...

Aktuell ist es auch so, dass mit der einfachen Config die gesamten Netze des IPFire Netzwerkes erreichbar sind. Woher das ganze Routing dafür herkommt kann ich nur spekulieren, dass es der Server beim Aufbau scheinbar vorgibt, denn in der Config steht nix:

Ja die Routen werden vom Server gepusht, da siehst du nichts in der Client Konfig von.

Ich habe jetzt auch mal folgende Regel versucht:

Code: Select all

iptables -t nat -A CUSTOMFORWARD -s tun10 -d 192.168.205.0/24 -j SNAT --to-source 192.168.178.0/24

Hab das virtuelle Netz mal auf 192.168.205/24 geändert damit es am Anfang einfacher ist.
tun10 ist das OVPN Netz. Selbst wenn der Tunnel aufgebaut ist kommt bei der Regel die Meldung, das tun10 nicht existiert .

Wie oben kurz erläutert wird das wohl alles umfangreicher und auf diesem Weg wohl nicht machbar, aber als Nebeninfo aber für die Regel: "-s" erwartet eine IP oder IP/Range, da kannst du kein Interface (was das tun ist) eintragen.

Was mir noch aufgefallen ist, dein Dienstleister verwendet einen Blowfish Cipher

Code: Select all

cipher BF-CBC

was ein 64 Bit Block Cipher ist, diese sind anfällig für Sweet32: Birthday attacks --> https://sweet32.info/ .

UE

[BeFore]

Hallo UE,

soetwas wollte ich aber nicht hören... eher wie es ist mit 2 Schritten getan und funktioniert ...

Hallo BeFore,

Der Server ist der insys connectivity Dienstleister. D.h. man bekommt pro Gerät eine OpenVPN Config. Die IPFires sollen also alle als CLient laifen.

OK ich denke das wird dann schnell umfangreich da IPfire offiziel keinen Client Mode für's OpenVPN unterstützt d.h. du musst alles zu Fuss machen. Es gibt ein Wiki Artikel der beschreibt wie IPFire als OpenVPN Client an ein Firmennetzwerk angeschlossen werden kann --> http://wiki.ipfire.org/en/configuration ... ns/addconf allerdings war es das für dein Szenario noch nicht.

Genau das habe ich befolgt und der Tunnel läuft problemlos (ohne Netmapping).

Nach dem INSYS Doc brauchts ja noch virtuelle IPs bzw. Aliases, IPfire biete hierfür zwar eine WUI an, welches allerdings nur WAN seitig Verwendung findet --> http://wiki.ipfire.org/en/configuration/network/aliases. Du müsstest sogesehen mittels iproute2 oder ifconfig dir ein Alias ( z.b. --> http://www.cyberciti.biz/faq/linux-crea ... -card-nic/ ) erstellen (und das persistent),

Heißt das nun, dass ich für WAN (ethX.X) oder den Tunnel (tun10.X) ein alias erstellen muss? Von der Logik her würde ich für den Tunnel eines erstellen.
Und das alias ist dann das virtuelle Netzwerk (in meinem Fall 192.168.205.0/24)?

hierfür benötigst du dann die entsprechenden IPTables Regeln (am besten in der firewall.local mit CUSTOM* Chains). Hier --> http://www.linuxquestions.org/questions ... ip-364084/ findet sich was in deine Richtung gehen könnte, auch der Hinweis das du das virtuelle Interface nicht mittels "-i" oder "-o" ansprichst sondern über die IP gehst sollte da wichtig sein. Das PREROUTING, FORWARD und dann auch das POSTROUTING wird kurz angesprochen und lässt sich vielleicht auf dein Szenario abstrahieren.

Von welcher IP sprichst du? Die IP, die ich vom VPN habe, oder eine Andere?
Wenn ich doch ein Netz auf das andere mappen möchte muss ich dann nicht für eingehende Verbindungen über den Tunnel ein FORWARD im Sinne von 192.168.205.0/24 alle Ports+Protokolle zu 192.168.178.0/24 setzen und das wars?
Für ausgehende Verbindungen häng ich auf dem Schlauch, wie das gehen soll.

Was mir noch aufgefallen ist, dein Dienstleister verwendet einen Blowfish Cipher

Code: Select all

cipher BF-CBC

was ein 64 Bit Block Cipher ist, diese sind anfällig für Sweet32: Birthday attacks --> https://sweet32.info/ .
UE

Als Crack in dem Bereich teile ich denen das gleich mit . Ich werde sie mal darauf hinweisen. Danke.

[ummeegge]

Juten Abend ,

Genau das habe ich befolgt und der Tunnel läuft problemlos (ohne Netmapping).

das ist doch schonmal gut... Jetzt brauchts nur noch das Netmapping ? Wenn ja dann noch besser.

Ich bin da nämlich noch wegen einer anderen Sache fündig geworden, vielleicht können wir die Tafel bez. Aliases nochmal sauber wischen und es anders probieren...

Also es gibt eine IPTables Erweiterung für das Target "NETMAP" --> https://www.netfilter.org/documentation ... html#ss4.4 (wusst ich selber auch noch nicht) mit dem ein Bidirectional full-cone NAT (bleah) geht. Hier findest du mal ein nettes Beispiel zu --> http://backreference.org/2012/03/20/bid ... nat-bleah/ . OpenVPN biete ebenfalls einen [ironie an]wahsninnsumfangreichen Artikel[/ironie aus] hier zu an --> https://openvpn.net/index.php/open-sour ... range.html .

Ich hab mal auf die Schnelle Testregeln auf dem Fire ausprobiert um zu schauen ob er sie anmeckert bzw. überhaupt übernimmt und das sieht ganz gut aus:

Code: Select all

-> iptables -t nat -n -vL CUSTOMPREROUTING && iptables -t nat -n -vL CUSTOMPOSTROUTING
Chain CUSTOMPREROUTING (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 NETMAP     all  --  tun0   *       192.168.90.0/24      192.168.123.0/24    192.168.77.0/27
Chain CUSTOMPOSTROUTING (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 NETMAP     all  --  tun0   *       192.168.77.0/27      192.168.90.0/24     192.168.123.0/24
    0     0 NETMAP     all  --  *      tun0    192.168.77.0/27      192.168.90.0/24     192.168.123.0/24

bitte mal auf Funktionalität prüfen.

Grüsse,

UE

[BeFore]

Hallo UE,

ich habe den Hersteller kontaktiert und diese wollen mir die notwendigen Routing rules schicken. Ein notwendiges Alias wurde mir verneint.

Ich denke mal diese werden so ausschauen wie deinem, nur hast du 3 Netze . Welches ist denn bei dir als loakes und virtuelles Netz gemeint und was stellt das 3. dar?

Vielen Dank und Grüße B4

[ummeegge]

Ich denke mal diese werden so ausschauen wie deinem, nur hast du 3 Netze

bei einem IP Konflikt (beide Seiten sind in der selben Range) wird der lokale Bereich 1:1 auf eine freie Range (fake range, hin- und zurück)) umgeschrieben <--> 2 unterschiedliche Standorte mit dem gleichen Subnetz + eine fake range = 3 . Da in den Regeln die PREROUTING und die POSTROUTING Chain vorhanden sind, ist das eine Art DNAT incl. SNAT aber halt mit einer gefakten range dazwischen <-- ich denke das ist die Eingangsfrage bzw. Bestandteil von Seite 14 von dem Doc. von INSYS...
Das Interface für den Tunnel gibst du in deinem Fall mit "tun10" an (gegebenenfalls variabel mit unterschiedlichen devices in den client configs).

Die bildliche Beschreibung hier --> http://backreference.org/2012/03/20/bid ... nat-bleah/ <-- zweites Bild, beschreibt ganz gut wie es gemeint ist, einwenig weiter unten wird auf die Syntax der Regel incl. Routing eingegangen... bitte mal durchlesen wie event. auch noch das firewall.local Wiki --> http://wiki.ipfire.org/en/configuration ... wall.local sofern nicht schon bekannt.

Grüsse,

UE

EDIT: Gibts vom Anbieter einen anderen Cipher ?

[BeFore]

Hast du an deinen Regeln noch mal was geändert? Jetzt sind es schon 3 und die verstehe ich jetzt noch weniger.
Wenn bei der 1. tun0 "in" ist, ist wohl mit source das virtuelle netz gemeint und destination folglich das lokale Netz. Das mit dem "fake" habe ich leider weiterhin nicht verstanden, sodass ich denke, dass das "fake" Netz und somit Regel 2 nicht notwendig sind, da sie doch nirgend hin führen!?! Das Bild auf Seite 14 habe ich so verstanden, dass es nur veranschaulichen soll, wie es zwischen dem Server und den virtuellen Netzen zu unterschiedlichen Standorten/Clients funktioniert.

So ich schreibe mal weiter, was ich so denke...
Wenn ich mir nun gerade Regel 3 anschaue, glaube ich doch zu verstehen, wieso wir das fake Netz benötigen, denn wenn ich hier wieder das lokale Netz nehmen würde, haue ich mir jegliche lokale Kommunikation im Falle eines Tunnelfehler kaputt (das habe ich ja schon hinter mir). Für genau diesen Fehler hatte ich noch keine Lösung gefunden. Das könnte es also lösen.

Ich muss mir mal in einer ruhigen Minute die Dokus durchlesen. Dann werde ich mehr wissen. Und dann probier ich es noch mal. Danke dir schonmal.

EDIT: Gibts vom Anbieter einen anderen Cipher ?

Ich bin da aktuell noch diplomatisch rangegangen und habe es erst einmal nicht erwähnt, denn sonst könnte es so wirken:

"... der hat schon keine Ahnung vom Tuten und Blasen und motzt dann noch auf wie <unser System sei unsicher...>"

Wenn es läuft werde ich es ansprechen .