Apr 19, 2024, updated at 10:19:09 (UTC)

1137

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:

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

Die FritzBox am Standort Pfarrei soll also nur bestimmte Geräte aus dem Netzwerk der Gemeinde reinlassen.

Am Standort Gemeinde lautet die AccessList einfach:

accesslist = "permit ip any 192.168.100.0 255.255.255.0";

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:

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-Key: 12937942092

Url: https://administrator.de/contentid/12937942092

Printed on: May 1, 2024 at 23:05 o'clock

22 Comments

Latest comment

Hi,

hast du Konfiguration vorher von der FB runtergeladen oder die alte editiert? Evtl. gab es eine Änderung bei den letzten Firmwareupdates.

Ansonsten kannst du testweise die Maske vergrößern:

192.168.116.48 255.255.255.248

Damit wären die IPs 49-54 als Clients erlaubt.

Gruß
Drohnald

Zitat von @Drohnald:

hast du Konfiguration vorher von der FB runtergeladen oder die alte editiert? Evtl. gab es eine Änderung bei den letzten Firmwareupdates.

Die alte editiert. Meines Wissens kann man importierte VPN-Konfigurationen hinterher weder exportieren noch bearbeiten.

Ansonsten kannst du testweise die Maske vergrößern:

Warum bin ich auf die Idee noch nicht gekommen? Das könnte ich tatsächlich mal probieren. Geht aber erst heute abend, wenn da Feierabend ist. Das wäre dann zumindest ein Würgaround. Schöner wäre natürlich eine Erklärung für dieses in meinen Augen unlogische Verhalten ...

Hallo,

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.

Schöner wäre natürlich eine Erklärung für dieses in meinen Augen unlogische Verhalten ...

Frage doch AVM

Gruss,
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.

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?

Ein Versuch hätte dich Schlauer werden lassen, oder gleich am Telefon gefragt wo du die schon am Telefon hattest.

Wer sagt, dass ich die am Telephon hatte?

Frage doch AVM

Ich zitiere mich selbst:

AVM weigert sich, dieses Problem zu behandeln - manuelle Bearbeitung der VPN-Konfigurationsdatei wird nicht supportet.

Aber gut ... ich kann mich nicht erinnern, von Dir jemals eine zielführende Antwort bekommen zu haben ...

Zitat von @aqui:

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 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.

Hm, zumindest mit den beiden "Altbestand"-Telephonen 116.51 und 116.52 hatte ich das gemacht. Und 116.53 ist zur Zeit eh nicht an.

* Arbeitest du im unsicheren Agressive Mode ("mode = phase1_mode_agressive;") oder im sicheren Main Mode (mode = phase1_mode_idp;) ?

Da ich keine festen IP-Adressen habe, muss ich im Aggressive Mode arbeiten.

* Führen deine FBs ein Keepalive aus (Initiator Seite!)

Wie ist "always_renew = ?;" gesetzt?

Tatsächlich auf No (wurde von "FritzFernzugang einrichten" automatisch so gesetzt, da wurde nirgends nach gefragt. Hat aber tatsächlich bisher nie Probleme gemacht, eigentlich sind die Verbindungen immer aktiv.

Da ich keine festen IP-Adressen habe, muss ich im Aggressive Mode arbeiten.

Das ist so nicht richtig. Im Main Mode geht das auch wenn du mit Key IDs oder mit den DDNS FQDNs arbeitest.

Zitat von @aqui:

Da ich keine festen IP-Adressen habe, muss ich im Aggressive Mode arbeiten.

Das ist so nicht richtig. Im Main Mode geht das auch wenn du mit Key IDs oder mit den DDNS FQDNs arbeitest.

ok ... aber "FritzFernzugang einrichten" fragt nicht viele Kenndaten ab. Wenn man einen DynDNS-Namen eingibt statt einer IP-Adresse, wird die Verbindung offenbar automatisch im Aggressive Mode eingerichtet. Und ich bin mit den Konfigurationsparametern nicht so vertraut, dass ich das fehlerfrei nachträglich umstellen könnte.

Hätte es denn irgendwelche Auswirkungen auf meine Fragestellung? Oder würde es die augenscheinliche Unlogik erklären, warum 116.52 bei der einen Konfiguration mit der TK-Anlage kommunizieren kann und und bei der anderen nicht, obwohl diese IP in beiden Konfigurationen unverändert zugelassen wird?

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)

Zitat von @aqui:

Nein, denn IT Profis, zu denen du ja auch gehörst, setzen diese Parameter alle immer manuell in einem Texteditor.

