[Frage] Client->LAN / LAN->LAN gesamten Verkehr durch VPN Tunnel

[brauchehilfe]

Hallo zusammen,

wahrscheinlich bin ich nur blind oder unfähig die Lösung zu finden, deshalb hier nun die Frage: Was muss ich in der Box und/oder der CFG Datei eintragen/einstellen damit bei einer Client->LAN und/oder LAN->LAN VPN Verbindung der gesamten traffic von der einen Seite Box B (4020) zur Anderen Box A (7490) durch den Tunnel geht?

Ziel ist, das Box B (4020) ein Netzwerk zur Verfügung stellt, bei dem jeglicher traffic, insbesondere auch jegliche WEB Anfragen, über den ISP der Box A gehen.

Folgendes Szenario habe ich am laufen:

FritzBox A (7490) 192.168.85.0 -> hängt direkt an einem VDSL der Telekom
Fritzbox B (4020) 192.168.185.0 -> hängt hinter einem Router ISP unbekannt

VPN Verbindungsversuche Client (4020)->LAN (7490) und LAN->LAN, sowohl über die FB Web-Oberfläche wie auch über eine CFG Datei konfiguriert, funktionieren. Sprich wenn ich von Box B (4020) ein Ziel an Box A (7490) anspreche, erreiche ich dies problemlos. Nur wenn ich jetzt vom Netz der Box B (4020) z.B. die Seite www.ard.de aufrufe, nutzt die Box nicht den Tunnel sondern geht den direkten Weg!

Bei diversen Clients gibt es für solche Fälle ja oft einen Parameter, den ich hier aber vergebens suche.

Danke schon mal für Eure Hilfe und sorry wenn es das Thema schon 100 mal gibt und ich es nur nicht finde.

 

[PeterPawn]

http://www.ip-phone-forum.de/showthread.php?t=278178

 

[brauchehilfe]

Ehrlich gesagt komme ich mit dem genannten Thread nicht wirklich zurecht.

 

[PeterPawn]

Ok ... und nun? Vielleicht hilft es ja, wenn Du mal schreibst, was Du verstanden hast und was nicht ... alles noch einmal von vorne aufzudröseln, ist sicherlich nicht Sinn der Sache, deshalb nur kurz als Abriß:

Die FRITZ!Box kriegt es ohne Modifikation nicht hin, allen Verkehr durch ein anderes System als ihr eigenes Standardgateway zu routen. Wenigstens die fertig gekapselten IPSec-Pakete müssen ja wieder über die richtige Verbindung gehen und da ist bei der FRITZ!Box dann Ende Gelände, da der IPSec-Verkehr auf demselben Interface landet, wie der "normale" Verkehr.

Wenn es nur um bestimmte Routen ginge, ließe sich das über entsprechende Einstellungen der IPSec-Selektoren oder tatsächlich über ein Szenario, wo die eine FRITZ!Box per Transport-Mode an der anderen per VPN angemeldet ist, realisieren (die "Server-FRITZ!Box" ist dann praktisch das "Firmennetzwerk" im GUI-Editor für VPN-Verbindungen). Aber das kann dann immer noch nicht allen Verkehr durch den Tunnel leiten ...

Also bleibt noch die Möglichkeit, die Fähigkeit der FRITZ!Box, einen oder mehrere LAN-Ports gezielt in ein eigenes Netz zu stecken, dafür zu benutzen. Damit arbeiten alle anderen an dieser FRITZ!Box angemeldeten Clients ganz normal mit deren Internetzugang (wenn man das nicht will, darf man eben keine Clients zulassen) und die an den reservierten Ports angeschlossenen Geräte (da kann ja auch wieder ein WLAN-AP drangehangen werden) senden alle Daten über den Tunnel.

Was davon ist jetzt am Ende unklar?

 

[brauchehilfe]

Okay - eines ist klar, ich stoße hier an die Grenzen mit meinen rudimentären VPN-Kentnissen !

Ich habe natürlich keine Ahnung wie das technisch gemacht wird, aber wenn ich auf einem PC Mac o. Win einen VPN-Client installiere, kann ich da teilweise angeben ob der gesamte traffic oder nur gewisse Teile davon durch den Tunnel sollen. Auch der PC bzw. seine physikalische Netzwerkschnittstelle hat ja weiterhin ein Default Gateway welches er vom DHCP bekommt, trotzdem geht alles durch den Tunnel. Ähnlich stelle ich mir das auch bei einer Fritzbox vor die ich als VPN-Client konfiguriere.

