[Problem] LAN-LAN Kopplung: Gesamter Traffic und DNS durch VPN trotz DynDNS

jo_nas

Neuer User
Mitglied seit
28 Feb 2022
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Hallo. Ich habe zwei örtlich getrennte Fritzboxen, die ich per Site-to-Site VPN verbunden habe. Dies funktioniert auch, allerdings nicht Namensauflösung. Mein Ziel ist, dass diese bash-Zeile erfolgreich verläuft (sprich, die Namen in den beiden Netzen können sich gegenseitig auflösen und erreichen):
user@pc-192-168-188-188$ ping pc-192-168-178-178 und gerne auch andersherum.

Was funktioniert ist das hier:
user@pc-192-168-188-188$ ping 192.168.178.178 und andersherum (der pc-... soll hier ein beliebiger host sein). Das ist der derzeitige Stand:

|7490|---|INTERNET|---|Unbekannt|---|6390|

Fritzbox 7390 (mit Freetz-NG):
  • VPN-Initiator/Client und Internetzugang hinter/über unbekanntem Netzwerk (172.16.0.1/24)
  • Name: my-fritzbox
  • WAN IP: 172.16.0.10, GW: 172.16.0.1
  • LAN IP: 192.168.188.1/24
  • VPN config: 7390.cfg
  • Fixed DNS: 192.168.178.1, 1.1.1.1

Fritzbox 7490:
  • VPN-Responder/Host und Router mit dynamischer IP Adresse
  • DynDNS (abcd.myfritz.net)
  • LAN IP: 192.168.178.1/24
  • VPN config: 7490.cfg
  • Im Netz: Ein Server der von außen unter example.com erreichbar ist

Der Tunnelaufbau und keep-alive funktionieren und der normale Traffic wird von 7390->7490 per VPN geschickt. Allerdings nicht die DNS-Abfragen über Port 53 (steht ja auch in 7390.cfg accesslist als reject), die verlaufen weiterhin über den Internetzugang des unbekannten Netzwerkes. Weiterhin betreibe ich im 192.168.178.0er Netz einen Server mit Portweiterleitung der 7490, soweit ich das verstanden habe, kann der über NAT-Hairpinning auch intern erreichbar sein.

Nun möchte ich gerne auch diese DNS-Abfragen über VPN schicken. Das klappt allerdings nicht, da ein Fehlen von reject udp any and eq 53 in der accesslist von 7390.cfg einen Aufbau des Tunnels nicht möglich macht wegen timeout der DNS-Auflösung. Das sagt soweit auch folgender Post.

Allgemein scheint die Idee mit DNS über VPN schon gefragt worden zu sein: https://www.ip-phone-forum.de/threads/dns-für-domain-controller-über-vpn.286675/, https://www.ip-phone-forum.de/threads/mini-howto-kompletten-internetverkehr-über-avm-vpn-routen.189391/post-2307151, https://www.ip-phone-forum.de/threads/eigene-dns-server-per-fritzbox-vpn-nutzen.283573/#post-2142484. Allerdings nicht mit vollständigen Lösungen.


Meine Fragen: Ist es dennoch möglich, den gesamten Traffic (einschl. DNS) über den VPN Tunnel zu senden (vielleicht via conn_type=conntype_user)? Falls nicht, könnte man dies über Freetz-NG (tinyc, wireguard, opencvpn) erreichen oder gibt es Alternativen? DNSmasq ist auf der Freetz-NG Fritzbox installiert, jedoch deaktiviert. Könnte DNSmasq da helfen?

Eine Möglichkeit wäre, in den DHCP-Einstellungen der 7390 die DNS-Server Adresse auf 192.168.178.1 (also 7490) zu stellen, ich erhalte jedoch keine IPs wenn ich dann z.B. user@pc-192-168-188-188$ dig pc-192-168-178-178 durchführe.

Achja, eine letzte Frage. Etwas OT: Gibt es irgendwo eine Übersicht/Erklärung der ".cfg"-Dateien? Speziell hinsichtlich conn_typ=conntype_lan, conntype_out, conntype_user


