AccessList-Konfiguration in FritzBox-VPN-Konfigurationsdateien
Hallo zusammen,
ich habe ein "kleines" Problem mit Box-to-Box VPN mit IPSec-Basis.
Gegeben sind zwei FritzBoxen, eine 7590 mit dem Subnetz 192.168.100.0/24 an einem Hauptstandort Pfarrei und eine 7490 mit dem Subnetz 192.168.116.0/24 an einem Filialstandort Gemeinde. Zwischen den beiden Boxen gibt es ein Site-to-Site-VPN, welches mit "FritzFernzugang einrichten" konfiguriert wurde. Anschließend wurde die AccessList manuell angepasst, damit nur bestimmte Geräte am Filialstandort auf den Hauptstandort zugreifen können. Am Standort Pfarrei lautet sie bisher:
Die FritzBox am Standort Pfarrei soll also nur bestimmte Geräte aus dem Netzwerk der Gemeinde reinlassen.
Am Standort Gemeinde lautet die AccessList einfach:
Da darf also alles raus.
Das funktioniert prima! Die Telephone mit den IP-Adressen 192.168.116.51 und 192.168.116.52 am Standort Gemeinde konnten problemlos auf die Telephonanlage mit der IP-Adresse 192.168.100.240 am Standort Pfarrei zugreifen!
Bis hierhin alles super!
Nun sollte am Standort Gemeinde ein weiteres Telephon (192.168.116.53) installiert werden. Ich habe daher in der VPN-Konfigurationsdatei die AccessList für Standort Pfarrei wie folgt um die zusätzliche IP-Adresse ergänzt:
Anschließend habe ich die VPN-Verbindung zum Standort Gemeinde in der FritzBox am Standort Pfarrei gelöscht und aus der geänderten Konfigurationsdatei neu importiert.
Danach konnte nur seltsamerweise noch das Telephon mit der IP-Adresse 192.168.116.51 (Standort Gemeinde) auf die Telephonanlage (Standort Pfarrei) zugreifen. Das neue Telephon 192.168.116.53 und auch das bisher funktionierende Telephon 192.168.116.52 haben keine Verbindung mehr.
Nachdem ich die VPN-Verbindung aus der ursprünglichen Konfigurationsdatei (mit nur zwei Einträgen in der AccessList) wiederhergestellt habe, konnte zumindest das Telephon 192.168.116.52 wieder kommunizieren.
Es handelt sich hier offenbar nicht um ein Problem der Telephonanlage, sondern der VPN-Konfiguration. Wenn ich das Telephon 192.168.116.52 entferne und durch ein Notebook mit gleicher IP-Adresse ersetze, bleibt bei der VPN-Konfiguration mit drei AccessList-Einträgen ein Ping an die Telephonanlage unbeantwortet, bei der Konfiguration mit zwei AccessList-Einträgen wird er korrekt beantwortet.
Eine Wireshark-Paketanalyse (die Auerswald-Telephonanlage kann Pakete im PCAP-Format mitschneiden) ergab, dass die Anfragen aus dem Netzwerk Gemeinde angekommen sind und beantwortet wurde. In die Richtung funktioniert die Kommunikation also. Nur kommen die Antworten im Gemeinde-Netzwerk nicht mehr an.
AVM weigert sich, dieses Problem zu behandeln - manuelle Bearbeitung der VPN-Konfigurationsdatei wird nicht supportet.
Hat jemand eine Idee? Am meisten macht mich stutzig, dass bei einem dritten Eintrag in der AccessList auch der zweite Eintrag, der sonst funktioniert, nicht mehr wirkt. Sonst läge ja die Vermutung nahe, dass die Zeichenkette zu lang ist, um korrekt ausgewertet zu werden.
Danke im Voraus,
\\//_ Sarek
ich habe ein "kleines" Problem mit Box-to-Box VPN mit IPSec-Basis.
Gegeben sind zwei FritzBoxen, eine 7590 mit dem Subnetz 192.168.100.0/24 an einem Hauptstandort Pfarrei und eine 7490 mit dem Subnetz 192.168.116.0/24 an einem Filialstandort Gemeinde. Zwischen den beiden Boxen gibt es ein Site-to-Site-VPN, welches mit "FritzFernzugang einrichten" konfiguriert wurde. Anschließend wurde die AccessList manuell angepasst, damit nur bestimmte Geräte am Filialstandort auf den Hauptstandort zugreifen können. Am Standort Pfarrei lautet sie bisher:
accesslist =
"permit ip 192.168.100.240 255.255.255.255 192.168.116.51 255.255.255.255",
"permit ip 192.168.100.240 255.255.255.255 192.168.116.52 255.255.255.255";
Am Standort Gemeinde lautet die AccessList einfach:
accesslist = "permit ip any 192.168.100.0 255.255.255.0";
Das funktioniert prima! Die Telephone mit den IP-Adressen 192.168.116.51 und 192.168.116.52 am Standort Gemeinde konnten problemlos auf die Telephonanlage mit der IP-Adresse 192.168.100.240 am Standort Pfarrei zugreifen!
Bis hierhin alles super!
Nun sollte am Standort Gemeinde ein weiteres Telephon (192.168.116.53) installiert werden. Ich habe daher in der VPN-Konfigurationsdatei die AccessList für Standort Pfarrei wie folgt um die zusätzliche IP-Adresse ergänzt:
accesslist =
"permit ip 192.168.100.240 255.255.255.255 192.168.116.51 255.255.255.255",
"permit ip 192.168.100.240 255.255.255.255 192.168.116.52 255.255.255.255",
"permit ip 192.168.100.240 255.255.255.255 192.168.116.53 255.255.255.255";
Anschließend habe ich die VPN-Verbindung zum Standort Gemeinde in der FritzBox am Standort Pfarrei gelöscht und aus der geänderten Konfigurationsdatei neu importiert.
Danach konnte nur seltsamerweise noch das Telephon mit der IP-Adresse 192.168.116.51 (Standort Gemeinde) auf die Telephonanlage (Standort Pfarrei) zugreifen. Das neue Telephon 192.168.116.53 und auch das bisher funktionierende Telephon 192.168.116.52 haben keine Verbindung mehr.
Nachdem ich die VPN-Verbindung aus der ursprünglichen Konfigurationsdatei (mit nur zwei Einträgen in der AccessList) wiederhergestellt habe, konnte zumindest das Telephon 192.168.116.52 wieder kommunizieren.
Es handelt sich hier offenbar nicht um ein Problem der Telephonanlage, sondern der VPN-Konfiguration. Wenn ich das Telephon 192.168.116.52 entferne und durch ein Notebook mit gleicher IP-Adresse ersetze, bleibt bei der VPN-Konfiguration mit drei AccessList-Einträgen ein Ping an die Telephonanlage unbeantwortet, bei der Konfiguration mit zwei AccessList-Einträgen wird er korrekt beantwortet.
Eine Wireshark-Paketanalyse (die Auerswald-Telephonanlage kann Pakete im PCAP-Format mitschneiden) ergab, dass die Anfragen aus dem Netzwerk Gemeinde angekommen sind und beantwortet wurde. In die Richtung funktioniert die Kommunikation also. Nur kommen die Antworten im Gemeinde-Netzwerk nicht mehr an.
AVM weigert sich, dieses Problem zu behandeln - manuelle Bearbeitung der VPN-Konfigurationsdatei wird nicht supportet.
Hat jemand eine Idee? Am meisten macht mich stutzig, dass bei einem dritten Eintrag in der AccessList auch der zweite Eintrag, der sonst funktioniert, nicht mehr wirkt. Sonst läge ja die Vermutung nahe, dass die Zeichenkette zu lang ist, um korrekt ausgewertet zu werden.
Danke im Voraus,
\\//_ Sarek
Please also mark the comments that contributed to the solution of the article
Content-ID: 12937942092
Url: https://administrator.de/contentid/12937942092
Printed on: November 8, 2024 at 18:11 o'clock
22 Comments
Latest comment
Hallo,
Gruss,
Peter
Zitat von @SarekHL:
Die alte editiert. Meines Wissens kann man importierte VPN-Konfigurationen hinterher weder exportieren noch bearbeiten.
Ein Versuch hätte dich Schlauer werden lassen, oder gleich am Telefon gefragt wo du die schon am Telefon hattest.Die alte editiert. Meines Wissens kann man importierte VPN-Konfigurationen hinterher weder exportieren noch bearbeiten.
Schöner wäre natürlich eine Erklärung für dieses in meinen Augen unlogische Verhalten ...
Frage doch AVMGruss,
Peter
Eine Erklärung könnte sein das die Phase 2 SAs aller 3 betroffenen Endgeräte mit dem Neuimport gelöscht werden und nur dann neu angelegt werden wenn die Endgeräte relevanten Traffic erzeugen.
Du hättest also zumindestens alle 3 Telefone einmal stromlos machen sollen damit die eine neue Session zur Anlage aufbauen und damit auch neue P2 SAs anlegen.
Du hättest also zumindestens alle 3 Telefone einmal stromlos machen sollen damit die eine neue Session zur Anlage aufbauen und damit auch neue P2 SAs anlegen.
- Arbeitest du im unsicheren Agressive Mode ("mode = phase1_mode_agressive;") oder im sicheren Main Mode (mode = phase1_mode_idp;) ?
- Führen deine FBs ein Keepalive aus (Initiator Seite!)
- Wie ist "always_renew = ?;" gesetzt?
ok ... aber "FritzFernzugang einrichten" fragt nicht viele Kenndaten ab.
Nein, denn IT Profis, zu denen du ja auch gehörst, setzen diese Parameter alle immer manuell in einem Texteditor.wird die Verbindung offenbar automatisch im Aggressive Mode eingerichtet.
Mit KlickiBunti ist das immer der Fall. Ein erfahrener Netzwerker wie du nutzt sowas auch nicht. 🧐Den Main Mode und auch das deutlich sinnvollere 8 Stunden Timing beim Key Exchange ("phase1ss = "LT8h/all/all/all"; ") erreichst du nur mit manueller Anpassung. Guckst du dazu auch hier.
Hätte es denn irgendwelche Auswirkungen auf meine Fragestellung?
Nein, vermutlich nicht.Mit einem Testaufbau einer aktuellen 7.5.7er 7490 und einer etwas gealterten 6490 mit latest Firmware lief dein Regelwerk absolut fehlerfrei und wie es soll. (Agressive mit LT8 und auch mit DH14 Erweiterung)
Also mit drei AccessList-Einträgen?
Sogar mit 4! Der Rest in Deiner Konfiguration ist "out of the box"?
Jein!Natürlich nutzt man also Netzwerk Admin kein so ein Dödeltool wie "Fernzugang". Typischerweise macht man immer einen Export des FB Setups, editiert das in einem simplen Texteditor wie z.B. Notepad++ und extrahiert daraus, wie es gemeinhin üblich ist, nur den Teil zw. vpncfg {... } also rein nur den VPN relevanten Teil.
Den editiert man dann manuell indem man dort einfach die relevanten Settings ändert.
So hat man auch immer eine simple VPN Grundkonfiguration, die man a. für den Notfall sichern kann und b. immer nach neuen Anforderungen schnell anpassen kann um sie in die FB hochzuladen.
Du kannst dir das in dem o.a. Tutorial von @orcape oder auch hier ansehen wie diese grundlegende Fritzbox VPN Konfig Datei zum Hochladen aussieht.
Wie oben schon geschrieben habe ich die Key Exchange Zeit auf das klassische 8 Stunden verändert und auch mal mit dem Main Mode statt Agressive rumgespielt. Das sind in der Hauptsache die 2 Parameter:
mode = phase1_mode_idp;
phase1ss = "LT8h/all/all/all";
zehn VPNs zu mehreren Gemeinden zusammenlaufen.
Und das mit einer schwachbrüstigen Fritzbox...?! 🤔 Du bist aber sehr mutig oder leichtsinnig, je nachdem. Eigentlich die völlig falsche HW bei solchen Anforderungen was dann früher oder später bestraft wird. Als IT Profi solltest du das eigentlich wissen, denn zumindestens da wo die 10 VPNs zusammenlaufen gehört definitiv eine andere, skalierbare Hardware hin. Mikrotik, OPNsense, pfSense, Cisco etc. die üblichen Verdächtigen wenn es um skalierbare VPN Hardware geht! Was erbrachte der Test mit der vom Kollegen @Drohnald empfohlenen Teilnetz Freigabe in der ACL??
Hallo,
Gruss,
Peter
Zitat von @aqui:
Und das mit einer schwachbrüstigen Fritzbox...?! Du bist aber sehr mutig oder leichtsinnig, je nachdem.
Er Arbeitet schliesslich für das grösste und weitaus Reichstes Unternehmen unseres Planeten. Und bei deren Glaubenskraft kann es doch noch passieren das auch eine FritzBox mehr kann Und das mit einer schwachbrüstigen Fritzbox...?! Du bist aber sehr mutig oder leichtsinnig, je nachdem.
Gruss,
Peter
Hallo,
https://www.wiwo.de/unternehmen/dienstleister/finanz-riese-grosskonzern- ...
https://www.academics.de/ratgeber/kirche-als-arbeitgeber
https://de.wikipedia.org/wiki/R%C3%B6misch-katholische_Kirche
https://de.wikipedia.org/wiki/Verm%C3%B6gen_der_r%C3%B6misch-katholische ...
https://www.tagesspiegel.de/wirtschaft/das-kreuz-mit-den-milliarden-3524 ...
https://www.m-vg.de/mediafiles/Leseprobe/9783959720892.pdf
https://www.welt.de/wirtschaft/article156376890/So-reich-ist-die-katholi ...
Gruss,
Peter
https://www.wiwo.de/unternehmen/dienstleister/finanz-riese-grosskonzern- ...
https://www.academics.de/ratgeber/kirche-als-arbeitgeber
https://de.wikipedia.org/wiki/R%C3%B6misch-katholische_Kirche
https://de.wikipedia.org/wiki/Verm%C3%B6gen_der_r%C3%B6misch-katholische ...
https://www.tagesspiegel.de/wirtschaft/das-kreuz-mit-den-milliarden-3524 ...
https://www.m-vg.de/mediafiles/Leseprobe/9783959720892.pdf
https://www.welt.de/wirtschaft/article156376890/So-reich-ist-die-katholi ...
Gruss,
Peter
Die Schwachbrüstigkeit der FritzBox ist also nicht das Problem
So pauschal und unreflektiert gesagt ist das Statement natürlich Unsinn und das weisst du als guter Netzwerker auch selber! Das deren onboard SoC kein Monster VPN Krypto Router ist wissen mittlerweile auch Laien. Dein Mikro Durchsatz von ein paar 64 Kilobit/s Voice Daten im VPN ist sicher auch kein Massstab für VPN Performance wenn man es fair betrachtet.Mit der Anpassung würde der MainMode auch mit dynamischen SelfHost-Adressen gehen?
Jein...du mischst hier jetzt 2 Dinge:- ""mode = phase1_mode_idp;" = schaltet generell die Fritzbox in den sichereren IPsec Main Mode. Bei dynamischen IP Adressen zwingt dich das aber zur Verwendung von FQDN Namen oder einer KeyID bei der ID.
- phase1ss = "LT8h/all/all/all"; = schaltet das IPsec Rekeying Intervall auf die generell üblichen 8 Stunden statt auf die sonst von AVM genutzen 60 Minuten. Diese Option gilt sowohl für den unsicheren Agressive als auch für den Main Mode!
Die Schwachbrüstigkeit der FritzBox scheint nicht die Ursache zu sein
Es liegt dann sehr wahrscheinlich daran das die Fritzbox bei Hostadressen keine /32er Hostmaske erwartet sondern die zum netz korrespondierende Netzwerkmaske. Mit der Angabe einer Hostadresse ist dann eindeutig das es ein Einzelgerät ist. Das wird zu 98% der Fehler sein. Ggf. ist dir das noch einen Test wert. War hier im Test auch so gesetzt. Bedenke aber das es performancetechnisch einen Unterschied macht ob eine ACL 3mal oder nur einmal durchlaufen werden muss. Die @Drohnald Lösung ist also netztechnisch gesehen immer besser wenn man die IP Adressierung der Endgeräte entsprechend intelligent nach Subnetzmasken Logik ausrichtet. Gut, bei nur 3 Geräten und gelegentlichem 64 kBit/s Voicetraffic ist das sicher wenig bis gar nicht relevant.
accesslist =
"permit ip 192.168.100.240 255.255.255.0 192.168.116.51 255.255.255.0",
"permit ip 192.168.100.240 255.255.255.0 192.168.116.52 255.255.255.0",
"permit ip 192.168.100.240 255.255.255.0 192.168.116.53 255.255.255.0";
Hm, aber beinhaltet 192.168.116.51 255.255.255.0 nicht das gesamte Netz 192.168.116.0/24?
Ja und nein.Hersteller behandeln das unterschiedlich. Die einen erzwingen auch eine /32er Hostmaske oder als Alias ein "host" in der ACL Definition, andere erwarten da die zum Netzwerk korrespondierende Maske weil die davor schon angegebene dedizierte Hostadresse (die ja keine Netzwerk Adresse ist) ausreicht um klar zu definieren das es eine Hostadresse ist.
Im Zweifel muss man da (leider) probieren wenn eine dedizierte Dokumentation des Herstellers wie das gehandhabt wird fehlt.
AVM verwendet auch schon keine inverse Maske wie es bei Accesslisten ja generell Usus ist! Consumer Produkt eben...! 🙄
Es erklärt übrigens auch nicht, warum trotz der 32er-Maske funktioniert.
Da hast du zweifelsohne recht.Es ist auch sehr gut möglich das dies ein Bug in der AVM Firmware ist...keine Frage!