2FB per VPN verbunden; Konfiguration DNS etc.

[drnicolas]

Mein Problem wurde wahrscheinlich schon hundertfach angesprochen und gelöst; ich finde die Lösung aber nicht. Oder habe nicht richtig gesucht.

Ich habe 2 FB per VPN miteinander verbunden. Man sihet den grünen Button, insofern denke ich ist alles okay.

"Master"-FB:
Ip-Adresse 192.168.1.2; kein DNS, kein DHCP aktiviert
im lokalen Netzwerk sind 2 DNS (192.168.1.3 undd .5) als Windows-Server und DHCP verfügbar.

"Slave"-FB:
IP 192.168.178.1; DNS und DHCP

Was muss ich tun, damit 2 Windows-Clients der Slave-FB gesehen werden und die anderen Clients/Server im Master-Netz finden?

Der externe internet-Verkehr der Slave-Box soll über die Slave-Box rausgehen und nicht etwa über den Anschluss der Master-FB.

Gibt's dazu ein best-practice oder so ?

 

[7390user1]

Für dein konkretes Ziel (das Erlauben/Routen der Subnetz-Zugriffe) schlage ich vor, dass du separat eine "VPN-Einstellungsdatei" erstellst, diese dann im VPN-Bereich der Server-Fritzbox importierst und dann auf der Client-Fritzbox eine VPN-Einwahl zur Server-Fritzbox mit den passenden Zugangsdaten aus der separaten "VPN-Einstellungsdatei" einrichtest (letzteres geht dann über die normalen Webseiten der Client-Fritzbox).

Der Inhalt der "VPN-Einstellungsdatei" ist dabei natürlich entscheidend ... . Letztenendes geht es um die permit Zeile im acceslist-Parameter.
Versuche es mal mit diesem Inhalt für die "VPN-Einstellungsdatei", die IP-/Netzwerk-Werte sind schon an deine oben genannte Konfiguration angepasst:

Hinweis: Du solltest (später) die Zugangsdaten für dich anpassen (in der Einstellungs-Datei und dann passend beim Einrichten der Client-Fritzbox). Hier im Beispiel verwendete Werte
username = "fritzbox.client192.168.1.200"; --> 2x in Client-FBox, bei "VPN-Benutzername(Key-ID)" UND "XAUTH-Benutzername"
passwd = "[email protected]192.168.1.200"; --> In Client-Fbox ins Feld "XAUTH-Kennwort"
key = "SehrGeheimesSharedSecret"; --> In Client-Fbox ins Feld "VPN-Kennwort (Preshared Key)"

/*
 * Einwahl-config als Kopiervorlage fuer eine "Server"-Fritzbox
 *
 * Folgende Netzwerk-Werte sollten sehr wahrscheinlich angepasst werden
 *   192.168.1.0    --> Das ist das Netz der "Server"-Fritzbox.
 *                       Steht einmal in der permit-Zeile bei accesslist
 *                       Ggf. mit Suchen+Ersetzen bei allen Suchtreffern anpassen.
 *
 *   192.168.1.200   --> Das ist die IP-Adresse, die der VPN-Client bekommt.
 *                       Sollte zum Netz der "Server"-Fritzbox passen und 
 *                       dort nicht vergeben sein bzw. werden (bspw. per DHCP)
 *                       Wird eine andere (private) IP-Adresse gesetzt,
 *                       funktioniert der VPN-Verkehr nur, wenn der Client
 *                       seinen gesamten Traffic durch den VPN-Tunnel schickt.
 *                       Ggf. mit Suchen+Ersetzen bei allen Suchtreffern anpassen.
 *
 *   eventuell:
 *   192.168.178.0     --> Das ist das lokale Netz vom VPN-Client.
 *                       Falls aus dem Netz der "Server"-Fritzbox auch 
 *                       IP-Adressen aus dem Netz vom Client erreicht werden sollen. 
 *                       Dann muss eine spezielle permit-Zeile bei
 *                       Parameter accesslist vorhanden sein
 *                       Ggf. mit Suchen+Ersetzen bei allen Suchtreffern anpassen.
 *
 * Weitere Anpassungen sind zwischen den Parameter-Zeilen kommentiert
 *
 * Die Werte fuer die Parameter
 *     key, username (i.d.R identisch zu key_id) und passwd
 * werden zum Konfigurieren des VPN-Clients gebraucht:
 *     username --> entspricht "Accountname" oder "Benutzername"
 *                  Achtung, wird zweimal verwendet (wenn wie key_id)
 *                  muss auch bei GruppenNAME eingetragen werden!
 *     passw --> entspricht "Passwort" bei "Accountname"/"Benutzername"
 *     key --> entspricht "Shared Secret" oder auch "Gruppenpasswort"
 *
 */