7390.cfg
Code:
vpncfg {
    connections {
        enabled = yes;
        editable = no;
        conn_type = conntype_lan;
        name = "abcd.myfritz.net";
        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 = 0.0.0.0;
        remotehostname = "abcd.myfritz.net";
        keepalive_ip = 192.168.178.1;
        localid {
            fqdn = "my-fritzbox.lan";
        }
        remoteid {
            fqdn = "abcd.myfritz.net";
        }
        mode = phase1_mode_aggressive;
        phase1ss = "all/all/all";
        keytype = connkeytype_pre_shared;
        key = "$KEY";
        cert_do_server_auth = no;
        use_nat_t = yes;
        use_xauth = no;
        use_cfgmode = no;
        phase2localid {
            ipnet {
                ipaddr = 192.168.188.0;
                mask = 255.255.255.0;
            }
        }
        phase2remoteid {
            ipnet {
                ipaddr = 192.168.178.0;
                mask = 255.255.255.0;
            }
        }
        phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
        accesslist = "reject udp any any eq 53", //permit does not work
                "reject udp any any eq 500",
                "reject udp any any eq 4500",
                "permit ip any any";

    }
    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";
}


7490.cfg
Code:
vpncfg {
    connections {
        enabled = yes;
        editable = no;
        conn_type = conntype_lan;
        name = "my-fritzbox.lan";
        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 = 0.0.0.0;
        keepalive_ip = 192.168.188.1;
        localid {
            fqdn = "abcd.myfritz.net";
        }
        remoteid {
            fqdn = "my-fritzbox.lan";
        }
        mode = phase1_mode_aggressive;
        phase1ss = "all/all/all";
        keytype = connkeytype_pre_shared;
        key = "$KEY";
        cert_do_server_auth = no;
        use_nat_t = yes;
        use_xauth = no;
        use_cfgmode = no;
        phase2localid {
            ipnet {
                ipaddr = 192.168.178.0;
                mask = 255.255.255.0;
            }
        }
        phase2remoteid {
            ipnet {
                ipaddr = 192.168.188.0;
                mask = 255.255.255.0;
            }
        }
        phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
        accesslist = "permit ip any 192.168.188.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";
}
 
bump
Keiner eine Idee? Ich habe auch reject udp 192.168.188.1 255.255.255.255 any eq 53 statt reject udp any any eq 53 ( 7390.cfg) probiert, ohne Erfolg. Oder hab ich da einen Konfigurationsfehler?

Ich glaube nämlich dass es in die richtige Richtung geht: extra DNS server (Raspi etc.) im netz 192.168.188.0, die fritzbox-7390 (192.168.188.1) setzt bei dhcp leases den DNS server auf den raspi, in der 7390.cfg wird alles getunnelt mit Ausnahme von IKE 500/4500 und DNS 53 von 192.168.188.1.
 
Solange hier wechselseitig (oder auch in einer Richtung) der AVM-DNS-/DHCP-Server multid verwendet und "befragt" werden soll, scheitert das an mehreren Hürden. Das Eintragen von ZWEI DNS-Servern (für die FRITZ!Box) hilft schon deshalb nicht, weil die Box immer nur EINEN davon verwendet (welchen, zeigt sie auch im GUI an) und nur wenn der nicht antwortet (was ein deutlicher Unterschied zu einer "negativen Antwort" (NXDOMAIN) ist), wird "der Andere" auch noch dazu konsultiert und danach selbst zum "Standardserver" ... da hilft es also auch nicht, wenn der erste wegen einer noch nicht aufgebauten VPN-Verbindung nicht erreicht werden kann - für das "Zurückschalten" müßte man dann schon den zweiten Kandidaten danach irgendwie zum "Verstummen" bringen.

Wobei das für neue/künftige Versionen nicht mehr stimmen muß ... es macht auf mich den Eindruck, als würde AVM (auch im Zuge der Stabilisierung des DoT-Features) an diesen Stellen schrauben und weitere/andere Fallback-Optionen implementieren ... vielleicht auch bis hin zu wiederholtem "qualifying" der Reaktionen eines DNS-Servers oder gar bis zur parallelen Abfrage bei mehr als einem Upstream-Resolver (das ist aber nur Theorie, basierend auf einigen ChangeLog-Einträgen bzw. Änderungen in den Meldungen für das Event-Log der Box). Aber das KANN hier auch nicht Thema sein, denn 7390 und 7490 sind davon sicherlich nicht betroffen.


Hinzu kommt noch, daß der multid im FRITZ!OS wohl auch nicht länger als "open relay" funktioniert und eigene ACLs verwendet, WELCHE Clients ihn eigentlich zur Arbeit auffordern dürfen bzw. von ihm die Daten für eine Zone abfragen können. Das sieht man z.B. in den Support-Daten oder auch direkt in einer Shell mit einem aicmd multi dnsd zone - bei "allowedv[46]" am Beginn der Ausgabe. Grund dürfte hier sein, daß die Clients in einem Gastnetz ja nichts über den Aufbau des "richtigen" Netzes lernen sollten durch das simple Abfragen des DNS-Servers (der für BEIDE Zonen zuständig ist - das Gastnetz kriegt dann seine eigene).

Diese Hürden müßte man also auch erst einmal aus dem Weg räumen ... ein eigener DHCP-/DNS-Server wäre da natürlich eine Option. Zumindest in einer Richtung ... denn da könnte man dann für die "entfernte Domain" (die dann besser nicht auch "fritz.box" heißen sollte - wobei die "zone" ja nicht zwangsläufig mit angegeben werden müßte, solange der DHCP-Server die auch mit als "search domain" übermittelt) ja die Abfrage des DNS-Servers im entfernten Netz ausführen lassen ... wenn der multid dort dann auch Abfragen von einer IP-Adresse AUSSERHALB der "allowedipX"-Einträge erlaubt. Aber m.W. funktioniert schon ein nslookup mit Angabe des entfernten DNS-Servers als Quelle gar nicht (mehr) ... für mich das Ergebnis der erwähnten ACLs.

Aber für die Gegenrichtung, auf einer originalen AVM-Firmware, ist ein eigener DNS-/DHCP-Server (auf der Box) ja auch keine Lösung. Mit zusätzlichen Geräten (sprich einem "open resolver / open relay", das aus BEIDEN Netzen erreichbar ist) könnte man das zumindest für die Clients im LAN noch realisieren, denn man kann dem multid ja auftragen, einen eigenen DNS-Resolver per DHCP an seine Clients zu annoncieren. Für die eigenen Abfragen der FRITZ!Box wird der aber meines Wissens auch nicht verwendet - was auch wieder von Vorteil sein KANN, weil dann DNS-Abfragen für die IP-Adresse des Peers eines VPN-Tunnels auch nicht an diesen internen Resolver gehen sollten. Nur könnten dann (bei einem einzelnen eigenen DNS-Resolver) die Clients aus dem entfernten Netz GAR KEINE DNS-Namen mehr auflösen, solange der IPSec-Tunnel zwischen den Boxen noch nicht etabliert ist. Also bräuchte man dafür dann auch wieder zwei dieser Resolver, in jedem Netz einen.
 
Ich hatte noch die Idee, bei Strato/Netcup/etc. eine feste IP zu holen (quasi als "Broker") und damit die VPN-Verbindung ohne DNS zu machen. Aber ich würde das vom techn. Know-How her glaube ich nicht schaffen und außerdem ist mir das Risiko etwas zu hoch, dass irgendwann da mal was schief geht.


ein eigener DHCP-/DNS-Server wäre da natürlich eine Option

Mir würde es auch ersteinmal reichen, wenn die "entfernte Domain" - ich schätze mal du meinst das Netz 192.168.188.0/FB7390/VPN-Initiator - auf das Netz 192.168.178.0/FB7490/VPN-Responder samt dort stehenden Server zugreifen kann.

Ok, alles in Allem klingt das also nach folgenden Ansatz:
|Server| --- |7490:192.168.178.10| --- |INTERNET| --- |Unbekannt| --- |7390:192.168.188.10| --- |DNS-Srv:192.168.188.10|

- DNS-Srv ist ein raspi dann mit dnsmasq. Der hat als upstream DNS 192.168.178.1 und verteilt die Namen sonst für seine eigene Domain (oder braucht das DHCP?).
- Die FB7390 annonciert diesen DNS-Srv und macht sonst nichts, kein Freetz extrakram also. Außer natürlich die VPN Verbindung, dessen IP er meinetwegen bei 1.1.1.1 bekommt.
- Die VPN config `7390.cfg` wie oben in #1 beschrieben, mit der Änderung in #2 Abs. 1.


Auswirkungen:
- Wenn die VPN-Verbindung nicht steht, läuft auf der 188.0er Seite garnichts, nur DNS/VPN Initiation der FB7390. Der FB7490 ist das schnuppe.
- Wenn der DNS-Srv nicht läuft funktionieren (wahrscheinlich) erstmal keine Namensauflösungen im 188er Netz.


Ist das soweit richtig? Ich würde das die nächsten Tage mal so ausprobieren. Danke schonmal für die Hinweise.
 
Wie soll das denn funktionieren:
Der hat als upstream DNS 192.168.178.1 und verteilt die Namen sonst für seine eigene Domain
?

Ich schrieb doch eindeutig, daß der multid von AVM wohl mittlerweile ACLs verwendet (Access Control Lists) und damit dafür sorgt, daß nur Clients aus seinem eigenen LAN-Segment bei ihm auch die DNS-Daten abfragen dürfen. Der DNS-Server im entfernten LAN wäre aber KEIN lokaler Client, denn der würde ja die Anfragen von seiner eigenen Adresse (192.168.188.10) senden.

Solange Du jetzt also nicht per Test bewiesen hast, daß von diesem Gerät (mit der IP-Adresse 192.168.188.10) aus auch tatsächlich eine DNS-Abfrage beim DNS-Resolver mit der Adresse 192.168.178.10 (wieso haben bei Dir eigentlich die Router jeweils .10 als letztes Tupel - mal abgesehen davon, daß das mit der 7390 und dem DNS-Server dann auch nicht so ganz stimmen kann, wenn die beide .10 sein sollen) erfolgreich abgewickelt werden konnte (und damit meine Behauptung widerlegt wäre), kannst Du diesen Plan ja ganz offensichtlich knicken.

Und daß das offenbar nicht funktioniert, hast Du nach früheren Aussagen ja auch schon selbst erlebt, wenn Du schreibst:
in den DHCP-Einstellungen der 7390 die DNS-Server Adresse auf 192.168.178.1 (also 7490) zu stellen, ich erhalte jedoch keine IPs wenn ich dann z.B. user@pc-192-168-188-188$ dig pc-192-168-178-178 durchführe.
Der Grund, warum Du dann auch mit Deinem dig keine Antworten erhältst, dürften genau diese ACLs und die Absenderadresse des DNS-Requests sein.

Wenn das tatsächlich klappen sollte, reden wir ggf. weiter ... ich denke mal, das ist bereits die erste, so nicht zu überwindende Hürde. WENN Du auf der Seite der 7490 einen DNS-Server haben willst, der von der 7390 aus (bzw. von LAN dahinter) befragt werden kann, dann brauchst Du da eben auch den zweiten Server bzw. das zweite Gerät.

Ich kann auch mit Aussagen "wie in #1 beschrieben" oder "#2 Abs. 1" nicht wirklich gut umgehen, wenn's um das "Zusammensetzen" von Konfigurationen geht, wo schon ein Komma oder Semikolon an der falschen Stelle das Ganze ungültig machen kann. Und ich habe ehrlich gesagt auch gar keine Lust, mir so etwas erst "zusammenzusuchen", solange das nicht "freiwillig" und weil ich etwas überprüfen will geschieht.

Wenn Du selbst etwas "zeigen" willst bzw. möchtest, daß man sich das noch einmal "insgesamt" anschaut (zumindest gilt das für mich), dann zeige es bitte auch so, daß man es auf einen Blick bzw. "unverstreut" ansehen kann. Dann KANN es auch keine Mißverständnisse zum Inhalt oder zu Reihenfolgen u.ä. in einer Konfigurationsdatei zusätzlich geben.
 
Welche FW ist da drauf? Weil es das bei mir in einer 7490 und neuer nicht mehr gibt:
Code:
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";
 
Die Fritzbox 7490 hat die Version 07.29. Das müsste dato die aktuellste sein. Vielleicht braucht es diesen Parameter nicht mehr, geschadet hat es (offensichtlich) allerdings nicht. Leider ist Dokumentation über diese Parameter rar. Ich könnte das mal ohne die Ausprobieren, habe aber aktuell keinen Zugang zu 7490.
 
Vielleicht braucht es diesen Parameter nicht mehr,
Steht es denn so in der FB oder ist das deine Konfig welche du da einspielst?
Wie sieht es denn in der Datensicherung aus?
 
Die Konfigurationen, die ich anfangs aufgelistet habe, ist die funktionierende, selbsterstellte Konfiguration (natürlich mit Annonymisierungen). Ich habe die in relativ mühevoller Recherche zusammengehackt, ich erhebe also keinen Anspruch auf Richtigkeit.

Ich kann derzeit keine Sicherungskopie erstellen, da dies physische Präsenz an der Box erfordert und das ist gerade nur mit Umständen möglich.
 
Auch hier bin ich etwas "irritiert" (wie im anderen Thread) ... aus:

Leider ist Dokumentation über diese Parameter rar.
(OK, "rar" ist schon mal besser als "schlecht bis gar nicht") und
Ich habe die in relativ mühevoller Recherche zusammengehackt
könnte man ja "ableiten", daß es tatsächlich an entsprechender Erklärung mangelt.

Da ich aber dafür ("Wie erstelle ich meine eigene VPN-Konfiguration mit einem Editor?") schon vor 8 Jahren einen Text verfaßt habe (den viele auch gefunden haben), würde mich auch hier dann interessieren, wie DU es denn besser machen würdest:

 

Statistik des Forums

Themen
246,217
Beiträge
2,248,328
Mitglieder
373,790
Neuestes Mitglied
loosenix
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.