Unklar im Zusammenhang mit dem genannten Thread ist mir die fehlende Info wie ich die gesamte Box und nicht nur einen Port davon dazu bringe allen Verkehr per VPN Nachhause zu schicken. Meine FritzBox 4020 hängt mit Ihrem WAN-Port hinter einem Firmenrouter, besitzt an diesem eine lokale IP 192.168.27.10 und kann so, mangels öffentlicher IP, ja wohl nur als VPN-Client eine Tunnel Nachhause zur FritzBox 7490 aufbauen.

 

[PeterPawn]

Eine FRITZ!Box ist nun mal kein Windows-Programm und auch nicht primär ein VPN-Client. Während ein Windows-PC eben über sein Standard-Gateway mit dem Rest der Welt (außerhalb seiner Familie - dem LAN) kommuniziert, ist eine FRITZ!Box selbst dieses Gateway und von sich aus nicht in der Lage, den VPN-Verkehr über ein anderes Gateway zu routen. Das liegt eben daran, daß der VPN-Verkehr nur "ausgeleitet" wird, wenn er am Standardgateway bzw. dem Interface, das zum Standardgateway führt, "vorbeikommt", sprich: Jedes über das VPN zu routende Paket in einer FRITZ!Box muß an das Standardgateway "dev dsl" gehen, sonst wird da nichts gekapselt.

Und die gesamte Box kriegt man eben (jedenfalls nach meiner Kenntnis) nicht dazu, über einen VPN-Tunnel zu kommunizieren ... da braucht Dir also nichts unklar sein, es geht (ich bin ein vorsichtiger Mensch und schreibe "vermutlich") schlicht nicht.

Wenn Du das so realisieren möchtest, mußt Du entweder die FRITZ!Box um geeignete Software ergänzen (viele dieser Lösungen setzen auf OpenVPN, weil das eben für den Tunnel ein anderes Interface verwendet als das Standardgateway) oder eben den von Dir angeführten Windows-PC bei aktiviertem VPN-Client als Gateway benutzen.

Zwar ist die Box auch in der Lage, als IPSec-Client im Transport-Mode zu arbeiten (so machen das die von Dir erwähnten Clients in der Regel), aber eben nicht, dabei allen Verkehr über die VPN-Verbindung zu leiten. Wenn Du dafür eine sicher funktionierende Lösung mit den Bordmitteln des FRITZ!OS findest, laß es uns wissen.

Das Hauptproblem ist (nach meiner Ansicht, ich habe das aber auch nie probiert) das Aktivieren/Aktualisieren der "accesslist", mit der entschieden wird, welcher Traffic über IPSec abgewickelt werden soll und welcher nicht. Ob dort tatsächlich auch "Negativeinträge" mit "reject" berücksichtigt werden, die bei Vorhandensein einer Regel "permit ip any any" benötigt werden (diese Regel würde allen Verkehr aus dem LAN (any) an jede andere Adresse (any) über den Tunnel abwickeln), damit der Tunnel erst einmal aufgebaut werden kann (denn es kann ja vor dem Tunnelaufbau nicht ein einzelnes Paket, von der DNS-Abfrage für den DynDNS-Namen der 7490 bis zum ISAKMP mit der 7490, über den noch nicht aufgebauten Tunnel gehen), weiß ich aber auch nicht.

Du kannst es ja mal mit der erwähnten "accesslist" in der VPN-Konfiguration probieren, mit ein wenig Glück funktioniert das sogar, wenn AVM den IPSec-Verkehr nach der Verschlüsselung erst "hinter" der Auswahl des zu verschlüsselnden Traffics wieder in den IP-Stack "einspeist" und dieser damit die Auswertung der angeführten "accesslist" nicht erneut durchlaufen muß ... aber das Henne-Ei-Problem beim Aufbau des Tunnels besteht für mich weiterhin.

Ob bei der 4020 überhaupt die Modifikation mit Zusatzsoftware möglich ist, wissen wir aber auch noch nicht ... dazu hat sich m.W. noch keiner der neuen Eigentümer einer solchen Box geäußert.

 

[brauchehilfe]

Sehr viel Dank "PeterPawn" für Deine Hilfe, ausführlichen Erläuterungen und Mühe meine VPN Kenntnisse zu erweitern !

Ich werde das der Reihe nach mal versuchen und berichten bzw. bei Unverständnis meinerseits nochmal die eine oder Andere Frage Stellen. Temporär hab ich das im Moment ähnlich dem Thread bzw. wie hier: VPN-Verbindung zwischen zwei FRITZ!Boxen für einzelne LAN-Anschlüsse gelöst. Denn siehe da, auch der ISP-Router hinter dem ich die FB 4020 konfigurieren will, ist eine FritzBox 7490 und der Admin ist sehr kooperativ. Er hat mir einen Port seiner FB nach meinen Wünschen konfiguriert und zur Verfügung gestellt. Scheine Doch ein vertrauenswürdiger Mensch zu sein !?

 