vpncfg {
        connections {
                /*  */
                enabled = yes;
                conn_type = conntype_user;
                /* Parameter name kann beliebig angepasst werden. */
                /* Erscheint in der Server-Fritzbox als Name der VPN-Einwahl */
                name = "Einwahl fuer Fritzbox mit Netz 192.168.178.0";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                /* remote_virtualip ist die IP-Adresse, die der VPN-Client bekommt. */
                /* Info dazu siehe oben */
                /* wird i.d.R. wie ipaddr in phase2remoteid gesetzt */
                remote_virtualip = 192.168.1.200;
                /* key_id wird i.d.R. wie username gesetzt */
                /* muss identisch zu "Gruppenname" in der Client-Config sein */
                remoteid {
                        key_id = "fritzbox.client192.168.1.200";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                /* key kann beliebeig angepasst werden, je laenger je besser */
                /* muss identisch zum "Shared Secret" in der Client-Config sein */
                key = "SehrGeheimesSharedSecret";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                /* username und passwd anpassen */
                /* username wird i.d.R. wie key_id gesetzt */
                /* muessen identisch zu "Accountname"/"Benutzername" in Client-Config sein */
                xauth {
                        valid = yes;
                        username = "fritzbox.client192.168.1.200";
                        passwd = "[email protected]";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                /* ipaddr in phase2remoteid wird i.d.R. wie remote_virtualip gesetzt */
                phase2remoteid {
                        ipaddr = 192.168.1.200;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                /* Zusaetzliche Zeilen fuer accesslist enden immer mit Komma, ausser die letzte mit Semikolon! */
                /* Soll die "Server"-Fritzbox auch Pakete ins Client-Netz routen, dann */
                /* muss es eine Zeile wie folgende geben: */
                /* "permit ip any client-netz-ip client-netz-subnetzmaske" */
                /* client-netz-ip und client-netz-subnetzmaske mit den zum Netz des VPN-Clients passenden */
                /* Ziffern und Punkten ersetzen. */
                /*  */
                /* Falls die IP-Adresse fuer den VPN-Client ausserhalb des Netzes der "Server"-Fritzbox */
                /* gewaehlt wurde, dann muss es eine Zeile wie folgende geben: */
                /* "permit ip any client-vpn-ip 255.255.255.255" */
                /* client-vpn-ip entspricht dem Wert von Parameter remote_virtualip */
                /* Ausserdem muss der VPN-Client so konfiguriert sein, dass der gesamte Internetverkehr */
                /* des Clients durch den VPN-Tunnel geht (machen Client-FBoxen automatisch). */
                /*  */
                /* Und immer schoen an Komma und zuletzt Semikolon hinten denken ... */
                accesslist =
                             "permit ip any 192.168.1.200 255.255.255.255",
                             "permit ip any 192.168.178.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

/*
 * Durch den zusaetzlichen Eintrag "permit ip any ..." unten bei accesslist
 * werden Pakete auch in das VPN-Client-Subnetz geroutet/erlaubt.
 *
 * Der VPN-Client bekommt hier die IP-Adresse 192.168.1.200 zugeteilt.
 * Damit das mit Routing von Paketen zwischen Client- und Server-Netz klappt,
 * muss auf dem VPN-Client hier am Beispiel eines Linux-Clients
 *   a) noch Routing aktiviert sein
 *      sysctl -w net.ipv4.ip_forward=1
 *   b) und das NAT masquerading eingeschaltet sein
 *      /sbin/iptables -t nat -A POSTROUTING -o WANDEV -j MASQUERADE
 *      WANDEV ist dabei das Netzwerkgeraet zum Internet (nicht das VPN-Device)
 * Eine Fritzbox als VPN-Client macht das automatisch.
 *
 * Ist ein weiterer VPN-Client (braucht dann eine separate Einwahl-Config auf der Server-Fbox) eingewaehlt
 * und soll auch das Subnetz 192.168.178.0 der anderen VPN-Einwahl erreichen, dann
 * klappt das nur, wenn
 * a) Der gesamte Traffic des "weiteren VPN-Client" durch den VPN-Tunnel geht, oder
 * b) wenn auf dem "weiteren VPN-Client" eine entsprechende Route gesetzt ist,
 *    mit einem Linux-Client
 *    route add net 192.168.178.0 netmask 255.255.255.0 tun0
 *    - tun0 ist das VPN-Device
 *    - Eine andere Fritzbox als VPN-Client braucht dann auch eine angepasste cfg-Datei mit access-list permit ... .
 *
 * In Smartphones laesst sich das i.d.R. gar nicht veraendern, dort geht immer alles
 * durch den Tunnel ...
 *
*/

// EOF

Bitte als Textdatei (bspw. mit Endung .txt oder .cfg) speichern und in der Server-Fritzbox via
Internet
--> Freigaben
--> Reiter "VPN"
--> Button "VPN-Verbindung hinzufügen"
--> "Eine VPN-Konfiguration aus einer vorhandenen VPN-Einstellungsdatei importieren"
Hab ich auch noch mal als txt-Datei hier angehängt.

Auf der Client-Fritzbox die VPN-Einwahl via
--> Freigaben
--> Reiter "VPN"
--> Button "VPN-Verbindung hinzufügen"
--> "Diese FRITZ!Box mit einem Firmen-VPN verbinden"
einrichten. Die drei Werte für Username, Passwort und Key so eintragen wie in der "VPN-Einstellungsdatei" festgelegt.
Unten bei "Erweiterte Einstellungen zum Netzwerkverkehr" kannst du noch Anpassungen für deine "internet-Verkehr"-Wünsche festlegen.

Da bei Fritzbox-VPNs normalerweise Routing im Spiel ist, funktioniert das "Einander-Sehen" der Clients nicht "automatisch" (sprich per Broadcast, bspw. über die "Netzwerkumgebung"). Aber direktes "Ansprechen" (bspw via ping) der IP-Adressen wird funktionieren.

Die Netzbereiche von Client- und Server-Fritzboxen müssen unbedingt unterschiedlich sein. Ist ja bei dir so, aber der Netzbereich 192.168.178.0 deiner Client-Fritzbox ist der "Standard"-Fritzboxen-Netzbereich.
Wenn ein VPN zwischen Fritzboxen zurechtgefrickelt werden soll, würd ich immer auf allen beteiligten Netzen von der 178 weggehen. Aber versuch es erstmal so mit 178 , das kann klappen.

Vielleicht gehts mit aktuelleren Firmware-Versionen auch ohne eine "VPN-Einstellungsdatei". Meine Versuche zu dem Thema sind schon ein paar Jahre her ...

 

[PeterPawn]

Sorry, aber warum sollte irgendjemand auf die Idee kommen, bei einer LAN-LAN-Kopplung eine VPN-Konfiguration mit "conn_type = conntype_user;" zu verwenden?

Das funktioniert zwar in speziellen Situationen auch, aber i.d.R. nur in einer Richtung, weil dann nämlich die Box, die sich als "Client" einwählt bei der anderen, ihrerseits NAT betreiben muß, damit alle hinter ihr versammelten LAN-Clients über die eine, gemeinsame IPv4-Adresse auf das andere Netz zugreifen können und da kommt dann niemand aus dem anderen Netz (hier ja "Master") in das Netz beim Client "Slave" (das habe ich mir abgewöhnt - zumindest weitgehend) und findet damit (ohne weitere Maßnahmen) auch keinen der dort vorhandenen Clients.

Das ist also - ich schreibe es mal so deutlich - ausgemachter Blödsinn, eine solche Konfiguration im hier in #1 beschriebenen Szenario zu verwenden.

Was aber an #1 tatsächlich fehlt, ist die Info, was das nun für Boxen sind und welche FRITZ!OS-Version sie verwenden. Mit der nächsten Release-Version (bzw. im derzeitigen Labor) ändert sich da nämlich auch einiges und man kann den "NetBIOS-Filter" für eine VPN-Verbindung dann auch ganz normal per GUI (für die betroffene VPN-Verbindung) ausknipsen.

 

[7390user1]

Dein Post liest sich so, als ob du der Meinung bist, dass der Vorschlag nicht funktioniert. Da steht sogar was von Blödsinn. Vielleicht testest du den Vorschlag mal?
Warum sollte die Client-Box NAT machen, wenn bei ihr am VPN-Device (192.168.1.200) Pakete für Ziel-IP-Adressen in ihrem internen Netz ankommen (bspw. 192.168.178.X für einen der "Windows-Clients") und sie die Pakete einfach routen kann?
Es gibt genau dafür in der "VPN-Einwahlkonfiguration" für die Server-Box eine Zeile
"permit ip any 192.168.178.0 255.255.255.0";

Oder du lieferst mal eine Anleitung mit conn_type = conntype_lan; für FB7390 und Firmware 6.51 , wie es beim Thread-Ersteller in der Signatur steht.

Mannmannmann, ip-phone-forum ist irgendwie nicht mehr das, was es mal war.

 

[PeterPawn]

Ich schrieb, daß dieses Szenario für den in #1 beschriebenen Zweck Blödsinn ist - und dazu stehe ich auch.

Mannmannmann, ip-phone-forum ist irgendwie nicht mehr das, was es mal war.

Warum? Weil es nicht widerspruchslos hingenommen wird, wenn man andere offensichtlich in eine falsche oder zumindest unnötige Richtung "schubsen" will? Offenbar bist Du Dir der Unsicherheiten ja auch selbst bewußt, wenn Du noch:

Vielleicht gehts mit aktuelleren Firmware-Versionen auch ohne eine "VPN-Einstellungsdatei". Meine Versuche zu dem Thema sind schon ein paar Jahre her ...

schreibst.

Oder du lieferst mal eine Anleitung mit conn_type = conntype_lan; für FB7390 und Firmware 6.51 , wie es beim Thread-Ersteller in der Signatur steht.

Ich denke gar nicht dran ... anders als Du gehe ich nämlich nicht automatisch davon aus, daß die Angaben in dieser Signatur noch irgendetwas mit dem derzeitigen Stand zu tun haben.

Und selbst wenn das so sein sollte, daß die Signatur noch stimmt ... auch dann fehlt für mich (der sich sonst durchaus auch zu VPN-Themen äußert) da noch so einiges an Informationen, weshalb ich bisher auch keine Antwort formuliert habe, zumal das alles mehrfach ausdiskutiert ist.

Nach den Angaben in #1 hat er sogar schon eine funktionierende VPN-Verbindung zwischen den beiden Standorten - aber auch da wäre etwas mehr "Fleisch" bei den Infos sicherlich hilfreich (gewesen), denn eindeutig ist die Aussage nicht, ob nun NUR der Windows-Netzwerkzugriff über die VPN-Verbindung nicht funktioniert oder ob sich die Annahme, daß die VPN-Verbindung funktioniert, nur aus der "grünen LED" speist:

Man sihet den grünen Button, insofern denke ich ist alles okay.

Wenn man aber der Beschreibung in #1 folgt, macht es noch weniger Sinn, sich jetzt eine andere VPN-Verbindung zuzulegen (zumal das ohnehin nicht funktioniert, wenn zwei "entfernte" Netze dasselbe LAN-Segment verwenden) - nur weil man einen Hammer in der Hand hält (oder selbst eine funktionierende VPN-Konfiguration besitzt, wobei ich das für das skizzierte Szenario auch noch bezweifele, aber da komme ich gleich noch drauf zurück), muß man ja nicht alles als Nagel sehen und den Fragesteller unbedingt auf den eigenen Weg "locken".

Vielleicht wäre es hilfreicher gewesen, ihn darauf hinzuweisen, daß es zum Problem des Zugriffs auf "Windows-Shares" über eine VPN-Verbindung schon zig Threads hier gibt (Du scheinst Dich ja im IPPF gut auszukennen, wenn Du Dir alte Zeiten zurück wünschst) und daß es vermutlich nur der passenden Einstellung der jeweiligen Windows-Firewalls bedarf, damit auch das "entfernte Netz" zu jenen gezählt wird, mit denen der Netzwerkverkehr gestattet ist.

Das ist nämlich die Einstellung, die bei diesem Szenario am häufigsten übersehen wird ... wenn die VPN-Verbindung tatsächlich funktioniert (schon ein "ping" in beide Richtungen zeigt das ausreichend deutlich), braucht es nur noch die passenden Einstellungen in den Firewalls, solange der NetBIOS-Filter für die VPN-Verbindung ("dont_filter_netbios = no;" - man muß sich etwas das Gehirn verrenken, weil eben "yes" den Traffic zuläßt) nicht aktiviert ist ... was bei LAN-LAN-Verbindungen Standard sein sollte, im Gegensatz zu "conntype_out" (getestet mit 07.12), was er ja nach Deiner Empfehlung auf der Client-Box konfigurieren soll(te).

==========================================================================

Obendrein leitet sich aus dem Aufzeigen von "Schwachstellen" (und das ist dann eine durchaus zurückhaltendere Formulierung) auch nicht automatisch die Verpflichtung ab, es (schon wieder) besser zu machen und den Fragesteller mit der Nase auf den richtigen Ansatz zu stoßen - ich will ihn nur davor bewahren, daß er am Ende in die falsche Richtung geschickt wird.

Das FRITZ!OS enthält seit Version 05.60 (bzw. dann seit 06.0x) die Möglichkeit, VPN-Verbindungen direkt im GUI zu verwalten und dazu gehört es auch, neue Verbindungen anzulegen. Damit braucht es also auch keine Unterscheidung zwischen 06.51 und aktueller Firmware, selbst wenn man eine 7390 unterstellt (da wäre aktuell dann die 06.86) - die nächsten wirklich relevanten Änderungen kommen erst mit der Release-Version 07.20 und die zwischendrin (iirc bei der 06.2x) mal aktualisierten Proposal-Sets ändern an der gesamten Funktion nichts.

Was macht eigentlich bei Deinem Vorschlag für die VPN-Konfiguration ein Client im Netz der "Master"-Box, wenn er auf einen der Clients an der "Slave"-Box zugreifen will, aber die VPN-Verbindung wurde noch gar nicht aufgebaut? Denn die wird hierbei ja nur dann überhaupt initiiert, wenn ein Client an der "Slave"-Box irgendein Paket an eine Adresse aus dem "Master"-Netz sendet - von der Seite des "Masters" aus gibt es gar keine Möglichkeit, die VPN-Verbindung aufzubauen.. Schon daher kann ich Deine Frage:

Dein Post liest sich so, als ob du der Meinung bist, dass der Vorschlag nicht funktioniert.

dahingehend bejahen, daß es schon "günstige Voraussetzungen" braucht, damit da überhaupt eine VPN-Verbindung aufgebaut wird, über die man dann mit dem Windows-Netzwerk kommunizieren könnte (und das ist nur ein Aspekt, warum das eher "nicht funktioniert").

Warum sollte die Client-Box NAT machen, wenn bei ihr am VPN-Device (192.168.1.200) Pakete für Ziel-IP-Adressen in ihrem internen Netz ankommen

Spannend ... welches wäre denn nach Deiner Ansicht dieses "VPN-Device" bei einer FRITZ!Box? Das FRITZ!OS weist bei einer VPN-Verbindung vom Typ "conntype_out" ihre IP-Adresse im LAN der Gegenseite (also die, welche sie per "config mode" zugewiesen bekam) dem AVM-WAN-Stack (hinter "dev dsl") zu:

root@fb7490:~ $ ip a show dev dsl
40: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 100
    link/ppp
    inet 192.168.130.1/32 scope global dsl
       valid_lft forever preferred_lft forever
    inet 192.168.178.200/32 scope global dsl
       valid_lft forever preferred_lft forever
root@fb7490:~ $ ip r
default dev dsl scope link  metric 2
169.254.0.0/16 dev lan scope link  src 169.254.1.1
172.31.189.0/24 dev guest scope link  src 172.31.189.1
192.168.128.254 dev dsl  metric 2
192.168.130.0/24 dev lan scope link  src 192.168.130.1
192.168.131.0/28 dev dsl  metric 2
192.168.180.1 dev dsl scope link  metric 2
192.168.180.2 dev dsl scope link  metric 2
root@fb7490:~ $ cat /proc/kdsld/dsliface/internet/ipsec/*
FB7580-Einwahl: 192.168.131.13:192.168.178.200 192.168.133.4:0.0.0.0 1 SAs  valid enabled dynlocalip
    permit ip any 192.168.178.0 255.255.255.0
    permit udp any host 192.168.178.1 eq 53
    permit tcp any host 192.168.178.1 eq 53
    Forbidden Clients: 172.31.189.0/24
FB7580-Einwahl: pmtu 0 mtu 1500 dpd_supported
root@fb7490:~ $ ping -c 5 192.168.178.1
PING 192.168.178.1 (192.168.178.1): 56 data bytes
64 bytes from 192.168.178.1: seq=0 ttl=64 time=4.353 ms
64 bytes from 192.168.178.1: seq=1 ttl=64 time=4.335 ms
64 bytes from 192.168.178.1: seq=2 ttl=64 time=3.927 ms
64 bytes from 192.168.178.1: seq=3 ttl=64 time=4.126 ms
64 bytes from 192.168.178.1: seq=4 ttl=64 time=2.476 ms

--- 192.168.178.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 2.476/3.843/4.353 ms
root@fb7490:~ $ ping -c 3 192.168.130.2
PING 192.168.130.2 (192.168.130.2): 56 data bytes
64 bytes from 192.168.130.2: seq=0 ttl=64 time=0.463 ms
64 bytes from 192.168.130.2: seq=1 ttl=64 time=0.525 ms
64 bytes from 192.168.130.2: seq=2 ttl=64 time=0.453 ms

--- 192.168.130.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.453/0.480/0.525 ms
root@fb7490:~ $

Hier hat die "Master"-Box das LAN-Segment 192.168.178.0/24, die "Slave"-Box verwendet 192.168.130.0/24 und 192.168.178.200 steht in den beiden VPN-Konfigurationen - obwohl die i.d.R. noch zur Standard-Range des AVM-DHCP gehört, denn die geht bis .200 und erst ab .201 gehen i.d.R. die Clients los. Alle beiden beteiligten Boxen verwenden nebenbei bemerkt die 07.12 als FRITZ!OS-Version.

Die anderen Netze in der Routing-Table sind für die "Notfall-IP" (169.254.1.1/16), das Gastnetz (172.31.189.0/24) und das "WAN-Netz" (die Box ist ein Router über LAN1) verwendet dann 192.168.131.0/28, wobei die Box selbst die 192.168.131.13 per DHCP erhalten hat, während der (externe) DNS-Server auf die 192.168.128.254 hört (deshalb hat die einen eigenen Eintrag in der Routing-Table).

Aber wie man sieht, hat dieses "Linux device" mit dem Namen "dsl" am Ende die Adresse 192.168.178.200 mit einer 32-Bit-Maske und es gibt gar keinen Eintrag in der Routing-Table für das "entfernte Netz" mit dem Segment 192.168.178.0/24. Das macht die Feststellung:

Da bei Fritzbox-VPNs normalerweise Routing im Spiel ist

auch schon fragwürdig - die Pakete für die VPN-Gegenstelle nehmen nämlich (wir sind hier erst mal nur auf der "Slave"-Box) die "Standardroute" und die führt nun mal über "dev dsl" und damit über den AVM-WAN-Stack. Ob man das jetzt so beschreiben sollte, daß hier "normalerweise Routing im Spiel" ist, weiß ich nicht ... aber meinetwegen soll das einfach mal so sein. Denn letztlich sind auch die "Selektoren" für den zu verschlüsselnden Traffic (in der "accesslist") eine gewisse Art von "Routing" (nur hat das mit dem Routing des IP-Stacks im Linux-Kernel nichts mehr zu tun) - sie sorgen halt dafür, daß die Pakete, die über die VPN-Verbindung gehen sollen, einen anderen Weg im AVM-WAN-Stack nehmen. Ob es da bei AVM dann tatsächlich ein "VPN-Device" gibt, weiß ich nicht ... das sind Infos, die in den Tiefen des AVM-Stacks (in "kdsldmod.ko" und "dsld") versteckt sind - aber ich wage mal die Behauptung, daß Du das auch nicht (sicher) weißt.

Was sieht man noch? Die "Slave"-Box kann über ihre "conntype_out"-Verbindung tatsächlich problemlos die 192.168.178.1 (die LAN-IP des Peers) erreichen und auch Geräte dahinter (die hatte ich hier nicht angeschlossen bzw. mit dem WLAN verbunden, daher keine "Demo" dafür) sind erreichbar, weil diese FRITZ!Box (die "Slave"-Box ist eine 7490, die "Master"-Box eine 7580, falls ich mal die Typen verwenden sollte) mit ihrer IP-Adresse 192.168.178.200 im LAN der "Master"-Box von ebendieser "Master"-Box per Proxy-ARP "annonciert" wird, denn ansonsten würden natürlich die LAN-Clients an der "Master"-Box auch nur lokal nach dieser Adresse suchen - daher behauptet die "Master"-Box eben einfach, sie wäre für die .200 "zuständig" und die LAN-Clients senden ihr dann die Pakete für diese IP-Adresse.

Wie sieht's denn aus, wenn man das jetzt mal aus der Gegenrichtung (also von der "Master"-Box) versucht - die VPN-Verbindung ist dabei tatsächlich aufgebaut (durch Pakete von der 7490 an die IP-Adresse 192.168.178.1):

# showdsldstat
time: 2020-05-25 19:55:55
0: sync_ata: ATA (showtime)
manual            100000000    6000000    100Mbit/s   6.00Mbit/s
syncsspeed        100000000    6000000    100Mbit/s   6.00Mbit/s
maxspeed L2        99607000    5976000  99.61Mbit/s   5.98Mbit/s
actual                    0        104       0bit/s     104bit/s
                                                  0%        0.00%
running (voip=0,tr069=0,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
VPN: FB7580_VPN connected since 2020-05-25 19:24:42 (setup time 3840 secs)
     localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0

0: name internet
0: sync_group: sync_ata
0: iface wan RBE/14/dsl e0:28:6d:95:82:df stay online 1 (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2020-05-25 18:57:24 (setup time 1 secs) (connect cnt 2)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 192.168.133.4 mask 255.255.255.0 gw 192.168.133.254 dhcp mtu 1500
0: IPv4: masqaddr 192.168.133.4
0: IPv4: dns 192.168.133.254
0: IPv4: ntp 192.168.128.254
0: route 192.168.133.0/24 protocol iface
0: route 192.168.133.254/32 protocol dns
0: RX bytes:90244 pkt error:0 discard:0 filtered:1 dropped:28
0: RX pkts:411 unicast:398 multicast:0 broadcast:13
0: TX bytes:117940 pkt error:0 discard:0 filtered:0 dropped:0
0: TX pkts:984 unicast:971 multicast:0 broadcast:13
# cat /proc/kdsld/dsliface/internet/ipsec/*
FB7580_VPN: 192.168.133.4:0.0.0.0 192.168.131.13:192.168.178.200 1 SAs  valid enabled dynlocalip dynremoteip
    permit ip any 192.168.130.0 255.255.255.0
    permit ip any host 192.168.178.200
    Forbidden Clients: 192.168.189.0/24
FB7580_VPN: pmtu 0 mtu 1500 dpd_supported dont_filter_netbios
# ip r
default dev dsl  scope link  metric 2
169.254.0.0/16 dev lan  proto kernel  scope link  src 169.254.1.1
192.168.133.0/24 dev dsl  proto 103  metric 2
192.168.133.254 dev dsl  proto 105  metric 2
192.168.178.0/24 dev lan  proto kernel  scope link  src 192.168.178.1
192.168.178.200 dev dsl  scope link  metric 2
192.168.180.1 dev dsl  scope link  metric 2
192.168.180.2 dev dsl  scope link  metric 2
192.168.189.0/24 dev guest  proto kernel  scope link  src 192.168.189.1
# ping -c 5 192.168.130.1
PING 192.168.130.1 (192.168.130.1): 56 data bytes

--- 192.168.130.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
# ping -c 5 192.168.130.2
PING 192.168.130.2 (192.168.130.2): 56 data bytes

--- 192.168.130.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
#

Wie man sieht, erreicht man bei dieser Art der Verbindung nicht mal die FRITZ!Box auf der "Gegenseite" selbst (die 192.168.130.1 ist hier ja die LAN-IP der 7490, die "Slave" spielt), geschweige denn irgendeinen anderen Client in deren LAN.

Die Feststellung, daß man beim AVM-VPN bei der Benutzung von "conntype_user" oder "conntype_out" dann auf PFS bei der Schlüsselaushandlung verzichten muß (das wird tatsächlich nur bei "conntype_lan" unterstützt), ist da nur noch die "cherry on top" - schon das ist ein Grund, warum man (wo immer es geht) am Ende "conntype_lan" verwenden sollte. Denn auch das (manuelle) Umstellen des Proposal-Sets für P2 hilft bei "conntype_user" oder "conntype_out" nicht ... zwar werden die Änderungen erst einmal akzeptiert (wenn man sie richtig ausführt), aber mit den solchermaßen angepaßten Konfigurationen kommt dann keine Verbindung mehr zustande (oder zumindest ich habe das mit 07.1x dann nicht mehr hinbekommen).

==========================================================================

Vielleicht testest du den Vorschlag mal?

Das habe ich ja jetzt getan. Ich war mir zwar beim zu erwartenden Ergebnis auch zuvor schon sicher, aber so konnte ich das wenigstens noch richtig "dokumentieren".

Was nun?

Hätte ich den Vorschlag lieber unwidersprochen stehen lassen sollen, damit sich der Nächste - bei der Suche nach einer Lösung für sich selbst - von Deinem Vorschlag in die Irre führen läßt? Wenn das Deine Ansicht gewesen sein sollte, hat sich vielleicht tatsächlich einiges geändert im IPPF ... aber in meinen Augen dann zum Guten. Selbst wenn ein Versuch zu helfen "nett gemeint" war, leistet man dem Fragesteller mit einer "fragwürdigen Antwort" (und das meine ich wörtlich, denn die war der Nachfragen tatsächlich würdig) eher einen Bärendienst. Und für diesen - ich schreibe nach den vorhergehenden Tests jetzt sogar "deutlich falschen" - Vorschlag war die (nicht mal wirklich deutliche) Ansage:

Meine Versuche zu dem Thema sind schon ein paar Jahre her ...

dann eindeutig zu wenig an "Warnung" für die (auch künftigen) Leser.

 

[drnicolas]

Vielen Dank an 7390user1.
Ich verstehe zwar nur Bahnhof, aber ich werde es die Tage probieren.

Und: Haut Euch nicht

 

[7390user1]

Zorri für die lange Sendepause. Hab mich jetzt wieder damit beschäftigen können.

Mein oben genannter Vorschlag funktioniert so nicht zwischen zwei Fritzboxen. Weil die Fritzbox nur maximal 32 Zeichen als Passwort verarbeiten kann! "[email protected]192.168.1.200" ist einfach zu lang.

UND - jetzt etwas ernsthafter - es funktioniert auch nicht für den gewünschten Netzwerkverkehr.

Danke PeterPawn fürs Ausprobieren. Aber so viel Text (ich messe hier 1,54m zum scrollen!) und so wenig Erhellendes dabei. Nagut, ist halt dein Style ...

Fakt ist: Die zusätzliche Zeile "permit ip any 192.168.178.0 255.255.255.0" für die accesslist in der VPN-Konfiguration bewirkt, dass die "VPN-Server"-Fritzbox (mit dem 192.168.1er Netz) Pakete mit Zieladressen im Netz der "VPN-Client"-Fritzbox (192.168.178.0) durch den VPN-Tunnel zum VPN-Client schickt. Also bspw. ein Ping von einer IP aus dem 192.168.1er Netz zu einer IP im 192.168.178er Netz schlägt bei der "VPN-Client"-Fritzbox auf.
Ohne die accesslist-Zeile macht die Server-Fritzbox das nicht.
Leider lässt die "VPN-Client"-Fritzbox diese durch den Tunnel kommenden Pakete für ihr internes Netz dann nicht rein. Tja schade.

Verbindet sich stattdessen ein ganz normaler Linux-Router (ich verwende das Paket vpnc) als VPN-Client mit der wie vorgeschlagen konfigurierten "VPN-Server"-Fritzbox (kürzeres Passwort! ), klappt die Vernetzung ohne weiteres zutun. Nur die drei passenden Zugangsdaten (Username=Gruppenname,Userpasswort und Gruppen-SharedKey) werden benötigt. Beide Netze können sich in beide Richtungen erreichen.
Somit eignet sich die "conn_type = conntype_user;"-Variante mit der passenden accesslist-permit-Zeile sehr wohl für eine LAN-LAN-Kopplung.
Aber leider nicht zwischen zwei Fritzboxen, wie es der Threadersteller angefragt hatte.

Tut mir leid, dass durch meinen Post der Thread in die völlig falsche Richtung gegangen ist. Ich habs nur gut gemeint! Und ich weiß auch, wovon "gut gemeint" das Gegenteil ist ...
Wenn der Threadersteller hier noch weitermachen möchte: Was genau funktioniert denn nicht bei dem, was AVM quasi als "best practice" anbietet:
https://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7390/016/hilfe_vpn_lanlan ?

 

[PeterPawn]

und so wenig Erhellendes dabei. Nagut, ist halt dein Style ...

Sorry, aber auf solche Frechheiten kann ich dann auch nur noch reagieren, indem ich mal festhalte, daß es nicht zwangsläufig an meinem Style, sondern vielleicht eher an Deinem Horizont liegt, daß das so wenig erhellend auf Dich wirkt.

Was an den gezeigten Beispielen jetzt unzureichend sein soll, wenn sie doch genau die von Dir als funktionierend behauptete Konstellation illustrieren, darüber mögen sich die anderen Leser ihre eigene Meinung bilden - wenn's irgendjemanden erhellen kann, ist mir das Erfolg genug.