Naja, im Vergleich zu Dir bin ich alles andere als ein Profi. Ich bin tatsächlich ein "Klick-Admin". Was anderes habe ich nie gelernt, und um mir das selbst beizubringen, habe ich nicht die Zeit. Es ist in dem Bereich, in dem ich mich bewege, aber auch nicht gefragt.

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? Hm, warum streikt er da bei mir? Der Rest in Deiner Konfiguration ist "out of the box"? Also so wie "FritzFernzugang einrichten" es raushaut?

Achso, vielleicht sollte ich noch erwähnen, dass auf der Seite "Pfarrei" zehn VPNs zu mehreren Gemeinden zusammenlaufen. Ich kann mir zwar nicht vorstellen, dass die sich gegenseitig beeinflussen, aber vielleicht irre ich mich da auch. Natürlich haben die keine sich überschneidenden IP-Bereiche.

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

Bei beiden rennt die ACL erwartungsgemäß fehlerlos.

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,

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

Gruss,
Peter

Er Arbeitet schliesslich für das grösste und weitaus Reichstes Unternehmen unseres Planeten.

Jaja 🥱 Deine Vorurteile langweilen langsam ...

Hallo,

Zitat von @SarekHL:
Jaja 🥱 Deine Vorurteile langweilen langsam ...

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

Zitat von @Pjordorf:

Hallo,

Zitat von @SarekHL:
Jaja 🥱 Deine Vorurteile langweilen langsam ...

https://www.wiwo.de/unternehmen/dienstleister/finanz-riese-grosskonzern- ...

Nur weil es im Internet steht, muss es noch nicht richtig sein. Klar, die nackten Zahlen stimmen. Dennoch ist die Kirche kein "Konzern". Und fast überall besteht ein strukturelles Defizit. Wir schließen fast überall im Erzbistum Hamburg gerade Kirchen. Bestimmt nicht, weil wir im Geld schwimmen. Goldene Wasserhähne habe ich im Bischofshaus übrigens auch noch nicht gesehen ...

Zitat von @aqui:

Was erbrachte der Test mit der vom Kollegen @Drohnald empfohlenen Teilnetz Freigabe in der ACL??

Den konnte ich heute durchführen und auf diese Weise geht es. Die Schwachbrüstigkeit der FritzBox ist also nicht das Problem

Den anderen Test muss ich auf einen besseren Zeitpunkt verschieben, dafür war heute keine Zeit. Noch mal zum Verständnis:

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

Mit der Anpassung würde der MainMode auch mit dynamischen SelfHost-Adressen gehen? Oder hattest Du beim "Herumspielen" feste IP-Adressen?

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!

Zitat von @aqui:

Die Schwachbrüstigkeit der FritzBox ist also nicht das Problem

Ich wollte hier auch kein generelles Urteil abgeben. vielleicht sollte ich präziser formulieren: Die Schwachbrüstigkeit der FritzBox scheint nicht die Ursache zu sein, dass ein drittes Telephon über das VPN bzw. drei per AccessList zugelassene Geräte nicht funktioniere. Die die FritzBox hat ja keinen Leistungs-Booster bekommen, nur weil ich statt

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

jetzt

accesslist =permit ip 192.168.100.240 255.255.255.255 192.168.116.48 255.255.255.248";  

verwende.

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

Zitat von @aqui:

Die Schwachbrüstigkeit der FritzBox scheint nicht die Ursache zu sein

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? Das wäre ja einen Scheunentor-AccessList. Und wozu dann alle drei IP-Adressen einzeln angeben, wenn in der Maske eh alle drin sind?

Es erklärt übrigens auch nicht, warum

accesslist = 
"permit ip 192.168.100.240 255.255.255.0 192.168.116.51 255.255.255.255",    
"permit ip 192.168.100.240 255.255.255.0 192.168.116.52 255.255.255.255";  

trotz der 32er-Maske funktioniert.

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!

Zitat von @aqui:

Im Zweifel muss man da (leider) probieren wenn eine dedizierte Dokumentation des Herstellers wie das gehandhabt wird fehlt.

ok, dass werde ich das mal machen. Vermutlich aber erst nächste Woche.

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!

Weiter oben hattest du geschrieben

Hast Du da wirklich mein Regelwerk mit 32-Masken verwendet oder mit 24er? Ein Bug kann ja gut sein, aber dann sollte er sich zumindest unter gleichen Voraussetzungen auch gleich verhalten. Oder?

German solved Question VPN

Hotly discussed

End of availability for classic Teams clientDani - 2 Comments

Ubuntu 24.04 LTS Noble Numbat availableFrank

Developer diary: Release 6.1admtech