[PeterPawn]

Bei der Gelegenheit muß ich dann AVM mal loben für den Support ... aus einer Konversation per E-Mail (es gingen tatsächlich mehrere Mails hin und her) zu den vorhandenen Unklarheiten in der Beschreibung auf dieser Seite (CID4154552) wurde offenbar eine weitere Seite abgeleitet, die sich mit dem Spezialfall der "Beschränkung des VPN auf bestimmte LAN-Anschlüsse" beschäftigt. Ich denke nicht, daß die vorher schon existierte, denn dann hätte der Support mich ja auch darauf verwiesen.

In jedem Falle bin ich positiv überrascht, daß sich aus einem Schriftwechsel mit dem AVM-Support in kurzer Zeit (das Ticket war vom 04.05., die letzte Mail dazu vom 08.05.) solche Konsequenzen ergeben. Das läßt mich dann doch wieder zu der Feststellung gelangen, daß der AVM-Support sehr gute Noten verdient, wenn man denn nur an den richtigen Mitarbeiter gerät bzw. das Ticket nicht irgendwo in der "Vorsortierung" mit einem Textbaustein beantwortet und abgeschlossen wird.

Insofern auch an @brauchehilfe mein Dank, denn die Seite bei AVM kannte ich auch noch nicht (das wäre das "Sahnehäubchen" gewesen, wenn da eine Mail von AVM mit dem Hinweis auf die neue Seite eingetrudelt wäre, als sie fertig war).

Letzte Bemerkung:

Er hat mir einen Port seiner FB nach meinen Wünschen konfiguriert und zur Verfügung gestellt. Scheine Doch ein vertrauenswürdiger Mensch zu sein !?

Ohne Deine Vertrauenswürdigkeit in Zweifel ziehen zu wollen, aber das ist eigentlich genau eine Lösung für weniger vertrauenswürdige Clients am eigenen Standort. Die Geräte an diesen Anschlüssen können eben gerade nicht mit den anderen Geräten an diesem Standort kommunizieren und auch der komplette sichtbare Internetverkehr wird ja über das entfernte Gateway abgewickelt, so daß selbst eine Anschlußermittlung bei Filesharing o.ä. immer erst einmal an dem anderen Anschluß endet.

 

[wolf.art]

Gehört vielleicht nicht hierhin, aber evtl. für einige doch interessant: Mit Hilfe der von PeterPawn verlinkten Seite http://http://avm.de/nc/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/1627_VPN-Verbindung-zwischen-zwei-FRITZ-Boxen-fuer-bestimmte-LAN-Anschluesse-einrichten/ habe ich nun endlich geschafft was ich schon lange vorhatte: Im Ausland (in diesem Falle Spanien) Netflix auf meinem WD-TV live nutzen. Und zwar ohne VPN oder IP-Maskerading Dienstleister, nur über den Zugang meiner in Deutschland stehenden FritzBox. VPN gemäß obiger Anleitung nur für LAN 4 der "ausländischen" FritzBox konfiguriert und an diesem Anschluss die WD-TV Live (es sollte auch mit AppleTV oder anderen Set-TopBoxen funktionieren) per LAN-Kabel angeschlossen. Netzwerk wird beim Neustart des WD-TV neu erkannt und nach einem weiteren Neustart der WD-TV denkt diese nun sie sei in Deutschland. Und damit funktioniert die Anmeldung bei Netflix, Maxdome etc. Ausreichende upload-Geschwindigkeit auf der "deutschen" Seite ist natürlich Voraussetzung, da dieser Stream (und nur dieser) Traffic natürlich über den VPN-Tunnel läuft. Das restliche Netzwerk an der FritzBox nutz aber weiterhin deren direkten Internetzugang. Möglicherweise ist diese Methode noch ausbaufähig, z.B. nur die Anmeldung (bei Netflix, o.A.) über diesen Tunnel zu machen und den Stream danach über die direkte Verbindung laufen zu lassen. Ich glaube ich habe dazu vor längerer Zeit mal was gelesen, weiß aber nicht ob das funktioniert hat. Das wäre was für Experten wie PeterPawn (der mir letztes Jahr schon dabei geholfen hat ein VPN mit einer Box hinter einem WLAN-Provider Router aufzubauen - läuft perfekt!) ... Für mich funktioniert es aber so auch schon. Werde demnächst noch probieren ob ich zusätzlich zum LAN 4 VPN auch noch ein normales mit der gleichen Gegenstelle aufbauen kann - über das normale VPN läuft meine Telefonie mit den Telekom All-IP Nr., die ich damit in Spanien benutzen kann (eine direkte Einrichtung von Telekom All-IP-Nr. funktioniert ja nicht mehr an fremden Anschlüssen)

 

[Igi2003]

Sehr guter Thread. Vielleicht gibt es für mein neues VPN Problem ebenfalls eine brauchbare Lösung, auf die ich bisher vielleicht noch nicht gestossen bin.
Vorab mal meine bisherige Konstellation:
FB 7570 am Hauptstandort mit Entertain. Die LAN Ports wurden mittels "ethmode: router_split" in drei IP Bereiche aufgeteilt. 192.168.170.X DHCP off da hier nur IP Telefone und ein weiterer Server im Netz sind. EtH0 und ETH1 und WLAN im selben Bereich. ETH2 war der Netzbereich hinter dem Server, da dieser für mich noch ein weiterer Router ins Netz 192.168.10.X ist, inc. DHCP mit registrierten MAC Adressen. ETH3 war komplett im 192.168.172.X mit DHCP Bereich für drei Entertain Receiver.
Am ETH2 hatte die Fritzbox die IP 192.168.10.150, die als Gateway für das VPN galt. VPN entferntes netz war 192.168.179.x und 192.168.9.x. An den beiden entfernten Netzen wurde sozusagen das 192.168.10.0 er Netzwerk angegeben. An meinem Server 192.168.10.1 wurden zwei feste IP Routen eingerichtet, und als Gateway die 192.168.10.150 angegeben.
Diese Konfiguration lief jetzt über 5 Jahre Problemlos.
Jetzt bekomme ich demnächst 100Mbit von der Telekom und habe mir am Wochenende eine 7490 dafür gekauft.
Mit bedauern musste ich feststellen das man so gar nicht mehr Telnet öffnen kann, und auch eine abgeänderte ar7.cfg mit NoChecks=Yes laden kann. In der 7570 habe ich die ar7.cfg manuell editiert um die Ports zu trennen.
In der neuen Netzwerkkonfig habe ich jetzt die 7490 als Hauptrouter mit der IP 192.168.170.10 (wie die 7570), der Server mit der EndIP 100 bleibt weiterhin mit der externen Netzwerkkarte, die IP Telefone bleiben weiterhin, nur die Entertain Receiver (evtl. neue) wechseln ebenfalls ins gleiche IP Netz.
Die beiden VPN Tunnels werden einwandfrei aufgebaut. Jetzt fehlt mir aber eine weitere IP der Fritzbox als Gateway. Ich habe LAN4 für das VPN reserviert und mit ins 192.168.10.x Netz verbunden. Die Ping und Trace Packete kommen von den anderen beiden Seiten an, können aber nicht beantwortet werden, da es keine Gateway IP mehr gibt.
Mein switch hinter der Fritzbox ist ein VLAN Switch, durch den die drei Bereiche per VLAN getrennt sind. Das hat den Hintergrund, das während dem Fernsehen über Entertain, nicht das komplette Netzwerk mit Packeten geflutet wird. Lasse ich die LAN Schnittstelle für VPN weg, habe ich einen Loop auf dem Netzwerk, wodurch das ganze lahm wird.
Jetzt kommt die eigentliche Frage, ist es möglich in den VPN cfg Dateien der Fritzbox eine IP zuzuordnen? Wenn nein, dann werde ich wohl über Console wieder die ar7.cfg editieren müssen um ihr eine weitere IP zu verpassen und die Port manuell zu trennen. Dazu habe ich mich mal gestern eingelesen, das ich da ShellInBox benötige und Dual booten kann.
Meine letzten Freetz/DS-Mod kenntnisse sind schon ein paar Jahre her. ShellinBox und NAND basierende Boxen sind für mich neuland.

PS. Durch den Tunnel greife ich nur auf meinen Server zuhause zu, telefoniere über meinen noch ISDN Anschluss am zweiten Wohnsitz per IP zwischen den Boxen.
Vielleicht hat jemand noch eine Idee.

Thx Igi

 

[Igi2003]

Guten Abend,
mein zukünftiges Problem hat sich gelöst. Dank Shellinabox und modfs konnte Telnet mit der aktuellen 6.92er Firmware aktiviert werden und die Einstellungen direkt in der ar7.cfg editiert werden.
LAN Port 1 und 2 haben 192.168.170.x ohne DHCP, LAN 3 hat 192.168.10.150 ohne DHCP, ist gleichzeitig VPN Gateway und ist gebridged mit WLAN, LAN 4 hat die 192.168.172.1 mit DHCP und drei IPTV Clients. Somit funktioniert alles wieder wie mit der 7570, nur schneller und mit IP Telefonie und 5GHz WLAN.

Lg Igi

 

[Shirocco88]

Die LAN Ports wurden mittels "ethmode: router_split" in drei IP Bereiche aufgeteilt.

Könntest Du uns Bitte die von Dir getätigten Änderungen an der ar7.cfg mitteilen;
ich denke das wäre auch für nachfolgende Leser interessant.

 

[Igi2003]

Ja, ich kann euch mal den Ausschnitt der ar7.cfg original und geändert anfügen

Original:

ar7cfg {
        mode = dsldmode_router;
        active_provider = "tonline";
        active_name = "";
        igddenabled = no;
        wan_bridge_with_dhcpc = yes;
        wan_bridge_gateway = 0.0.0.0;
        dhcpc_use_static_dns = no;
        dhcp_dslforumorg = no;
        ethmode = ethmode_bridge;
        tcom_targetarch = yes;
        vdsl_resalearch = no;
        aontv_arch = no;
        bng_arch = yes;
        hsi_use_wan_vlan = yes;
        hsi_vlancfg {
                vlanencap = vlanencap_none;
                tagtype = vlantagtype_customer;
                vlanid = 0;
                vlanprio = 0;
                tos = 0;
        }
        mtu_cutback_mode = mtumode_auto;
        mtu_cutback = 1500;
        StatisticStartOfMonth = 1;
        enable_mac_override = yes;
        macdsl_override = 00:00:00:00:00:00;
        ipv6mode = ipv6_automatic;
        ipv4mode = ipv4_normal;
        serialcfg {
                mode = serialmode_off;
                number = "*99#";
                provider = "internet.t-mobile";
                username = "$$$$IZXUWR5FY3RCIHHZGSFXEMGSNS6EWVKHXRKDU4UOMUJHFJWYZARKIPVCTB5AU65E5FNN4BB4JTQPGAAA";
                passwd = "$$$$OL3UU44EWNQYWFY41GZBPB4UZHXSBTY3X15DKBJ1VFFL2KS4EDBL5PRJUJV5EPUF4XBWQ4UPP5L4SAAA";
                connect_chatscript = "ABORT BUSY ABORT 'NO CARRIER'",
                                     "ABORT VOICE ABORT 'NO DAILTONE'",
                                     "ABORT 'NO ANSWER' ABORT DELAYED",
                                     "ABORT ERROR", "TIMEOUT 20",
                                     "'' 'AT+cgdcont=1,\\"IP\\",\\"${provider}\\"'",
                                     "OK 'ATDT${number}'", "CONNECT",
                                     "WAIT 2";
                stay_always_online = no;
                inactivity_timeout = 1m;
                backup {
                        enabled = no;
                        quickstart = serialquickstart_off;
                        downtime = 3m;
                        reverttime = 30m;
                }
        }
        ethinterfaces {
                name = "eth0";
                dhcp = no;
                ipaddr = 192.168.170.10;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 192.168.170.110;
                dhcpend = 192.168.170.120;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "eth0:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "wlan";
                dhcp = no;
                ipaddr = 192.168.182.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        brinterfaces {
                name = "lan";
                dhcp = no;
                ipaddr = 192.168.170.10;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0", "eth1", "eth2", "eth3", "wlan", "plc";
                dhcpenabled = yes;
                dhcpstart = 192.168.170.110;
                dhcpend = 192.168.170.120;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "lan:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "guest";
                dhcp = no;
                ipaddr = 192.168.181.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "wlan_guest", "guest_ct*", "guest_st*";
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = yes;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        dslinterface {
                name = "dsl";
                dhcp = no;
                ipaddr = 0.0.0.0;
                netmask = 0.0.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        dslinterface_metric = 2;
        routes {
                enabled = yes;
                ipaddr = 192.168.10.0;
                mask = 255.255.255.0;
                gateway = 192.168.170.100;
                metric = 0;
                dev = "";
        }
        ipbridge {
                enabled = no;
        }
        ipsecbridge {
                enabled = no;
        }
        pppoefw {
                interfaces = "lan", "usbrndis", "eth0", "eth1", "eth2",
                             "eth3", "wlan";
                nofirewall = yes;
                dnsfilter_for_active_directory = yes;

und geändert:

ar7cfg {
        mode = dsldmode_router;
        active_provider = "tonline";
        active_name = "";
        igddenabled = no;
        wan_bridge_with_dhcpc = yes;
        wan_bridge_gateway = 0.0.0.0;
        dhcpc_use_static_dns = no;
        dhcp_dslforumorg = no;
        ethmode = ethmode_router_split;
        tcom_targetarch = yes;
        vdsl_resalearch = no;
        aontv_arch = no;
        bng_arch = yes;
        hsi_use_wan_vlan = yes;
        hsi_vlancfg {
                vlanencap = vlanencap_none;
                tagtype = vlantagtype_customer;
                vlanid = 0;
                vlanprio = 0;
                tos = 0;
        }
        mtu_cutback_mode = mtumode_auto;
        mtu_cutback = 1500;
        StatisticStartOfMonth = 1;
        enable_mac_override = yes;
        macdsl_override = 00:00:00:00:00:00;
        ipv6mode = ipv6_automatic;
        ipv4mode = ipv4_normal;
        serialcfg {
                mode = serialmode_off;
                number = "*99#";
                provider = "internet.t-mobile";
                username = "$$$$K33QYE4TSC6ZBFYE2ZK5FZHLDENAW3Y6IPFZ3TZVRLGWVCBCBGLBHDKU5MSXSZ2NLPIVNMASVKFKI4XL";
                passwd = "$$$$IS2D4GZZLSWSTXZ4CVRT3EMMIXZFG51QT2IPVMHCVYXYN65Y2ADJNGXVJ45CZDAJSRWX6IBFH5Z614XL";
                connect_chatscript = "ABORT BUSY ABORT 'NO CARRIER'",
                                     "ABORT VOICE ABORT 'NO DAILTONE'",
                                     "ABORT 'NO ANSWER' ABORT DELAYED",
                                     "ABORT ERROR", "TIMEOUT 20",
                                     "'' 'AT+cgdcont=1,\"IP\",\"${provider}\"'",
                                     "OK 'ATDT${number}'", "CONNECT",
                                     "WAIT 2";
                stay_always_online = no;
                inactivity_timeout = 1m;
                backup {
                        enabled = no;
                        quickstart = serialquickstart_off;
                        downtime = 3m;
                        reverttime = 30m;
                }
        }
        ethinterfaces {
                name = "eth0";
                dhcp = no;
                ipaddr = 192.168.10.150;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "eth0:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "eth3";
                dhcp = no;
                ipaddr = 192.168.172.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 192.168.172.2;
                dhcpend = 192.168.172.4;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "wlan";
                dhcp = no;
                ipaddr = 192.168.182.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        brinterfaces {
                name = "lan2";
                dhcp = no;
                ipaddr = 192.168.170.10;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0", "eth1";
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "lan:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {     
                name = "lan";
                dhcp = no;
                ipaddr = 192.168.10.150;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth2", "wlan", "plc";
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {     
                name = "iptv";
                dhcp = no;
                ipaddr = 192.168.172.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth3";
                dhcpenabled = yes;
                dhcpstart = 192.168.172.2;
                dhcpend = 192.168.172.4;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        } {
                name = "guest";
                dhcp = no;
                ipaddr = 172.31.181.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "wlan_guest", "guest_ct*", "guest_st*";
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = yes;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        dslinterface {
                name = "dsl";
                dhcp = no;
                ipaddr = 0.0.0.0;
                netmask = 0.0.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                is_guest = no;
                is_hotspot = no;
                multicast_snooping = yes;
                is_public = no;
        }
        dslinterface_metric = 2;
        routes {
                enabled = yes;
                ipaddr = 192.168.10.0;
                mask = 255.255.255.0;
                gateway = 192.168.170.100;
                metric = 0;
                dev = "";
        }
        ipbridge {
                enabled = no;
        }
        pppoefw {
                interfaces = "lan2", "usbrndis", "eth0", "eth1",
                             "eth2", "eth3", "iptv", "wlan", "lan";
                nofirewall = yes;
                dnsfilter_for_active_directory = yes;

Unter brinterfaces sind die Gruppen zusammegefügt, die im selben Netzbereich liegen.
ethmode_router_split versetzt den switch Baustein in einzelmode.
Wichtig ist bei pppoefw .... interfaces die Reihenfolge. Bei mir ist zuletzt "lan" da sich "wlan" mit in der gruppe befindet. Bei alten Boxen war dies egal, bei neueren gab es keine kommunikation über WLAN. Dies lag daran, das die Gruppen gebildet wurden, bevor die ath0 und ath1 Schnittstelle physikalisch gestartet wurden. Deshalb habe ich "wlan" als vorletztes gesetzt und "lan" als letztes Bridgeinterface das gebildet wird.
Oben bei "ethinterfaces" und "brinterfaces" sollte soweit jedem klar sein wie die sich zusammensetzen.
Als Editor habe ich Notepad++ benutzt. Bloß keinen normalen Editor nehmen. Der Editor muss utf-8 beherrschen.

Die ar7.cfg habe ich per Telnet ins NAS kopiert, dann auf den Rechner, bearbeitet, wieder zurück in den NAS geladen und per Telnet wieder in /var/flash kopiert. Dabei ist zu beachten, das direkt nach dem cp Befehl innerhalb einer Sekunde der Stromstecker der Box gezogen wird. Die Box vergleicht wohl eine im RAM befindliche ar7.cfg mit der im flash, ändert man diese im flash, wird sie wieder durch die originale ersetzt.Dies umgehe ich mit ziehen des Stromsteckers eine sekunde nach dem kopiervorgang.

Falls noch Fragen sind, jederzeit melden.

Mfg Igi

 

[PeterPawn]

Bis auf die beschriebene Prozedur mit dem Steckerziehen ist das nachvollziehbar ... anstelle dieser sehr rabiaten Methode kann man auch einfach den "ctlmgr" beenden (mit "ctlmgr -s") und dann die geänderte "ar7.cfg" in den Flash kopieren. Anschließend kann man auch den "ctlmgr" wieder starten (einfach mit "ctlmgr") und der liest dann die gerade geänderte "ar7.cfg" auch ein. Allerdings wird vielleicht nicht in jedem Falle die Änderung an den Interfaces sofort umgesetzt (dafür braucht es den Neustart des "dsld", aber den könnte man auch über "rc.net" auslösen), wie man u.a. im AVM-GUI bei den VPN-Verbindungen nachlesen kann, wenn man einen Port zur IPSec-Bridge erklären will (oder das rückgängig macht) ... das ist auch erst nach einem Neustart wirksam.

Wobei das Kopieren mit "cp" für einen TFFS-Node auch nicht so ganz logisch klingt ... da "cp" normalerweise blockorientiert arbeitet, funktioniert genau das eigentlich nicht und man nimmt besser ein anderes Kommando (z.B. "cat").

 

[Igi2003]

Ja, die Methode mit dem "ctlmgr" ist mir bekannt. Die rabiate Methode ist nur schneller ;-).
Was das kopieren angeht, hatte es bisher immer so genutzt, muss ich mir mal angewöhnen. Ich hatte mich schon damit angefreundet das WLAN bei der 7490 ausgeschaltet zu lassen und stattdessen die 7390 als AP zu nutzen, da ich dies schon vor ca. zwei Jahren mit der 7390 probiert hatte und am WLAN Problem gescheitert bin. Bei dieser kam sogar Authentifizierungsfehler am AP. Mit der 7490 wurde die WLAN Verbindung zumindest aufgebaut und eine gültige IP per DHCP wurde vergeben. Die gab mir schonmal den Anstoß weiter zu suchen und zu probieren. Darauf bin ich aber nur zufällig gestoßen, als ich eine statische Route in der Oberfläche entfernt habe und dabei den "multid" beobachtet habe.
Ob das ganze auch Live am Anschluss so funktioniert, werde ich heute Abend mal testen, da ich mich gerade am Zweitwohnsitz befinde und ich dies hier nur etwas simulieren konnte.

Lg Igi

 

[Shirocco88]

LAN Port 1 und 2 haben 192.168.170.x ohne DHCP, LAN 3 hat 192.168.10.150 ohne DHCP, ist gleichzeitig VPN Gateway und ist gebridged mit WLAN, LAN 4 hat die 192.168.172.1 mit DHCP und drei IPTV Clients.

Habe auch eine Blick auf die ar7.cfg geworfen;
Kann es sein, dass hier eine statische Route schon in der orginal ar7.cfg definiert ist ?

        routes {
                enabled = yes;
                ipaddr = 192.168.10.0;
                mask = 255.255.255.0;
                gateway = 192.168.170.100;
                metric = 0;
                dev = "";
        }

weitere Fragen:
Kann man dies auch per Web-IF (ggf. LUA-Skript oder CLI) statt hand-made per Notepad++ konfigurieren ? z.B. vpn ipsecbrX-Config ?

Wie sieht das Routing aus (gerne "netstat -rn" output beifügen) ?
ich gehe davon aus, dass IP-Forwarding zwischen den VLANs aktiv ist und auch die Defaultroute über DSL-Device implizit mit NATTING genutzt werden kann.

VPN:
ist das alles bzgl. vpn.cfg transparent ? d.h. man trägt statt dem Netz "192.168.170.0/24" einfach das Netz "192.168.10.0/24" in die vpn.cfg ein ?

Ist diese Configuration persistent gegenüber Reboot ?

Muß mann bei Administration per Web-IF aufpassen ? gibt es da Menüs, die diese Config wieder "wegrationalisieren" ?

Der Editor muss utf-8 beherrschen.

sind da Umlaute in ar7.cfg zu erwarten ?

 

[Igi2003]

Hallo,
Nein, die statische Route war von mir gesetzt worden, zum Glück. Denn beim entfernen stieß ich auf den Fehler bei WLAN Clienten.

IP-Forwarding ist gesetzt, sodas man in das andere Netz pingen kann und auch auf die normalen Inhalte zugreifen kann. SMB Freigaben, NetBIOS etc. gehen natürlich nicht. Allerdings ist deine Aussage mit VLANs falsch. Es sind keine VLANs eingerichtet. Oben erwähnte ich VLAN, da ich einen VLAN Switch habe und diese Netze alle über den einen Switch (24-Port Cisco) laufen, diese aber im Switch per VLAN Konfiguration getrennt gehalten werden. Wenn ich z.B. den Switch neu starte und alle Ports aktiv sind ohne das er die VLAN Konfig gestartet hat, dann habe ich für wenige Sekunden einen Megaloop auf dem Netzwerk.

Be VPN, ja, einfach das Netz eintragen. Da ich aber einen anderen Server im Netz habe, der die Clients managed und nicht die Fritzbox, muss auch im diesen Gateway eine statische Route eingetragen werden. Deshalb benötige ich eine zusätliche IP im 192.168.10.X Netz

Die Einstellungen sind beim reboot persistent. Die alte Box hatte den Eintrag "ethmode_router_split" wieder ersetzt, wenn sie etwas in der ar7.cfg gemacht hat. Bei der 7490 blieb während der Simulation alles erhalten, auch ethmode_router_split. Werde ich aber mal Live testen wenn der Anschluss umgestellt ist und die finale Konfiguration fertig ist.

In der ar7.cfg sind eigentlich keine Umlaute zu erwarten,

Lg Igi

 

[Shirocco88]

Bei VPN, ja, einfach das Netz eintragen. Da ich aber einen anderen Server im Netz habe, der die Clients managed und nicht die Fritzbox, muss auch im diesen Gateway eine statische Route eingetragen werden. Deshalb benötige ich eine zusätliche IP im 192.168.10.X Netz

d.h. es gibt eine Möglichkeit (hand-made, un-supportet), die ergänzend zur offiziell supporteten "ipsecbrX-Methode" einen Port im remote Netz für VPN nutzen läßt, jedoch ohne die Einschränkung "Port-Isolation".

VPN-Verbindung zwischen zwei FRITZ!Boxen für einzelne LAN-Anschlüsse einrichten
Beim Einrichten einer VPN-Verbindung zwischen zwei FRITZ!Box-Netzwerken können Sie den VPN-Tunnel auch auf einzelne LAN-Anschlüsse der FRITZ!Boxen begrenzen. Über diese LAN-Anschlüsse ist dann nur noch der Zugriff auf das entfernte FRITZ!Box-Netzwerk möglich, nicht jedoch der Zugriff auf Geräte im lokalen FRITZ!Box-Netzwerk. Auch der Internetzugriff über die lokale FRITZ!Box ist an den ausgewählten LAN-Anschlüssen nicht mehr möglich.

Deshalb benötige ich eine zusätzliche IP im 192.168.10.X Netz

unklar wozu diese zusätzliche statische Route in der Fritzbox sein soll, wenn doch schon alle Routen zu den in brinterfaces definierten Subnetzen vorhanden sind.

 

[Igi2003]

d.h. es gibt eine Möglichkeit (hand-made, un-supportet), die ergänzend zur offiziell supporteten "ipsecbrX-Methode" einen Port im remote Netz für VPN nutzen läßt, jedoch ohne die Einschränkung "Port-Isolation".

Ja, sollte klappen, sogar ohne IP-Forwarding oder auch komplett abgeschirmt (was ja die Variante von Avm wäre)

unklar wozu diese zusätzliche statische Route in der Fritzbox sein soll, wenn doch schon alle Routen zu den in brinterfaces definierten Subnetzen vorhanden sind.

Da meine Clients von einem anderen Server als der Fritzbox gemanaged werden, benötige ich die statische Route zu den VPN Netzen. Der Server benötigt die Info über welchen Gateway er zu den entfernten Netzwerk kommunizieren muss, da die VPN Verbindung ja durch die Fritzboxen hergestellt wird und der Server damit nix am hut hat

 

[Shirocco88]

Ja, sollte klappen, sogar ohne IP-Forwarding oder auch komplett abgeschirmt (was ja die Variante von Avm wäre)

ich dachte da an folgende Thread https://www.ip-phone-forum.de/threa...-traffic-über-vpn-routen.297705/#post-2252799
und hier die Aufgabenstellung "Doppelnutzung", das sollte statt der ipsecbrX-Methode mit der hier vorgestellten Methode "ethmode_router_split mit brinterfaces" funktionieren, oder habe ich hier etwas falsch gelesen ?